Forums

Ummm....

Maybe I am wrong, or I am missing something.

If I use this command...

..\tools\bmp2tile\bmp2tile gfx\%1.png -8x16 -nomirror -removedupes -tileoffset 0 -savetiles assets\%1tiles.bin -savetilemap %1tilemap.bin

I found that bmp2tile will build the tiles using the 8x16 pattern, as expected.

But I wonder why not to build a 8x16 tile based tilemap, instead of a 8x8 one, as this (8x16)tilemap is of utility to manage sprite patterns.

Also, I found that, in bmp2tile code,

new[] { "8x16" },
"Treat image as 8x16 tiles (does not work will with duplicate removal)",

Could this two questions be fixed? I found both of big utility if you want to use 8x16 sprites. (if not, I wouldl try to implement both functions using bmp2tile code, and post them here).

Regards.

I didn’t see a use for an 8x16 tilemap. 8x16 is only really useful for sprites, and then you don’t want the tilemap data.

I explain...

Since Galactic revenge, I use the createtilemap feature of bmp2tile to get tilemaps representing a bunch of frames of sprites which compose an animation (using the removing duplicate tiles feature of bmp2tile i save tiles, which often is mandatory, due to vdp limitations).

By example, if you look in the image, will found that, by example, the two upper 8x16 sprites in each frame are the same in all the frames with the same direction, saving 16 tiles in total.

Of course, I can load this image in mappy and optimize the output (the tiles and the tilemap as csv and then to bin)(by example) or do my own script to do this, but I feel this should be done by bmp2tile (as the master system has 8x16 sprites) (and bmp2tile optimize the tiles and should output a tilemap matching that optimization).

All my games (after silvervalley) use 8x8 sprites so no trouble (until now).

playertall.png (1.87 KB)

I guess the idea is to de-duplicate the 8x16 regions, without flipping, and then emit just the low bytes as they are sprite tile indices? As BMP2Tile tilemaps are background tilemaps, they are 16-bit entries with flipping. It also treats tiles as 8x8 at all times, 8x16 mode simply changes the order that tiles are extracted from the image. Making it work for 8x16 sprites would definitely require a bunch of work…

Well... I changed (minimally) your code to allow what I need.

I only removed the creation of two tiles when you pass a 8x16 param,
Next I changed the functions to do the same but with 8x16 tiles if needed.
Finally, put a function to split the 8x16 tiles to 8x8 tiles before pass them to the compressor.

More or less, I changed about twenty lines of code (should have clone your repository, sorry!!!)

Do what you want with the code, merge it, fork the project, etc. or nothing, but I found sense in this upgrade.

Regards.

PD. Last but not least.... So many thanks to you for this awesome tool, I have used it near a miilion times since Baluba Balok ;) Love it!

bmp2tile-master.zip (232.56 KB)

Modified project

I wonder if Maxim can somehow merge this mode into BMP2Tile because it indeed could be interesting...

Yes, I plan to merge it some time soon after I understand it. It might be worthwhile to extend it to other sizes and “windings” within a larger tile, I had to do that for some parts of the Sonic editor.

I'm looking at this now but it's opening more questions in my mind :)

I think there are multiple issues to address which might require multiple ways to control it. The first is to consider the order in which tiles are extracted from the image. Currently this happens left to right, top to bottom, but 8x16 mode changes this to try to preserve ordering to match 8x16 sprites mode on the SMS VDP. In general, you don't care what tiles go in which indices, just that the 8x16 ones are in adjacent pairs. However, for some game hacking scenarios, the order is very important. The game might expect a certain order that is not easy to achieve sensibly in the PNG file.

Next is the consideration of duplicate removal. Tile optimisation on 8x8 tiles already ordered for 8x16 mode can be catastrophic. If the de-duplication worked on the tiles as 8x16 then it would solve this, but that would preclude optimisation using mirroring.

Thirdly we have the ordering of tilemap data in this scenario. Again we default to left to right, top to bottom; this being the VDP VRAM tilemap format. Plugins are at liberty to reorder things if wanted, or you can post-process the data some other way - I'm increasingly using Python scripts to do project-specific data munging. As described above, the goal is to emit only the initial tile index of the first tile of each 8x16 block - but not to try to include the x/y parameters too. That might be useful for cases where the image contains a "sprite sheet" and you might want to emit count + (index + x + y) * count data for each frame - but then the tool has no idea how big a frame is.

In this particular change - now at https://github.com/maxim-zhao/bmp2tile/pull/25 - it seems the goal is mostly around part 2, to de-dupe at an 8x16 level, although it seems to also support 8x16 flipping; and also some of part 3. I'm not sure about merging it as-is, I will think some more...

A solution could be to have BMP2Tile work in two different modes: one is 'BG' mode, the other would be 'Sprite' mode.

So, in BG mode you have only 8×8 tiles, and you optionally have duplicate removal, with additional and optional flip/mirror duplicate removal, plus additional and optional 'second' palette support and 'priority bit' support. The tilemap will then be a matrix of 16-bit values matching the hardware arrangement of the bits in each BG entry, and of course plugins can change this if needed.

In Sprite mode you can pick either 8×8 or 8×16 mode. You can have duplicate removal, but no flip/mirror of course. The tilemap should then be a matrix that matches how the sprites are arranged on the sprite sheet, so nothing to deal with the hardware VDP' BG entries, because we're not in BG mode. It is probably a good idea to keep this 16 bits values - plugin can save to 8 bits values of course.

On top of this - if I may - I would love to have a transpose option, to optionally have the BG arranged in column-major order, which would make it perfect for horizontally-only backgrounds (yes, I know one would probably better using metatiles, but many games would not even need that...)

I think that 8x16 mode is only for sprites. With my patch you have the tiles ordered as needed.

I guess in 8x16 mode the tilemap data is sort of meaningless. I have used it a bit, though, to allow correct ordering on some game hacks.

I think I’d prefer to keep the current functionality, but then to extend it to support outputting sprite data; that would be single-byte tile indices, or optionally more verbose sprite sheet style data, including x and y offsets and omitting blanks. This would fail if you tried to remove mirrored duplicates, but would have to handle de-duplication on an 8x16 level if in that mode. This certainly adds some complication, so I’ll take some time to think it through and maybe try to build some unit tests around it to help validate that I don’t break things.

Maxim wrote

I guess in 8x16 mode the tilemap data is sort of meaningless.

if you think about it not as 'tilemap data' but as a sprite reference sheet, it makes sense, and it can be used when duplicates are present, as in eruiz's original example

sverx wrote

Maxim wrote

I guess in 8x16 mode the tilemap data is sort of meaningless.

if you think about it not as 'tilemap data' but as a sprite reference sheet, it makes sense, and it can be used when duplicates are present, as in eruiz's original example

In fact, the optimal (for sprites) would be too have an additional setting to remove the empty tiles in both tile data and tilemap data.(putting a -1 by example when no tile to draw)

Also, only comment that a tilemap based complex Sprite definition is optimal, not only for speed when submitting sprites, but also to cut the array against borders and display the visible tiles only).

Honestly it's far easier, quick & precise to make a little script (C, python, etc) to use BMP2tile (ou png2tile) output to whatever needed.
As every game has is own particularity, it will never be perfect.

ichigobankai wrote

As every game has is own particularity, it will never be perfect.

I agree it won't ever be able to produce *every* possible output per se, but I think some improvements could greatly expand the possibilities

... and of course the fact that one can code their own exporter plugin is what makes it flexible enough to do everything anyway.

Author	Message
eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	BMP2Tile with 8x16 tiles Posted: Sat Sep 02, 2023 1:10 pm
	Ummm.... Maybe I am wrong, or I am missing something. If I use this command... ..\tools\bmp2tile\bmp2tile gfx\%1.png -8x16 -nomirror -removedupes -tileoffset 0 -savetiles assets\%1tiles.bin -savetilemap %1tilemap.bin I found that bmp2tile will build the tiles using the 8x16 pattern, as expected. But I wonder why not to build a 8x16 tile based tilemap, instead of a 8x8 one, as this (8x16)tilemap is of utility to manage sprite patterns. Also, I found that, in bmp2tile code, new[] { "8x16" }, "Treat image as 8x16 tiles (does not work will with duplicate removal)", Could this two questions be fixed? I found both of big utility if you want to use 8x16 sprites. (if not, I wouldl try to implement both functions using bmp2tile code, and post them here). Regards.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Sep 02, 2023 1:40 pm
	I didn’t see a use for an 8x16 tilemap. 8x16 is only really useful for sprites, and then you don’t want the tilemap data.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sat Sep 02, 2023 2:20 pm
	I explain... Since Galactic revenge, I use the createtilemap feature of bmp2tile to get tilemaps representing a bunch of frames of sprites which compose an animation (using the removing duplicate tiles feature of bmp2tile i save tiles, which often is mandatory, due to vdp limitations). By example, if you look in the image, will found that, by example, the two upper 8x16 sprites in each frame are the same in all the frames with the same direction, saving 16 tiles in total. Of course, I can load this image in mappy and optimize the output (the tiles and the tilemap as csv and then to bin)(by example) or do my own script to do this, but I feel this should be done by bmp2tile (as the master system has 8x16 sprites) (and bmp2tile optimize the tiles and should output a tilemap matching that optimization). All my games (after silvervalley) use 8x8 sprites so no trouble (until now). playertall.png (1.87 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sat Sep 02, 2023 4:41 pm
	I guess the idea is to de-duplicate the 8x16 regions, without flipping, and then emit just the low bytes as they are sprite tile indices? As BMP2Tile tilemaps are background tilemaps, they are 16-bit entries with flipping. It also treats tiles as 8x8 at all times, 8x16 mode simply changes the order that tiles are extracted from the image. Making it work for 8x16 sprites would definitely require a bunch of work…

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sat Sep 02, 2023 7:17 pm
	Well... I changed (minimally) your code to allow what I need. I only removed the creation of two tiles when you pass a 8x16 param, Next I changed the functions to do the same but with 8x16 tiles if needed. Finally, put a function to split the 8x16 tiles to 8x8 tiles before pass them to the compressor. More or less, I changed about twenty lines of code (should have clone your repository, sorry!!!) Do what you want with the code, merge it, fork the project, etc. or nothing, but I found sense in this upgrade. Regards. PD. Last but not least.... So many thanks to you for this awesome tool, I have used it near a miilion times since Baluba Balok ;) Love it! bmp2tile-master.zip (232.56 KB) Modified project

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Thu Sep 21, 2023 9:21 am
	I wonder if Maxim can somehow merge this mode into BMP2Tile because it indeed could be interesting...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Thu Sep 21, 2023 1:40 pm
	Yes, I plan to merge it some time soon after I understand it. It might be worthwhile to extend it to other sizes and “windings” within a larger tile, I had to do that for some parts of the Sonic editor.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Sep 24, 2023 10:52 am
	I'm looking at this now but it's opening more questions in my mind :) I think there are multiple issues to address which might require multiple ways to control it. The first is to consider the order in which tiles are extracted from the image. Currently this happens left to right, top to bottom, but 8x16 mode changes this to try to preserve ordering to match 8x16 sprites mode on the SMS VDP. In general, you don't care what tiles go in which indices, just that the 8x16 ones are in adjacent pairs. However, for some game hacking scenarios, the order is very important. The game might expect a certain order that is not easy to achieve sensibly in the PNG file. Next is the consideration of duplicate removal. Tile optimisation on 8x8 tiles already ordered for 8x16 mode can be catastrophic. If the de-duplication worked on the tiles as 8x16 then it would solve this, but that would preclude optimisation using mirroring. Thirdly we have the ordering of tilemap data in this scenario. Again we default to left to right, top to bottom; this being the VDP VRAM tilemap format. Plugins are at liberty to reorder things if wanted, or you can post-process the data some other way - I'm increasingly using Python scripts to do project-specific data munging. As described above, the goal is to emit only the initial tile index of the first tile of each 8x16 block - but not to try to include the x/y parameters too. That might be useful for cases where the image contains a "sprite sheet" and you might want to emit count + (index + x + y) * count data for each frame - but then the tool has no idea how big a frame is. In this particular change - now at https://github.com/maxim-zhao/bmp2tile/pull/25 - it seems the goal is mostly around part 2, to de-dupe at an 8x16 level, although it seems to also support 8x16 flipping; and also some of part 3. I'm not sure about merging it as-is, I will think some more...

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Sep 25, 2023 9:19 am
	A solution could be to have BMP2Tile work in two different modes: one is 'BG' mode, the other would be 'Sprite' mode. So, in BG mode you have only 8×8 tiles, and you optionally have duplicate removal, with additional and optional flip/mirror duplicate removal, plus additional and optional 'second' palette support and 'priority bit' support. The tilemap will then be a matrix of 16-bit values matching the hardware arrangement of the bits in each BG entry, and of course plugins can change this if needed. In Sprite mode you can pick either 8×8 or 8×16 mode. You can have duplicate removal, but no flip/mirror of course. The tilemap should then be a matrix that matches how the sprites are arranged on the sprite sheet, so nothing to deal with the hardware VDP' BG entries, because we're not in BG mode. It is probably a good idea to keep this 16 bits values - plugin can save to 8 bits values of course. On top of this - if I may - I would love to have a transpose option, to optionally have the BG arranged in column-major order, which would make it perfect for horizontally-only backgrounds (yes, I know one would probably better using metatiles, but many games would not even need that...)

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Mon Sep 25, 2023 4:30 pm
	I think that 8x16 mode is only for sprites. With my patch you have the tiles ordered as needed.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Sep 25, 2023 5:59 pm
	I guess in 8x16 mode the tilemap data is sort of meaningless. I have used it a bit, though, to allow correct ordering on some game hacks. I think I’d prefer to keep the current functionality, but then to extend it to support outputting sprite data; that would be single-byte tile indices, or optionally more verbose sprite sheet style data, including x and y offsets and omitting blanks. This would fail if you tried to remove mirrored duplicates, but would have to handle de-duplication on an 8x16 level if in that mode. This certainly adds some complication, so I’ll take some time to think it through and maybe try to build some unit tests around it to help validate that I don’t break things.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Tue Sep 26, 2023 1:44 pm
	Maxim wrote I guess in 8x16 mode the tilemap data is sort of meaningless. if you think about it not as 'tilemap data' but as a sprite reference sheet, it makes sense, and it can be used when duplicates are present, as in eruiz's original example

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Tue Sep 26, 2023 1:54 pm
	sverx wrote Maxim wrote I guess in 8x16 mode the tilemap data is sort of meaningless. if you think about it not as 'tilemap data' but as a sprite reference sheet, it makes sense, and it can be used when duplicates are present, as in eruiz's original example In fact, the optimal (for sprites) would be too have an additional setting to remove the empty tiles in both tile data and tilemap data.(putting a -1 by example when no tile to draw) Also, only comment that a tilemap based complex Sprite definition is optimal, not only for speed when submitting sprites, but also to cut the array against borders and display the visible tiles only).

ichigobankai Joined: 04 Jul 2010 Posts: 542 Location: Angers, France	Posted: Tue Sep 26, 2023 2:50 pm
	Honestly it's far easier, quick & precise to make a little script (C, python, etc) to use BMP2tile (ou png2tile) output to whatever needed. As every game has is own particularity, it will never be perfect.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Wed Sep 27, 2023 10:36 am
	ichigobankai wrote As every game has is own particularity, it will never be perfect. I agree it won't ever be able to produce every possible output per se, but I think some improvements could greatly expand the possibilities ... and of course the fact that one can code their own exporter plugin is what makes it flexible enough to do everything anyway.

Forums

View topic - BMP2Tile with 8x16 tiles