attention sprite hud users

Mugi

Member
we all (well, atleast i do) grieve the fact that we use a sprite hud that draws from object tiles or monster tiles, and meanwhile our large chunk of hud tiles sits allocated into the graphics bank, completely unused and inaccessible.

here's my solution.

there is this nifty macro called ChangeAllTiles.

this macro can directly access your tileset, your screen tiles, your path tiles, AND your hud tiles, in order to draw new tiles to the screen.
now all you have to do is write a tiny piece of code in a place that you know runs all the time (i generally use predraw for this.) that runs the macro at the time you warp to a room.

you can now make all your unused tiletypes into tiles that draw graphics from banks that are not accessible from nesmaker UI.

here's a screenshot of me drawing into the wall from my HUD tiles, because why not :p

game_034.png


and here's my HUD tiles.

HudTiles.bmp



this can eb expecially useful for people who have similar designs than i do, where in my game for example, the normal HUD is substituted by the sprite hud, so the hud tiles wont be needed for that,
and i have tiles in my game that will never change in appearance, such as the health platforms i've created. I simply hold the health platform graphic in the hud tiles, and draw from there using a custom tiletype. that's 3 16x16 metatiles for me for EACH of my tilesets.

there was somewhere in the forum a nice picture that explained the layout of how the graphics are loaded in the rom but i cant seem to find it now, so bear with me for some ASCII art to explain how to draw this.

the ChangeAllTiles needs 4 arguments;

; arg0 - what tile index (collision) are you trying to change?
; arg1 - what is the new collision type?
; arg2 - what is the new top left meta tile value?
; arg3 - which nametable, left or right. 0 - left, 1 = right

so what you give it is the tile number (you can name these however you wish from project settings, by default, #$00 is NULL - walkable, and #$01 is SOLID etc etc)

so lets say you use the last tile type for your custom tile, you give it #$0F

new collision type is what you want it do do (again 00 is null, 01 is solid, some tile is a monster lock etc etc, whatever you have there.) lets make it solid, so it's #$01

arg2 is the important part here. this is where the engine fetches the graphic from.

in your normal tileset, you have 3 rows of 16x16 metatiles.
after the normal tileset, the screen tileset is loaded in memory, this is one row of 16x16 pixel tiles.
after the screen tileset, you have your path tiles. this is 2 16x16 rows of tiles***
after path tiles, you have your HUD tiles, which are always there, and for us sprite hud users, completely unused and unaccessible.... until now.

each 8 pixel tile row in each sheet is represented by #$10 in arg2

so to draw the first tile from your second metatile row from your normal tileset, you define #$20 (3rd 8x8 tile row in the sheet)
following the same pattern, you can go over the normal tileset that ends at #$5F (last 8x8pixel tile in the bottom right of your tileset)

now, define #$60 to arg2 and suddenly it will draw from your screentiles....

following this logic, if you count down, you can draw all the way down to your hud tiles, as my screenshot demonstrates.

enjoy.




**** the way path tiles are sorted in memory as opposed to how they show up in nesmaker UI differs A LOT so some handcrafting is required to use those this way.
 

dale_coop

Moderator
Staff member
Interesting explanation, Mugi. I found and used this macro, but didn’t completely understand what was the last param about.
It makes more sense now.
 

Mugi

Member
this was just a test implementation so it has a lot of room for improvement, but i wanted to demonstrate the basic idea here.
(this is what i classify as an advanced use anyway. so if you're looking at this, chances are you know what you're doing.)

but yeah, for example, predraw executes every frame, so it's not really a good place to keep this code at, since it just burns cycles for no reason.
i need to locate a place i know executes at the beginning of every room, and just do an include for my code file there that holds the tile replacement parameters.
that way it will look like the tiles act as normal, but in reality they change from whatever you defined them as as an asset into whatever you want them to be instantly when a screen is loaded, but dont waste cpu cycles after that.

personally im going to definitely use this to store static objects like an item crate, the health platforms, and whatever other tiles i know that will always look the same throughout the whole game.
i have also coded myself a condition system that will allow me to redefine tiles based on what i want them to do.

for example, i can draw an item crate using tiletype 04, but if im in the stage selection screen, my tiletype 04 now draws a background null tile using graphics from the HUD tiles into the wall :p
that way i can have 13 extra types of tiles to put into my screens at will (currently this method can only replace tiles defined as certain tiletypes, so it has it's limitations, but it's getting there.)
 

dale_coop

Moderator
Staff member
It's definitely interesting that way to use tiles that you don't have access when making your Screens.

For example, your script (where you put your code ChangeAllTiles with the needed tests) could be assigned to the "Handle Triggers" element in the "Project Settings > Script Settings", so this script would be executed once when a screen is loaded.
 
Top Bottom