Rates Received - Jay Dolan

Pages: [1] 2
Quake / Re: quake 2 Skill rater app
Funny Funny
on April 09, 2018, 02:20:57 PM by kickstartbubba
There is already an app that ranks Quake2 skill level. It's called Quake2. When you play against people who are better than you, their score is higher than yours. You should try it.
Quake / Re: Quake 2 netcode and tick rate
Demonstrates Exceptional Knowlege of the Game Demonstrates Exceptional Knowlege of the Game
on December 08, 2017, 12:37:46 PM by haunted
Yea, I mean, it sounds like the connection you had to that server became saturated with the higher packet rate. A lousy connection would probably do better with fewer, fatter packets than with 4 times as many packets that are, individually, a little smaller. Might be interesting to fire up a Quake3 server (30Hz, I believe) to see how that performs over the same connection.
Quake / Re: reals new Red Pak!
Frag Hall of Fame Frag Hall of Fame
on July 14, 2014, 05:39:16 AM by X7
Hehe. Q2W is and will always be 100% free and open source. It's goal is to borrow some of the best aspects of the Quake series and meld them into a game that is, while better in many regards, still undeniably Quake2. We should chat sometime when your pak is complete, if you're still looking to work on that kind of stuff.
Quake / Re: Quake 2 Map question
Whoosh! You done missed the joke thar Cletus! Whoosh! You done missed the joke thar Cletus!
on June 18, 2014, 10:53:35 PM by X7
I started mapping with Qoole in 1999, and then learned QeRadiant in 2000. I guess, having learned it when I was still a teenager, I never appreciated how odd / unintuitive it is. I've never found the mechanics of mapping to be difficult (with the exception of bending pipes) -- just the creative part :D
Quake / Re: FFA Changes?
Well-Reasoned Argument and/or Conclusion Well-Reasoned Argument and/or Conclusion
on April 04, 2013, 11:43:28 AM by ppoint432
I like dm4, too. It actually scales up to 10+ players, where e.g. dm7 is a total mess.
Quake / Re: Carter glitch on q2dm1?
Informative Informative
on March 23, 2013, 02:26:40 PM by quadz
Possibly. I'm not actually aware of being able to strafe jump noticeably faster along walls, but the "overbounce" velocity I mentioned earlier might enable that. The other thing that likely helps there is the clip against an immediate wall doesn't cost any pmove time: your movements are each time-boxed like everything in Quake. But time and distance traveled are treated as one in the same in the pmove code, so if you don't actually travel any distance, you don't burn any time. Thus, clipping against an immediate wall and picking up that overbounce is essentially free. Here's what I'm talking about:


Notice how time_left is decreased only by distance traveled -- it is not impacted by changes in your velocity vector as a result of clipping.


To break it down a little further:

When you run into a wall, pmove attempts to clip your velocity along that plane and scale it back up to your intended speed. Here's the code that calculates how to clip along edges and applies overbounce:


And here's where that clipping is invoked (PM_StepSlideMove, the heart of Quake physics):


It's this logic (the "go along the crease" bit) that likely enables what you're describing, but it's also what hangs you up when jumping up stairs sometimes. I spent literally weeks rewriting all of this logic to try to simplify clipping and produce more fluid interactions with stairs and crates and things. This is why double-jumping is incredibly easy in Quake2World. But I only had limited success in making stairs easier to jump up:


Someday I'll revisit that and get it totally right ;)
Quake / Re: Carter glitch on q2dm1?
Informative Informative
on March 23, 2013, 02:20:45 PM by quadz
Useful information, I didn't know that the X Y Z cordinates had any affect on a snap postion. I thought snap postion was only caused when a played did a noclip through a wall and disabled noclip. And you say that pmove is a consistent acceleration applied on negative Z which I don't know what that is. I honsely thought of -x -y -z when you said Negative Z. And how does Quake 2 use inverted plane distances? And you're saying quake which I'm sure you're perfering too quake 2 instead of quake. I honsetly ask alot of questions.

Snap position is called after every single pmove, both server-side for your authoritative movement, and client-side for prediction. The purpose of Pm_SnapPosition is to reduce the precision of your coordinates to 16 bit integers so that they may be transferred over the network in half the space. In 1997, saving 6 bytes per packet was worthwhile.

Since simply rounding your coordinates to the nearest integer might place you inside the world model (or other solid), PM_SnapPosition tries several "nudges" to push you into a safe space. These nudges favor moving your player towards the origin rather than away from it.

By applying gravity as constant acceleration in negative Z, I just mean that your Z velocity is constantly receiving gravity as a function of time when you are not categorized as being on the ground:

By inverted plane distances, I just mean that Carmack chose to use negative plane distances. Other engines don't. He also chose to use clockwise plane windings -- most other engines use counter. But it really doesn't matter; in the case of Quake, you subtract the plane distance instead of adding it when determining sidedness. As LordHavoc once told me:

The key to a correctly working game engine is to have an even number of sign errors.


Quake / Re: Carter glitch on q2dm1?
Demonstrates Exceptional Knowlege of the Game Demonstrates Exceptional Knowlege of the Game
on March 23, 2013, 02:18:27 PM by quadz
Bugs like this are all a consequence of floating point math done at 32 bit precision and / or large time intervals. The way that Quake works, basically everything from physics interactions to determining visible surfaces relies on calculating plane-sidedness (dot-product of origin or view vector against plane / surface normal vector, offset by plane distance).

Physics interactions in Quake happen once every client-packet for players (variable, generally 8-30ms) or, for AI and items, once every server-packet (100ms fixed). That's plenty of time for collisions to fall through the cracks, so to speak, particularly for fast-moving objects (ever shoot a rocket through a really thin wall?) On top of that, 32 bit floats provide plenty of precision loss for near-misses to be counted as collisions and vise versa.

Where something should have hit and slid along the wall or maybe exploded, it instead passes [partially] through the wall. For rockets, this is generally harmless unless the wall is very thin. For grenades, they might stick to the floor in unusual ways. In the case of your player model, passing only partially through the wall results in you being stuck inside the wall at the very next frame.

The player movement code doesn't cope with these conditions, and continues to build up bounce-off velocity (which, under normal circumstances is what keeps you running at normal speed when you intentionally run along walls). When that bounce-off velocity finally builds to a high enough value to again trigger a missed collision with the wall you're stuck in, you shoot out of the wall at a ridiculously high velocity and instantly crater :)

Math is fun.
Quake / Re: Carter glitch on q2dm1?
Demonstrates Exceptional Knowlege of the Game Demonstrates Exceptional Knowlege of the Game
on March 23, 2013, 02:16:07 PM by quadz
Okay, a couple key concepts for understanding Quake:

  • Quake uses a right-hand coordinate system where positive X is "north" positive Y is "west" and positive Z is "up".
  • Quake BSP is a partitioning of 3D space by two volumes, recursively, until every volume is convex. The barriers that describe these volumes are planes.
  • Planes in BSP are described by a normal vector (direction in 3D space) and a distance (offset from origin, or the negated center of the "surface", if it helps to visualize it that way).

So an axially-aligned (read: flat, non-sloped) floor surface that's at -128 units would have a plane definition of (0, 0, 1) @ 128. That's a normal vector of positive Z and a distance of 128 units. Quake planes use inverted distances for some reason.

The dot-product of any two vectors essentially determines if they face each other, and how much. Vectors with a dot-product less than 0.0 face one another (read: collide), while those with dot-products greater than 0.0 would never intersect. But that's assuming the vectors start at the origin (0, 0, 0). So each plane's distance from the origin must be factored into the equation to determine sidedness correctly (consider two surfaces where one faces east and the other west, but they are "behind" each other -- e.g. the outward facing surfaces of your average column or pillar or door).

You can find this "dot-product minus distance" test throughout the Quake code base, in everything from pmove to the BSP compiler to the renderer:

The origin has no "pull" on your player's position in pmove. There is intentional precision loss (conversion of 32 bit floating point to 16 bit integer) to save network bandwidth. And gravity in Quake's pmove is nothing more than a constant acceleration applied in negative Z (which is probably the least crude approximation in all of pmove.c :)).

Hope this helps!

Edit: So, after I wrote this, I thought for a moment about the intentional precision loss in pmove (converting to 16 bit ints), and re-checked the code. It does in fact favor rounding your coordinates towards the origin. I don't think this could be considered significant, but there is not a measure in place to counter it:
Quake / Re: Windows 8 Vs. R1q2
Informative Informative
on March 19, 2013, 06:43:06 AM by ImperiusDamian
BTW, that post above was a tounge-in-cheek jab at my own system.  :>  But I actually do get fair performance on it anyway.  OpenGL runs average about 60-90 fps now, on this basic Intel integrated chipset.  The processor dictates how well things run.  1.8 Ghz does the current FPS, but I know someone who has a slightly newer, but same class of Express Chipset, on a 2.67 Ghz processor.  He gets around 250 FPS on average, which means that more intense games like Quake 4 could actually run decently on it.  Probably not anything higher-end though, especially within the last 4 years especially.

It's not that simple. id Tech 2 and id Tech 3 do not use the programmable pipeline. They use the OpenGL 1.x fixed-function pipeline, which any card from the last 10 years can utterly crush. This is why Quake2 and Quake3 are entirely CPU-bound on most hardware.

id Tech 4 was one of the first AAA engines to take advantage of OpenGL 2's programmable pipeline, in the form of per-pixel lighting. The fragment shaders in DOOM3 and Quake4 require a heck of a lot more GPU cycles than the FFP rasterization of Quake2. For this reason, plenty of hardware that was CPU-bound with Quake2 either becomes heavily GPU-bound or won't even run Quake4. I'm not sure your card supports OpenGL 2.0 at all.
Pages: [1] 2