VOGONS

Common searches


First post, by user222

User metadata
Rank Member
Rank
Member
Anonymous wrote:

I made simple modifications to DOSBox to update screen only when frame buffer is changed.
Originally CPU load was 100% in command prompt at my old K6-2-550MHz. After my modifications CPU load becomes ~30% (screen is updeted to draw cursor blinking).
But further modifications is needed - to update not whole screen, but only changed parts. Such approach will eliminate whole screen updates on mouse cursor move (for example).

Could someone get this into the official source repository, and post a binary file? Also, why isn't this patch applied to the CVS source? It's not on CVS Compile either.

Reply 2 of 6, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

DOS games are mostly weird when it comes to updating the screen. They generally don't use vsync, sometimes even update only parts of the screen with the next frame. I experimented with partial updates at the early stages of my D3D patch (very convenient, since d3d allows you to only partially update the texture) but I've dropped it later. Any minor (because of the constant updates) speed increase you get by not updating the whole screen you loose when you try to figure out what has changed. Surface, overlay (and D3D) modes take only a fraction of my cpu (0%-5%) when simply left idle in prompt, even at 70 updates per s.

Reply 3 of 6, by user222

User metadata
Rank Member
Rank
Member
gulikoza wrote:

DOS games are mostly weird when it comes to updating the screen. They generally don't use vsync, sometimes even update only parts of the screen with the next frame.

This is actually the best, because it uses the least system resources. I actually wish the newest games would do this. However, it's too bad that the DOS games themselves don't implement idle detection.

Reply 5 of 6, by jusid

User metadata
Rank Newbie
Rank
Newbie

Currently I placed a memory range check in write to memory functions. When a program writes to frame buffer memory and value to be written is differnt from existing value a flag is set. In screen update function this flag is checked. If the flag is set - screen is updated, if not - update is skipped.

It is simple and effective.

As I mentioned it saves a lot of CPU time at old computers.

Currently I am busy and have no time to prepare patch. When I have some free time I will do it.

Reply 6 of 6, by user222

User metadata
Rank Member
Rank
Member
jusid wrote:
Currently I placed a memory range check in write to memory functions. When a program writes to frame buffer memory and value to […]
Show full quote

Currently I placed a memory range check in write to memory functions. When a program writes to frame buffer memory and value to be written is differnt from existing value a flag is set. In screen update function this flag is checked. If the flag is set - screen is updated, if not - update is skipped.

It is simple and effective.

As I mentioned it saves a lot of CPU time at old computers.

Currently I am busy and have no time to prepare patch. When I have some free time I will do it.

Yes, I agree it's a very good idea, since a normal application doesn't usually update the screen constantly. It's not really necessary for games, though. However, please make this option available in the config file, because it's very useful for software that aren't games, such as Windows 3.11.