OpenBOR

OpenBOR 4.0 4.0 Build 7735

No permission to download
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
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.

You’re already way past grains-of-sand land, you chaos goblin. 😄

Let’s do the irresponsible back-of-the-envelope math:
  • 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³¹
Types layer on top:

  • 13 types, again with 4 masks → 13 × 4 = 52 bits
  • That’s 2⁵² ≈ 4.5 × 10¹⁵ possible type configs
Stack them conceptually together:

  • 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:
  • 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”
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.

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. :P
 
Is it possible to check if the
Code:
boss 1
flag is experiencing a specific issue across multiple entities?
This is the case in my latest tests (7735).
 
Is it possible to check if the
Code:
boss 1
flag is experiencing a specific issue across multiple entities?
This is the case in my latest tests (7735).

No issues at all with Boss I am aware of, and that part of the code was not changed. You'll need to be more specific please.

DC
 
As I mentioned in the Golden Axe Remake thread, both Bad Brothers died during the first boss encounter. The game continues, doesn't advance to the next level, and it's impossible to exit via the menu. I only have this problem in version 7735; I didn't have it before in version 3.0 6412. I can upload an archive for testing.
 
As I mentioned in the Golden Axe Remake thread, both Bad Brothers died during the first boss encounter. The game continues, doesn't advance to the next level, and it's impossible to exit via the menu. I only have this problem in version 7735; I didn't have it before in version 3.0 6412. I can upload an archive for testing.
I haven't seen those posts. I'll take a look when I can - am currently very busy on another project.

DC
 
I noticed one thing: whether it's NPCs or enemies, if they find themselves facing a wall, they get stuck in animation block indefinitely in version 4.0 (whereas in 3.0 they would jump over this wall/platform or go around it).
 
I noticed one thing: whether it's NPCs or enemies, if they find themselves facing a wall, they get stuck in animation block indefinitely in version 4.0 (whereas in 3.0 they would jump over this wall/platform or go around it).

That statement doesn't make sense @kimono, I think there might be a language barrier issue. Are you saying they play a block animation, or that they are trying but can't get past the wall?

If its the latter, you need to adjust the jump ranges, which you should be doing anyway. 3.0 had very over generous ranges that were sub-optimal. 4.0 tightens them up quite a bit, and Golden Axe sprites are not sized for what the defaults are meant for.

DC
 
That statement doesn't make sense @kimono, I think there might be a language barrier issue. Are you saying they play a block animation, or that they are trying but can't get past the wall?

If its the latter, you need to adjust the jump ranges, which you should be doing anyway. 3.0 had very over generous ranges that were sub-optimal. 4.0 tightens them up quite a bit, and Golden Axe sprites are not sized for what the defaults are meant for.

DC
NPC Wall block.png
Enemies and NPCs advance towards a wall and become stuck in front of it, remaining indefinitely in an anim block.
I can make a video of this phenomenon.
 
Last edited:
Update: The problem stems from the victory animation when boss 1 is present and no longer being played.

Regarding the platform walls, it is indeed a jump issue.
Is this fixed by adjusting the distance within the jump animation?
 
Update: The problem stems from the victory animation when boss 1 is present and no longer being played.

I have said this before: I highly recommend never using Victory. I did not add that feature, and the way it works internally is very lazy and very unstable. Essentially, Victory is a pain animation - the dead boss hits players with a full screen attack that triggers the "Victory". It doesn't take much thought to realize that set up is easily broken by a variety of in game conditions.

It's one of many reasons that person is no longer on the development team. I only left the functionality there as is for backward comparability. Since the policy post 4.0 release is no longer keeping backward compatability for its own sake, I will likely depreciate or change the way it works.

Until then, If you want a victory animation, you are far better off scripting one. It's not complex at all to set up.

Regarding the platform walls, it is indeed a jump issue.
Is this fixed by adjusting the distance within the jump animation?

Yes. All documented here. Compared to 3.0, OpenBOR 4.0 changes the following:

Default ranges are more tuned. Specfically, the default X axis for jumps is 50 and 60 in both, but in 3.0 the Base axis range is -1000 to 1000. In 4.0 it is calculated with a forumla similar to the other axes

3.0 - Basically says "F*** it" and uses an absurdly huge area for Y and Base axis:

1767888860771.png

4.0 - Defaults are much tighter and therefore more optimal:

1767888926734.png

In both cases, they are tuned for typical KOF/Street Fighter sized sprites and platforms, since that's the vast majority of use cases. You'll need to set your own ranges for Golden Axe.

4.0 also adds the air control property and allows you to adjust the global jump height. Everything else is identical to 3.0:


HTH,
DC
 
Thanks Damon, your posts are always very detailed and interesting.
I'm going to think about writing a script that checks if any enemy entities remain in the level.
I'll admit that I wouldn't mind if an animation victory were included later under a less intrusive mechanic; if it's not planned, I'll manage :)

I'll do some tests regarding the range in that case, thank you!
 
For people dropping negative reviews on the engine due to port problems - ports have NOTHING to do with the engine or its codebase, and those reviews are removed on sight. Just one more reason I am against porting the engine to consoles.

Many of those ports are not even made by by us. Also, I agree with @O Ilusionista from earlier in the thread. At this point, the Wii port is nothing but an albatross making us look bad. Next official release, it's gone.

DC
 
Sorry, I was too fast with my raw review, I didn't want to discredit your great work! I'm glad to see that the Wii platform is supported again, but what a pity that the latest release 7735 do not start games, is there an memory check that prevents games from loading?

Thats not an albatross, it is a fine gem that the Wii is supported and there is still a big gamer community behind the Wii.
It would be sorrowful if you drop the Wii support :-(
 
Last edited:
but what a pity that the latest release 7735 do not start games, is there an memory check that prevents games from loading?
That is the point.
It's not a problem with the engine itself, but rather with how much RAM the Wii has (88MB, if I am not wrong). Unless a game developer designed it specifically for the Wii, there's no guarantee that a game developed in OpenBOR will work on the Wii.

First, because you need to use the same version and build used for development. Second, the console may simply not have enough memory to run a game that was never initially intended to run on it.

That's exactly why the PSP version was discontinued and the Wii version will follow the same path – and it's about time.

Anyone who wants to continue developing OpenBOR games that run on these legacy platforms can simply use legacy versions.
 
Sorry, I was too fast with my raw review, I didn't want to discredit your great work! I'm glad to see that the Wii platform is supported again, but what a pity that the latest release 7735 do not start games, is there an memory check that prevents games from loading?

Thats not an albatross, it is a fine gem that the Wii is supported and there is still a big gamer community behind the Wii.
It would be sorrowful if you drop the Wii support :-(

I appreciate the comment - no worries. Still, my decision stands.

To be clear, it would be more accurate to say the Wii port is already dropped, and has been for quite some time. All I would do now is make it official and remove the remnants.

The issue is maintenance. The developers who originally handled the Wii work are long gone, and I have no practical way to support it. I did not write a single line of code for the Wii. For me to support it now, I would have to buy a Wii to test on, rebuild my dev environment, and learn an entirely unfamiliar toolchain and platform-specific APIs. That is a completely unjustifiable investment of time, effort, and resources for hardware released in 2006, with a comparatively minuscule user base and limited system resources.

About build 7735 not loading games - I do not believe it is a deliberate “memory check” meant to block anything. There certainly isn't any such thing in the core engine. It is far more likely the Wii code path has simply rotted over time as the engine evolved, so newer changes are incompatible or untested on that platform. Since I cannot test or maintain it, I cannot responsibly debug it.

So, yes - Wii support is effectively gone, and I am not going to maintain it going forward. Sorry.

DC
 
Back
Top Bottom