Best practices for managing assets

stevenshepherd

New member
I want to get started on making assets for the gsme that I ultimately want to make. The survival horror demo I've been working on has been useful and through trial and error have learned a bit about efficency. Any best practices for managing graphics banks etc while one is developing a game?
 

RadJunk

Administrator
Staff member
Great question, and this is still a bit in flux. The main reason - currently, graphic banks are IMPORTANT. Like, you can only mix and match graphics within a bank...you can only use a main tileset and screen tileset and path tileset from a single bank...so they'd all have to be in bank 1, for instance, which is why the tool is set up that way.

However, one of the benefits we got from the redux of the collision data is negating this as a *need*. So, the graphic bank will no longer be a thing you have to worry about. You'll simply be able to pick your tileset, screen tileset, and individual collection of four paths, out of ALL available choices. All of this in theory.

The benefit to this is that if you need, say, mountains with the first bank, and also with the second bank, right now you waste that tileset. Or if you need a water path across all three, you waste two paths that you can now get back. This potentially frees up a lot of duplicate graphics needed to construct a game.

However, I'm saying that this is in theory, because it involves a pretty big rework of how the tile picker is handled and whatnot, and I know Josh is dreading the amount of time and energy that will be required for this one thing, major as it would be.

So best practices for graphics?...hard to say right now. But from the looks of your project, you've got a good handle on it!
 

Mihoshi20

Member
stevenshepherd said:
I want to get started on making assets for the gsme that I ultimately want to make. The survival horror demo I've been working on has been useful and through trial and error have learned a bit about efficency. Any best practices for managing graphics banks etc while one is developing a game?

report.jpg

A quick look under the hood demonstrates how they took great care managing where all the data goes and gives a lot of wiggle room and flexibility to making your game with UNROM-512 in mind. Poking around in the ASM and studying where everything goes, it's fairly cleanly laid out with banks usually dedicated entirely to a single purpose.

Each bank is 16k in size but some of it is already used by engine data.
Bank00 - Bank07 is dedicated to the overworld screens, though as of version 3.1.4(Pi) seems to have some extra data at the end of Bank00 I need to investigate the purpose of.
Bank08 - Bank0F are dedicated to the underworld screens.
Bank10 - Bank12 are the Tileset banks for BG tiles, path tiles, and screen tiles.
Bank13 is Monster Bank 1 Graphics.
Bank14 is for the engine data. Mostly Monster AI and Tile Types.
Bank15 is Monster Bank 0 Graphics.
Bank16 contains Palette data, nametable pointers, collision tables, and attributes.
Bank17 is commented as string data but doesn't seem to contain hud information or anything else. Assuming it's where NPC text goes.
Bank18 - Bank19 are blank and don't ever seem to store any data.
Bank1A is blank but I assume this will be the save data bank.
Bank1B is the music and sfx bank, both the sound engine code and audio data for play goes in here.
Ban1C is fairly important and handles object data, solid edge routine, and handling of sprite drawing.
Bank1D also important as it contains the CHR data for the HUD, Start Screen, Player/gameobjects, win screen, and something new to (Pi) version called BoxTiles.
Bank1E is dedicated to the Win and start screen nametables and attributes. I need to play around and find out why these aren't in the normal NT/ATT banks.
Bank1F is the most important bank of all, the last bank containing main game loop, NMI, and Reset code and vectors required for the NES to boot normally.

This should give you a better idea of what you have to work with and the free space allocated to each bank on a blank project. Not sure how helpful it will be in the grand scheme of things but may give an understanding of why the tool does what it does.
 

RadJunk

Administrator
Staff member
Wow Mihoshi20 - very astute! You nailed almost everything perfect. :)

14, 18 and 19 are sort of our custom user / custom engine banks for extended routines that may be necessary for certain genres or games. They give us lots of space to play with additional logic, additional graphics, etc. Other than that, spot on :)

My guess...what you're seeing at the end of bank 0 is the screen data you created :)
 

Mihoshi20

Member
TheNew8bitHeroes said:
Wow Mihoshi20 - very astute! You nailed almost everything perfect. :)

14, 18 and 19 are sort of our custom user / custom engine banks for extended routines that may be necessary for certain genres or games. They give us lots of space to play with additional logic, additional graphics, etc. Other than that, spot on :)

My guess...what you're seeing at the end of bank 0 is the screen data you created :)

Ah, Okay, I was thinking Banks 18 and 19 at least were for future expansion or reserved for features not yet implemented but planned.

As for the extra data in Bank00, I didn't create any screens yet, this was just an unzip, startup and export and run, guess I should have just chose export instead and see what happens. This chunk of data isn't present on 3.1.0 nor 3.1.3 builds of a rom so i'm curious as to if it might be the hud and playfield definitions. Though I ended up just selecting all that data which was a large cluster of 01's and deleted it and nothing in the game changed, screen transitions, hud, and ladders still worked as intended so still have no idea what that data was.

But yeah when I was compacting the banks down to run on MAME's Vs System and Playchoice 10 implementations I had to get very familiar with where all the data was and how it was stored as cramming 512 down to 128 is no easy task.
 

RadJunk

Administrator
Staff member
Probably what's there as a NES file is whatever one I was last working on. If you export and test, it'll overwrite that, and then the bank 00 stuff will probably go away :)
 
Top Bottom