In the OpenBOR engine source code, over half of the code logic revolves around the BTU type, such as AI, UI, animations, and more.
I don't expect you to fully understand me, but when I want to implement collision detection for irregular objects,
when I want to implement true-color PNG images,
when I want to implement skeletal animations,
when I want to achieve a 720P resolution with thousands of sprites on-screen while maintaining smooth 60 frames per second,
when I want to script using object-oriented programming,
when I want to create better and cleaner scripts,
when I want to implement the transmission of extremely long strings,
and so on and so forth—these are all issues that give me a headache.
Although I could choose Godot, Unity, or other engines,
I've been using OpenBOR for over a decade and don't want to rebuild my game from scratch.
It's just that OpenBOR can be better.
The reason I voice my opinions is because of my love for OpenBOR.
After using it for over a decade, I wouldn't just switch to another engine if it weren't for this attachment.
Of course, maybe I have no other choice.
Actually, I really hope everyone can take a closer look at how other engines are designed.
Of course the engine could be "better". But on specific points, I have no polite way of saying this - you simply don't know what you're talking about. I've seen your threads and projects. You name drop a lot of coding features, but don't really offer any fundamental understanding of how and
why OpenBOR (or any other engine) works the way they do.
I'll try to address these, best I can.
when I want to implement true-color PNG images,
First, OpenBOR DOES support true color, you just have to know a little something about how sprites work. It is true that individual sprites are 8bit, and for a very good reason. Without getting into too much long winded technial stuff, the bottom line is
professional developers don't use true color. Ever. No, not even the big AAA graphic powerhouse 20 gagillion shaded polygon projects. Individual assets are 8-bit, sometimes 10-bit or 16-bit (which OpenBOR ALSO supports through alpha channels). Per our google overlords:
- 8-bit per channel (24-bit RGB or 32-bit RGBA):This is the most common format for individual assets (textures, sprites). Each channel (Red, Green, Blue, and Alpha) gets 8 bits, allowing 256 levels per channel.
- 16-bit per channel (48-bit RGB or 64-bit RGBA): Used in high-fidelity rendering, or for specific assets requiring more color precision and dynamic range (e.g., cinematic scenes, HDR textures).
- 10-bit per channel (HDR Pipelines):Commonly used in HDR rendering pipelines, particularly for projection or final image display. This is more relevant to how the game engine outputs the final frame, rather than how individual sprites or textures are stored.
- Intermediate or Lighting Passes: Sometimes, certain passes in rendering (e.g., HDR lighting or post-processing) might use 10-bit or higher precision.
Individual sprites and shaded textures in games are typically authored and stored in 8-bit per channel formats. If HDR precision is needed, 16-bit per channel formats might be used, but this is more common in AAA titles where fidelity is critical.
when I want to implement skeletal animations,
No, we don't support skeletal animations, and don't plan to. But how does that stop you? In our view, that's design time work, and better left to tools optimized for it, not bloatware in an engine.
when I want to achieve a 720P resolution with thousands of sprites on-screen while maintaining smooth 60 frames per second,
What?! No engine can do this out of the box - at all. Hundreds maybe, which OpenBOR has no problem with. You're not getting thousands out of any engine without some serious knowledge in sprite batching techniques, and if you knew how to do that, you wouldn't be posting this.
when I want to script using object-oriented programming,
This again shows a lack of knowledge. OOP is a
paradigm not a function.
Encapsulation,
inheritance, and
polymorphism have nothing at all to do with language functionality. OpenBOR script doesn't include the syntactic sugar, but you absolutely can apply OOP.
Been there, done that, bought the T-Shirt.
when I want to create better and cleaner scripts,
...uhm... write better and cleaner scripts. If you are cobbling together a bunch of procedural spaghetti, that's your own fault. Ask us, and we can help. Also, I can't believe you’d mention this in the same breath as wanting support for JavaScript – widely regarded as one of the messiest languages ever conceived.
when I want to implement the transmission of extremely long strings,
I'll give you this one. Strings are limited to 512, and there's not much we can do to change that right now. The technical reason for it is all script variables are handled by a union structure under the hood (and there are reasons for that too). So increasing string size would mean increasing memory load for all script variables. If you think that means the engine sucks... Fair enough.
After using it for over a decade, I wouldn't just switch to another engine if it weren't for this attachment.
Doesn't matter if you've been here for 10 years or 10 minutes - it's the wear, not the age. Right now, you don't have it. And here's the thing:
That's okay! There's not a thing wrong with not knowing something. The catch is, you need to approach with the mindset of
"how do I do I achieve X result" and ask accordingly, instead of
"I want X feature because it's cool". This isn't me speculating or defending a codebase. You want to make certain types of games, like say, an FPS? You go get Unity and run wild, because it's the best there unless you've got a few million to toss around for Unreal. In our genre, OpenBOR is the top dog.
DC
