How does Chocolate Doom load textures into SDL?

[BBQgiraffe]

Sorry if this sounds like a stupid question, I'm semi-decent with C/C++ and am poking around the Chocolate Doom source code to learn more about game engines, and I just can't figure out how it loads images into SDL from the WAD，I know how to use some SDL stuff but I'm used to having SDL_Image do all the work for me, does anyone know how it loads files from WAD?

 

 

[Linguica]

It doesn't load normal images. Doom WAD graphics are in a custom format https://doomwiki.org/wiki/Picture_format that get loaded into memory and drawn onto a framebuffer. SDL is mainly used as a shim to get all the cross platform audiovisual stuff necessary.

[chungy]

It'd be a good idea to look through this book: http://fabiensanglard.net/gebbdoom/

 

Chocolate Doom doesn't change the engine enough to make any details differ; it mostly just implements SDL hooks in i_video. SDL gets full 320x200 frame renders 35 times a second, and then it's SDL's job to put that on an OpenGL surface and scale it.

[BBQgiraffe]

On 9/13/2019 at 2:34 PM, chungy said:

It'd be a good idea to look through this book: http://fabiensanglard.net/gebbdoom/

 

Chocolate Doom doesn't change the engine enough to make any details differ; it mostly just implements SDL hooks in i_video. SDL gets full 320x200 frame renders 35 times a second, and then it's SDL's job to put that on an OpenGL surface and scale it.

oh so SDL itself doesn't do the BSP math or sprite blitting, it just renders the frame Doom generates?

[chungy]

Exactly, yes.

[Gez]

And it's the same deal for all other ports. Even those that do change the renderer completely (Eternity's Cardboard, the OpenGL renderers in GLBoom+, GZDoom or Doomsday, etc.) do not use SDL (when they're using SDL in the first place) for generating the image, only for displaying it on a surface.

 

The Doom engine is quite particular about how things look, so it's the only way you can render Doom levels without them looking wrong.