No more slowdown
#21
(03-19-2013, 06:15 PM)nosisab Ken Keleh Wrote: To be in peace with my conscience I tried those settings with a few games in my system. The most demanding ones, which could really enjoy some performance, like Zone of Enders actually had the FPS decreased by fair amount and (at least in my system, none the games got a boost).
have you change that game res to your GPU capability?(e.g 640x480,800x600,etc)or lower it res? cos some games run slow on native res and need to be changed it res. Smile
Reply

Sponsored links

#22
(03-19-2013, 05:18 PM)Preet Wrote: Hi billyash,thanks for all your effort.i appreciate settings.now my game run at full speed even in 2x native.now i can enjoy playing my favourite games in some HD resolution.but one problem audio is broken in cutscenes.how i can fix that?? Thanks in Advance!!! Smile
coz it value is constant,
right now i request dev to make it automatic, that might be solve sound issue
http://forums.pcsx2.net/Thread-Request-for-dev
i hope dev hear me and implement in svn. Smile
Reply
#23
(03-19-2013, 11:51 PM)billyash Wrote: have you change that game res to your GPU capability?(e.g 640x480,800x600,etc)or lower it res? cos some games run slow on native res and need to be changed it res. Smile

Hmm, no, I used the 3x I use normally. But then, I made the test to have clear notion of what is going on. Actually the resolution should not affect the final result since it is done totally at the GPU side and not involves the emulator that much.

But, there is a but, that's not the kind of tweak I need to resource on my system since it runs many games at full speed and a few which needs just a little speedhack. Actual test of that procedure leads only to issues in that case and I understand is not fair to judge from that stand point.

It may help those struggling to get performance on weaker machines although probably still dependent on the game, to some it will just fail totally, to another it may mean the difference and make for an enjoyable play.
Imagination is where we are truly real
Reply
#24
(03-20-2013, 03:47 PM)nosisab Ken Keleh Wrote: Hmm, no, I used the 3x I use normally. But then, I made the test to have clear notion of what is going on. Actually the resolution should not affect the final result since it is done totally at the GPU side and not involves the emulator that much.

But, there is a but, that's not the kind of tweak I need to resource on my system since it runs many games at full speed and a few which needs just a little speedhack. Actual test of that procedure leads only to issues in that case and I understand is not fair to judge from that stand point.

It may help those struggling to get performance on weaker machines although probably still dependent on the game, to some it will just fail totally, to another it may mean the difference and make for an enjoyable play.

but I am sorry I don't get the point? Are you gain speed on lower res? I mean on your game (zone of enders)
Reply
#25
(03-20-2013, 03:54 PM)billyash Wrote: but I am sorry I don't get the point? Are you gain speed on lower res? Smile

I did not test at lower resolution and if I'd need to do it so the tweak already is not for me since I can have the game running at full speed using VU cycle stealing at 2 (Yeah, I'm telling about Zone of Enders and that game is hard on the emulator, actually it is a game that does not like EE cyclerate even). Almost every other game I have and play do it nicely without any hack at all.

In my case, no game at all got any improvement from the tweak since they ran at 60 FPS already and I see no point removing the framelimiter to verify if had general FPS gain. On the other side some games got issues at once and some seemed to ran normally on the short testing done.

That's the reason I told would not be fair judging those settings under that scenery, beyond not helping in that case it actually harmed the experience.

Still, since it is really reducing the number of frames to be rendered by second, it may help weaker machines, there is a price but in this specific case may be a good tradeoff.

Edit: EE cyclerate does something similar by reducing the "apparent" clock the actual EE (the PS2 CPU) runs, the difference is EE does it in a relatively more integrated way and even then may lead to sound sync issues on many games (see the similarity?). That could explain why ZoE actually got FPS hit, since it does not run fine with EE cyclerate also. Still, despite the similarity, EE cyclerate and the proposed Frames to render reduction tweak aren't the same thing and will have different results.
Imagination is where we are truly real
Reply
#26
(03-20-2013, 04:09 PM)nosisab Ken Keleh Wrote: I did not test at lower resolution and if I'd need to do it so the tweak already is not for me since I can have the game running at full speed using VU cycle stealing at 2 (Yeah, I'm telling about Zone of Enders and that game is hard on the emulator, actually it is a game that does not like EE cyclerate even). Almost every other game I have and play do it nicely without any hack at all.

In my case, no game at all got any improvement from the tweak since they ran at 60 FPS already and I see no point removing the framelimiter to verify if had general FPS gain. On the other side some games got issues at once and some seemed to ran normally on the short testing done.

That's the reason I told would not be fair judging those settings under that scenery, beyond not helping in that case it actually harmed the experience.

Still, since it is really reducing the number of frames to be rendered by second, it may help weaker machines, there is a price but in this specific case may be a good tradeoff.

so is it mean lowering that game res and set without VU stealing makes game faster?
Reply
#27
(03-20-2013, 04:19 PM)billyash Wrote: so is it mean lowering that game res and set without VU stealing makes game faster?

VU cycle stealing does skip some the vector calculations but not whole frames as the Frame skip would do.

The proposed tweak does not skip frames, it just changes the number of frames to be rendered per second. That would not be a problem for PC, as you must have noticed already, in native PC games does not changes that much the visual experience if the game runs at 30 or 60+ FPS.

That's because everything is synchronized in real time, if something is to take 3 seconds to happen (like moving from point A to point B) it will take that time does not matter the FPS. What changes in this case is the length of the step in each frame of that moving object. The eye is not so selective to perceive the lack of smoothness above certain FPS.

But in console that's not totally true. In almost all PS2 games, the movement from A to B is tied with the frame, so if the FPS falls the object is slowed (slowmotion). When you change the FPS limiter you compensate this making the emulator to draw more frames (actually repeating already filled buffers).

That's of course is already issues prone by itself and made worse because not only the image but almost everything else is tied with that frames expected from PS2, not the FPS the emulator is actually displaying. Among the things depending on that synchronization is sound, but not the only thing, general events may be bound to it also.

Is not hard to imagine the potential for problems which could arise. On the other hand, that is a performance trick also and I believe PS2 itself uses something like it in some games by the game's developer (GoW was discussed once as presenting something like it). Just that in this case the game's developer provided ways to keep the sync and the whole thing works as expected.

So, that could become a way to actually increase performance in some games from the PCSX2 perspective. But to it would be necessary the several modules to be aware of that so to not lose the sync and to compensate correctly eventual discrepancies.

As proposed, just changing the ini to "force" low frames to be rendered per second might work for weak machines, more powerful machine simply don't need it but could take advantage if no collateral issues arise.

The problem is almost always the price will be high with that change in the ini alone, enough to break a lot of things if used in a general fashion.

So, for now, the tweak may help some people to get certain games to run better on machines where it would not run nicely otherwise. So, those with problems getting reasonable speed should try it, knowing the potential problems and willing to accept eventual glitches, for even then may be a good tradeoff.

That is something to be experimented case by case, trying different values and if is the case, trying to compensate whatever else is broken, the sound for instance, or just accepting the tradeoff.

What shall not be expected is perfection and shall not ever be reported as "bug" any problem, issue or glitch under this circumstance. The user may attempt it but must be aware it is a workaround, not a solution for weak machines.
Imagination is where we are truly real
Reply
#28
(03-20-2013, 05:07 PM)nosisab Ken Keleh Wrote: VU cycle stealing does skip some the vector calculations but not whole frames as the Frame skip would do.

The proposed tweak does not skip frames, it just changes the number of frames to be rendered per second. That would not be a problem for PC, as you must have noticed already, in native PC games does not changes that much the visual experience if the game runs at 30 or 60+ FPS.

That's because everything is synchronized in real time, if something is to take 3 seconds to happen (like moving from point A to point B) it will take that time does not matter the FPS. What changes in this case is the length of the step in each frame of that moving object. The eye is not so selective to perceive the lack of smoothness above certain FPS.

But in console that's not totally true. In almost all PS2 games, the movement from A to B is tied with the frame, so if the FPS falls the object is slowed (slowmotion). When you change the FPS limiter you compensate this making the emulator to draw more frames (actually repeating already filled buffers).

That's of course is already issues prone by itself and made worse because not only the image but almost everything else is tied with that frames expected from PS2, not the FPS the emulator is actually displaying. Among the things depending on that synchronization is sound, but not the only thing, general events may be bound to it also.

Is not hard to imagine the potential for problems which could arise. On the other hand, that is a performance trick also and I believe PS2 itself uses something like it in some games by the game's developer (GoW was discussed once as presenting something like it). Just that in this case the game's developer provided ways to keep the sync and the whole thing works as expected.

So, that could become a way to actually increase performance in some games from the PCSX2 perspective. But to it would be necessary the several modules to be aware of that so to not lose the sync and to compensate correctly eventual discrepancies.

As proposed, just changing the ini to "force" low frames to be rendered per second might work for weak machines, more powerful machine simply don't need it but could take advantage if no collateral issues arise.

The problem is almost always the price will be high with that change in the ini alone, enough to break a lot of things if used in a general fashion.

So, for now, the tweak may help some people to get certain games to run better on machines where it would not run nicely otherwise. So, those with problems getting reasonable speed should try it, knowing the potential problems and willing to accept eventual glitches, for even then may be a good tradeoff.

That is something to be experimented case by case, trying different values and if is the case, trying to compensate whatever else is broken, the sound for instance, or just accepting the tradeoff.

What shall not be expected is perfection and shall not ever be reported as "bug" any problem, issue or glitch under this circumstance. The user may attempt it but must be aware it is a workaround, not a solution for weak machines.
ok, that means that games gain speed,right?
im just curious if my methode was work for all PS2 games or not cos some says it was mechanic allow. Cos in my expectation, if my methode
http://forums.pcsx2.net/Thread-Request-for-dev?page=2
was implemented in pcsx2 and games still slow, i think was caused with GPU or CPU
capability Smile
Reply
#29
Are all your demanding games run faster on lower res? Smile thank you
Reply
#30
(03-20-2013, 05:57 PM)billyash Wrote: ok, that means that games gain speed,right?
im just curious if my methode was work for all PS2 games or not cos some says it was mechanic allow. Cos in my expectation, if my methode
http://forums.pcsx2.net/Thread-Request-for-dev?page=2
was implemented in pcsx2 and games still slow, i think was caused with GPU or CPU
capability Smile

You can eat half the dinner faster than the whole dish, right? good but you might get hungry.

Why I'm thinking I'm failing to explain the simpler part of the whole thing?

Is more or less like that: If the machine can already get full speed without the tweak, that's OK, it will not see improvement from it and possibly will get a lot of problems.

If the machine can't render the totality of frames in due time, it may be able to render half of them in due time, so may come gain from it. Just that there is a price and may be a very high price, enough to prevent that tweak to be generally and officially recommended...

Actually you could change these same NTSC and PAL defaults directly under the GUI till some time ago (they are still there, just were grayed out) but people began trying this very same thing and broke a lot of things and then started crying in despair and to blame the emulator for their actions.

Edit, to make yet more clear: When I say frame, above, I don't mean only the image but all things associated with that frame in the actual PS2. And that is something falling on the CPU, the EE processing the program flow, the VUs actually calculating the vetors (mostly associated with the graphics but still on the PC CPU), and so on.

When the result of the above mess go to GS, then the graphics plugin comes to action and is in it (the graphics plugin and then the GPU) that all party with upscale and those other fancies do happen. GS still have the rasterization and everything else needed to transform the vectors into actual image. Normally that last stage is pushed onto the GPU and processed in it's hardware, else it enters software mode and then still more load for the already overloaded CPU.

If the Video card is good enough it will do well the upscale 2x, 3x ... and all those other fancies in GSDX or another plugin, without taxing the CPU. So, if the GPU is good enough it will not harm the final emulation speed, if it is crappy, then it may have difficulty with anything else than native and sometimes even with it.
Imagination is where we are truly real
Reply




Users browsing this thread: 1 Guest(s)