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.