The game (demo? ;-)) is in screen 5.
Precomputing sprites at different sizes is ok, but they have to be clipped too, in order to be partially visible behind corners.
Ideally each enemy should have at least 4 (8?) directions, with some frames of animation.
the use of HW sprite implies this limitation:
- one monocrome enemy at time on teh screen composed by 4 x 8 sprites == 64x128 pixel wide
- complex clipping due to the interaction with raycasting (maybe some code for screen 2 sw sprites - ZX like, could be reused here).
SW sprites
- are simpler to be integrated in the raycasting engine
- you can have more than one enemy
- they are damn slow (!)
The game (demo? ;-)) is in screen 5.
Precomputing sprites at different sizes is ok, but they have to be clipped too, in order to be partially visible behind corners.
Ideally each enemy should have at least 4 (8?) directions, with some frames of animation.
the use of HW sprite implies this limitation:
- one monocrome enemy at time on teh screen composed by 4 x 8 sprites == 64x128 pixel wide
- complex clipping due to the interaction with raycasting (maybe some code for screen 2 sw sprites - ZX like, could be reused here).
SW sprites
- are simpler to be integrated in the raycasting engine
- you can have more than one enemy
- they are damn slow (!)
I'd stay away from the HW sprite, the question of clipping alone and the color constraints make it more trouble than it's worth.
- For the sw sprite and clipping... it's easy (I think), you just copy the horizontal size you need an nothing more... It may actually go faster once they are "clipped" since the copy is smaller.
- You don't need to have the sw sprites in every single sizes.... just approximate and it will be good enough... perhaps 10 stages of zoom should do.
- Since you rebuild the entire background every time, you have the advantage of not having to use double buffering for the sprites and restore the background etc.... the entire rebuilding of the 3d background is already done anyway.
- You probably need to use logical copy for those sw sprites which are a bit slower.
No, but it is due to some tricks:
- the code draws only 2xN color boxes
- the code draws only differences between frames
This latter detail is possible only thanks to the fact that walls are flat
Anyway, adding RLE encoded textures on some walls should work as well without drastic losses in the frame rate
