3 ms·

Yes, I was thinking the same thing, but then I became glad somebody was going this direction. After all these years, it may be nearly impossible to eke out much

by b6 8y ago

Yes, I was thinking the same thing, but then I became glad somebody was going this direction. After all these years, it may be nearly impossible to eke out much more in the way of realtime effects. So I think this is just a sign that the creativity is spreading into whatever interesting areas remain.

bitwize 8y ago
Seeing things like this puts a big smile on my face because I can take satisfaction that I'm on the right track and not crazy with some of my projects. I'm actually using newskool-like effects in a game I'm writing. I'm writing it directly against X11, exactly as I would have back in 1996 when I discovered X. No SDL or other abstraction layers like that -- not even XShm. The thing about X11 that not a lot of people realize today is that it is fast. You can easily generate a quite complex game display -- at 60 fps -- just by loading sprite images into pixmaps and sending XCopyArea draw calls (with appropriate mask pixmaps) for each frame. I found that this was possible in the 90s on hardware that is quite weak by today's standards. What you can't do is easily and quickly draw transformed (e.g., scaled, rotated, mirrored, or palette-swapped) images to the display. But! You can precompute such images and send them over as pixmaps, for example when the level loads, and then use XCopyArea as usual, and that'll get you pretty far. I was inspired by two similar techniques from old-school game development: * the use of precomputed scaled versions of a platform to make a pseudo 3D effect in Sonic 3D Blast on the Sega Genesis * Smoothly moving sprites in Commander Keen. Because of the EGA's planar memory layout, it's potentially very slow to draw a sprite at arbitrary pixel locations. Most developers punted, and so Duke Nukem in his very first game moves horizontally in jerky 8-pixel jumps. Carmack's solution to the problem of smooth scrolling in Keen was to use EGA register trickery. His solution to the problem of smooth sprites was simply to cheat like mad and precompute four sprite images for Keen and the other moving sprites in the game, one image for every two pixels of the sprite's x position mod 8.

by b6 8y ago

bitwize 8y ago

Seeing things like this puts a big smile on my face because I can take satisfaction that I'm on the right track and not crazy with some of my projects. I'm actually using newskool-like effects in a game I'm writing. I'm writing it directly against X11, exactly as I would have back in 1996 when I discovered X. No SDL or other abstraction layers like that -- not even XShm. The thing about X11 that not a lot of people realize today is that it is fast. You can easily generate a quite complex game display -- at 60 fps -- just by loading sprite images into pixmaps and sending XCopyArea draw calls (with appropriate mask pixmaps) for each frame. I found that this was possible in the 90s on hardware that is quite weak by today's standards. What you can't do is easily and quickly draw transformed (e.g., scaled, rotated, mirrored, or palette-swapped) images to the display. But! You can precompute such images and send them over as pixmaps, for example when the level loads, and then use XCopyArea as usual, and that'll get you pretty far. I was inspired by two similar techniques from old-school game development: * the use of precomputed scaled versions of a platform to make a pseudo 3D effect in Sonic 3D Blast on the Sega Genesis * Smoothly moving sprites in Commander Keen. Because of the EGA's planar memory layout, it's potentially very slow to draw a sprite at arbitrary pixel locations. Most developers punted, and so Duke Nukem in his very first game moves horizontally in jerky 8-pixel jumps. Carmack's solution to the problem of smooth scrolling in Keen was to use EGA register trickery. His solution to the problem of smooth sprites was simply to cheat like mad and precompute four sprite images for Keen and the other moving sprites in the game, one image for every two pixels of the sprite's x position mod 8.