Is there any NES game which uses more than one tile layer? I am studying a game made for another system which renders static screens as Metroid does, by rendering blocks which are made of tiles. However, this is an isometric game and some tiles are drawn over others (for example, we draw a block that is the floor of the room, and then draw a pillar. Some of the pillar's tiles will overdraw the floor ones, and you have to combine both.
I wondered if something like this could be made for the SNES... I was thinking on using CHR-RAM, and 'rendering' the scene there, but I think that will be prohibitive.
Hope I'm explaining well...
Have you checked out Solstice?
A lot of games simulate having two layers in various ways. I'll omit examples that are just a horizontal parallax split, since this is a relatively common/easy technique.
* Mega Man 2's opening cinematic does some vertical parallax using sprites.
* Punch Out's jogging/bicycle cinematic does a little bit of horizontal parallax layering with sprites (the railing).
* Battletoads level 2 does vertical parallax by using CHR-RAM to scroll tiles at the edges of the screen.
* Solsice uses CHR-RAM to occlude the character if he walks behind parts of the environment.
Well, if simulated parallax counts, you can't leave out Metal Storm or Crisis Force
...or
Sword Master! That games has multiple scrolling planes every level.
Since you specifically mentioned isometric games, I suppose you're not looking for scrolling layers, you just want to place tiles in front of other tiles. The NES has only one background plane and there's no way to add another one that doesn't require modifications to the console itself (this would involve putting 2 PPUs in the same NES), so everything that appears to have more than one layer is simulated. Some examples of isometric NES games are: Solstice, Snake Rattle n Roll, Marble Madness, The Immortal, R.C. Pro Am II, among others. Take a look at them and use an emulator with a pattern table viewer to study how each one draws their levels.
Ah yeah, Sword Master has a really simple and elegant technique for it. It uses MMC3, which has 1k CHR banking, and then just has 32 1k CHR banks dedicated to 4 32x32 scrolling tile animations. Really simple to set up and code for, no fancy timing or anything, all you need is a mapper with 1k CHR banking and 32k of CHR ROM space to spare! (Batman RotJ does a similar thing for some scrolling clouds.)
Probably the most complicated techniques are the ones that use CHR-RAM, since they tend to require very optimized NMI routines to get that data across in vblank (e.g. Battletoads puts CHR write code in RAM then modifies its immediate values), or something like Solstice where it's doing a lot of bit packing to build CHR tiles on the fly.
Dwedit wrote:
Have you checked out Solstice?
Just thought of it moments after I posted!
I don't want to dive into parallaxing, as it would be much more difficult... I'm more, as Dwedit pointed out, in the line of isometric, static backgrounds, but as iso tiles are not square, parts of foreground tiles will unavoidable be mixed with the floors and things like that.
This is the game. It was developed in Spain for the Amstrad CPC, a british 8-bit microcomputer:
If you examine it closely, parts of the image are meant to occlude the characters but ALSO have to be mixed with the floor when drawing the screen.
Well, you don't really need layers to occlude the characters. You just need to occlude characters graphics with background graphics. So you could prepare an occluded version of a sprite for current frame in software and send it to the VRAM.
Solstice used CHR RAM to cut background tiles out from in front of the hero sprite. This can get CPU intensive if a lot of sprites are moving, but you don't absolutely need 60 fps. A lot of these old isometric games for 8-bit micros ran at 5-8 fps, so a Micronics style 12 fps should be enough.
SaucJedi wrote:
If you're going to restrain yourself to 4 colors (like in this CPC video mode), then drawing the background becomes much easier, since you won't have to deal with tile attributes.
Quote:
If you examine it closely, parts of the image are meant to occlude the characters
One way to mask sprites on the NES is to use another sprite, of higher priority than the masked one, with the shape you want to cut and put it behind the background using the sprite priority bit. This works because the PPU first resolves the sprite collisions (if there are 2 sprites in the same screen pixel, the one with higher priority wins) and only then it resolves the sprite-background collisions, and since the sprite that's supposed to be rendered is behind the background, the background is drawn instead, effectively masking the first sprite. If you don't want to do it like this, the only option is to edit the CHR-RAM during runtime, like has been suggested.
Quote:
but ALSO have to be mixed with the floor when drawing the screen.
If your isometric tiles are 8 (not good if you use more than 4 colors though) or 16 pixels wide, you'll only have to worry about mixing the top and bottom of objects with further away tiles, and unless you predict all the overlaps that can happen (this is actually a good choice if you don't have that many different tiles or if you know the level design takes into account that some tiles can't overlap), you'll have to modify the tiles in CHR-RAM.
It's perfectly possible to make isometric games on the NES, but it won't be as easy as creating a second background plane. You'll have to decide what limitations you can live with (how many colors you want, how many different tiles can overlap, etc.) and be ready to deal with more complex solutions (e.g. runtime CHR-RAM editing) depending on the limitations you absolutely don't want in the game.
Is that Crime Monastery on the ZX screenshot?
Anyway, I'll watch this thread closely, I wanted to do something in isometric perspective on the NES/PCE but I have no idea how to.
Punch wrote:
Is that Crime Monastery
I did not know this game had an english title, but considering that the filename is "abadia_crimen_iso.gif" I guess you are right.
Quote:
on the ZX screenshot?
Not ZX Spectrum though, that's an Amstrad CPC screenshot (this was mentioned by the OP). I believe the CPC has a "high resolution" (i.e. no wide pixels) mode with 4 colors, which kinda makes games look like CGA DOS games (with way better color options though!).
Quote:
Anyway, I'll watch this thread closely, I wanted to do something in isometric perspective on the NES/PCE but I have no idea how to.
There are plenty example games to study. There are other consoles/computers with isometric graphics drawn in single background layers. The Game Gear for example has Sonic Labyrinth and Putt & Putter.
Punch wrote:
Is that Crime Monastery on the ZX screenshot?
Anyway, I'll watch this thread closely, I wanted to do something in isometric perspective on the NES/PCE but I have no idea how to.
I don't know if it was even released out of Spain, which is a shame because the game is pretty good and . The literal translation would be 'The Abbey of Crime', however, Crime Monastery is not a far cry... However, this is the Amstrad CPC version, there was one for the ZX, but it had even uglier colors.
tokumaru wrote:
If your isometric tiles are 8 (not good if you use more than 4 colors though) or 16 pixels wide, you'll only have to worry about mixing the top and bottom of objects with further away tiles, and unless you predict all the overlaps that can happen (this is actually a good choice if you don't have that many different tiles or if you know the level design takes into account that some tiles can't overlap), you'll have to modify the tiles in CHR-RAM.
It's perfectly possible to make isometric games on the NES, but it won't be as easy as creating a second background plane. You'll have to decide what limitations you can live with (how many colors you want, how many different tiles can overlap, etc.) and be ready to deal with more complex solutions (e.g. runtime CHR-RAM editing) depending on the limitations you absolutely don't want in the game.
I want to keep it in 4 colors justo to avoid the attributes issue. Once I have an interpreter for the original data, which renders the screens on the NES, I'l worrry about taking it to 16 colors. There is a remake for the MSX2 which has 16 color, though I think this would be quite a lot of work on the NES, I'm sure I can make this look way better than on the CPC.
Weird, I remember reading about "Crime Monastery" somewhere... wasn't it on Commandos 2 credits? Anyway, it doesn't matter much.
I guess the challenge is to do proper sprite masking and z-sorting. I'll see if I can program a quick tech demo, and report the results
How do these iso games typically represent their level maps?
I've done it with a grid where each tile had a top, two sides, and a height, or it could be a ramp and one side.
This was software rendering though, walking the grid in diagonal strips back to front. Not a situation where I would be fighting the hardware like on the NES.
Also, this was for a scrolling map. For a square screen I guess a complete grid would be inefficient use of memory, but you could replace a grid with a list of strips (each with appropriate length to fit its span across the screen), and it might be nearly as efficient.
rainwarrior wrote:
I've done it with a grid where each tile had a top, two sides, and a height
I can see how that'd work given a one-height-per-sector geometry limitation like that of
Doom and
Doom II. But a lot of scenes from famous iso games involve floors above floors. How would one represent an arch (as seen in the bottom of the screenshot of
La AbadÃa del Crimen) or a staircase that the player can walk under?
I don't think it is a big deal to store actual 3D tile grid for a flip screen iso game. Like, 10x10x10 tiles (they are pretty large usually) is just 1K RAM buffer, and locations could be compressed pretty well even with RLE, considering how much empty space they usually have.
If it is a scrolling iso game, memory could be a problem, but again, Doom-like tech could work pretty well. I.e. columns for the bottom part, and colums with a gap for top part - allows to make 'floating' platforms.
For an overpass situation I had planned to use a trigger that changes the tile height when the player steps on the tile next to the dual-height zone. It would have been uncrossable by NPCs, but I didn't consider that a problem.
There are other ways to solve this problem as well, like placeable platforms as a game object rather than a part of the map.