type-in box or free selection of ID in room building window.

FrankenGraphics

New member
It would be super beneficial if there was an input mode where the user could freely type in, edit or otherwise freely select any ID for each cell on each "room" map, since the UI limits:

-tile ID:s to be even numbers.
-path ID:s to always be x0.

For normal tiles: With free type-in or the like, entering odd-numbered ID:s will give you 16-by-16 tiles derived from both (or all 4 if going on the y axis) neighboring entries with even ID:s. The format and size remains the same. So you can potentially get (not quite) x4 the amount of unique meta-tiles if you arrange them clever enough. Not all of them will be useful even with careful planning, but the ambitious user can get a lot more out of it this way while still leaving the underlying structure intact. Not quite sure how tile type settings will affect these mixed up metatiles, but we can work around whatever after finding out. I'm guessing they will either have mixed attributes, or borrow them from the lower even metatile ID depending on how it was made.

For paths: With free type-in or the like, use MistSonatas' path mod to the fullest without backdoor editing the files without the aid of instant GUI feedback. You can offset the path type behaviour on a per-cell level which would be really powerful. You could for example build paths within paths without it looking wrong (ie. avoid creating "double borders") or vary up a path border with a normal tile without making a border around it.

A quick implementation of this could be to have an input textbox anywhere in the room edit window that shows the metatileID in hexadecimals. Click to edit. Commit a change by hitting enter or click elsewhere to cancel. A shortcut key to begin entering values would help as well.

[Originally posted this in the beta subforum by mistake. sorry about that]
 

Mugi

Member
I definitely support the idea of "unlocking" behavior for more advanced users.
i noticed the this whole metatile business myself earlier today when i was playing around with the "changetile" code, that changes the appearance of a tile when you do something.
in this macro, you punch in the new tile type as a hex value, and it actually increments it going by 8x8 tiles, which means that using the changetile macro, you can already use metatiles that start from a selected 8x8 tile.
all you would have to do is to set it up, and make a way to instantly trigger it.

Code:
MACRO ChangeTile arg0, arg1
	;; this tile uses arg0 to figure an arbitrary place on a the collision table
	;; and then translates it to nametable space.  Arg 1 is the tile starting value
	;; loaded to the PPU.  It uses this to draw a metatile.
	
	;; arg0 - new collion type
	;; arg1 - starting tile number of new metatile
 

FrankenGraphics

New member
Yup - at first when i realized that there was no odd-numbered tile ID:s (or rather, that no odd-numbered tile ID:s are used by the user), i thought that it maybe was a bit packing scheme to compress data (the unused LSB could hypothetically have stored an unrelated bitfield or something but it'd be awkward to use, so i didn't spend much thought on it). It doesn't look that way from a quick glance anyway.

The macro proves a good point - just be aware that there's a big caveat to using it extensively. Each time you do, you spend some 30+ bytes of ROM space, and some 80-90 cycles for the cpu to process (i didn't count). You could remake it into a function and save the rom space. But remember that it will still run during runtime. If you hardcode the room tables directly (through the interface preferrably, and with direct visual feedback), no resources whatsoever are hogged. The level with all the odd ID:s is then constructed during build-time.
 

Mugi

Member
i figured that the case with it is something of the sort, since it's a function that runs at runtime, triggered by something.
i suppose if you'd make a trigger that instantly triggers when you enter a room, and leave it at that, it could work without causing too much extra issues (aside the extra rom space spent i guess.)
but yeah, it was just an observation i made, im not actually using this for anything myself (at the moment atleast.)
 

FrankenGraphics

New member
I thought you might've come to the same conclusion. :) Just typing the rest of it out if anyone else is reading this and may be interested in the macro. The ideal time to use it extensively would be after the next table has been loaded, but before rendering is turned on again. That way the total cycle count won't be much of a problem even if you're using it extensively. But.. if you go through the trouble to manually type up a table of contents for the function (or macro) to use, you could as well spend that trouble manually editing the room data directly in a text editor. What's more, that table of changes to make will also weigh in on the total ROM use. So, it's still best used for special events and should probably not be considered as a general solution to getting the most out of your tileset on several screens.

For example, player is pulling a switch --> replace this wall-behaving position with a walkable floor asset, or something like that.
 

FrankenGraphics

New member
Another 2 cents on the matter:

I feel it's really only experimental as long as it's theoretical, or as long as you need to go the backdoor way to achieve it. Once (if) in the GUI, anyone could use it with little or no help.
 

FrankenGraphics

New member
UPDATE: I did try something else -editing the assets themselves through a hex editor directly on the project file (the .MST). It is *sort of* possible in that the data should be legit for the NES/emulator, but if you enter anything other than the already established rule of "only evens", it won't be graphically represented, and the program will throw you an unhandled exception if you try to place it on any screen on the map. So.. currently, no good. The GUI makes some assumptions about the representation of graphics tiles, i'm afraid. Else, this method could've skipped needing to search and replace stuff in the pre-assembly text file after every build if it had worked.
 
Top Bottom