Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Captain Dreamcast97 days ago

I looked into it, the main culprit seems to be that the timings for when the round is over are still wrong with Dolmexica.

In the fight motif/fight.def over.wintime is set to 0, while leads to the win animations being played immediately after KO, giving them no time to land. Whether they should still play in mid-air when given no time to land is a bit of a tricky question, it could be tied to landing, but then it would probably fail for floating characters, I need to do more testing with that. A quick workaround right now is to set over.wintime in the fight.def to 45, which is its original value in Mugen. I originallyset it to 0 because there was a bug in earlier versions that led to timings taking forever until restarting the round, which STILL kind of exists in 1.7. Dolmexica first plays the win animation of the winning character, then shows the win text or animation, then finally waits for over.time until starting the new round. This is not how Mugen does it. After showing KO or whatever else happened, Mugen starts all these counts at the same time, e.g. over.time until the round ends for real, over.wintime until showing the character win animation and win.time until showing the win text. That's why it doesn't take forever, because unlike Dolmexica it doesn't do it in succession.
I've adjusted the fight.def wait values to their original Mugen values for the next release and fixed it to behave the same way, that will hopefully fix most weird end-of-round behavior like the floating win animations. I also fixed a bug that the current text UI is broken, there was a bug in the loading, that's why it doesn't show stuff like "Kung Fu Man Wins" after the round, that will also work again next release. Still has to go through all that in-depth testing with other characters and motifs to make sure nothing else broke, but I hope this should instead be more stable than the weird logic before.


So yeah, TL;DR: Will be fixed in the next release, workaround right now is to increase over.wintime in fight.def to 45 or higher to give airborne characters a chance to land.

Thanks a lot again for reporting the bug, I think I was able to fix a lot of stuff thanks to that!

Reply
fank2z2 days ago(+1)

Hi Captain Dreamcast,

I’ve performed more in-depth testing and found a few more critical issues that are breaking the gameplay experience in Dolmexica:

  1. Chaotic Grab Animations ("Tornado" effect): When a character performs a grab, the throw animation becomes chaotic, like a "tornado of frames." It seems the engine is struggling with TargetBind or synchronization between the attacker and the victim. Instead of following the specific frames of the throw, the victim's sprites flicker or cycle rapidly during the transition.
  2. Overlapping States (Sprite Layering): If a character is in a custom state (e.g., Ryu's "on fire" state) and gets hit, the engine displays the "get hit" sprite and the "on fire" sprite simultaneously. The previous visual state isn't being cleared properly.
  3. Damage while Down: Characters are taking damage while in "Liedown" . They should be invulnerable to standard attacks unless a "Ground" flag is present, but currently, they can be hit by anything.


I hope this helps you track down the logic errors in the state handler. Looking forward to the next update!

Best regards.

Reply
Captain Dreamcast1 day ago

Whoa, thanks a lot  for the in-depth testing! I'll try and get them fixed for the next update, this helps a lot!

I'll have to look into what's causing all of them, I know 1) has always been a huge issue, with freezes with some grapplers making their enemies get stuck in their target state, I'll try to make it match Mugen for the next update. Flickering is an interesting observation, I can imagine a few things causing that, will probably have to go through that frame-by-frame to figure out where it's getting the bad state info from. 2) is interesting, might be some trigger failing related to the on fire sprite effect? But yeah, I'll have to take a deeper look. 3) might just be that flag check missing like you wrote. I don't remember there being an invulnerability check based on the ground flag, so this is probably a bona fide oversight.

So yeah, thanks a lot again for the in-depth debugging and info, really super helpful, and thanks a lot for taking the time to share it with me! 

Reply
AboutFAQBlogContact us
Copyright © 2026 itch corp · Directory · Terms · Privacy · Cookies