currently released auto frameskip got another bug.
its about the no-wait, which prevents the limiter from waiting if there was skip the last frames.
this function was not working at all, resulting in lower fps at same speeds.
got a new version with up to about 50% more real fps at same speed.
of course it wont help if you need the full skip(full 1, full 2 etc)), but it helps a lot if you for exmaple would need only 0,5.
for example i get 19 real fps with fullspeed in z:tp at starting area where you get the horse.
before it was 12 realfps with fullspeed.
ordon raised from 12 to 16 fps, also with remaining same gamespeed.
i will do some more optimizing and release it maybe tomorrow.
I realized there were even more bugs still, since FPS wasn't very good (below 20 when I could do 40 without it)... Oh well, once again I'm excited to see how the auto frameskip will really perform.
ok, fixed and testet, it should work now.
note : framelimit is not as staedy anymore, because it tries not to waste processing power(sleep) when the game is allready to slow.
please note, that the patch file here is
for testing purpose only
there are two lines with :
no_framelimit=5;
that means, there will be no wait from framelimiter for 5 frames if a frame was skipped recently.
this is the part that needs optimizing.
the higher the number, the more fps will be drawn at same gamespeed, but also the gamespeed is more unsteady.
you can see how many waittime you have at the VPS counter in status bar.
for example : vps : 100 means that 100ms are wasted this second.
100 would mean, you could have up to 10% more fps, 50 means up to 5% more fps, etc.
of course that only matters if fps are below the limit you choose.
if you have 25 fps and set framelimit to 25, you will have waited time for obvious reasons.
please try it and tell me if you have games showing vps >1 while they are slow.
(frameskip and framelimit must be set !)
[
attachment=1095]
ok i tried it with baten kaitos. rev4016 frameskip set to 1 and framelimit set to 50
the VPS shows 1/6 17% never really understood how to read that.
but i notice the fps increases 3-4 more on the area that the game is usually slow. while fast areas i get about 1 fps increase.
i get good speeds on the slow areas now almost the same as the fast areas. its also feels a tiny bit smoother.
i dont really fully understand how it works. so i go buy how the game feels and right now it seems that it has gotten a lil bit better.
the first number shows the milliseconds of wasted power : in your case zero. (it starts with 1)
thats the way it should work
the second number shows how many next frames will be without framelimit.
thats not really instresting.
of course you cannot await wonders. it just removes the unneccary wait time from the frameskipper when the game is already slow.
still, more real frames is always better
thanks for testing.
if someone else confirms that, i will remove the debug stuff and it can be in svn.
I used to do a bit of programming including work on my own games.
Iulius What you're are doing is not really autoframeskipping and kind of a hack as you probably know, but I guess it can be a temporary solution until an official implementation.
However thank you for this thread and work
This is how auto frame skipping works from what I remember years ago ..
Basically you have game logic rendering, and the actual graphic rendering - they are seperated as the game logic always have to work regardless
1. Render frame X
2. if there's still time left until the end of this frame everything proceeds normally, and frameSkippingVariable = 0.
3. However if rendering made the game time pass into a different frame, it will check how many frames are behind and store them in a frameSkippingVariable. (integer)
4. the game continues the game logic calculations, and skips frames based on the last rendering.
Basically it does it by skipping rendering if (frameSkippingVariable > 0), and do frameSkippingVariable --. (so it counts down until all the missing game logic frames are calculated)
The FPS counter you see in games, is how many frames were actually rendered, while the game logic usually has a fixed FPS for algorithms, etc.
The fact the official team implemented frameskipping is great because it means they have seperated control between game logic and graphical rendering, it's only a matter of time until they implement real autoframe skipping and we'll be able to play without gameplay lags like in other emulators !
there is only 1 point where we differ :
Quote:However if rendering made the game time pass into a different frame, it will check how many frames are behind and store them in a frameSkippingVariable. (integer)
this is wrong.
you cant say at this position how many frames will have to be skipped.
It is much better and accurate to look EACH frame if the one before is still to late then to look in future for x frames.
Quote:because it means they have seperated control between game logic and graphical rendering
as long as i remember (early 3000) they always have been seperated, thats nothing new
Quote:The FPS counter you see in games, is how many frames were actually rendered, while the game logic usually has a fixed FPS for algorithms
you really think i could write a framelimiter and auto skip if i didn't know that ?
Auto Frame Skipping without much lag by 1)Storing frames in buffers? Not possible now, Dolphin needs huge processing power and games need sync. 2) guessing if next frame will be rendered in time? It can be done, with lots and lots of code, timers, counters, but it will have this sluggish effect in every major scene/polycount change.
Sometimes, after leaving heavy (in processing amount) areas, you would be skipping a few frames which could be rendered (wasting cpu) and when entering a new heavy area, it would slow down the game a little until you get to see the max amount of polys (and framebuffer effects) in screen.
This kind of frameskipping would work wonders reducing some lag in rendering if the amount of processing power needed for the scenes didn't change all the time, in fact, regular pc games avoid these lags by not implementing a fixed framerate formula... but that's not the way for wii/gc games, so it's not possible, and we stick the normal one.
(08-22-2009, 04:03 PM)Iulius Wrote: [ -> ]this is wrong.
you cant say at this position how many frames will have to be skipped.
It is much better and accurate to look EACH frame if the one before is still to late then to look in future for x frames.
Ya definitely, looks like you're on top of things !
Seems I misinterpreted this thread, based on the first post, good luck and thanks for your work