OpenBOR

OpenBOR 4.0 4.0 Build 7735

No permission to download
Overview Updates (5) Reviews (6) History Discussion
Borkjh said:
One more question, can I convert openbor 3.0 games to 4.0?
Click to expand...
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.
 
Last edited:
Bruce said:
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.
Click to expand...
I just play old openbor games at openbor 4.0 android.
 
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:
Code: 
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
 
kimono said:
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:
Code: 
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
Click to expand...

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
 
DCurrent said:
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
Click to expand...
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:
Code: 
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.
 
kimono said:
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:
Code: 
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.
Click to expand...

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.

OpenBOR DCurrent

Resource update in 'OpenBOR'

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...
  • Like
  • Love

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


DC
 
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.
 
...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
 
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
 
The only time I use GIFs is for alternative color palettes because these images allow me to have an optimized color palette.
 
Smart Kitty said:
ye png is better, using gifs are the reason why some old projects are very heavy in space.
Click to expand...
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.

DCurrent said:
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".
Click to expand...
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 :)
 
kimono said:
The only time I use GIFs is for alternative color palettes because these images allow me to have an optimized color palette.
Click to expand...

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, and the .png file is a bit smaller in your module.

However, as @O Ilusionista siad, .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 imputus for getting rid of .gif is that since .png is better, however slightly, then it's foolish to support in the codebase and in documentation. One right tool for the job.

DC
 
You must log in or register to reply here.
Back
Top Bottom