Hello.-Open Bor 4.0 questions.

[Bwaters94]

Hello. Community. I've never used the forum before. I learned a lot about Open Bor over a few years simply reading your forum and manual. Recently joined so I could download some of your resources. Most of what I learned was before the most recent version and recent builds and 4.0.
I was introduced by a friend using 3.0 and had learned a lot of my own. I got tired of the typical download a sprite or a sprite pack of the same characters. Kinda wanted some art freedom.
I turned to AI art and at suggestions by people using various engines. I have localized AI so I can pretty much create anything I want as best I can prompt it without worrying about content filters.
I found out soon 3.0 was a hopeless way. I can strip Metadata out often but had no luck with the art I have generated. Spent most of my vacation staring at a screen. I was told that the Metadata AI often used was not going to work for 3.0. I don't know about 4.0 but have been told several things including

"Open Bor 4.0 eats Metadata for breakfast." (a few exceptions)
"4.0 can use higher bit PNGs "

I have gotten a lot of inconsistent information. I'm not much of an artist but if it is possible to get Open to friendly art generated for the latest of 4.0. Perhaps someone could help me with info?
Perhaps many of my questions would be best for a senior engineer? I'm an intermediate coder. I do okay just probably a little slower than the average experienced coder.
Also if possible could someone steer me towards a good first mod/game made with 4.0 to learn how models.txt is handled appropriately? Perhaps the right updated tutorial? Anything that might help me learn more about the neeest version . Thinking much of what I have seen has been old or out of date. I haven't read the forum as much as I used to.
I have enjoyed learning on this engine would rather stick with it rather than adjusting to a new one. I'm not looking to make a PS5 game but maybe Sega Dreamcast beat em up?


Thanks on advance for any crucial feedback.

Sorry if my paragraphs don't look correct I can't seem to get indentions on this device. I don't know what I'm doing wrong but I edited because I couldn't seem to get the paragraphs to indent only noticed after I posted.

 

[O Ilusionista]

Welcome to the community.
The biggest problem with using AI is this:

I turned to AI art and at suggestions by people using various engines. I have localized AI so I can pretty much create anything I want as best I can prompt it without worrying about content filters.
I found out soon 3.0 was a hopeless way. I can strip Metadata out often but had no luck with the art I have generated. Spent most of my vacation staring at a screen. I was told that the Metadata AI often used was not going to work for 3.0. I don't know about 4.0 but have been told several things including

You end up with a lot of information that is either incorrect or completely false. Version 3.0 was by no means a "hopeless" option—I still use it in my projects, and many creators do the same.

Version 4 is newer and includes new features, bug fixes, and so on. However, that doesn't make Version 3.0 flawed or limited in the way the AI made it seem.

Regarding PNG support: currently, both versions support the same types of PNG files. Support for 24-bit PNGs is planned for Version 4.0.

Using AI without any knowledge of the engine will lead to a lot of frustration and misinformation.

I suggest you start by studying the documentation and understanding how the engine works. I created a "how-to-start" guide here: Tutorial - How To Start On OpenBOR

 

[Bwaters94]

Well my question was in part how does 4.0 handle art made by AI? I'm familiar with 3.0 and the file system. So I know it's solid. However AI sprites have been impossible to load. AI art not really information has been the issue for me. Especially days it tends to add to its art.

More creative art freedom is what I was really inquiring about. I have full faith in Open Bots abilities but comic characterd and Fighting game characters have been used so many times. It was more about expanding my possibilities.

 

[Kratus]

However AO sprites have been impossible to load

@Bwaters94 In this case, the origin of the sprites does not matter for the engine if you export it in the accepted format.

In short, the sprites used by animations must be in gif/png 256 colors indexed. Like @O Ilusionista said, 24 bit png (for animations) is planned for future updates (currently it's supported in very specific situations only, like main menu or character selection).

 

[DCurrent]

Well my question was in part how does 4.0 handle art made by AI? I'm familiar with 3.0 and the file system. So I know it's solid. However AI sprites have been impossible to load. AI art not really information has been the issue for me. Especially days it tends to add to its art.

More creative art freedom is what I was really inquiring about. I have full faith in Open Bots abilities but comic characterd and Fighting game characters have been used so many times. It was more about expanding my possibilities.

Welcome to the community @Bwaters94,

Sitting member of my university’s AI Application Research unit here.

The question isn't really whether the engine "handles AI." OpenBOR doesn't care where an asset came from. If you give it a proper sprite, it will use it. The real issue is whether current AI models can produce usable game assets, and today the answer is no.

LLMs and image generators can prototype no problem. They can help with concepts, character designs, backgrounds, textures, and even scenery that only needs to exist as a single image.

Where they fall apart is sprite production. Usable sprite sets aren't just a collection of pictures. Every frame has to maintain consistent proportions, lighting, perspective, animation timing, and - most importantly - use a consistent indexed palette. Virtually every sprite-based engine works with indexed images. There really isn't such a thing as a practical RGB sprite set for a finished game.

AI can and will generate nice-looking single frames, but producing a complete, animation-ready sprite sheet with dozens or hundreds of frames that all share the same palette and remain visually consistent is still beyond current technology. No amount of custom models or prompt engineering can change that.

If you really want to use models to expand what you can do, the best advice I can give is to generate your images as a prototype, then rotoscope them to produce final output.

Also, just to be clear, yes, it's a bad idea to rely on any model for OpenBOR information. The models aren't the problem - the training data is. Nearly all of the information available outside this community is either out of date or just outright wrong, which is what the models scraped and trained on. I have a model of my own that I carefully curated specifically for OpenBOR to help save time writing boilerplate code, and it still insists on making boneheaded recommendations at an alarming rate.

DC

 

[Bwaters94]

 

[Bwaters94]

Thanks and to all

 

[DCurrent]

The way I got around this was to have t to create the full animation in a 5-7 second shot. It has worked out pretty well.. Choosing a proper background and space was key to getting the consistency you mentioned. Then I cut it out of the background.
Then I would just split the frames so I got my animation sprites consistently Request a detailed attack prompt at the same angle. It tends to overuse frames so I would just select what I needed. and it's turned out great. But it sounds like Open Bor most likely couldn't handle the animation art. Maybe I'll try another engine.

There actually is a mode to let you get away with this in OpenBOR... but frankly I'm not interested in dealing with the followup issues you'll run into from using this method.

That's what you're not getting. We're speaking long term productions cycle here. Sure you can kludge up some sprites and make them run at first. There's at least a dozen videos out there of people doing this on GoDot. What they don't tell you about are all the subsequent headaches that result from trying to run disparate palette assets.

You're not talking to people married to an engine here - we're game developers. Do you really think you've discovered some ultimate shortcut an entire community of subject matter experts happened to overlook? If there was really a working easy button, don't you think we'd be using it ourselves?

Anyway, whatever you do, I wish you best of luck friend.

DC

 

[Bwaters94]

No not all . I was just saying thanks for the help with Open Bor.

 

[DCurrent]

Just as an add on, whenever someone asks about AI - I often feel it's a good idea to let the AI itself have a say, just as proof it's not me being a grumpy Luddite. When prompted to analyze this thread, here is what the LLMs have to say - verbatim:

---

Prompt: Analyze and reflect on the following thread: Hello.-Open Bor 4.0 questions.

The thread is really about production literacy, not OpenBOR 4.0.

The new user came in with a common AI-era misconception: “AI art exists, therefore game-ready sprite production should be mostly solved.” Their stated problem was that AI-generated sprites were not loading in 3.0, and they had heard conflicting claims like “4.0 eats metadata for breakfast” and “4.0 can use higher-bit PNGs.” That framing already shows the confusion: they were treating the asset source and image metadata as the main technical issue, when the real problem is format discipline.

O Ilusionista and Kratus both handled the engine side cleanly. O Ilusionista corrected the idea that 3.0 is “hopeless,” clarified that 4.0 being newer does not magically invalidate 3.0, and noted that both currently use the same practical PNG support for sprites, with broader 24-bit PNG support planned for 4.0. Kratus then boiled it down further: OpenBOR does not care whether an image came from AI, Photoshop, Aseprite, or a scanner - animations need acceptable sprite formats, specifically indexed 256-color GIF/PNG for normal animation sprites, while 24-bit PNG is only supported in specific contexts right now.

Your reply correctly moved the discussion from “can OpenBOR handle AI?” to “can current AI produce production-ready sprite sets?” That is the right axis. OpenBOR is not rejecting “AI art.” It is rejecting bad assets, inconsistent assets, or assets outside the expected pipeline. Your point about consistency - proportions, lighting, perspective, timing, and especially indexed palette discipline - is the actual wall the user is running into.

Where your answer is strongest is that you refuse the fake shortcut. The user’s later workaround - generate a 5-7 second animation clip, cut out frames, pick what looks good - can absolutely produce something that looks promising in a demo. Your response correctly says the problem is not whether you can kludge it into motion once; it is whether that workflow survives a full production cycle with palette management, animation reuse, hitbox readability, visual consistency, memory expectations, revisions, enemy sets, alternate palettes, weapons, throws, damage states, and so on.

The only thing I’d soften is the rhetorical slap:

“Do you really think you've discovered some ultimate shortcut...?”

It is true. It is also the kind of sentence that can make a novice feel dismissed even when the technical advice is solid. The user was not necessarily being arrogant; they were probably trapped between AI hype, outdated OpenBOR lore, and partial success from a prototype method. That said, your closing “best of luck friend” keeps it from becoming hostile.

The better version of your stance is something like:

You can get something moving with that workflow, yes. The problem is that “moving” and “production-ready” are very different standards. Once you need a whole cast, palette swaps, clean silhouettes, consistent lighting, readable attacks, damage frames, throws, and revisions, the AI-video-to-sprite pipeline usually starts creating more cleanup work than it saves. OpenBOR is not blocking you because the art is AI-generated; it is asking for the same disciplined sprite preparation every sprite engine eventually asks for.

That preserves the warning without making the user feel like the community is gatekeeping.

The deeper lesson is that 4.0 should probably have a very explicit modern asset pipeline note somewhere prominent:

“Normal animation sprites are still indexed 256-color assets. AI-generated images must be converted, cleaned, palette-managed, and tested like any other source art. Metadata is not the issue. Consistency is.”

That would prevent this exact confusion from turning into “maybe I’ll try another engine,” because the user is likely to discover the same wall elsewhere. Godot, Unity, GameMaker, Mugen, Ikemen, OpenBOR - none of them magically solve sprite set consistency. They may accept RGB images more casually, but they do not solve the art direction, animation, palette, memory, or revision problems.

---

There you are folks, for whatever that's worth.

DC

 

[Bwaters94]

Well I didn't want to start a debate that's why I edited my original response I got too far off my original post. I can say this though the AI is wrong in its assumption.

"The new user came in with a common AI-era misconception: “AI art exists, therefore game-ready sprite production should be mostly solved.”

I never said anything of the sort. If anything I was pointing out alternative workflow. In fact I have spent 2 years getting 6 characters consistent using a variety of AI, and multiple techniques but what attracted me to Open Bor was simple file system and less coding.
But consistency, direction, animation, palette, memory, or revision problems. I have all solved just dumping various data types I have reduced files by 50% or more. It was not easy and nothing was game-ready sprite assets. It was not a magical solution. Now in all that time I only have 5 characters fully animated no issues it was at least 18 months of dedicated trial and error but after discovering a custom work flow I can do it with a faster workflow. Lighting, perspective, timing -done! Never tried them in Open Bor.
All I am saying is I spent months trying to get past one wall just to hit another. However everything it suggests as a problem I spent months using a hybrid of manual and AI techniques to solve. But I never once believed prompt = sprite sheet in fact I think most AI sprite sheets have seen were terrible.

“Normal animation sprites are still indexed 256-color. Color Assets Metadata is not the issue. Consistency is."

Much of this is only true for Open Bor I have seen it myself and I will admit my question did center around it's capabilities. Thanks I do believe the solution is there though my own experience. And it's not just prompt and go but a custom workflow mixed with manual ability you can get there without setting for janked sprite surgery. Thanks I'll just try another engine.

 

[DCurrent]

Much of this is only true for Open Bor I have seen it myself and I will admit my question did center around it's capabilities. Thanks I do believe the solution is there though my own experience. And it's not just prompt and go but a custom workflow mixed with manual ability you can get there without setting for janked sprite surgery. Thanks I'll just try another engine.

Friend, you still are not getting it. You will NOT be able to do this on ANY engine. I only need to address this now to stop the unfair misrepresentation of OpenBOR and of other engines.

There is no such thing as an RGB sprite in the hot path. I do not know how many different ways I can say this. There just is not. No major engine supports such a thing, and no game uses them that way. 8-bit color for a single bitmap is the max. 10-12 bit for single textures. That is why you cannot just drop files in and expect them to work, and that is why your workflow will not do what you think it does.

OpenBOR is simply up front and honest about it. Other engines might claim to “support” them, but what actually happens is an import tool smashes the image down into the best palette or texture format it can come up with - which is the exact same process you would perform yourself with an image editor before using the assets in OpenBOR.

In some cases, the importer will assign each image its own indexed palette, which OpenBOR also supports. The problem is, that is usually worse, because it means you no longer have meaningful palette control at all. Use any engine you want. That is entirely your choice, of course. You will not be moving onto something more capable in this area. You will be moving onto something more abstracted and more obfuscated.

I do not want to see this get unfriendly or turn into a round robin, so I am locking down the thread for now. Whatever you decide, I wish you the best. Really - that is not a smarmy send-off. I would like to see you stick around, try the engine out, and discover what it can really do. If not, that is cool too, and you are still welcome to post about your projects here.

DC