Push NES graphics to their limits ?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Push NES graphics to their limits ?

Post by Bregalad »

I'm wondering if doing pseudo-3D graphics on the NES in the same fashion Tactics Ogre did for the SNES would be abordable. I have pretty much trouble to understand how their work on the SNES, everything looks to be diagonal-based, allowing tiles to have an actual Z-index. Speaking about quality (but not quantity), Tactics Ogre looks much closer to a PSX game than a SNES game.
Any ideas ?
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I totally believe the NES can do games along the lines of Tactics Ogre (haven't played the game yet though, I've just seen some screenshots). The NES already has a few isometric titles such as Snake Rattle n Roll, Solstice...

I believe that the hardest part in building an isometric game for the NES is due to the low resolution of attributes (palettes applied to 16x16 pixel areas). When your view is 2D that is not much of a problem since most games are based on 16x16 pixel blocks anyway, but in isometric views, the level's blocks are not aligned to the screen's blocks, and a wall will often share the same 16x16 pixel area with a floor. If they use the same colors, it will look kinda dull, and if they use different colors the graphics can't be very "textured" as the little ammount of colors left for each are barely enough for a "plastic" kind of texture.

It surelly is easier on systems with multiple background layers, since one of them can hold the basic structure (floors and walls) and another one can hold the ornaments (as, I think, is done on Sonic 3D Blast for the megadrive) so you get a lot more colors.

Another issue is the number of avaliable tiles. Just as different types of things (walls and floors) share the same attribute blocks, they also share many tiles. So, you must have a tileset prepared for every combination of encounters.

Using MMC5 will surelly help with both problems. By using the ExAttribute mode we would have more attribute resolution and access to a bunch of tiles. It could never look as good as a SNES game, specially because the NES has only 4 BG palettes, in my opinion.

EDIT: Oh, of course, there are non-graphical issues too. Representing a 3D map can be very memory intensive. However, since most isometric games will not let you go under a floor (like in a tunnel, for example), the map can be a 2D array of heights, plus the types of walls and floors. Translating the 2D map to a 3D view could be a little tricky too, since we have little time to write to the screen.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Yeah, I was wondering it with both attributes and internal structure.
Tilesets could be a little problems, and the attributes will definitely be a bigger one. I think it is can be done by having some remniscent colors between BG palettes (black and another standardised color, such as grass green).
I didn't know about isometric NES games, I'll try them when I'll got time.
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

Snake Rattle n Roll does a pretty decent job producing an isometric view out of the NES, but the color limitations do show:
http://prezkennedy.org/modules/myalbum/photos/354.jpg
The megadrive got nice colorfull trees, while the NES got... uh... spiky... piramid... ah... things...!

Also, in the NES version the floor has the same color as the walls, when in the megadrive they are different, making it all prettier. And in the NES version you can see small color glitches here and there. This game looks nice, but I believe it is possible to do better.

I won't say anything about Solstice (wich looks very nice) because it seems to belong to another category... It is all set inside small rooms and is generally easier to design. I guess the focus here are the larger, outdoor maps... right?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Then there's Starcraft, which pretends to be isometric but isn't.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Yeah, I looked at those games. Solstice really suck, but it's graphics looks really nice, but they "cheated", because all rooms uses only one single palette.
Snakes'n'stuff looks graphically decent, but also the game itself suck (I don't understand your goal).
Scince it seems to be possible to have this style of graphics on the NES, my new question is now how. I think things are getting a LOT simpler if the height of a metatile can only be supperior or equal to the one just as its left and to the one just as its right. That would remove some dexterity from the game, but I thing that would simplyfy a lot the engine, making stuff like having a metatile half-hidden behind the one previous to it impossible.
Now how to process to maze it to the screen ? Having a normal 2D map plus a Z-index of all metatiles relative to the ones at its bottom and at its right would probalbly work pretty well. But mazing the wole stuff on the screen seems nerly impossible both at the tileset level and at the nametable level. And, how make a metatile looks higher than the other one ? Put some "cliff" between two seems the correct answer, but how to handle that in 2D nametables ? And I don't even mention attribute tables. Also, for a strategy game, it would be fear to fetch unit's graphics to BG when they doesn't moove, to avoid having too much sprites on the screen. This will make stuff harder, but I think the result would be worth it. I mentionned that just for cusiosity, but if I would be able to pass over all problems and do it, I'd be ready to code a game using that.
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

I don't think we should use the concept of "right" and "left". I think the map has to be stored as any 2D array would, and be converted to 3D at drawing time, like this:

Image

I propose that each position in the array holds the type and the height of that block. Then, we draw the map from back to front, begining at the top right corner (3, 0) of the 2D array, wich will be at the very top of the 3D view. then we move to the next block, at position (3, 1) in the 2D array, and update the drawing coordinates a bit to the right and a bit down and draw it as high as it is, overlaping the column behind it if needed. And we go through all the map like this.

The hard part will be the scrolling. Suppose you rendered the initial view, of the place where the level starts. Suppose there are some large columns behind the player, hiding anything back there (green thing is the player):

Image

Then the player goes UP, and we have to decide what to draw over there. Should we read the map from the wall back until we find the first thing that shows? That could be slow... You see, this is the hard part, drawing what's behind the wall without destroying it. Drawing the full view is easy, the hard part is to draw it little by little as has to be done on the NES.

Since the columns can have any height, there is no way to compute what should be where on the screen. We can compute where a height 0 block would be. maybe that is the way: When the screen goes up and we have to draw what's behind the wall, calculate what position in the map represents that space, supposing a height of 0. Then render from there to the wall, only if the columns are higher than the wall...

Well, still sounds too complex... I'll think about it for a while and maybe I'll have any ideas...
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I was saying to not allow any tile to have a Z index lower than the tile just below it or the tile at its left would correct the wall problem : If there is a wall, there would be no "behind" the wall, because the engine simply wouldn't allow it. Quite restrictive, but that would still give a 3rd dimention to the game and allow the player to battle trough mountain, even if there would not be "hidden parts" in the field. Anyway, "hidden parts" aren't profitable to the player (unless he can rotate the map), scince he cannot see the whole hole. To allow the player to rotate the map means have a 3d polygon-based engine, so wihtout any rotation hole can only be small.

However, a such wall could represent a cliff or a wall that marks the end of the map.
Useless, lumbering half-wits don't scare us.
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Post by WedNESday »

Don't forget using the PPU's VRAM ($0000-1FFF) gives you almost direct access to the video buffer. If you set the 960 tiles to 0, 1, 2, 3, 4 etc. in the pattern table then you have 2-bit colour access.
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

WedNESday wrote:Don't forget using the PPU's VRAM ($0000-1FFF) gives you almost direct access to the video buffer. If you set the 960 tiles to 0, 1, 2, 3, 4 etc. in the pattern table then you have 2-bit colour access.
The trouble is, the PPU can only address 256 background tiles - if you want to use more per screen, you need to either do carefully timed bank switches OR use the MMC5 (which generally also restricts you to CHR ROM).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well) and that, when scrooling, it would be WAY too slow to calculate each pixel in VRAM.
However, I think VRAM can calculate tiles given from two diagonal halves dinamicly for each stage, that *may* be usefull to gain tile spce. However, I'm not sure about how to handle tilesets with such graphics.
SNES games definitely have a single palette and priority control per tile, making a great advantages (another advantage is that palettes are 16-colors and no 4-colors, so multiple color scales are possible).
Holding attribute with an isometric view is definitly difficult (but not impossible). Assuming that each tile have to be square, but rotated, that make a metatile using either 4 tiles fully and 8 tiles half that are arround the full tiles (large) or 1 tile full and 4 tiles half with smaller gird.
Handling attribute with the large gird would be pretty comfortable. The 2x2 square that sure is the metatile is its proper color, and about the others, I think there would be a "default" color for tile border (I'm not sure it would work fine). With the smaller configuration, holding attribute pointlessly is impossible, but holding them grossierly is abordable.
Useless, lumbering half-wits don't scare us.
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Post by WedNESday »

Bregalad wrote:Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well)
You could overwrite the areas in VRAM to produce more tiles.
User avatar
Quietust
Posts: 1918
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

WedNESday wrote:
Bregalad wrote:Exept that the BG pattern table is limited to 256 tiles (assuming I want to use the other one as well)
You could overwrite the areas in VRAM to produce more tiles.
Even if you consume the Sprite tiles as well, you still get only 512 tiles, which is not enough for the entire screen. Remember, you can NOT update CHR RAM during rendering - the only thing you can do is bankswitch it.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Post by WedNESday »

Sure but 512 tiles could be enough. Especially if you only used part of the screen. Super Mario Bros. is a good example, the top and bottom of the screen is either blank of repeats the ground over again.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

hum...

Reducing the screen could help, but CHR RAM is not the way. If RAM is used, the game will run at, like, less than 1 frame per second! And we can't use the whole 512 tiles for the background 'cause we'd have nothing left for sprites! Unless you want to do an MSX kind of game you can't just draw the sprites to the BG.

I say MMC5 is the way to go. ExAttribute mode will give access to enough tiles, and improve attribute resolution, wich I think is the bigger problem here. 256 tiles would be enough for a fairly good isometric game though, if you keep the design somewhat simple (not many slopes, not many types of surfaces, etc).

EDIT: Actually, I think that the MSX had sprites... it was the Spectrum that didn't, right? And then it was just a mess because the "sprite" had to use the same color as the background or the color of one would spill to the other... anyway, it was just a mess, real ugly.
Post Reply