gconvert 2 bit PNG support

This forum is for artists to post their music and graphics or discuss artistic matters that could be used in Uzebox games.
Post Reply
User avatar
danboid
Posts: 265
Joined: Sun Jun 14, 2020 12:14 am

gconvert 2 bit PNG support

Post by danboid » Sun Oct 30, 2022 2:52 pm

I had the CRAZY idea of wanting to add a title screen to my mode 3 game but is that a doable thing considering the restrictions of the UB ROM and using gconvert to convert the image? gconvert insists on using an 8-bit PNG as the input and when I feed a full 256x224 PNG into gconvert I get a ~180K include file, which I suspect isn't going to fly.

What if gconvert added support for 2 bit PNG files as input so that the resultant include file of a full screen image would only be more like ~45K? I've got more of a chance of squeezing that into the rom then but would I have to do something clever to display it to convert it back into 8-bit?

User avatar
nicksen782
Posts: 703
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: gconvert 2 bit PNG support

Post by nicksen782 » Tue Nov 01, 2022 6:11 pm

How complex is your title screen? Some games such as B.C. Dash (https://uzebox.org/wiki/B.C._Dash) reuse the game tiles as the title screen. The only extra flash cost would be for the title screen map itself. If you can make it a collection of smaller maps then the space between the individual graphics could just be a background tile using Fill or something.

When I was working on a Zelda clone I quickly found out that the size of the maps themselves were more costly than the size of the individual tiles. I used the SD card and later SPIRAM to hold the tilemaps.

Being able to draw tiles in a different format would either require a change to the kernel to draw those types of tiles OR you could do something with RAM tiles. If the title screen doesn't have sprites then just temporarily turn off the sprite engine and use SetRamTile after copying/generating data into the ram tiles array.

What does your title screen look like?

User avatar
danboid
Posts: 265
Joined: Sun Jun 14, 2020 12:14 am

Re: gconvert 2 bit PNG support

Post by danboid » Tue Nov 01, 2022 9:31 pm

See

https://github.com/danboid/IKD/blob/mai ... scaled.png

It seems that if I use RAM tiles, I would have to be able to reduce my image to 255 tiles whereas a mode 3 title screen where every tile is unique would require closer to 900 tiles so would it be possible to rapidly cycle between 3 or 4 RAM tile banks, one bank for each third / quarter of the screen? I do not need sprites for the title screen.

I've had a quick read of this page:

http://uzebox.org/wiki/Ram_Tile_Effects_Primer

The most interesting bit of which to me was this section:

"I have also implemented sprite compression to 16 colors or 4 bits per pixel, further reducing the cost of sprites to about 12.5% of what it would have normally been. It has been a huge difference, and I am of the opinion this is a very important thing to have in the kernel as an option. Hopefully by demonstrating its effectiveness, we can come up with a universal solution for 4bpp and 2bpp applications."

Maybe that was never completed or it just wasn't publicly released but it sounds like that (Megabomber) sprite compression might be useful to me?

User avatar
nicksen782
Posts: 703
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: gconvert 2 bit PNG support

Post by nicksen782 » Wed Nov 02, 2022 5:24 pm

485 unique tiles in your image. The black tile is used 366 times where most the other tiles are used once or twice and occasionally six times. I've attached a picture from GconvertJS to illustrate how many unique tiles are in your image. Before you start going technical and changing the kernel you should try to see if you could reduce the number of tiles used by your graphic. If you open the attached graphic in something like GIMP/Photoshop and show 8x8 pixel grid lines you can see how you are creating tiles where you don't need to. For an example look to the top-right and you'll see how there is a pixel column on the right that creates two unique tiles. You could just change your image to remove those pixels and nobody would notice or just shift that part to the left one pixel for the same effect. The lines for the tank use a lot of diagonal lines which are hard to reuse in their current state. Look to the PROGMEM OUTPUT on the right to see how many times a tile is actually used by a map. I added that part as comments since I like knowing that sort of stuff.

If you would like to generate the image that I did then go to nicksen782.net and "Online Uzebox Gconvert", load the MegaTris demo files (TEST DATA on the right) and replace the tilemaps in the right section with this:

Code: Select all

<?xml version="1.0" ?>
<gfx-xform version="1">
 <input file="input_templates/img_template1_Uzebox_MegaTris.png" type="png" tile-width="8" tile-height="8" />
 <output file="data/graphics.inc">
 <tiles var-name="tetrisTiles" />
 <maps pointers-size="16">
  <map var-name="map_main" left="0" top="0" width="32" height="28" /> 
 </maps> 
 </output> 
</gfx-xform> 
Then copy and paste your image into the center canvas. Double click that canvas and press control+v.

Load maps into editor, process, and you'll see the results. The image that you want is on the left. It just shows which tiles of the source image were unused or duplicates. There is a little version of the graphic there that you can right-click and copy and then paste into an image editor.

... But, if you do find a "secret" part of the videomode 3 that draws tiles as you suggest then I would really really like to know about it. Jubation has some other video modes that do something like that too.
Attachments
dedupedTileset.png
dedupedTileset.png (11.93 KiB) Viewed 280 times

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests