Commission for OpenBOR to accept transparent PNG in game

[Aerisetta]

Hi,

Here is my situation and my issue. This is more of a commission request.

The games I make usually include a lot of cut scenes like a visual novel. Those cutscenes have images. The images are made in full 32 bit transparent PNGs.

Right now, in order to overcome the challenge of the game not accepting the PNGs as is, I need to take many steps
1. go into gimp
2. add stroke (to prevent weird outlines when it changes to 256 color)
3. add transparent background color
4. change to 256 colors
5. rearrange the color map to set transparent color
6. make 0 0 0 black not black

I need to do this repeatedly for each image, 100+ images a week (sometimes can batch) In the end, the result is something of lower quality, and I am also purposely avoiding the use of gradients because the result of those is something wonky.

This is something that really hampers my workflow, if the engine can just accept transparent PNGs, it will cut down my workload many hours per week.

I know I make "unconventional" games and this is not how most people use the engine, I don't know how much time or changes to the engine it would require...so I will be very happy to discuss this as a commission and pay for whatever time it takes.

There is also the technical issue of file size. I actually do not care about storage size, BUT i am worried the game cannot handle loading all these larger files. Something to figure out.

This is an example image.




I need to turn it into this

 

[oldyz]

@Aerisetta -
I use transparent PNGs for NSX sprites


I do all the image editing & manipulation on RGB color, save, transform to 256, deactivate layers - export layer by layer...
they all have alpha channel

i do not export layers as image files because they would fail the few times i tried - but they might have failed because of this next weird reason:

A problem i had faced with Gimp was the fact that even tho i chose to convert images to 256 colors, after exporting some images turned into 7,9,16, 32, 87 - etc, color images & Openbor would crash...

The old method i had to resolve this , was to cut from gimp & paste to Fighter factory (it would "magically " fix the palettes ) & then save

My new method to solve it is by making sure i have layer featuring a gradient fill, the gradient fills the gaps & forces the exported images to always feature 256 colors -
the gradient layer is deactivated before exporting - of course.
only use this method if you find Openbor crashing with an image that gimp exports with weird low numbers..

another thing of note is the fact that entities do not need to have a palette file, so your cinema entities can feature frames that are only limited by the 256 color palette.

Now , i am not sure - but i think that the only drawback is that transparent pngs stress the systems a bit more, as well as entities with no palette file -
my module would probably be of less size if it where optimized in the graphics department...

 

[oldyz]

Bout the huge size - you might have to cut them to tiles & use spawbind to load them

 

[Aerisetta]

@Aerisetta -
I use transparent PNGs for NSX sprites


I do all the image editing & manipulation on RGB color, save, transform to 256, deactivate layers - export layer by layer...
they all have alpha channel

i do not export layers as image files because they would fail the few times i tried - but they might have failed because of this next weird reason:

A problem i had faced with Gimp was the fact that even tho i chose to convert images to 256 colors, after exporting some images turned into 7,9,16, 32, 87 - etc, color images & Openbor would crash...

The old method i had to resolve this , was to cut from gimp & paste to Fighter factory (it would "magically " fix the palettes ) & then save

My new method to solve it is by making sure i have layer featuring a gradient fill, the gradient fills the gaps & forces the exported images to always feature 256 colors -
the gradient layer is deactivated before exporting - of course.
only use this method if you find Openbor crashing with an image that gimp exports with weird low numbers..

another thing of note is the fact that entities do not need to have a palette file, so your cinema entities can feature frames that are only limited by the 256 color palette.

Now , i am not sure - but i think that the only drawback is that transparent pngs stress the systems a bit more, as well as entities with no palette file -
my module would probably be of less size if it where optimized in the graphics department...

thanks but unfortunately that takes a lot of time for me to set up each image as well and does not solve my problem.

Also, the story systems that I use to create these cutscenes will require a huge overhaul to spawn images like. Not feasible.

 

[oldyz]

@Aerisetta -

the only thing i have not tested is exporting them as layers using a batch command -

but if the gradient layer trick works with them too - after you export them all (the layers) you end up with pngs that are transparent & compatible
you wont need to turn every sprite with green or magenta & you can discard the exported gradient layer -

if i have time i will test & send you a Gimp file with instructions -

if there is no way to make it work with gimp alone, then the other option is to use ffmepeg or some other program to turn a folder of images to an optimized set with transparency included and a 256 color limit applied to all of them....

there is a mention of a program around the forum that converts images in a batch, but i cant recall the name

 

[Kratus]

The games I make usually include a lot of cut scenes like a visual novel. Those cutscenes have images. The images are made in full 32 bit transparent PNGs.

In case you don't care about the total pak size, I suggest making the cutscenes in webm format at least for the ones that the player does not need to interact with dialogs.

You can render directly to webm on Adobe Premiere or use the combo Sony Vegas + XMedia Recode to reduce the webm file's size.
By using this method on static images, I was able to create 1mb files (or less) depending on how many different images the cutscene has. If you create animations the files can have around 30mb each for 1 min cutscene.

A problem i had faced with Gimp was the fact that even tho i chose to convert images to 256 colors, after exporting some images turned into 7,9,16, 32, 87 - etc, color images & Openbor would crash...

As a suggestion, you can solve this issue by using single/batch manipulation on PalApply v2.0.3

 

[oldyz]

@Aerisetta -
thanks @Kratus -

so basically you export all your transparent PNGs as normal, then use PalApply to apply the palette correction to all of them in a batch
(replace the alpha channel w green- if its possible - if necessary)

 

[Kratus]

so basically you export all your transparent PNGs as normal, then use PalApply to apply the palette correction to all of them in a batch

Basically yes, but before at least for the source image, you need to convert it to an indexed palette on Gimp instead of leaving it in RGB format, otherwise the PalApply will not recognize the source palette. You don't need to convert all your sprites to an indexed mode, PalApply does it automatically while applying the palette.