This is a brilliant DOSBox front end. Better than D-Fend as far as I am concerned! Well done for taking your time to do this for us retro gamers!!! You are a star!

Thanks man, I do my best.

D.O.G. is as stated on the DOSBox wikki a work in progress.And one that, as my ideas go, is neverending. 😎 😁 🙄

Anyways thanks,

Recent activities :
Getting this freak bug gone : The disapearing profiles in 1.53d and on.
Toolbar that is fully customisable
Full DOSBox long to shortname conversion.
...
And well, I can go on and on here but this forum is for DOSBox, so I'll stop.

Thanks to keep my spirit up,

Erik.

In my builds, SDL_Flip is related to the number of frames drawn. I don't know why this isn't in cvs, I've suggested it a few times 😀

As this is a thread about D.O.G within the DOSBox forum, I think you have every right to post as many messages as you want Eric! 😀 Keep up the good work!

Hi gulikoza,

The SDL_Flip is related to the number of frames drawn by DOSBox, not by the game. When I ran my SDLSpy on the official 0.65 running the house of the dead, then I always got 70 frames back. Wich in fact was not even close to the 1 frame a sec of the game.
I concluded that DOSBox just draws standard 70 frames a sec no matter what the game does (forgetting the frameskip), even if nothing changed. Correct me if I'm wrong here.
I don't know what the current CVS does, but I think it is due to the improved scalers.
The catch is that I need to get hold of a way to acces the internal flip command of the emulated VGA card.
When running into this problem I came up with two idea's. Maybe they already exist, don't know.

1.
Making a DOSBox patch that lets frontends read out values in DOXBox by using shared memorymapped files. But the problem with this is, I have no idea if Linux or a Mac allows such a thing, as I'm a Windows programmer.

2.
Making a DOSBox patch that allows for an auto frameskip. The current situation is that by setting cycles to auto, DOSBox decides what number of cycles need to be emulated but it keeps pumping out 70 frames a second while nothing changed in the picture. The thing that this patch could do is blocking an SDL_Flip and all mechanisms involved when no emulated VGA flip is done. Don't know what this does to the picture when doing this but if it works then I can read out the frames drawn by the game itself, and as a surplus DOSBox gets faster.

And I would love to do it myself, I've compiled DOSBox already a few times with gcc and it worked. But the thing I still need to know if I'm to build a patch, what do you need for it to be a valid patch, what files?

Erik.

The fps you're talking about is the screen refresh rate (70hz in
the case of your game).

> The catch is that I need to get hold of a way to acces the internal flip
> command of the emulated VGA card.

That's exactly the screen refresh rate. But, as you already noticed,
this is not correlated to what the game actually puts onto the screen.

As I've said...no. 2 is in my build, see the source on my page, it's a simple change. Scalers already track what has changed, it's just the matter of skipping the unecessary flip...

what the game puts on the screen isn;t that easy to detect. (without slowing dosbox down) you might want to play with the renderer code and see on each loop if there are modified blocks. If there are increase the amount of drawn pages. but it's always an estimate and probably not very accurate.

> Scalers already track what has changed, it's just the matter of skipping the unecessary flip...

That'd only give useful results if they're copying the screen at once.
How would you measure the fps of a game that has a static background
but uses a lot of sprites (which are not all drawn at once)?

Of course you can only get an estimate...a dos game might not even be doublebuffered and thus the concept of frames is rather vague 😀

ErikGG, see how my builds report FPS in the titlebar...this also speeds up opengl (an openglhq) a lot, since the updates are expensive.

Sorry gulikoza, got confused with "the number of frames drawn". Will check out the build.

The check for changes was one of the things I tried and as wd said, a static picture would return 0 frames rendered. Wich would freak out a noob and would think DOSBox isn't working anymore and it would slowdown DOSBox as QBix said.

So detecting the FPS of a DOS game is a bit more complex and game specific then I thought.
I could also copy the 'screen drawn' to D.O.G. from my SDLSPY and check it there. The advantage is that D.O.G. is on another core then DOSBox and therefore wouldn't slowdown DOSBox a lot. But this is only when running on a dual core.
Just checking a little block is a possibility but isn't accurate. I'll look for another way to detect a frame drawn.

Erik.

As a user, I am just glad these programs exist and I have fun playing these great old games because of them, so well done whoever is involved! 😀