The Shrine

http://www.putfile.com/media.php?n=css_hit_b0x_bb

The hitbox is like 2 steps ahead.

Wow. That's pretty interesting...

I wonder why game designers use bounding boxes instead of spheres. Spheres seem like they might be easier to use well - more accurately representing rounded shapes - and I don't think they'd be any harder to program. Might be slower I suppose...but I could imagine that one could pretty easily write a simple algorithm to check point-sphere and sphere-sphere collision (and probably even box-sphere collision) without even having to use floating-point math.

Any other programmers want to weigh in on this?

I took a computer graphics course as an undergrad, and we covered some of the basics of "Does this line interect this line/area?" Going from that background and intution, I think it's simpler mathematically (and hence, faster computationaly) to determine if boxes intersect than spheres.

Mental wrote:but I could imagine that one could pretty easily write a simple algorithm to check point-sphere and sphere-sphere collision (and probably even box-sphere collision) without even having to use floating-point math.

I doubt it. I haven't worked it out on paper, but you probably need to do a division.

Also, a sphere wouldn't be accurate - most things in a game are going to be longer in one dimension. You'd have to use an ellipsoid. But even then, a bounding box probably gives you the tightest fit.

Hmmm...good point - an ellipsoid calculation would definitely be trickier.

I suppose given the example we just saw, the extra precision offered by having a sphere to represent something that it could (say, a human head), is not really as important right now as - apparently - getting the goddamn bounding box to actually fit around your model in realtime...

As far as the division goes, you can use bitshifting to do divides without floating-point math with good precision...that's what mobile phones do for 3D games, as I don't even think there are phones (U.S. models at least) that even have FPUs.

Bit shifting is only accurate with powers of two. Since the entire point of using a different kind of bounding box is greater precision, I don't think loss of precision is tolerable.

Kup, I'm not familiar with the internal workings of it offhand, but in programming some rudimentary 3d stuff for mobile, they offered some macros that did exactly what I'm talking about. Any time you wanted to use a floating point value, you just wrapped it in a macro and away you went.

I don't know if they were just using bit-shifting to change all the floats to HUGE ass integers (but still maintaining the ratios) and doing the math then - or something else - I would think integer divides would be quicker, but it's still a divide, and if you're doing a divide on a hugeass integer I can't imagine it's that different from doing it on a floating-point number - but I do know it's possible.

Mental wrote:Kup, I'm not familiar with the internal workings of it offhand, but in programming some rudimentary 3d stuff for mobile, they offered some macros that did exactly what I'm talking about. Any time you wanted to use a floating point value, you just wrapped it in a macro and away you went.

I don't know if they were just using bit-shifting to change all the floats to HUGE ass integers (but still maintaining the ratios) and doing the math then - or something else - I would think integer divides would be quicker, but it's still a divide, and if you're doing a divide on a hugeass integer I can't imagine it's that different from doing it on a floating-point number - but I do know it's possible.

My point wasn't on whether or not it's possible, but whether or not it makes sense in the context we're talking about. Doing non-floating point divides is going to result in a loss of precision. Sometimes this is tolerable. But if the express purpose of what you're doing is to increase accuracy, then it's probably not tolerable.

I'll put it on my list of "not worth arguing about today". I think there may be some benefit to looking into it, but without actually doing the research, there's not much point to discussing it.

Barret wrote:http://www.putfile.com/media.php?n=css_hit_b0x_bb

The hitbox is like 2 steps ahead.

That would explain why me actually aiming right at people never worked...

Shifting away from the geometrics of the hitbox, it seems like the concept of the forward-stepping hitbox is flawed. First, you have to remember a few things (at least in reference to any decently-coded FPS):

1. Movement is not lagged. The server knows almost exactly where every player is at all times, where every OBJECT is at all times. Player data involving their positions contains both a X,Y,Z position and a vector. In other words, the server gets both "where I am now (definately)" and "where I will be soon (probably)". The server uses the vector to compute every single point in between data packets, so if the player is slow to send packets, it still knows where it is (relatively). (Changing direction could be lagged, but this isn't nearly as important.)

2. Object creation, or firing a bullet (or just plain any new action), COULD BE lagged. The server cannot predict when you're going to do something new until you actually do it, so it's at the whim of a data packet to say "Hey, this is some new shit here, so handle it when you get it".

Given that, there are a couple of problems with the actual concept of the "laggy" hitboxes:

1. The hitboxes are INVERSED! In its current state, this isn't used for compensating for lag; it's used for compensating for Jedis using their predictive powers to shoot the enemy before they appear. The hitbox should be BEHIND the player, so that if somebody sees the player (which is accurately predicted by both server and client, remember) and fires a bullet, the lag time between firing the bullet and the server calculates that the bullet actually hit is compensated by the hitbox.

2. The hitboxes aren't variable according to how MUCH lag per client the player is experiencing. If a client has say, 100ms average ping time, they should have a hitbox 100ms behind the actual targets. Obviously, in a client server game with no lag, the hitbox should BE the actual targets, not behind or forward of it.

/doesn't even play CS:S, but has an interest in FPS programming

BTW, Barret, any threads on what CS players are saying about this video? Shit, if I was them, I'd stop playing until it was fixed.

Not sure if anyone else has heard about it. May want to check www.steampowered.com, that's the main hub of the CS:S community with ub3r b4d4$$3s and complete n00b f0dd3r who probably couldn't program their way out of a paper bag, (not saying I can either, but I think I could if I had my HS programming book.).

I stole it off an mIRC chat with a local CS 1.6 team from Cal that plays near me.

Heh, it's illegal in their forums to post any videos showing glitches. Why is it that the most popular forum for these games are always on the designer's server, where they can censor content? Blizzard does it, too. "Oh, we can't talk about bugs! Just be happy about our great game, guys!"