Same FPS, slower games?

[gcp111]

(06-27-2009, 12:02 PM)Xtreme2damax Wrote: I know how to compile, but that's about all I know how to do. I'm not sure what needs to be changed in the code in order to solve this problem.

lol you should learn some C++ bro

I'm too lazy and don't have very many games ripped to test, so I can't. CacoFFF, just attach a patch if you do please

[CacoFFF]

I have experience in coding, but not c++, i have experience with the UnrealScript (which is based on c or c++), so i do know the basics.

I'm downloading VC++2008 express right now, making both xp use the same pagefile.sys saves a lot of space =)

Also, i still have to learn the basics with patch files.


Here's the simplest sample of unrealscript of mine i could find:

Code:

function FLOAT FRango(float Min, float Max, float Valor)
{    if (Min == Max)
        return Min;
    if (Min > Max)
        return Max;
    if ( Valor < Min )
        Valor = Min;
    else if (Valor > Max)
        Valor = Max;
    return Valor;
}
local variables work like this in uscript
    local int i;
    i = 0;
instead of
    int i = 0;

There's a whole bunch of differences here and there but i think that as long as i compile and test if it works, i can make some changes in dolphin without causing a mess.

I think i'll start by setting the watchdog to 15 in rev 3545 to see what happens. As soon as i finished downloading everything.

---

The DirectX SDK is a *little* bigger than expected, i doubt i'll get finished things up soon

[gcp111]

(06-27-2009, 12:34 PM)CacoFFF Wrote: Also, i still have to learn the basics with patch files.

I think you can use TortoiseSVN to export Patch files on Windows.

UnrealScript looks like JavaScript & C++ mixed together

[CacoFFF]

(06-27-2009, 12:52 PM)gcp111 Wrote:

(06-27-2009, 12:34 PM)CacoFFF Wrote: Also, i still have to learn the basics with patch files.

I think you can use TortoiseSVN to export Patch files on Windows.

UnrealScript looks like JavaScript & C++ mixed together

Yeah, it's perfect for learning..

Anyways, before posting an actual patch, i'll want to compile the thing and test it for myself first, my silly xp64 didn't even had any .Net framework installed, and i'm still downloading tons of stuff.

[Iulius]

3545 messed that up completly, you can change watchdog to 15 if you like, but it wont make things better (at least not for me)

framelimiter does nothing when its off, but it wont work with 3545 anymore, so you can remove that too.

(06-27-2009, 06:33 AM)gcp111 Wrote: lol, well... (1) request SVN access (2) submit patch to devs (3) make unofficial fork like you were going to (4) release patch for users to compile

(1)+(2) : devs dont want that kind of stuff in main svn

(3) simply no

(4) someone who cant put two "/" before a line of code will probably not be able to compile anyway.

[CacoFFF]

Well, it's time to bang our heads to the nearest wall we can find, i wonder how ector will react.

[gcp111]

(06-27-2009, 04:28 PM)CacoFFF Wrote: Well, it's time to bang our heads to the nearest wall we can find, i wonder how ector will react.

who knows... man this is fucked up
so what should we do?

[CacoFFF]

Well, i just tested 3548 and your framelimiter does work Iulius, i saw that the emulator had an overall 1 or 2 fps less than usual, with or without framelimiter or other audio.

Of course, i used 50 as limit since my games are PAL.
Also, I find annoying that fps counter that's always showing 50/~60 83%.

EDIT: I mistakenly wrote 3458 instead of 3548

[Iulius]

Caco, if the games run fullspeed for you with 50fps thats fine, but thats not the case here.

i have zelda tp still running fullspeed with around 25 (not exact anymore)

mario sunshine with 50fps fullspeed instead of 25 before.

mario kart DD running with 90fps and still being slow.

zelda WW now fullspeed around 40fps, before 25. of course other audio only limits at 50 or 60, so its allready much too fast.


and framelimiter does NOT work as it is supposed to work, at least not in the low fps regions (like 25 for zelda TP)

reason : the function where framelimiter sits is now called more often then the cpu actually calculated a frame as more frames are pushed out when only 1 frame has been calculated.

So it will limit twice or more for each frame, resulting in too low fps.


i dont see a good reason why you should, for example, in mario sunshine show every image twice to reach 50fps, while in background game still runs with 25fps.

the fps counter shows a 50, but you still only see 25 different pictures.


but you dont have any timing anymore.
framelimiter "thinks" the game runs with 50 fps, cause dolphin calls it 50 times a second, but the game itself is still running with 25fps -> so it calculated wrong sleep times -> stuttering.

[gcp111]

(06-28-2009, 05:27 PM)Iulius Wrote: reason : the function where framelimiter sits is now called more often then the cpu actually calculated a frame as more frames are pushed out when only 1 frame has been calculated.

Oh So are you going to fix it? Obviously you need to throw the code in where the frame actually starts...