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