Open MatthewCallis opened 12 years ago
+1! Or even just a way to change the main background image, if possible. Like placing a .PNG with the correct dimensions (256x224? 512x448?) in the sd2snes directory. Thank you!
I don't think PNG is a good solution, something like a raw bitmap should be better. (PNG and other compressed file format need processing power to be decompressed and displayed)
Edit: A simple PNG source (for exemple LodePNG: http://lodev.org/lodepng ) will generate a 33KB ARM object file with nearly all options disabled:
$ gcc lodepng.c -DLODEPNG_NO_COMPILE_ENCODER -DLODEPNG_NO_COMPILE_DISK -DLODEPNG_NO_COMPILE_ERROR_TEXT -DLODEPNG_NO_COMPILE_ANCILLARY_CHUNKS -DLODEPNG_NO_COMPILE_CPP -c -o lodepng.o && ls -lah lodepng.o -rw-r--r-- 1 godzil godzil 33K 5 juil. 18:02 lodepng.o
Oh sure, an uncompressed format (raw bitmap - .BMP) would be totally fine as well!
Color reduction would probably take too long to be performed on the fly, and there are lots of reserved palette entries for fonts and sprites (the lower part of the logo gfx (behind the file list) is actually made of manually placed sprites). Also with a new logo image you'd probably want to change the background gradient to something else, too, which in turn means tweaking the HDMA tables. So some preprocessing has to be done on the PC side before everything fits together. I'll most likely go the route of devising a "skin file format" including fonts, palettes, BG gfx, sprites, and HDMA tables and creating a PC tool to create such skins. Or if anyone else wants to do it - be my guest... ;)
Make the format and I'll make the tools!
I made a webapp to create custom skins a couple months ago and just found this issue, so for anyone curious: here is a link to it. It doesn't support the sprites behind the text just to make it simpler, but you can change pretty much everything else.
Thanks much Dotsarecool, it works perfectly! What I'm confused about is the Quality dropdown menu: why would anyone not want max quality (50)?
Hey @Dotsarecool. Again, great job on the skin creator!
My apologies for requiring a ROM hack to replace the assets at the moment. ;) I'm working on and off on a skin file format and some changes to the VRAM layout in general. One idea is to switch to 32x32px sprites so it would be possible to actually get a 4x15-color full screen backdrop behind the file list. Also there will be enough space in the HDMA tables to change the background color every scanline.
I think it would be cool if you were willing to change your skin creator to output that file format in the future! It's planned for v1.9 though, so there's no hurry ;) If you are interested I can give you the preliminary specs.
In the meantime I'll gladly give you the new offsets of the present data structures whenever I put out a new version of menu.bin.
That sounds great, I would totally be willing to do that. It's cool to see work is still being put into the visuals after all this time.
And @TheShadowRunner , mainly because the color reduction function can take a long time to run if you set the quality really high. It was there as a debug feature but I just left it in because it is fun to mess with.
Dotsarecool, happy to report menu v0.1.7e still works ok with your webapp except a small cosmetic bug: At "Main Menu" > "Configuration" > "BSX Settings" > "Custom Time", the font color is all weird after using the webapp. It's green in the original menu.bin. Can you reproduce? (I export only the Image btw)
I just checked and all the addresses for the graphical assets (font, logo, sprites, palette, color bar tables, bg color table) are the same as v0.1.7d... I wonder what's up :)
I think I know what's up :) The tool allocates too many colors to the logo graphics.
2-bit palettes 0-7 (indexes 0-31) are reserved for font colors. These also need to be mirrored to the first 4 indexes of 4-bit palettes 0-7. (Font palette 4 is actually a dummy copy of palette 1 because of the overlapping indexes.)
In addition, sprite palettes 4-7 (indexes 192-255) are reserved for sprites (but they may be used for the logo as well if no sprites are used), and sprite palette 3 (indexes 176-191) is reserved for GUI element sprites (cursors etc).
This is what the stock palette looks like:
The colors outlined in white are actually usable for the logo (120 colors total).
The purple colors are either unused (sprite palette 3) or unusable (index 0 of each used sprite palette).
Thanks for looking into it and the advanced details Ikari, I hope Dotsarecool can use this info to further enhance the webapp (even if it's a really minor issue tbh ^^;).
Now we could get crafty and allocate some more colors for the logo that are otherwise unreachable anyway, e.g. index 0 of each 2-bit palette and 4-bit palette used for the text layers, and index 0 of each sprite palette, yielding 18 more colors. BTW sprite palette 4-7 (as opposed to 0-3, or 0-7) are used for the sprite overlays because only sprites with these palettes can participate in color math. Otherwise they'd stick out through the selection bar.
To maximize colors for the logo I only preserved colors I knew were used by the text, so I didn't save all 8 palettes. But I just updated it so they are now all saved--the BS-X clock color should now be fixed if you use the newest version. And thanks for that palette image, it really helped!
Thank you both, the (mini) bug is fixed ;)
A skin-able UI would be awesome. It doesn't have to be made easy to maintain all the feature, but being able to build the tilemap / graphics would be awesome.