Poll: How would you prefer a first-person shooter on the NES to look like?

A place for your artistic side. Discuss techniques and tools for pixel art on the NES, GBC, or similar platforms.

Moderator: Moderators

What kind of resolution would you prefer in an NES first-person shooter?

Lower resolution, occupying more screen space
5
24%
Higher resolution, occupying less screen space, only if the frame rate doesn't drop
10
48%
Higher resolution, occupying less screen space, even if the frame rate drops a bit
5
24%
Higher resolution, occupying less screen space, even if the frame rate drops a lot
1
5%
 
Total votes: 21

User avatar
tokumaru
Posts: 11644
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Poll: How would you prefer a first-person shooter on the NES to look like?

Post by tokumaru » Tue May 05, 2020 1:26 pm

Bananmos wrote:
Tue May 05, 2020 11:21 am
Great to hear you're working on the raycaster again! I think it was such a cool project and would love to back a Kickstarter for the first fun'n'playable NES FPS. :)
Thanks! Let's keep our fingers crossed!
I think in cases like these, faking stuff is always better than brute-forcing it.
Yeah, I totally agree. I'm already faking quite a few things!
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.
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.
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 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.
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.
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.
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.
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.

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.
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.
That's a good point.
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'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!
I'll try to find some time to clean up the code and do some more experiments in the next week or so.
I'd love to see what you have on sprite scaling.

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!

Pokun
Posts: 1431
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: Poll: How would you prefer a first-person shooter on the NES to look like?

Post by Pokun » Thu May 14, 2020 5:10 am

Although I would probably need to test a demo to make a good judgement, I spontaneously think that performance is important in this case, no matter if it's an action game or a dungeon crawler. More so in an action game, but also in a dungeon crawler it's important to not loose orientation which is easy to do if the 3D maze movement isn't smooth enough. Resolution should probably not be too low though, and like some other here said, I don't really mind a smaller screen with a frame either. For these reasons I voted the second option "Higher resolution, occupying less screen space, only if the frame rate doesn't drop".

All that said, like Bregalad I'm not really a fan of FPS games (Goldeneye 007 is a notable exception) and I hardly played neither Wolfenstein 3D nor Doom back in the day. I was ever only really interested in them for their technical aspects rather than their aesthetics which never appealed to me. I'm still looking forward to see how this project turns out though.

dink
Posts: 32
Joined: Sun Jan 12, 2020 8:42 pm

Re: Poll: How would you prefer a first-person shooter on the NES to look like?

Post by dink » Thu May 14, 2020 5:28 am

[x] Like Contra!!

User avatar
za909
Posts: 206
Joined: Fri Jan 24, 2014 9:05 am
Location: Hungary

Re: Poll: How would you prefer a first-person shooter on the NES to look like?

Post by za909 » Fri May 15, 2020 1:08 am

I wonder if lighting like this is possible on the NES. It really adds a lot to the mood of the level, like you are in a scary, enclosed space: https://m.youtube.com/watch?v=ieCqOjwh3fA

User avatar
tokumaru
Posts: 11644
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Poll: How would you prefer a first-person shooter on the NES to look like?

Post by tokumaru » Fri May 15, 2020 1:45 am

za909 wrote:
Fri May 15, 2020 1:08 am
I wonder if lighting like this is possible on the NES.
I guess it should be possible to do something similar to what Doom does: https://doomwiki.org/wiki/COLORMAP

Apparently the Doom engine uses several lookup tables, each simulating a different brightness level, but still only using a total of 256 colors.

I, however, have only 16 colors, which are actually dithered patterns built from only 4 colors, making it that much harder to create convincing gradients into darkness. This would also lock the engine to a specific set of 4 colors, while with the setup I'm currently using I am able to change the palette as the player moves through the level.

Here's an interesting raycasting engine for the Amstrad CPC that implements lighting effects: https://youtu.be/TbUWK461Vkk

It's kinda cool, but also a bit disorienting. I'm not sure this is the best route to take when the number of colors we have is so limited.

Post Reply