Emulator

Are the games running too fast, that is, faster than they would on actual Nintendo
hardware?

Yea games runnig too fast cause i don't use any framelimiters new framelimiter
causes games running too slow, and patch gives ovewrall speedup

And when game changes limit from 30 to 60 even with higher fps game feels slower

in other words : the FPS counter doesn't work anymore since r3545 :(

You know better, i like new 60 fps fullspeed, but i don't like framelimiter and
fullspeed limit autochange

there is not even a limit at 60 with pal.

for example i got mario kart DD pal, running with 50fps fullspeed before 3545.
now it has up to 90fps but it is NOT fullspeed, its slow.

the problem is that gamespeed is no longer related to frames at all.

framelimiter can obviously not work when gamespeed is not synced with frameoutput.

i allready tried to fix that, but its not possible. i was not able to calculate a
appopriate cpu-wait anymore as the frametimes are extremly random now.

this results in effects like mario sunshine runs with 50fps framelimit in full speed,
but feels like stuttering cause many frames are showed twice or more and some dropped
completly.

i really like the update, it made some games much faster.

But please take care of the timing issue so that the frames are related to gamespeed
again.
at the moment, there is no possibility to control them for many games.

games where it can be testet easily :

• both zelda (GC) PAL, running much to fast with other audio

• mario kart DD Pal - runs about same speed like before, but shows at least double fps

• Wave race NTSC - hard, you need a very good cpu to see that there is no upper
  speedlimit even with other audio

• same with 1080°

Found one thing:
All games no matter how fast the are and PAL or NTSC, all games limit itself to
50fps in Single Core mode

Found that i SC mode games don't do saelfchanging fullspeed value to 20 or 30 it
stands constantly on 60, so maybe its DC issue?

I can't code again till July 9th. But I think this may be caused by at least one of:

• g_VideoInitialize->pCopiedToXFB may be called in the wrong place

• The CPU thread is calling Video_UpdateXFB multiple times before the GPU thread has
  a chance to respond to the update request. Video_UpdateXFB should wait till the GPU
  has responded to the previous request (which will stall the CPU but hopefully get
  correct timing back).

if updatexfb is called more then once per frame, that would explain everything.

if changing that works it would be wonderful.

just to understand : why is this respond important ?
cant you just go ahead ?

and if its important, would it be possible to go ahead and get the respond via some
interrupt or timer (like gpu watchdog)

so that we maybe dont loose the better performance with getting the timing back.

Only the thread that created the OpenGL context may call Renderer::Swap

I'm still out but I can't stand to watch people suffer because of my work...so please
try this patch. I know it compiles, but I can't test it on my crappy laptop. It might
not work. If anyone else can make sure it fixes problems, please feel free to commit.
Otherwise, I'll be back on July 9th.

I tested out that patch, and while single core mode works ok (although I'm not sure
about speed change), dual core mode is completely broken - just hangs.

Darn. Well, it was worth a try anyway.

"Frames per second" doesn't quite have the traditional meaning in Dolphin. There are
two rates: the rate of XFB copies and the rate of GL buffer swaps. XFB copies are
triggered by the graphics thread and buffer swaps are requested by the CPU thread
(but the graphics thread has to respond to the request).

XFB copies are controlled by the game, but buffer swaps are controlled by the Video
Interface emulator and they should occur at 50 or 60 Hz depending on the TV format.
In practice, that rate is limited by things like the GP Watchdog hack or the
framerate limiter if we get that working.

Buffer swap requests may occur too frequently. We might not be limiting that rate,
though we probably should. That's what the framerate limiter is for. Try setting it
to 60 FPS (or 50 on a PAL game) and tell me what happens. Oh, the framerate limiter's
broken. Crud.

Previous working behavior:

Buffer swaps happened at the same time as an XFB copy. It would only display the
results of that XFB copy, ignoring the game's XFB address. I don't think that
behavior is correct, so I was working to change it.

I'm just thinking aloud.

Please test with the latest commit.

If the game runs too fast, try setting the framelimiter to 50 or 60 FPS (depending on
PAL or NTSC). It may be working again.

This should be closed :)

I think the actual issue is that the FPS counter that we currently see has nothing to
do with "FPS", what we see now and call "FPS" is the refresh rate, and as it's
triggered by the CPU thread, it doesn't always variate when the GPU thread is slow...
You can see that easily by modifying the "watchdog" value, or using games like Mario
Sunshine, Starfox Assault those are heavy on the GPU thread, but not as much on the
CPU thread.

So the "FPS" counter actually lets you think the game is running fullspeed, while
there are some slowdowns and actual variations on the real framerate.
I'll commit a fix asap.