Search results

You are most likely forgetting to set 8bit color. For direct export from Photoshop, use Save for Web (Legacy) and make sure to choose png-8 type. HTH, DC

I was starting to write a detailed breakdown of the game, but I can see how that would go. So... You do you friend. And by all means go on and do it somewhere else. The whole "I don't care" mantra while proving very much otherwise is done to death. I'm going ahead and cutting this nose off at...

Pumping lithium grease into your car's oil supply works too. It will run beautifully, smoother than anything you ever imagined - for about 500 kilometers. Then it will never run again. That's pretty much vibe coding in a nutshell. AI is a tool. You are using it as a crutch. You WILL hit a wall...

LOL, sorry. I figured it was ripped that way from the original game. DC

Not to offend YOU, but I don't care if you don't care. Bad advice is bad advice, and it makes a problem for the rest of us. Stop giving it. DC

I started to try it myself and send you the pieces - until I saw the original creators hadn't bothered to properly mask the tile boundaries. Oof... yeah, never mind. :p DC

Demo or not, basic housekeeping is basic housekeeping. Asset size is a known quantity, and OpenBOR is extremely efficient when it comes to module size / content ratio. Even members who are not technically adriot are aware that bitmap assets are on average ~2KB each, sounds tend to hover ~20KB...

@Adroiid, You want to avoid animation loops for this, because that could have side effects you didn't plan for and limits your design later. Instead, you'll want conditional script loops in the onmove event c that reduce velocity by a given % until it reaches a threshold, and then halting. DC

I had a quick look. Tumbnail.dbs left in the folder, massively bloated music files with baked in loops, lots of orphaned assets that don't do anything - Ex: There's a 300+MB pak file sitting in Misc folder. The whole project could be easily brought down to ~100MB with some cursory optimizatios...

It's like anything else. You get out of it what you put into it, simple as that. Personalty, I find script easier than the native functions in a lot of ways, because the native functions are rote memorization. Scripts are based on C, meaning they have rules and syntax developed over decades by...

Oh, I forgot there was a list of builds there. Thanks @O Ilusionista. I'll try to mirror those too when I get a chance. Since they are marked version 3, that helps a lot, though as mentioned above, I don't have have any release notes for them. *Edit for clarity:* To be more accurate, there are...

Set the projectile's "owner" property to the parent entity. That's what OpenBOR uses to determine who a projectile belongs to and who gets credit for it hitting something. There's no native way to limit extra lives. If you want to do that, you'll need to monitor the score and add lives yourself...

Didn't I just answer this same question the other day? You are "on the ground" if fallen and <= 0.01 altitude above your base. Fallen flag resets as you start to rise or rise attack, so no, they are not subject to OTG. They ARE of course subject to regular attacks assuming you haven't set rise...

You're confusing the engine's internal target property for entities with a local variable in a function. "Target" in this case just means target object for the function to act on, nothing more. I could have named it "have_a_nice_day" if I'd wanted to. DC

Target is the current entity targeted by AI - meaning, which one it's applying movement logic to, whether that is seeking or evading depending on its setup. Obviously meaningless for players, but does apply to homing projectiles. Opponent is the last entity interacted with. That coukd be...

The builds I posted were all the official builds, meaning ones we compiled and posted and are (reasonably) stable. There are plenty of other builds, but those were dev builds. The biggest problem with anything older than posted is they predate the move from Sourceforge, which I never had admin...

Yep, horses for courses. The Genesis flexed its muscles for beat em ups. The biggest things are the video RAM and size freedom. Genesis has the same 64KB as SNES, and it's nowhere near as restrictive. In practical terms, you can almost arrange blocks at will. That reduces overhead dramatically...

That's down to a combination of specific bottlenecks in the SNES architecture that are especially bad for beat em' ups. The first, is that even though the SNES has 128 on screen sprites and a lot of size choices (8x8, 16x16, 32x32, or 64x64) you've got a 32 sprite AND a 34 8*8 tile per...

For anyone not aware, 3.0 builds back to 3769 (the earliest official release available after migration from Sourceforge) have always been accessible via a "Legacy Build" entry in the GitHub repository. I had thought that would make builds easier to find, but apparently it had the opposite...

3.0 legacy builds are now available as a ChronoCrash Resource. That should make them a bit easier to find. https://www.chronocrash.com/forum/resources/openbor-legacy.427/ DC