Project

General

Profile

Actions

Emulator Issues #1050

closed

VideoInterFace issue

Added by Autoran1 over 15 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Since 3545 all games now has fullspeed like it must be 50 for PAL and 60
for NTSC this is great, but here's the issue PAL games are also has 60fps
limit, and some games like Mario and Zeldas changing the fullspeed limit
itself like here:
http://img151.imageshack.us/img151/7526/17832635.jpg
http://img151.imageshack.us/img151/6067/76577287.jpg
after all here's the patch that raises speed and would be more recent to
the latest VideoInterface changes

Actions #1

Updated by Nolan.Check over 15 years ago

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

Actions #2

Updated by Autoran1 over 15 years ago

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

Actions #3

Updated by Autoran1 over 15 years ago

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

Actions #4

Updated by sl1nk3.s over 15 years ago

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

Actions #5

Updated by Autoran1 over 15 years ago

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

Actions #6

Updated by Realsmasher over 15 years ago

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°

Actions #7

Updated by Autoran1 over 15 years ago

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

Actions #8

Updated by Autoran1 over 15 years ago

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?

Actions #9

Updated by Nolan.Check over 15 years ago

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).

Actions #10

Updated by Realsmasher over 15 years ago

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.

Actions #11

Updated by Nolan.Check over 15 years ago

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

Actions #12

Updated by marcus over 15 years ago

  • Status changed from New to Accepted

Note that the fps counter doesn't work right now and will probably not be fixed until
Nolan comes back.

Actions #13

Updated by Nolan.Check over 15 years ago

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.

Actions #14

Updated by Anonymous over 15 years ago

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.

Actions #15

Updated by Nolan.Check over 15 years ago

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.

Actions #16

Updated by Nolan.Check over 15 years ago

Please test with the latest commit.

Actions #17

Updated by Nolan.Check over 15 years ago

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.

Actions #18

Updated by sskkiipp over 15 years ago

This should be closed :)

Actions #19

Updated by sl1nk3.s over 15 years ago

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.

Actions #20

Updated by sl1nk3.s over 15 years ago

  • Status changed from Accepted to Fixed

now this should be fixed by r3920

Actions

Also available in: Atom PDF