Plombo's to-do list

Plombo said:
Look into the possibility of using 24-bit PNGs for backgrounds (not sprites).  The framework for this is already in place, we just don't have a 24-bit PNG loader even already have a 24-bit PNG loader which we use for the OpenBOR logo/menu graphics.

Well, I looked into it.  Here's the rundown:
  • For static backgrounds (title screen, loading screens, etc.) it should be doable with a bit of work.  In 16/32-bit mode, these use a global s_screen variable called "background" with pixelformat PIXEL_x8, and loading one of these backgrounds just updates the contents of the background without reallocating it.  The load_background() and unload_background() functions (and load_cached_background() used by the Wii) will need to be changed to allow PIXEL_32 backgrounds to be loaded as well by reallocating the background if necessary.
  • For the furthest-back layer of level background, there are no glaring issues.
  • For other background/foreground layers, there is the glaring issue of transparency.  32-bit images don't have a transparent color like 8-bit ones, so we have the problem of defining which colors should be transparent.  The easiest solution to this problem would be to use the unused color channel in PIXEL_32 color for an alpha channel, and add a new blending mode to drawmethod where the source color replaces the destination color if and only if its alpha != 0.
 
The question now is how do you make a 32/24 bit png that can utilize that channel, probably make a utility that adds that on the PNG?

Tusubasa said:
Will it be possible to change the menu openbor? Have we have the opportunity to make our own menu?
Some people have claimed to have done that, Battletoads mod for example, but the thing's too tedious to do  considering using a lot of advanced scripting. I think it's better if Chronocrash would do its own UI commands via script to make the menu for your own.
 
Only instances when i would like to use png graphics with alpha channel is for foreground out of focus elements  to create shallow depth of field effect and for blending panel with background like on this pic :
Rayman7.jpg

It would be also useful for other semi-transparent effects like flares or smoke but this can be done already even with gif files and alpha drawmethod.
It wouldnt change much if i could use more than 256 colours for backgrounds, i rarely have issues with not enough colours in palette.Im also wondering if performance hit wouldnt be too big with 24bit pngs

 
CRxTRDude said:
The question now is how do you make a 32/24 bit png that can utilize that channel, probably make a utility that adds that on the PNG?

The PNG format already has support for an optional 8-bit alpha channel in 24-bit RGB images.  You can easily create such PNGs in GIMP or Photoshop.

bWWd said:
Only instances when i would like to use png graphics with alpha channel is for foreground out of focus elements  to create shallow depth of field effect and for blending panel with background like on this pic :
...
It would be also useful for other semi-transparent effects like flares or smoke but this can be done already even with gif files and alpha drawmethod.

If a fully customizable alpha channel is all you want, it should already be doable with alpha masking, no?

bWWd said:
It wouldnt change much if i could use more than 256 colours for backgrounds, i rarely have issues with not enough colours in palette.Im also wondering if performance hit wouldnt be too big with 24bit pngs

There would definitely be a performance hit, but I don't think it would be much worse than the performance hit that you already get from alpha blending.
 
Plombo said:
The PNG format already has support for an optional 8-bit alpha channel in 24-bit RGB images.  You can easily create such PNGs in GIMP or Photoshop.

Oh, I thought you would make some utility for it.

Speaking of performance, that depends on how many are drawn right and I don't know if it's related, but I think it also has to do with the way the PNG is drawn to the screen and its garbage collection I guess ... Just saying
 
CRxTRDude said:
Plombo said:
The PNG format already has support for an optional 8-bit alpha channel in 24-bit RGB images.  You can easily create such PNGs in GIMP or Photoshop.

Oh, I thought you would make some utility for it.

It's "Your source for useful modding tools".  No need to reinvent things that existing programs already do well. ;)

CRxTRDude said:
Speaking of performance, that depends on how many are drawn right and I don't know if it's related, but I think it also has to do with the way the PNG is drawn to the screen and its garbage collection I guess ... Just saying

By time they're drawn to the screen, they're not PNGs anymore - they're 32-bit (PIXEL_32) screen objects in memory.  They work the same way as regular 8-bit (PIXEL_x8) screens as far as "garbage collection" goes.
 
Plombo said:
Plombo said:
Look into the possibility of using 24-bit PNGs for backgrounds (not sprites).  The framework for this is already in place, we just don't have a 24-bit PNG loader even already have a 24-bit PNG loader which we use for the OpenBOR logo/menu graphics.

Well, I looked into it.  Here's the rundown:
  • For static backgrounds (title screen, loading screens, etc.) it should be doable with a bit of work.

As of r4094 a few minutes ago, 24-bit PNGs are now supported in 32-bit color mode for these static backgrounds.  So your data/bgs/title.png, data/bgs/select.png, etc. can now be true color PNGs as long as the color depth for the mod is set to 32-bit.
 
Plombo said:
As of r4094 a few minutes ago, 24-bit PNGs are now supported in 32-bit color mode for these static backgrounds.  So your data/bgs/title.png, data/bgs/select.png, etc. can now be true color PNGs as long as the color depth for the mod is set to 32-bit.

Really? That is awesome to know. Its possible to complile this version for us to use?
 
Great work ! Do you think it would be possible to do it for backgrounds ingame (fglayer/bglayer and panel ) and characters so everytjing woould blend nicely using alpha channel in pngs ? I know characters would lose remaps and this is understandable, not really a big deal for me considering such step forward.
I know there is alpha masking feature and i tried it with not much success, it is a bit painful to create separate alpha frames for all animations.Most convenient method would be using alpha channel inside of png's.
I tried some game engines awhile ago and most of them support even jpegs for static backgrounds without transparency effects and 32bit png's or gifs for sprites, some games use different style of graphics than pixel art so 32bit pngs would be useful.
I suspect is a lot of work to code it but since youre on it now then its worth to ask, and i can only speak for myself, i know i will be using 32bit pngs if they will be supported.
Now if only someone could recompile all ports with 32bit support for bgs  ;D
 
bWWd said:
Great work ! Do you think it would be possible to do it for backgrounds ingame (fglayer/bglayer and panel ) and characters so everytjing woould blend nicely using alpha channel in pngs ?

I'm planning to add support for in-game backgrounds at some point.  Characters, though, are staying as they are for a variety of good reasons.  In addition, 24-bit PNGs in backgrounds won't support a full alpha channel, and might or might not support regular drawmethod alpha blending.

(rest of post)

A better solution would be to release a tool to make alpha mask creation less painful.  I already have something on my hard drive that's like a combination of PalApply and an alpha mask generator.  You give it a 24-bit PNG with alpha and a palette, and it generates both an indexed version and a compatible alpha mask.  It might need to be cleaned up for release though.

 
Im using palapply all the time , it saves me so much work, i copy pasted every frame into mspaint to save it.Something like this for alpha mask would be perfect.
 
So I just spent the last 6 hours working on a release-worthy version of the aforementioned software.  The actual image manipulation program is all ready to go in the form of a lightweight command line program, but people always demand graphical interfaces for these things, so I've been working on a GUI.  It's mostly done now, but I still have to actually connect it to the command line tool.  There should hopefully be a release sometime in the next few days.
 
Just a question of curiousity, what do you use to make a GUI for Windows and stuff, do you use something like WxWidgets or just your own implementation of the MFC?
 
CRxTRDude said:
Just a question of curiousity, what do you use to make a GUI for Windows and stuff, do you use something like WxWidgets or just your own implementation of the MFC?

I don't make enough GUIs to really have a standard for creating them.  This time, I decided on a whim to try out Gtk# (.NET/Mono), which was a bad idea because the documentation for Gtk# is so scarce that it makes OpenBOR seem well-documented by comparison.

I do generally like GTK though, and the closest thing I have to a standard for GUI creation is using either C or Python with GTK+, and designing the interface with Glade.
 
A better solution would be to release a tool to make alpha mask creation less painful.  I already have something on my hard drive that's like a combination of PalApply and an alpha mask generator.  You give it a 24-bit PNG with alpha and a palette, and it generates both an indexed version and a compatible alpha mask.  It might need to be cleaned up for release though.

I don't use PalApply for converting images (I do prefer to use Fighter Factory to do that), but a combination of both tools will be handy, for sure.
 
Plombo said:
I do generally like GTK though, and the closest thing I have to a standard for GUI creation is using either C or Python with GTK+, and designing the interface with Glade.

I recommend Python + Qt  if you haven't tested it yet.
 
Plombo, how hard it would be to implement animated gif support for things like data/bgs/title.gif, data/bgs/select.gif, etc ?
 
Back
Top Bottom