Bregalad wrote:
Good luck having code that is even remotely maitainable...
Well, it's just the rendering code, so I don't expect it to change at all once it's working and generating proper results.
Quote:
If you're already loosing a lot of times to render the screen, you don't want to loose any CPU time waiting for synchronization, even if it is just a little.
The strategy I plan on using is basically to unroll the tasks and do as much as possible in 4 or 8 scanlines, and then decide whether to continue in the same block or jump to another one. For example, there'll be a block of code that just extends the ray and checks the map for collisions with walls, and this will be used over and over until a wall is found. If there's enough time to test, say, 6 wall boundaries between scroll splits, I'll have to include wait loops for when a wall is found before the 6 checks, so that the block still takes the same amount of time to finish. That could add up to a lot of lost CPU time, unfortunately.
Quote:
but you want to make sure your rendering algorithm is set is stone and is not going to be changed once you start coding this... because maintaining it will be a complete nightmare.
Not much worse than an Atari 2600 kernel, I suppose.
Quote:
You could also aim at constant-time rendering, so that the framerate even if slow will be constant. I think it's a good idea. At least you'll be really pushing the system to its limit.
With the different amounts of distances rays have to travel, the different heights of the walls, and the varying amounts of enemies and their proximity to the player, I think that'd be very hard, and wasteful. I have to believe that these things are going to compensate for each other (e.g. a longer ray that takes more time to cast will result in a smaller wall that takes less time to texture), and design the levels in ways that avoid too much heavy processing in the same spot.
Quote:
If you needed to develop a new mapper anyway, you might as well have the mapper doing the ray-casting itself, so I agree it's a bad approach.
That doesn't sound particularly fun to me. I want to see the NES do all the work, not just have the PPU pump out the pixels.