6 ms·

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

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.

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.