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
OpenBOR 4.0 4.0 Build 7735
- Thread starter DCurrent
- Start date
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
Well-known member
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")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.
As noted there, if you run into a "constant" that doesn't work, it is probably found here:
DC
kimono
Well-known member
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.
.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.
You can (and should) use "arrow.png". This goes for fonts too, and pretty much everything else.
DC
...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
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
Well-known member
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
O Ilusionista
Captain 100K
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.
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
Well-known member
wow, you really work with images all the time lul
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
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
Missed this - yes, it is their ignorance. It's still OUR problem. Perception matters, marketing matters, and for a community to thrive it has to attract new blood. Every time some potential talent cracks open a game module to find archaic image types or gets told by someone somewhere "you have to use .gif", laughs and moves on to Unity or GoDot, that's a loss for us and them.
It's just like supporting multiple packs has the wider world convinced OpenBOR is some kind of emulator. We're the ones who have to deal with the repetitive questions and complaints about the engine being trash when that blows up in their faces. We have to deal with ChatGPT and Google AI telling potential users OpenBOR is not a modern engine because according to them it's compulsory reliant on methodlogies that are only there because of backward compatability.
Now obviously we can't fix human nature, nor can we redo things all in one big swoop, but this is low hanging fruit.
Supporting .gif has no benefit outside of inertia. It just costs me time and the community confusion. If you have an existing project on an existing engine - nothing changes for you. It's not like I can retroactively go back and break things. If you want to port it up, then you run a batch job to swap the formats and the text extensions. Five minutes flat.
DC
Smart Kitty
Well-known member
anyways I'll use OpenBOR no matter if the image format used is png, gif or even bmp
Once upon a time, you COULD. We supported .bmp, and .pcx too, but that was before I was involved. Why on earth the engine would support .bmp I'll never know, but I'm sure there was a good reason at the time.
You also missed out on the global palette stuff. The early engines were 8bit color. Not 8bit sprites, an 8bit screen. As in, one global 8bit palette at any given time. For everything. Fun stuff. For a while after that, it was still the default mode of three (8bit, 16bit, and 32bit color). Caused a lot of problems and cost us a lot of new blood who got a bad impression and walked away before we could explain it was a backward compatibility thing. So I nixed it fully and made the engine 32bit color only. The sky didn't fall.
DC
Smart Kitty
Well-known member
ah I see 
. OpenBOR has a loooong history, could be interesting have something that describes its evolution, like "Openbor evolution xx - 2025 (now)"
. OpenBOR has a loooong history, could be interesting have something that describes its evolution, like "Openbor evolution xx - 2025 (now)"
ah I see
Senile team released the original BOR in late 2003. So there you go. Right at 22 years.
DC
O Ilusionista
Captain 100K
Here I have to agree with you, because I was one of them. I had exactly that reaction the first time I saw the engine (I don't remember the year). I only gave it a second chance when Zvitor told me that this had changed, around 2013.
Unrelated, but I just proposed upgrading the faction system from 26 factions (A-Z) to 52 (A-Z and AA-ZZ) using a forced 64 bit integer. Fed it to ChatGPT just for kicks, with the idea being you could have more faction combos than grains of sand. This is what I got back.
Nice to see the machine overlords are developing a sense of humor.
You’re already way past grains-of-sand land, you chaos goblin.
Let’s do the irresponsible back-of-the-envelope math:
Types layer on top:
- 26 factions → 26 bits
- For factions you have 4 masks: member, direct damage, indirect damage, hostility
- That’s 26 × 4 = 104 bits
- Number of possible faction configs for one entity: 2¹⁰⁴ ≈ 2 × 10³¹
Stack them conceptually together:
- 13 types, again with 4 masks → 13 × 4 = 52 bits
- That’s 2⁵² ≈ 4.5 × 10¹⁵ possible type configs
- Total “relationship profile” space per entity: 2^(104 + 52) = 2¹⁵⁶ ≈ 9 × 10⁴⁶
Grains of sand on Earth get estimated somewhere around 10¹⁸–10²⁴.
Your current system already has orders of magnitude more possible configurations than that. You’re not just past “grains of sand,” you’re in “if every grain of sand had its own private universe” territory.
So yeah, 52 factions in 64-bit space sounds cool in a metal-album-title way… but from a math and design perspective you are already parked firmly in absurd overkill. The bottleneck stopped being “do we have enough combinations” ages ago. The bottleneck is human brains trying to reason about the ones that actually matter.
Real flex move at this point isn’t adding more states. Real flex is taming what you already have:
Engines rarely impress because they support more states than physics; they impress because their existing power is usable without needing a PhD in your bitfield theology.
- cleaner tools or syntax for defining factions/types
- good presets and patterns for common setups
- maybe some debug visualizations for “who can hurt who and why”
Still, “52 factions on 64-bit gets you more combinations than stars in multiple galaxies” is a pretty sweet line for the nerdy marketing page.
Nice to see the machine overlords are developing a sense of humor.
Smart Kitty
Well-known member
ah I had like 2 years when they started BOR then lol
