This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Regarding tilification

Regarding tilification
by on (#91086)
I recently added a feature to NESICIDE [not in the released version yet]. This feature takes any set of "images" of any size (8x8 up to 256x256) and removes redundant "tiles" within the whole set, producing a CHR-ROM out the back-end. I was pretty proud of myself and ready to incorporate the feature into a release. But then I got to thinking...

Duh. There's a number of cases where one might actually need redundant tiles in a single 8KB bank of CHR-ROM [redundant tiles that are redundant between two or more different CHR-ROM are not removed...].

Example: X-marks-the-unused-tile. My redundancy removing algorithm blindly removes all but one of the X's.

I'm sure there are other cases where redundant tiles within an 8KB CHR-ROM might be desirable.

1. When the background page and sprite page have one or more identical tiles between them [weird but possible].

2. When the CHR-ROM is 1, 2, or 4KB bankswitchable and it's necessary [for some reason] to have an identical tile in one or more of the sub-8KB banks.

If you know how I organize CHR-ROM in NESICIDE, it's done by creating a Graphics Bank item. Each Graphics Bank item has a list-view, which can be used to add, remove, or re-arrange any of the available Tiles (here a tile is an 8x8 up to 256x256 image, not an 8x8 hardware tile) into a CHR-ROM. Obviously a 256x256 image of unique tiles won't fit so hopefully what you've drawn is reducible or it'd just plain tell you it can't do it! The tilification is done in real-time as Tiles are added or removed or when Tiles are modified. But of course, the issue is how to best solve the above problems:

1. For the "I want to use this tile as filler, please don't redundantly reduce it" case, I thought perhaps a combo-box selection for each listview line item containing the choices "Fill to next 1KB", ... "Fill to 8KB" would work.

2. For the background-vs-sprite page case, I thought perhaps splitting the list-view into two separate list-views would work. Or an option in the combo-box again, something like "Start 4KB page here".

3. For the identical-tile-in-bankswitched-bank case, I thought perhaps another option in the combobox for each listview line item "Don't remove" or similar.

So the questions. Have I considered all the cases or are there more? Does the combo-box per line item solution make sense or seem cluttery? The default for the combo-box would be "Reduce if possible" or similar phrasing.

I'd appreciate feedback from anyone that may have attempted to use the Graphics Bank in NESICIDE. If the solution to that equation is the empty set, I'll entertain feedback from anyone.
Re: Regarding tilification
by on (#91094)
cpow wrote:
I recently added a feature to NESICIDE [not in the released version yet]. This feature takes any set of "images" of any size (8x8 up to 256x256) and removes redundant "tiles" within the whole set

Sort of like Chris Covell's CHARlie, my chropt, or an unreleased tool that I used for the new version of Who's Cuter.

Quote:
1. When the background page and sprite page have one or more identical tiles between them [weird but possible].

Yep. Examples include objects that switch between being tiles and being sprites, where either they are 8x8 pixel sprites (as in Super Mario Bros.) or they have to coexist with a PA12-spreading scanline counter (as in the MMC3). Or if a sprite engine has fixed size actors, thus needing a blank tile in the sprite page. Compare background and sprite tiles $0FC and $124 in Super Mario Bros.

Quote:
2. When the CHR-ROM is 1, 2, or 4KB bankswitchable and it's necessary [for some reason] to have an identical tile in one or more of the sub-8KB banks.

Such as Ninja Gaiden, where different sets of enemies share the same duplicated Ryu frames. An extensive hack of Monster Party even takes advantage of this duplication to change the story to put a different player character in each chapter.

Quote:
2. For the background-vs-sprite page case, I thought perhaps splitting the list-view into two separate list-views would work. Or an option in the combo-box again, something like "Start 4KB page here".

Yeah, I'd make 4 KiB the base unit for tile pages.
Re: Regarding tilification
by on (#91098)
tepples wrote:
Sort of like Chris Covell's CHARlie, my chropt, or an unreleased tool that I used for the new version of Who's Cuter.

Yeah. I wasn't claiming it was a Grand New Idea. :shock:
tepples wrote:
Yep. Examples include objects that switch between being tiles and being sprites, where either they are 8x8 pixel sprites (as in Super Mario Bros.) or they have to coexist with a PA12-spreading scanline counter (as in the MMC3). Or if a sprite engine has fixed size actors, thus needing a blank tile in the sprite page. Compare background and sprite tiles $0FC and $124 in Super Mario Bros.

Thanks. I'll check that out.
tepples wrote:
Such as Ninja Gaiden, where different sets of enemies share the same duplicated Ryu frames. An extensive hack of Monster Party even takes advantage of this duplication to change the story to put a different player character in each chapter.

Let me try to clarify. Are you saying that in a *single* 8KB CHR-ROM there are 1KB or 2KB banks that contain the same player sprites? Or are you saying that there are the identical player sprites in multiple 8KB CHR-ROM banks in the same 1KB or 2KB bank within them?
tepples wrote:
Yeah, I'd make 4 KiB the base unit for tile pages.

Do you mean make two UI elements, one listview for the left page and one for the right? I guess that'd be OK...the listviews could even be spatially placed so there's one on the left and one on the right...so when you add sprites to the right they show up in the right-side of the image below the listviews that represents the current CHR-ROM content.

Having two UI elements removes the need for a "fill to 8KB" combo box option.

Thanks for the feedback!
Re: Regarding tilification
by on (#91099)
cpow wrote:
Let me try to clarify. Are you saying that in a *single* 8KB CHR-ROM there are 1KB or 2KB banks that contain the same player sprites?

Yes. An MMC1 game's CHR ROM is divided into 4 KiB banks. Say the first 1 KiB of each 4 KiB sprite bank ($000-$3FF) is player sprites. If two such sprite banks are in the same 8 KiB, then you'll have $0000-$03FF and $1000-$13FF identical. And in Super Mario Bros. 2: Mario Madness, which uses 1 KiB bankswitching, you still have identical 1-Up mushrooms and a couple other repeated sprites in the 1 KiB subpages of the 4 KiB page that has the graphics for Mario, Luigi, Yvan, and Peach.

Quote:
tepples wrote:
Yeah, I'd make 4 KiB the base unit for tile pages.

Do you mean make two UI elements, one listview for the left page and one for the right?

That's what I had in mind.

by on (#91106)
As long as redundant tile removing/marking isn't turned on by default I think it's an awesome idea.

I know with Genesis programming I end up duplicating tiles due to the way my compiler allocates them for sprites. I guess what I'm saying is, there's definitely a time when redundancy checking could get in the way.