4 ms·

I built a 2.5D engine back in about 2006 with SDL and C on OSX. It worked (eventually) and taught me a lot. It wasn't particularly clever but had collision dete

by cjsuk 9y ago

I built a 2.5D engine back in about 2006 with SDL and C on OSX. It worked (eventually) and taught me a lot. It wasn't particularly clever but had collision detection and textures, the latter stolen from Wolf 3D of course. It's a valuable experience as a programmer. What I never managed to understand was how they managed to get the performance they did out of the hardware. Mine crawled at a miserable 8fps at 640x480 on a 2GHz Core 2 Duo iMac. Performance is where the magic in this really is! Can't wait for the book.

abritinthebay 9y ago
They didn’t use SDL for a start ;) SDL is great but it’s not in the same league as the hand-rolled & optimized code they used. Different goals. Great job tho! That’s not an easy project!
- chrisseaton 9y ago
  With VGA you write directly to video memory don't you? The only extra indirection SDL adds is that you write directly to system memory instead, and then SDL copies that to video memory for you when you swap buffers. Like the person you're replying to, I've also never seen how copying 640x480 bytes from system memory to video memory can introduce such a bottleneck. What's the bandwidth between the two? 10 Gbps or something? There must be more to it than SDL overheads.
  - AstralStorm 9y ago
    Indeed, perhaps SDL graphics primitives other than surfaces were used. These are notoriously slow implementations. Or the code was not in C/C++ and messed up the garbage collector or had huge overhead memory allocating.
    - cjsuk 9y ago
      I can't remember how exactly I did it but the entire thing was written to a surface in a massive for loop per-pixel (C was used) and then flipped.
  - gurkendoktor 9y ago
    It depends on how you use the SDL as well. In ca. 2000, I've written a game using DirectDraw (which I think the high-level functions in SDL 1.x also used?), and it worked quite well on ~400 MHz PCs. Then graphics drivers stopped hardware-accelerating 2D graphics(?), and the same game turned into a CPU hog that performed much worse even on much more recent hardware. This thread is vaguely about the same issue: https://www.reddit.com/r/gamedev/comments/1rpwig/sdl_blit_is_slow/cdpucyj/ https://www.reddit.com/r/gamedev/comments/1rpwig/sdl_blit_is...
  - cjsuk 9y ago
    In this case I suspect it was inefficient algorithms by me. To be fair it went like lightning (400fps) until I added textures as it was just drawing vertical lines before then.
- jackmott 9y ago
  SDL used as normal in this conext just gets you a window and then gets out of your way.
psyc 9y ago
Instead of SDL on a protected windowing OS, hand-optimized assembly with direct hw access.
- jackmott 9y ago
  sdl doesn't impart any per frame penalty i don't think, and the os not much. 640x480 is also way more pixels than 320x200

by cjsuk 9y ago

abritinthebay 9y ago

They didn’t use SDL for a start ;) SDL is great but it’s not in the same league as the hand-rolled & optimized code they used. Different goals. Great job tho! That’s not an easy project!

chrisseaton 9y ago
With VGA you write directly to video memory don't you? The only extra indirection SDL adds is that you write directly to system memory instead, and then SDL copies that to video memory for you when you swap buffers. Like the person you're replying to, I've also never seen how copying 640x480 bytes from system memory to video memory can introduce such a bottleneck. What's the bandwidth between the two? 10 Gbps or something? There must be more to it than SDL overheads.
- AstralStorm 9y ago
  Indeed, perhaps SDL graphics primitives other than surfaces were used. These are notoriously slow implementations. Or the code was not in C/C++ and messed up the garbage collector or had huge overhead memory allocating.
  - cjsuk 9y ago
    I can't remember how exactly I did it but the entire thing was written to a surface in a massive for loop per-pixel (C was used) and then flipped.
- gurkendoktor 9y ago
  It depends on how you use the SDL as well. In ca. 2000, I've written a game using DirectDraw (which I think the high-level functions in SDL 1.x also used?), and it worked quite well on ~400 MHz PCs. Then graphics drivers stopped hardware-accelerating 2D graphics(?), and the same game turned into a CPU hog that performed much worse even on much more recent hardware. This thread is vaguely about the same issue: https://www.reddit.com/r/gamedev/comments/1rpwig/sdl_blit_is_slow/cdpucyj/ https://www.reddit.com/r/gamedev/comments/1rpwig/sdl_blit_is...
- cjsuk 9y ago
  In this case I suspect it was inefficient algorithms by me. To be fair it went like lightning (400fps) until I added textures as it was just drawing vertical lines before then.
jackmott 9y ago
SDL used as normal in this conext just gets you a window and then gets out of your way.

psyc 9y ago

Instead of SDL on a protected windowing OS, hand-optimized assembly with direct hw access.

jackmott 9y ago
sdl doesn't impart any per frame penalty i don't think, and the os not much. 640x480 is also way more pixels than 320x200