This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 2 Vote(s) - 3.5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Very simple frame skipping code!
#1
Hello guys,

I'm pretty new here, and always wanted to have a look on a real emulator's source code. I saw that this one dosen't have any frame skipping option, so I decided to try implementing a simple code that omits the rendering process of the PaintGL() method in sceDisplay (from package HLE.modules150) every X frames for X frames. It was really hard at first to have a look on the source code globally because there was many files and I had troubles locating where the roots of the opengl/lwjgl calls were made, but I have finally find my way. I also had to find a work around a weird freeze bug, but that was simply because the emulator pauses if something is not called in the redering loop (and I don't understand this, but at least, it dosen't freeze now)

The code is still trash, and there are probably many ways to improve and optimize it, but the idea is there. It mght be very usefull for low end PCs. Well it is for me. Here is the link:
http://www.copypastecode.com/75893/

based on rev2255
Reply
#2
(08-05-2011, 02:31 PM)overgamer Wrote: Hello guys,

I'm pretty new here, and always wanted to have a look on a real emulator's source code. I saw that this one dosen't have any frame skipping option, so I decided to try implementing a simple code that omits the rendering process of the PaintGL() method in sceDisplay (from package HLE.modules150) every X frames for X frames. It was really hard at first to have a look on the source code globally because there was many files and I had troubles locating where the roots of the opengl/lwjgl calls were made, but I have finally find my way. I also had to find a work around a weird freeze bug, but that was simply because the emulator pauses if something is not called in the redering loop (and I don't understand this, but at least, it dosen't freeze now)

The code is still trash, and there are probably many ways to improve and optimize it, but the idea is there. It mght be very usefull for low end PCs. Well it is for me. Here is the link:
http://www.copypastecode.com/75893/

based on rev2255

Hmm... Interesting. Smile
I haven't really tested how much frame skipping has a positive impact on the emulator's rendering process, but it should still be a nice feature to have.
Reply
#3
ooooooHeartHeartSupport you Big GrinBig Grin
cpu: e8400 4g gpu: AMD HD6870 3g ddr2 800 I love jpcspHeart
Reply
#4
Frameskipping is more complicated than this. Some games are expecting to receive a signal when some display lists are run. If they don't receive it, they will be stuck.
I think it would be better to change the PRIM command to achieve frameskipping !
Reply
#5
(08-05-2011, 04:27 PM)Orphis Wrote: Frameskipping is more complicated than this. Some games are expecting to receive a signal when some display lists are run. If they don't receive it, they will be stuck.
I think it would be better to change the PRIM command to achieve frameskipping !

You mean executeCommandPRIM() from the VideoEngine class? But is there anything else in here that must definitively be called at rendering or you can omit the whole method without breaking the reception of thoses signals? Also I don't know if it is possible to use a profiler to check where exactly is the heavy rendering part, it would help a lot.
Reply
#6
I think the heavy functions in the OpenGL pipeline are the PRIM, BEZIER, SPLINE and the frame buffer transfer command (XKICK if I remember correctly). The other ones aren't very time consuming.
Reply
#7
(08-05-2011, 05:30 PM)Orphis Wrote: I think the heavy functions in the OpenGL pipeline are the PRIM, BEZIER, SPLINE and the frame buffer transfer command (XKICK if I remember correctly). The other ones aren't very time consuming.

Thanks for telling me that, I'll look carefully and see if I can add a flag to disable all the heavy routines and opengl calls when frameskipping is active. I'll ask questions if they are things I don't understand. =')

After some testing, you're right, my code dosen't improve much, so I'll have to dig thoses commands and see if anything can be disabled without hurting thoses signals.
Reply
#8
If we're lucky this will be like the other portable emulators and frame skipping will be 75% positive effect, if we're unlucky it will be like PCSX2 and be 90% negative effects.
Processor: AMD Phenom II X4 970 3.7 GHz, GPU: Geforce GTX 550 Ti, Ram: 16 GB, Windows 7 64-bit
Reply
#9
(08-05-2011, 04:27 PM)Orphis Wrote: Frameskipping is more complicated than this. Some games are expecting to receive a signal when some display lists are run. If they don't receive it, they will be stuck.

Indeed, but this basic frameskipping feature can IMHO be included as an "experimental" feature, that allows user to turn on/off at judgment.
I'm looking at this more as a solution to some flicking problems instead of a performance enhancing sneak oil Smile
Reply
#10
(08-05-2011, 05:30 PM)Orphis Wrote: I think the heavy functions in the OpenGL pipeline are the PRIM, BEZIER, SPLINE and the frame buffer transfer command (XKICK if I remember correctly). The other ones aren't very time consuming.
Yes, PRIM, BEZIER and SPLINE can be skipped, but TRXKICK should not: it is used by some games to copy parts of the display list.
Also, bounding boxes can probably be skipped as well: skip BBOX and always take the jump in BJUMP.

overgamer Wrote:Also I don't know if it is possible to use a profiler to check where exactly is the heavy rendering part, it would help a lot.
Statistics (e.g. duration of each VideoEngine command) can be activated by setting jpcsp.util.DurationStatistics.collectStatistics to true. Statistics are then displayed in the log file when Jpcsp exits.

In your draft implementation, you were actually not skipping any frame rendering: the GE list was still enqueued in the VideoEngine, the list processing was just delayed (probably to the next VSYNC). This would probably only cause the application to run slower, but not skip any frame.
The approach proposed by Orphis is much more promising.
Always include a complete log file at INFO level in your reports. Thanks! How to post a log
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)