It is currently Sat Dec 16, 2017 7:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Tue Apr 26, 2016 6:54 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1131
Location: Gothenburg, Sweden
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).

Image
Some of the tiles currently used.

Image
Compositions, mirrors and slots in the pattern table.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 8:28 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
WheelInventor wrote:
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 "mirroring" is actually double buffering. There is not enough time to update all tiles during vblank, so to ensure a partial update isn't shown, it must update to an unseen buffer, then switch to it all at once.

The four sprite limit is probably more to do with that than it is to do with flicker. If you watch frame by frame, you will see that the game is only updating one object per frame. More objects would have lowered the effective framerate even more.


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 9:11 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
WheelInventor wrote:
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?

I think when you see garbage/noise somewhere it's probably because that space originally had graphics which were deleted or moved, and there was some reference to it that was never cleaned up, causing it to fetch irrelevant data from the space it would have occupied in the ROM. (Or something equivalent.)

There's actually a lot of invisible garbage in this game, not just in the PPU tables, but title graphics and cutscenes have unused/nonsense sprites and other stuff that you can't see but it's in the data. I think there's a lot of evidence that the makers of the game were only worried about the stuff you actually see. Whatever toolset they had wasn't designed to clean up around the edges for them and validate everything. There doesn't have to be a logical reason for the garbage, it's just leftover dirt that nobody was interested in sweeping up.

I wouldn't call it "wasteful" to not use all available CHR tiles for every screen. Extra detail is extra data to fit in your ROM budget, and extra development cost to produce. I can only find about 2k of obvious wasted space in the ROM, which is not bad at all (a 98% full ROM is pretty dang full). If you're trying to make the most beautiful single screen you can, sure it's a waste, but in the context of a whole game where everything eats a part of your resources, it's not at all, really. (Commercial development mentality is very different than a hobbyists, in this respect, too.)


Actually, another thought on the 4-sprite limit you mentioned earlier; you proposed that it was to eliminate flicker-- since sprites are sorted front to back here, there's no chance for the software to reorder sprites to produce flicker in the first place; breaking the 8-sprites per line limit would always result in one of them being entirely invisble, because flicker is not an option! Flicker was a software coping technique to deal with the hardware limitation, not something the hardware does on its own, and you can only do it if your rendering technique is allowed to re-order the sprites. So, yeah, you're probably right that this was one of the reasons they had to restrict to 4.


Attachments:
File comment: The title screen shown without sprites. There is garbage on the top line (hidden in NTSC). The pale blue square is intentional, hidden by a black sprite, I believe for a sprite 0 hit to switch tilesets.
solstice_bad_title_bg.png
solstice_bad_title_bg.png [ 4.36 KiB | Viewed 2546 times ]
File comment: If you turn off the 8 sprites per line limitation in your emulator, you can see there are erroneous sprites in the OAM data.
solstice_extra_sprites.png
solstice_extra_sprites.png [ 2.92 KiB | Viewed 2556 times ]
File comment: Garbage on the top line (hidden in NTSC).
solstice_bad_title.png
solstice_bad_title.png [ 3.41 KiB | Viewed 2556 times ]
Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 2:17 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1131
Location: Gothenburg, Sweden
Thanks for these remarks, rainwarrior! It really helps me get a better concept of what limitations i am facing.

rainwarrior wrote:
I wouldn't call it "wasteful" to not use all available CHR tiles for every screen. Extra detail is extra data to fit in your ROM budget, and extra development cost to produce. I can only find about 2k of obvious wasted space in the ROM, which is not bad at all (a 98% full ROM is pretty dang full). If you're trying to make the most beautiful single screen you can, sure it's a waste, but in the context of a whole game where everything eats a part of your resources, it's not at all, really. (Commercial development mentality is very different than a hobbyists, in this respect, too.)


This is true. Though, i think i might have totally missed the mark on what i was trying express by hurrying the post (and by being confused).

There are rom tiles depiciting floor that are half-black, half filled in a diagonal fashion. It's like they drew every platform isolated from one another. It seemed to me these isolate pieces are then combined into more complete looking tiles (not tilesets, as i sloppily wrote by mistake) we see copied to the pattern table. I'm probably not seeing the whole picture yet, but i thought it was an interesting choice/process. For my iso concept i drew mine completely filled in for the rom, which means more condense gfx data, more room for variations, ultimately having the advantage of easily doing all sorts of neighbour tile combinations, which makes less graphics data seem like a lot more when on-screen. In the light of what you wrote, though, their design choice is very understandable (ie. doing just as much gfx as does the job for an atmospheric iso puzzler that looks good in an almost minimalist sense, and leave it at that, because labour is costly). Mine probably needs to be split up in repeatable structures in some fashion or another, so i don't know if it's any good yet, even.


Quote:
Actually, another thought on the 4-sprite limit you mentioned earlier; you proposed that it was to eliminate flicker-- since sprites are sorted front to back here, there's no chance for the software to reorder sprites to produce flicker in the first place; breaking the 8-sprites per line limit would always result in one of them being entirely invisble, because flicker is not an option! Flicker was a software coping technique to deal with the hardware limitation, not something the hardware does on its own, and you can only do it if your rendering technique is allowed to re-order the sprites. So, yeah, you're probably right that this was one of the reasons they had to restrict to 4.


And reasons i might have to do so, too, which would be bad for a 2 player coop game concept with hopes of dungeon crawl/hack'n'slash elements. I'm trying to come up with as many background tile based enemies/dangers as possible to choose from that could work, but that in itself isn't going to cut it. I need to solve that equation or change some core elements.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 4:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
Yes, I think the background CHR tiles are likely composited at load time from pieces of isometric shaped tiles overlaid on each other. Since the source art is tiled isometrically, this should keep everything a bit more compact.


Top
 Profile  
 
PostPosted: Sun May 01, 2016 12:24 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1131
Location: Gothenburg, Sweden
Here's a new bit i found to be rather interesting. It's the 'nintendo presents' logo.
It looks garbled, but what it does is something i could best describe as a left-right shift of colour information.

The common colour is normal
3rd colour (blue here) is shifted 8 pixels left
4th colour (light cyan here) is shifted 8 pixels right
So is the second (green here), but it is not used as a colour definition, but rather to bridge areas where common and 4th colours overlap due to the shift.

Note the easily distinguishable upper part of 't' and how it is doubled. everything is. had it only been the black copy, the text would show as black. had it only been the light teal copy, it would be first shown as background white in the game (shifted 8 pixels left from the information), then shifting as the game does the palette shift to black or red depending on overlap. Whew. I hope i got that down right.

This effectively means just three usable colours, but theystamp in the (r) symbol as a gray and transparent sprite, so it appears to be four.

There's also the two upper lines in every tiles being palette shifted, and they're actually read as the lower two lines.

I'm not sure what this is supposed to do, but it intrigues me, and i wonder if it can be a technique of use. First i thought it to be some sort of compression but i don't see any apparent trace of anything being compressed. Also, it's only for the 'nintendo prestents' screen and nowhere else in the game. Next i thought it was just something the programmer put in as a waterstamp. But could it be something else?


Attachments:
nintendo presents.png
nintendo presents.png [ 5.32 KiB | Viewed 2376 times ]

_________________
http://www.frankengraphics.com - personal NES blog
Top
 Profile  
 
PostPosted: Sun May 01, 2016 12:36 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
You're decoding your bytes off by 10, so the two planes are misaligned.. as well as the seeming garbage on the first two rows. Start interpretting the .NES from offset 78058 as CHR to get it to be correct.

If you actually start the PAL version of the game in an emulator, the two planes are put in the right places.


Top
 Profile  
 
PostPosted: Sun May 01, 2016 12:51 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1131
Location: Gothenburg, Sweden
lidnariq wrote:
You're decoding your bytes off by 10, so the two planes are misaligned.. as well as the seeming garbage on the first two rows. Start interpretting the .NES from offset 78058 as CHR to get it to be correct.

If you actually start the PAL version of the game in an emulator, the two planes are put in the right places.



I didn't realize a single portion could be offset like that when the rest isn't? :shock:

EDIT: It is the pal version i'm using.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun May 01, 2016 12:59 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6535
Location: Seattle
The NES has two entirely disjoint regions of memory. One for the CPU, one for the PPU.

Games can be divided into two types: those that had two separate fixed memories (e.g. Super Mario Bros.), and those that had one fixed memory and used RAM for the PPU.

If RAM is used for the PPU, then the CPU has to copy the data to the PPU to be able to show anything. Furthermore, then there's no particular restriction of where in memory the tile data is stored, or even that it's stored uncompressed.


Top
 Profile  
 
PostPosted: Sun May 01, 2016 1:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
tepples' RHDE did some of its text screens by combining 2 layers of text into a single block of CHR. Trades a palette slot to double the space available for 2-colour graphics. (Not related to Solstice, I don't think, but kind of in line with the idea you were just describing?)


Attachments:
rhde_help_chr.png
rhde_help_chr.png [ 6.45 KiB | Viewed 2361 times ]
Top
 Profile  
 
PostPosted: Sun May 01, 2016 1:36 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
The text engine in Action 53 and my ports of robotfindskitten and 240p Test Suite uses exactly the same trick.

Among non-homebrew games, the title screen of The Goonies does this. I wonder if some Chinese or Japanese RPGs do something similar for dialogue.


Top
 Profile  
 
PostPosted: Sun May 01, 2016 2:11 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1131
Location: Gothenburg, Sweden
Yes, that is it! Even if the solstice example was just an offset hickup when viewed from beginning till end in TLP, this occurrence made me wonder if tile data could be be offset to achieve other, more practical ends. That RHDE trick looks very neat. Does it use two palettes, or does it translate the tiles at load time?

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun May 01, 2016 3:06 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
It uses two palettes: one white, black, white, black, the other white, white, black, black. Then it draws 1bpp lines of text into each palette.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group