Collision Rework
- Thread starter DCurrent
- Start date
Thank you msmalik681 and bWWd.
I just tested new collision boxes for real collision detection on the attack side. Using the new collisions and old body boxes, everything works great. I forgot about recursive damage though. Ooops... it doesn't crash or go wacky, but recursive damage just isn't loaded and does nothing. Obviously I'll need to finish that part up. Then I can implement and test body boxes using new collision as well.
DC
I just tested new collision boxes for real collision detection on the attack side. Using the new collisions and old body boxes, everything works great. I forgot about recursive damage though. Ooops... it doesn't crash or go wacky, but recursive damage just isn't loaded and does nothing. Obviously I'll need to finish that part up. Then I can implement and test body boxes using new collision as well.
DC
O Ilusionista
Captain 100K
Oh that IS nice!
Is it ready for me to test ?
Ok its fine i can wait.
Just please make a test version that logs each step of the process so if it breaks we know exactly what broke.
Just please make a test version that logs each step of the process so if it breaks we know exactly what broke.
16-bit Fighter
Active member
Nice to know you're making it progress DC!
Update:
Attack collisions are now handled fully by the new system - legacy attacks are gone. The long delay in updates was partially my life going crazy (as any programmers and IT guys will tell you, quarantine/work from home orders mean MORE stuff to do, not less... a whole ton more...). The other reason was experimenting with reallocating arrays since they are nominally faster than my linked list method - but the complexity just made it a bigger mess than it was worth.
Legacy body and space remains, but that should take nearly as long now that I have the attack system locked in.
DC
Attack collisions are now handled fully by the new system - legacy attacks are gone. The long delay in updates was partially my life going crazy (as any programmers and IT guys will tell you, quarantine/work from home orders mean MORE stuff to do, not less... a whole ton more...). The other reason was experimenting with reallocating arrays since they are nominally faster than my linked list method - but the complexity just made it a bigger mess than it was worth.
Legacy body and space remains, but that should take nearly as long now that I have the attack system locked in.
DC
Great work so is this ready for testing yet ?
Damon Caskey said:Here's Ryu showing off three attack boxes on his jab.
There's still plenty more to do. Body boxes are still using dummy values - only attacks are read in fully. There's also a bug where one of the attacks always stays active till the end of an animation. Once those are resolved, I can begin to implement the new system fully and remove the old the collision boxes from source code.
DC
Just to clarify are you working on multi bbox's too?
Yes, it's all part of the same update. I haven't touched the engine code for a while though. It's looking like midsummer before I can really dive back in (that's when end of fiscal year stuff and work and summer classes are over). Once that happens, I'll get it finished up.
DC
DC
Damon Caskey just to be sure will this update also allow us to make and manipulate attack and bbox by script ?
msmalik681 said:
Yes. It's a multi process - just like internally in the engine:
[list type=decimal]
[*]You can allocate and de-allocate new objects at will.
[*]You can access or mutate existing attack, body, and space object attributes (damage, drop velocity, etc.).
[*]You can allocate or de-allocate existing collision pointers on frames - each frame may have an unlimited number of unique collision pointers*[1].
[*]You can access or mutate existing collision pointers on frames, or allocate and de-allocate them.
[/list]
So yes, you can actually programmatically build model designs during runtime. I don't expect many will do this often, if at all. Sounds really cool and it is, but it's a very advanced concept - make even one mistake it will be a seg fault and crash... as in, a real crash, not an intentional shut down. I am not adding that as a feature for its own sake - it just happens to be a side effect of the overall script design access I'm working on. There are tons of other applications that are much more practical, so I'm not going to TLDR this any more than it is. Suffice to say, if you are about to ask me another question about anything collision related - the answer is yes.
*[1]: Technically there is limit: 2.4 billion. In practical terms, use some common sense. Collision calculation is very expensive, no matter how powerful the platform is, and multiplies for every box on a given frame. In perspective, Capcom and SNK fighters typically have three body boxes, one space box, one attack box, and range. Their beat em' ups have one body box, one attack, and range (same as OpenBOR up to this point).
DC
