This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Wolf3d.nes

Wolf3d.nes
by on (#137308)
Several years ago I've downloaded what seemed to be an NES port of Wolfenstein 3D (name same as title of the thread). Graphics were really simplistic - textures were very minimalistic and very blocky, most of the time it was full colors though and it has only first one or two maps made (probably WIP rom), though all basic systems were in, aside of nazi's AI.

Has anyone this rom? Perhaps there is improved version around?
Re: Wolf3d.nes
by on (#137309)
This thing by Tokumaru? https://www.youtube.com/watch?v=po69zgqyFWM
Re: Wolf3d.nes
by on (#137310)
Or this earlier demo from mic: https://www.youtube.com/watch?v=tPlZI1OTSvY
Re: Wolf3d.nes
by on (#137312)
Neither have Nazis though, and mic's doesn't have textures... so maybe there's another NES raycaster out there? =)
Re: Wolf3d.nes
by on (#137323)
rainwarrior wrote:

I think it used this engine, but it was improved to have shooting, etc. Maybe it was advanced hack of it, who knows? Anyway, seems like game I played except different textures and no real gameplay so...
Re: Wolf3d.nes
by on (#137324)
Mic's demo is glitchy and didn't work on my Everdrive. Tokumaru's demo works though.
Re: Wolf3d.nes
by on (#137325)
Pokun wrote:
Mic's demo is glitchy and didn't work on my Everdrive. Tokumaru's demo works though.

I think Mic's is PAL only, so it's expected to glitch in NTSC consoles.
Re: Wolf3d.nes
by on (#137330)
I see.
Re: Wolf3d.nes
by on (#137350)
darkhog wrote:
I think it used this engine, but it was improved to have shooting, etc. Maybe it was advanced hack of it, who knows?

I haven't improved my engine in any way since I released the demo, and I'm not aware of anyone else doing it either (nobody talked to me and I don't think I released the source code). If such a version exists I'd like to see it though.

A while ago I did think of a couple ways to make the ray casting and the texturing a little faster (I'd basically reorganize the level maps so they're easier to read and turn some of the texturing math into more look-up tables), and since those steps are performed many times every frame that improvement should buy me enough CPU time to consider more features without having to sacrifice the frame rate much.

What I want most is to add objects to the maze. I planned all the math for that already, but the low sprite limit of the NES will make drawing objects/enemies a real challenge. I can't use the background because all the possible texture, color and height combinations used up nearly all the tiles, so I can't possibly add another component to that mix. Enemies can probably be programmed to run away from you, so they never get too big, and static items could be limited to narrow objects. I'm confident that sprites can work, but I haven't thought of the perfect way to use them yet, so I don't have the motivation to go forward with this.

Once objects are in, shooting would be extremely simple to implement. Then the only think missing for a Wolfenstein 3D lookalike is animated doors, which aren't exactly hard, but do interfere with the way rays are cast and distances are calculated.

Quote:
Anyway, seems like game I played except different textures and no real gameplay so...

The texture (yes, it's only one and it's stupid) in the YouTube video is outdated, the demo has better textures and dithering.
Re: Wolf3d.nes
by on (#137360)
tokumaru wrote:
What I want most is to add objects to the maze. I planned all the math for that already, but the low sprite limit of the NES will make drawing objects/enemies a real challenge. I can't use the background because all the possible texture, color and height combinations used up nearly all the tiles, so I can't possibly add another component to that mix. Enemies can probably be programmed to run away from you, so they never get too big, and static items could be limited to narrow objects. I'm confident that sprites can work, but I haven't thought of the perfect way to use them yet, so I don't have the motivation to go forward with this.

Gonna ditch the Wolfstein 3D part here and assume this is only raycasting.

The first thing that comes to my mind is to make everything around a single 4 color palette (tough, but doable - although I suppose the top and bottom half could use two different palettes, which again would require clever art but would be doable). Also you'd be restricted to only 4 "pixels" per tile. That'd look blocky as hell (but then again so is the existing demo, so maybe this is OK?). Drawing objects at a decent speed will be the biggest blocker, though.

Alternatively, ditch sprites altogether and make all interactive elements actually walls. This will probably require some really specific gameplay made just around that limitation, but it may be an alternative if sprites don't work (and as a bonus, walls are already proven to actually work, the only modification needed to the engine is to make the map modifiable).

EDIT: omg 2⁹th post =P
Re: Wolf3d.nes
by on (#137387)
Sik wrote:
Gonna ditch the Wolfstein 3D part here and assume this is only raycasting.

I only used textures and colors similar to those in Wolfenstain 3D because that's what got me into raycasters in the first place, but I'd never attempt to actually port it to the NES.

Quote:
The first thing that comes to my mind is to make everything around a single 4 color palette (tough, but doable - although I suppose the top and bottom half could use two different palettes, which again would require clever art but would be doable).

I can actually have 5 colors: 3 wall colors, ceiling/wall, and black for shading everything. The trick to have 3 wall colors is to use 3 palettes, each with a different combination of 2 wall colors, while the remaining 2 colors (floor/ceiling and black) are constant, and pick the appropriate palette for each pair of wall slices depending on the colors of the textures they use. The palettes are calculated dynamically, so I have to design the levels in a way that no more than 3 wall colors are visible at once, but other than that I can use as many colors as I want in the level.

With scanline IRQs it should be possible to change one color halfway down the screen and have different floor and ceiling colors. with the MMC5 it would be possible to have 6 different wall colors at once, using the same 3 palettes, but I don't like designing programs around that mapper because even today the only way to use it in a cartridge is to use original nintendo donors, because it hasn't been fully implemented in flash carts and hasn't been replicated for use in new boards.

Quote:
Also you'd be restricted to only 4 "pixels" per tile. That'd look blocky as hell (but then again so is the existing demo, so maybe this is OK?).

It's already 4 pixels per tile, only the pixels are not square (i.e. each tile is 1x4 pixels, not 2x2). I tested both ways before making the NES version, and the reduced vertical resolution made it really hard to judge distances. Having to cast less rays also influenced this decision, and now I'm sure that it wouldn't be nearly as fast if I had to shoot twice as many rays.

For objects, 2x2 pixels in a tile would probably work better. In this case, the depth perception wouldn't be affected because the sprites can be pushed closer together to simulate scaling.

Quote:
Drawing objects at a decent speed will be the biggest blocker, though.

Most things in my engine use look-up tables, and I don't think objects would be an exception. I would probably pre-calculate some key sizes, and interpolate (by compressing the sprites towards the center) the rest. This means that the drawing process itself wouldn't be much different from normal meta-sprites. Calculating their positions and size will require some math... A division to find the angle and another to find the distance, but I already do a lot of math for the wall stripes and there are 28 of them, so 2 or 3 objects in a room probably won't be such a big problem.

Quote:
Alternatively, ditch sprites altogether and make all interactive elements actually walls. This will probably require some really specific gameplay made just around that limitation, but it may be an alternative if sprites don't work (and as a bonus, walls are already proven to actually work, the only modification needed to the engine is to make the map modifiable).

I actually planned on using sprites to add more detail to some walls, usually closer to the top and bottom, so that they're out of view when players get too close to the wall. This could be used for blinking lines, switches, things like that. I'd use a similar algorithm to the one that scales walls, but rendering sprites instead.
Re: Wolf3d.nes
by on (#137389)
tokumaru wrote:
I can actually have 5 colors: 3 wall colors, ceiling/wall, and black for shading everything. The trick to have 3 wall colors is to use 3 palettes, each with a different combination of 2 wall colors, while the remaining 2 colors (floor/ceiling and black) are constant, and pick the appropriate palette for each pair of wall slices depending on the colors of the textures they use. The palettes are calculated dynamically, so I have to design the levels in a way that no more than 3 wall colors are visible at once, but other than that I can use as many colors as I want in the level.

The problem is that it makes the assumption that you won't cross a palette boundary. You can easily do this for walls, but once sprites are in the mix you can't easily predict it anymore, especially not if they move around.

tokumaru wrote:
Most things in my engine use look-up tables, and I don't think objects would be an exception. I would probably pre-calculate some key sizes, and interpolate (by compressing the sprites towards the center) the rest. This means that the drawing process itself wouldn't be much different from normal meta-sprites. Calculating their positions and size will require some math... A division to find the angle and another to find the distance, but I already do a lot of math for the wall stripes and there are 28 of them, so 2 or 3 objects in a room probably won't be such a big problem.

That stuff isn't the problem, in fact it isn't much worse than for walls. The real problem is that sprites can have transparent parts, and ensuring they don't overwrite the walls is the biggest performance issue (you can't just plot pixels like you do with walls). You need to check for transparent pixels, then read back from the already rendered map and override the pixels that are not transparent, then write back. This is where most of the time will go.
Re: Wolf3d.nes
by on (#137393)
Sik wrote:
The problem is that it makes the assumption that you won't cross a palette boundary. You can easily do this for walls, but once sprites are in the mix you can't easily predict it anymore, especially not if they move around.

Yeah, this wouldn't work well for sprites, specially considering that a stripe will often contain the object and the wall that's behind him, so there would be a lot of attribute clash.

tokumaru wrote:
That stuff isn't the problem, in fact it isn't much worse than for walls. The real problem is that sprites can have transparent parts, and ensuring they don't overwrite the walls is the biggest performance issue (you can't just plot pixels like you do with walls). You need to check for transparent pixels, then read back from the already rendered map and override the pixels that are not transparent, then write back. This is where most of the time will go.

That's why I'm placing my bets on sprites for drawing objects. Blending walls with objects would be a nightmare. With sprites, transparency is free, and the only clipping necessary will consist in comparing the object distance to the distances of each wall stripe it overlaps, in order to decide whether to draw the sprites over that strip at all.

I was considering designing sprites similar to the ones found in this page, very low resolution and using very few colors (these specifically appear to fit my requirements, but there are many other good examples). To draw them I would probably store as many 1bpp patterns as possible in the pattern tables, repeated 3 times (each using one of the non-transparent color indices), while also counting on flipping to reduce the tile count. I have to do the math in order to see how many pixels I could cram in each tile (or 2 tiles, if I use 8x16 sprites), but having 9 colors to draw objects should compensate the monochrome feel of the level a bit.

The important thing when using sprites is to make sure the player can't get to close to wide objects, because I can only cover about 28% of the viewport with sprites.