oldyz:
oldyz said:
for more polishing later on true hand-drawn sprites can be implemented later on by paying an artist
Not interested. I want the work to be mine, and I'm good enough to do polishing on my own.
so now im wondering about the hitboxes in gI joe, Think they are they "scaled" manually (like thee way each frame has its hitboxes values on most mods - except that for frames that are marked "closer" they rezise - or do they scale in real-time (using programming that automatically rezises the hitboxes for each "entity"
I've already solved this (see below), but it requires a bit of explanation. First thing, scalable hitboxes have one big drawback: They double memory consumption because you have to maintain the original value somewhere as a base. That has to be dealt with somehow.
In GI-Joe, Space Harrier, etc. the hit detection does indeed scale. There's no way to know for certain how they did it without seeing their original source code, but I can tell you how it most likely worked. If you pay attention in those games, you'll notice the profile shape of a given enemy sprite never changes. No matter if they are running, jumping, shooting at you, etc., they always maintain a uniform profile. So I'm guessing they're doing one of two things to get around the memory issue:
- Each model has exactly one set of global collision coordinates that are scaled based on its Z position. They might even share sets of collision coordinates across multiple models with similar profiles.
- (more likely) They're using hardware sprite collision. Poor precision, but if you design sprites carefully (see above) it's good enough for an arcade rail shooter and the detection scaling takes care of itself.
i was trying to tinker with the info that
bWWd provided about z-scaling - if i am not mistaken , in order to scale the hitboxes a similar script has to be invented - so mods will have to use 1 script that takes care of the scaling visually & a separate script to scale hitboxes, no?
OpenBOR is a very different situation than the arcades. OpenBOR keeps collision data for every frame, and can even have multiple sets per frame. That's a truly massive amount of data to store. Plus, you'd need to write the script in a way it would know if a particular frame's original values were captured or not. It's not all that difficult to code, but severely resource intensive.
In theory you could use a static set of coordinates for each model as your base (same principal as arcade solution 1), but then you have to limit sprite design to a uniform profile and I just don't want to do that.
So... I developed a third solution. Remember
DoAttack? In this video I explain the basic concept, and mention it has many applications for advanced hit detection work:
Lucia's Run Leverages the
DoAttack() event for its scaled hit detection. Instead of scaling the actual hit boxes, the
DoAttack() event calculates a theoretical scaled hit box whenever a hit occurs. If the hit location falls outside of the calculated box, the hit is canceled. I'd like to think it's a pretty creative solution.
DC
