411–420 of 516 posts
CS before it went downhill. Played so much de_dust (before de_dust2 became popular) from the beta days to 1.6.
If you played the betas I wonder if you remember beta 7 and the jeepathon2k map. Not many people know that CS had driveable vehicles for a short time. It was pretty silly but a lot of fun.
i wonder how hard it would be to make this work for Counter Strike: Source
I remember playing one of the early CS betas as a Half-life mod in ~1999. It was such a huge leap in gameplay and style from anything else out there. Most FPSs up to this point were SciFi based, guns like the BFG and plasma guns. Counterstrike's focus on realism really altered how you connected with the game. Columbine had happened very recently and was still very much in the zeitgeist. There was a very real cultural…
Earlier quoted context omitted.
Is this actually true, or BS? If true, can someone explain? My mental model is that vsync will lock the framerate to the same as the monitor refresh. So if monitor is 60hz, my games graphical update rate runs at 60fps. Let's say without vsync, my graphical update rate would generously go up to 120hz. Worst case we're talking about an additional input latency due to vsync of maybe 1/60s? 16ms? I don't believe 16ms is…
if you have 0 input delay, worst case latency is still 32ms, because your input might come in when back frame is ready, but blit hasn't happened yet: render frame A, input comes in, blit frame A, render frame B, blit frame B. but your input delay is not 0, so your input might come in before frame A above, but frame A doesn't reflect input yet, which makes your worst case input latency 48ms: input comes in, blit ...,…
99% of the time a game after 1998 or so says "vsync" it means double buffered vsync, so I'll explain that version.
Let's say the game renders frames instantly.
Without vsync but locked at 60FPS, an input can take up to 16ms to cause an effect on the monitor because the game loop only applies and renders pending inputs once every 16ms at this framerate. Each input will have between 0ms and 16ms of lag.
In double buffered vsync at 60Hz, its the same thing: the game loop applies and renders pending inputs once every 16ms. But now the frame is not shown on the monitor right away. Instead, the loop waits for the monitor to be ready. And because the loop will restart right after that, this wait will always be another 16ms. Each input will have between 16ms and 32ms lag.
Of course if your render takes more than 16ms you will have more issues, but that's not the problem here. Even with a computer that renders instantly, the lag will be too much.
And yes this will be on top of the already existing lag of the game and peripherals.
I don't understand how you get 48ms. If I have a mouse with 4ms of lag, it will just add a constant 4ms to the total making worst case 32ms + 4ms. I did think it was 48ms at some point but now I think I just imagined it.
I recall installing CS from CDs. I was so excited to play, but my internet was so slow it took basically the rest of the day to download the updates. Then, when I got into the game, some servers had mods and maps to download which took forever. Needless to say, once I was playing I felt so gradified and cool. My dad brought home a 'flat' CRT a few months later from his work. It felt life changing at the time. A while…
Earlier quoted context omitted.
Given the boundary condition that a web browser can certainly not allow a game to make more out of the hardware, that is, the best case is that in-browser gaming is equal to native gaming, and the probable case is that it's somewhat worse; what is the rationale between targeting a browser?
Portability and accessibility are the two big ones for players. When games are a single click away, no dedicated client or launcher download required.... anyone can be a gamer.
Earlier quoted context omitted.
The latency issue would be in the timing of samples between the sound drivers, not from the game to the sound port. The sound data could take 50ms+ to make it through the DAC, but as long as it plays the signal to each driver with enough precision relative to the other (and assuming the response of the driver is sufficient), your brain would get the orientation info. The frames you're seeing are already around 50ms l…
I’m surprised to hear 50ms for audio processing. I’m a music producer and I can feel it at about 20ms of latency. (Pressing key on keyboard (musical) to hearing sound) I would have thought video games wouldn’t have more latency than audio production software.