OpenBOR 4.0 4.0 Build 7735

[Bruce]

One more question, can I convert openbor 3.0 games to 4.0?

What is your goal for converting to 3.0 to 4.0? If the game was made for 3.0, I think it is best to just leave it alone unless the developer updates it to 4.0.
If you decide to move on,
I would recommend you to read the whole forum.
There are new functions don't work properly. At least for the ones that I reported a while back.
There are bugs in this 4.0...
I give an example, falldie 1 works,
but falldie 2, death animation never triggers. for me Not a big deal, I can just use falldie 1.
and the unresolved walk off screen bug that I reported.


If I were you, I would wait until more tests on this 4.0.

 

[Borkjh]

What is your goal for converting to 3.0 to 4.0? If the game was made for 3.0, I think it is best to just leave it alone unless the developer updates it to 4.0.
If you decide to move on,
I would recommend you to read the whole forum.
There are new functions don't work properly. At least for the ones that I reported a while back.
There are bugs in this 4.0...
I give an example, falldie 1 works,
but falldie 2, death animation never triggers. for me Not a big deal, I can just use falldie 1.
and the unresolved walk off screen bug that I reported.


If I were you, I would wait until more tests on this 4.0.

I just play old openbor games at openbor 4.0 android.

 

[kimono]

A question regarding the latest version 4.0: can we confirm that ACT palettes are no longer supported?
If so, is there an equivalent system for level palette changes like in Golden Axe?
An example:

palette data/bgs/wilder/pals/mist1.act 0 1 0 0 0 1         #1

palette data/bgs/wilder/pals/mist3.act 0 1 0 0 0 1         #2
palette data/bgs/wilder/pals/mist5.act 0 1 0 0 0 1         #3
palette data/bgs/wilder/pals/mist7.act 0 1 0 0 0 1         #4
palette data/bgs/wilder/pals/sunny.act 0 1 0 0 0 1         #5

palette data/bgs/wilder/pals/sunset2.act 0 1 0 0 0 1       #6
palette data/bgs/wilder/pals/sunset4.act 0 1 0 0 0 1       #7
palette data/bgs/wilder/pals/sunset6.act 0 1 0 0 0 1       #8
palette data/bgs/wilder/pals/sunset8.act 0 1 0 0 0 1       #9

#palette change
setpalette 1
at 0

 

[DCurrent]

A question regarding the latest version 4.0: can we confirm that ACT palettes are no longer supported?
If so, is there an equivalent system for level palette changes like in Golden Axe?
An example:

palette data/bgs/wilder/pals/mist1.act 0 1 0 0 0 1         #1

palette data/bgs/wilder/pals/mist3.act 0 1 0 0 0 1         #2
palette data/bgs/wilder/pals/mist5.act 0 1 0 0 0 1         #3
palette data/bgs/wilder/pals/mist7.act 0 1 0 0 0 1         #4
palette data/bgs/wilder/pals/sunny.act 0 1 0 0 0 1         #5

palette data/bgs/wilder/pals/sunset2.act 0 1 0 0 0 1       #6
palette data/bgs/wilder/pals/sunset4.act 0 1 0 0 0 1       #7
palette data/bgs/wilder/pals/sunset6.act 0 1 0 0 0 1       #8
palette data/bgs/wilder/pals/sunset8.act 0 1 0 0 0 1       #9

#palette change
setpalette 1
at 0

Confirm? Where on Earth did you get that idea in the first place? The .act palettes are what you're supposed to use. Support is not dropped and there are no plans to.

DC

 

[kimono]

Confirm? Where on Earth did you get that idea in the first place? The .act palettes are what you're supposed to use. Support is not dropped and there are no plans to.

DC

The ACT palettes are an old mechanic, and while testing the game in 4.0,
I had a problem with a level that wouldn't load.

Finally, according to the log, it's possible that this is due to this function:

openborconstant("FRONTPANEL_Z")

Sorry, I shouldn't make assumptions like that and should do more research.

I'll look into this with @Kratus since it's part of one of his CPU Partner scripts.

 

[DCurrent]

The ACT palettes are an old mechanic, and while testing the game in 4.0,
I had a problem with a level that wouldn't load.

Finally, according to the log, it's possible that this is due to this function:

openborconstant("FRONTPANEL_Z")

Sorry, I shouldn't make assumptions like that and should do more research.

I'll look into this with @Kratus since it's part of one of his CPU Partner scripts.

FRONTPANEL_Z as you have it is indeed an issue, and is well documented in release notes. 3.0 had several values incorrectly exposed as constants when they are in fact mutable system variables. These are fixed in 4.0.

Resource update in 'OpenBOR'

Dec 31, 2023

This is the first release of OpenBOR 4.0, representing over five years and 1,139 updates to the source code. In order to avoid yet more delays and keep the promise I made to release before year end, there are still elements in progress that I will be finishing up in the coming weeks. However...

• DCurrent
• Engine

• 
• 

As noted there, if you run into a "constant" that doesn't work, it is probably found here:

System Variables – OpenBOR Wiki

DC

 

[kimono]

Thanks Damon, that's a big help .

I have a few questions, but I'm not sure if I can post them here.
For example: is arrow.png accepted in 4.0, or is it necessary to stick with arrow.gif for the "Go" arrow in sprites?
I would prefer to use PNG images as much as possible rather than GIFs.

 

[DCurrent]

For example: is arrow.png accepted in 4.0, or is it necessary to stick with arrow.gif for the "Go" arrow in sprites?

You can (and should) use "arrow.png". This goes for fonts too, and pretty much everything else.

DC

 

[DCurrent]

...adding to the above, eventually, I will fully depreciate .gif other than for cut scene playback - and at some point I might even remove that.

For sprites, it's just simple black and white. Png is better, full stop. As time goes on it has wider support, more future-proofing options, roughly 20% greater compression, and (in 4.0 only) slightly better load time. There is no reason at all to support two formats in code that do the exact same thing when one objectively superior. The fact we support .gif at all is one of the many reasons outsiders take one look at the engine and dismiss it as not "modern".

Cut scenes are not quite so obtuse, but even there .gif is severely outdated. Cut scenes in .gif used to be a necessity when you were limited to ~30 frames per model animation and we had no timing control, script, or webm support. Those limitations haven't been a thing for some 15 years now. I think it's time to let .gif die.

DC

 

[Smart Kitty]

ye png is better, using gifs are the reason why some old projects are very heavy in space. maybe in the future cutscene stuff gets improved with video support. But well I am very happy with what 4.0 is so far, very good sort of options to set free your imagination

 

[kimono]

The only time I use GIFs is for alternative color palettes because these images allow me to have an optimized color palette.

 

[O Ilusionista]

ye png is better, using gifs are the reason why some old projects are very heavy in space.

As someone who works professionally with images all day, I have to disagree with you here for two reasons:

1- What made those old projects large wasn't the difference between GIF and PNG, but rather sound effects and music. Many people used stereo sound effects at 41kHz (even though stereo makes no difference here) and stereo music in .bor format.

In the case of music, stereo can make a difference in certain situations. When you change the format from .BOR to .OGG, the difference is quite large – much more so than the difference between .PNG and .GIF.

I've helped some people reduce the size of their game .pak files just by reducing the number of sound effect channels and lowering their quality to 22kHz. If you use optimized .OGG, the difference is even greater (I use this in my projects).

2- PNG isn't always lighter than GIF; it's not a rule. There are several factors that can affect this:
- GIF encoding type (GIF87a, GIF89a, LZA compression, etc.)
- Image size
- PNG compression type (interlacing)

Many people used GIFs in games (as is my case) because version 3 had a problem where using PNG increased the game's loading time, which was only fixed after a long time.

If you use interlaced PNG, the chance of increasing the loading time is real.

The fact we support .gif at all is one of the many reasons outsiders take one look at the engine and dismiss it as not "modern".

But that's their problem and their ignorance, since we're talking about 8-bit images in most cases – there's nothing an 8-bit PNG can do that an 8-bit GIF can't.

Of course, this changes when we're talking about 16-bit images.

Interestingly, trying to work with 8-bit images and palettes in the "modern" Unity is a nightmare

 

[Smart Kitty]

wow, you really work with images all the time lul

 

[DCurrent]

The only time I use GIFs is for alternative color palettes because these images allow me to have an optimized color palette.

No - no they don't. There is nothing what so ever optimal about .gif compared to .png, ever. Png has a stronger compression algorithm. It just does, this is a mathematical fact. If you are getting better compression from .gif, then you have a setting wrong in your tool-chain somewhere.

In the case of palettes, .act is even better than that, because there's nothing but palette information. One 8bit (256 entry) .act file is exactly 768 bytes.

To get really technical, it doesn't matter anyway once loaded. OpenBOR isn't shuffling .png or .gif files around the screen. It doesn't work that way. On load, it reads the image contents, makes a copy with all the uneeded transparency areas trimed away, places that into a sector of allocated memory as raw pixel data (AKA a sprite), and dumps the orginal. That process just happens to be a little faster with .png (in 4.0), and the .png file is a bit smaller in your module.

However, as @O Ilusionista said, .gif is not the reason for module bloat. The compression advantage of .png (~20%) is small potatoes when most images are no more than a few kilobytes each. The impetus for getting rid of .gif is that since .png is better, however slightly, then it's foolish to support both in the code-base and documentation. One right tool for the job.

DC

 

[DCurrent]

2- PNG isn't always lighter than GIF; it's not a rule. There are several factors that can affect this:
- GIF encoding type (GIF87a, GIF89a, LZA compression, etc.)
- Image size
- PNG compression type (interlacing)

But it is. Those are edge cases where you do everything possible wrong with .png and everything right with .gif, (which I kind of covered mentioning tool-chain settings above) and bringing them up only causes more confusion. In singular flat 8bit bitmaps, which is what we're talking about - and the only thing you can use here, .png's Deflate always beats .gif's LZW.

Though I would point out again, it's all a wash once the file is loaded. There is no such thing as a .gif or .png sprite. It's just raw pixel data, small as you can ever get, stored in the hardware memory.

DC