Theory about skipping frames

[¥R M0dd€r]

Here is an idea. I have no idea how well this is going to work, or if its possible(was planned by VK way back), anyway:
When a game lag(online or not), instead of printing every single frame with delay(ie lag), skip x amount of frames so the game can keep its original speed, or close to it.

Thoughts?

[WoRmINaToR]

So much of this game's math is based on frames-- I don't see how this would be possible to incorporate and maintain synchronization in multiplayer games. I just don't. How is math based on game frames supposed to be accurate if the processor is having to skip frames without completing the necessary cycles it needs to complete to make the calculations based on those frames it skipped? FPS games (as this is what you are referring to, right?) are allowed to take liberties with the lag scenario for several reasons-- none of which pertain to RTS games, unfortunately. Frame-for-frame synchronization is pretty necessary because RTS games aren't hosted on a master server that tells the players what they should be seeing. Each computer has its own version of the game environment running which is influenced by the information the other computers send them (as in, the commands they give their units), and each computer needs to maintain the EXACT SAME environment or things go haywire fast. If a computer is skipping frames, that's just too large of a possibility for something to go wrong and then BAM! Desync.

Anyways, even if this was possible, it would most likely require such an immense amount of work and would likely introduce an unimaginable amount of bugs into the game... I just don't see enough of a benefit to this to warrant the work and the risk of introducing show-stopping bugs.

[AlexB]

Lots of work has to be done to ensure the game is still in synch and the player actually still sees what's happening. It would not really help if the screen drawing pauses for a moment and the next thing you see is your base blowing up and you had no way to interact in the mean time. And if your PC lags about 15 frames behind, all your decisions would come a second too late.

[¥R M0dd€r]

May be impossible on this engine. I dont know. VK had plans to add this into NPatch, but he left quickly after he announced those plans(but it is a sign it may work?).
Btw, frame skipping is used in a lot of games(not just strategy), and the results are amazing.

There are many people who play online matches but havnt set their FPS to fixed. What this does is that your FPS run however well your PC can handle the scene, which can be slower then you would desire in an online match. The problem however when playing against someone else is that if their FPS is higher then yours, they end up running at a slowed down speed, the same as yours would be on variable FPS, so both your games suffer. When running at fixed FPS, the game seems to lock the frame rate at 60 FPS, and both yours and your opponents games run at the same 60 FPS speed, with what other people have said are frame skips to accelerate the games speed.

If you turn frame skip on, the game will skip frames in order to improve performance and reduce lag. Turning frame skip off forces the game to show every frame which reduces performance and can cause the game to go into an almost "slow-motion" mode if your computer isn't powerful enough to handle it.

This may also help
http://phoinix.sourceforge.net/frameskip.html

[Graion Dilach]

YRM, don't ignore the fact that what we do can't be that far away from YR itself. As Alex said, this is a big part of the core, which can't really be rewritten.

If this would be an engine rewrite, not a hack-to-fix project, then yes, what you say, do apply. But here it's just not a way.

FYI, LH_Mouse did tried to expand YR to two cores and he told us that he failed, because he couldn't sychronizate the cores to work together.

[AlexB]

In my opinion the article overcomplicates the matter a little. It's actually quite trivial: You cannot skip updating units and their positions, only the drawing of said units. You can draw (1_second - fps * update_time) / drawing_time frames per second without lag. Skipping drawing of more frames than this can make the game run faster, but only up to 1_second / update_time fps, where nothing will be drawn.

The problem is we aren't creating a new game. And if we were, there would be many more ways to optimize the game for modern hardware. The multicore support fail was to be expected. Really.

All in all, optimizations of this kind are impossible or at least too much hassle.

[Graion Dilach]

I know it was a bad idea from the first moment, I just wanted to pointed out that synchronization within a single PC failed, so no wonder it wouldn't work if we add network speed into it.

[XTF]

You'd skip drawing the frame, you wouldn't skip updating the 'world'. In theory this could work fine.

But time might be better spend finding why the game is performing so poorly on modern hardware.

[DCoder]

Whoa, deja vu.

The game lags like ass because the drawing routines are ass. They do all blitting and translucency in software, and do RLE unpacking of all compressed SHPs every time they need to be drawn. Because they do blitting in software, they have to Lock() and Unlock() the surfaces around each drawing operation. If the surfaces are in video RAM (like the sidebar is by default), that causes major pain because the surface pixel data has to be copied from VRAM to system RAM, and back afterwards.

[XTF]

Didn't you already move all surfaces to system memory?
What about caching the uncompressed SHPs?

[DCoder]

We did move them, according to some testers it helped a lot.

Caching uncompressed SHPs is bug 1686, it will probably get done someday.

After that, translucency and blitting algorithms would be the next big problem - I don't know how they did it, but Translucent=yes items lag a lot more than Translucency=xyz items do.

[¥R M0dd€r]

Translucent should not be a problem, We can avoid it by putting "no" on the tag
The other lag, we can not ignore.