Thanks! Let's keep our fingers crossed!
Yeah, I totally agree. I'm already faking quite a few things!I think in cases like these, faking stuff is always better than brute-forcing it.
Yeah, the symmetry trick isn't nearly as useful on the NES as it is on the SNES and on the Genesis. Plus, I am trying to go a little beyond what Wolfenstein 3D did, by adding some vertical movement and walls of variable height.The key thing is cheating by using vertical symmtry to only render half the screen. Of course, vertical flipping of the background isn't totally free on a system like the NES which lacks BG tile flipping, and the feasibility heavily depends on whether you'll use an IRQ-capable cart or not.
I guess you convinced me to give this a try, but I think that the flickering at the sides will be too distracting. To avoid the flickering and do this properly I'd have to render extra columns at the sides of the screen and also figure out a way to mask them until they need to be scrolled in, so unfortunately this trick isn't as trivial to implement as it sounds. I also worry about the disparity in smoothness when turning vs. walking forwards and backwards.Untested, but as I've mentioned before, I think using the scroll registers to fake horizontal (and even partial vertical) movement has some great potential to create a smoother experience.
I see. I will give this a try without bothering about the sides at first, and if the results are promising, I'll see if there are enough resources to do it the proper way.When you move forwards in an FPS the low resolution / FPS is usually not too distracting in my experience. It's when you try to turn / strafe that the chunkiness and low framerate become glaringly obvious.
Interesting, I also remembered tepple's sprite scaling experiments when looking for a solution to my problem, but ended up not looking into it after all. I did think of solutions that would result in those dreaded "zombie pixels" you talked about, and couldn't find a satisfactory solution.Finally, as for sprite objects and clipping, just this week I have been playing around with making a sprite scaler based on Tepples lookup table concept, but using unrolled loops for the vertical scaling in place of the DDA algorithm Tepples used. I've also chosen to overlap sprites vertically as well as horizontally, which greatly simplifies the loop unrolling problem - albeit at the expense of sprite assignment and OAM cycling being a lot more difficult, in order to make sure that blank "zombie pixels" in sprites that not supposed to be visible any more never get assigned to horizontally higher priority sprites than those that have "live pixels" on the same scanline.
Currently, my (untested) solution for drawing sprites is to use pre-rendered tiles containing all 256 patterns of 2x4 soft-pixels of a single color + transparency. With sprite mirroring, all 256 patterns fit in only 76 tiles, so I can have 3 separate sets, one for each of colors 1, 2 and 3, occupying 228 tiles (actually 226, I don't need repeats of the transparent tile). This is cool because it gives objects access to the whole 12 colors of the sprites, they're not restricted to a single set of 3 colors, but the fact that each color needs to be rendered as a different set of sprites means that the graphics have to be carefully designed to avoid excessive overlap. Pre-scaling the sprites could help with optimizing the sprite arrangement and reducing overlap.
That's a good point.This also made me think that only a subset of the columns / rows actually need updating each frame, and that temporal coherence could be taken advantage of in order to update only a subset of the scaled sprites data each frame.
I'm not sure I follow the whole thing about the "free" clipping. BTW, the horizontal clipping is not much of an issue, you can just compare the distance to the wall and the distance to the object, and not draw that column of the object if the wall is closer. The problem is that when you have varying floor/ceiling heights, objects need to be clipped vertically, and that's a whole other can of worms!As long as you don't mind a *lot* of wasted PRG, you can actually get the clipping against 3d walls "for free" by combining the lookup table for the horizontal scaling with the table for horizontal clipping, and just point it at another 256 page. The lookup table and your scrambled tile data should still fit in a 16kB bank, which is all you really care about if it's a visual demo more than a size coding competition.
I'd love to see what you have on sprite scaling.I'll try to find some time to clean up the code and do some more experiments in the next week or so.
I have the feeling that doing sprites "properly" will be way to slow for an FPS on the NES. Like almost everything else in this engine, this will have to be accomplished via a few tricks and a ton of lookup tables!