Isometry. There's few nes games that does it, despite the fact that the pixel ratio helps make it look pretty nice and believable. One of the reasons i went for it as shown in this thread.
I suppose some of the reasons for the limited library is that it isn't a very direct approach, that it requires realtime editing of PPU data, attribute tables won't conform, and so on. But since i'm getting into this field, which is way over my head, i might aswell do a short write-up on my findings so far on how it is handled on the nes. Maybe this is common knowledge, i don't know, but some may find it interesting.
I begin with Solstice, and waybe i fill in with other games at a later stage if there's interest. Note of warning: this is a deduction based on the fceux ppu viewer and tile layer pro, not an actual disassembly of the game, so there are holes and assumptions.
To warm up, here's a 'the making of' feature which is basically a studio promo shot, but you get to see some of their tools, some of the process, placeholder graphics and some other minor things of interest. (part 1, part 2)
Solstice keeps four slots @ 6 tiles each sequentially in its second pattern table, representing a 2x3 tile object each (lime green outine in picture below). This sequence decides the drawing order of sprites. This means only four sprite objects (2 tiles wide each) may be present at any one screen, even though technically, sprites such as the blob enemy, the moving platform, or any item is just 2x2 tiles large, which means most of the time some tiles in these slots are left unused; limiting the number of objects to a player object and three other objects.
The four sprite object limitation is most likely imposed to garantuee a gaming experience within flickerless territory at all times. They could aswell have designed some rooms so that more than 8 in a room never would occur, but i guess this is more pragmatic. The four slots are actually mirrored (cyan outline) within the table for a reason i don't know, and the main character also has a few more duplicates along with title screen data, so space doesn't seem to be an issue.
The content of these slots is overwritten, much like in Battletoads, to animate the objects.
They are dynamically swapping sets of tile data with each other to determine drawing order, and thus, what is rendered as in front of the other. Besides this point, this swapping of tile sets also seems to be part of determining wether or not the content should be subject to pixel erasing before being drawn.
Even if there's just one sprite object in a room, this swapping occurs when moving forth and back. The unused slots are filled with a movable cube if no other objects are present.
You would see that if something moves "behind" a background that has a higher height attribute asigned to it than the main character/object/enemy, the sprite tiles held in memory are redrawn with transparent pixels to reflect this, if the object is further away than the background tile in question. I'm wondering if this is done by masking through lookups (graphical or not) or some algorithm.
One odd thing is than rather pushing tile data directly unto the pattern table; the program seems to be composing PPU tilesets in use from fragmented parts in data. This is also true for some title screen data such as "nintendo presents", but that's a sidenote. I'm not sure why they did it like this since it seems a bit wasteful and impractical. But i'm primarily an artist, not a smartist. Maybe it has to do something with the sprite masking, but then they could have just used generic masking tiles and a logic gate. Maybe someone else can chime in on this?
(edit: it may be that the game is using the unused objects that are filling the slots for masking the player character).
Some of the tiles currently used.
Compositions, mirrors and slots in the pattern table.
I suppose some of the reasons for the limited library is that it isn't a very direct approach, that it requires realtime editing of PPU data, attribute tables won't conform, and so on. But since i'm getting into this field, which is way over my head, i might aswell do a short write-up on my findings so far on how it is handled on the nes. Maybe this is common knowledge, i don't know, but some may find it interesting.
I begin with Solstice, and waybe i fill in with other games at a later stage if there's interest. Note of warning: this is a deduction based on the fceux ppu viewer and tile layer pro, not an actual disassembly of the game, so there are holes and assumptions.
To warm up, here's a 'the making of' feature which is basically a studio promo shot, but you get to see some of their tools, some of the process, placeholder graphics and some other minor things of interest. (part 1, part 2)
Solstice keeps four slots @ 6 tiles each sequentially in its second pattern table, representing a 2x3 tile object each (lime green outine in picture below). This sequence decides the drawing order of sprites. This means only four sprite objects (2 tiles wide each) may be present at any one screen, even though technically, sprites such as the blob enemy, the moving platform, or any item is just 2x2 tiles large, which means most of the time some tiles in these slots are left unused; limiting the number of objects to a player object and three other objects.
The four sprite object limitation is most likely imposed to garantuee a gaming experience within flickerless territory at all times. They could aswell have designed some rooms so that more than 8 in a room never would occur, but i guess this is more pragmatic. The four slots are actually mirrored (cyan outline) within the table for a reason i don't know, and the main character also has a few more duplicates along with title screen data, so space doesn't seem to be an issue.
The content of these slots is overwritten, much like in Battletoads, to animate the objects.
They are dynamically swapping sets of tile data with each other to determine drawing order, and thus, what is rendered as in front of the other. Besides this point, this swapping of tile sets also seems to be part of determining wether or not the content should be subject to pixel erasing before being drawn.
Even if there's just one sprite object in a room, this swapping occurs when moving forth and back. The unused slots are filled with a movable cube if no other objects are present.
You would see that if something moves "behind" a background that has a higher height attribute asigned to it than the main character/object/enemy, the sprite tiles held in memory are redrawn with transparent pixels to reflect this, if the object is further away than the background tile in question. I'm wondering if this is done by masking through lookups (graphical or not) or some algorithm.
One odd thing is than rather pushing tile data directly unto the pattern table; the program seems to be composing PPU tilesets in use from fragmented parts in data. This is also true for some title screen data such as "nintendo presents", but that's a sidenote. I'm not sure why they did it like this since it seems a bit wasteful and impractical. But i'm primarily an artist, not a smartist. Maybe it has to do something with the sprite masking, but then they could have just used generic masking tiles and a logic gate. Maybe someone else can chime in on this?
(edit: it may be that the game is using the unused objects that are filling the slots for masking the player character).
Some of the tiles currently used.
Compositions, mirrors and slots in the pattern table.