11-08-2013, 06:59 PM
OP, although is understandable the user not understanding the differences between running native code and emulating a hardware (or even software), your reply sounded bad because you acted as know that difference, what clearly don't.
Emulating a different computer hardware goes beyond simply translating totally different instruction set (what is by itself demanding around that three times mentioned by refraction). The emulation is a lot easier when the emulated machine is equal or at least resembles the emulating one and that is not PS2 case at all.
Don't be fooled by the apparent weakness of EE (the PS2 CPU), PS2 hardware is far more complex than just it. Where in your common PC the bulk of processing is divided by the CPU and GPU, PS2 uses a different approach including yet two more hardware pieces called VU (for Vector unities).
x86/amd64 based CPUs all have one or few more embedded vector unities you can call float point unities but the bulk of them goes under the GPU. This approach allows for PC games pushing on the GPU almost all graphical processing, as it must be while the CPU is responsible by the general logic flow.
PS2 works differently in that the VUs are not exactly part of it's CPU as aren't part of GS (PS2 graphical engine). The VUs sit midway serving both, making too hard to define and decide which should be using it, EE or GS. What is meant is there is no clear definition about what is general processing task and graphical treatment task, the consequence is the bulk of work goes to the emulating machine CPU.
That's the reason for people saying is nonsense comparing native code with emulation and that's right. Not only because the sheer power necessary for the emulating machine over the emulated machine's power but the performance is affected by the actual emulated machine software (I mean the games here) which can be nicely behaving, making easier to implement optimizations and shortcuts as might be a misbehaving bit** making those optimizations more a hindrance than help.
Better stopping pointing the differences here but you can believe there are many more, all contributing to making direct comparison near uterly nonsense.
So, better is saying in all your posts you told us about the youtube tutorials and things you did, all questionable. which should be reserved as despair resources when everything else failed. At this point reinstalling the emulator might not be enough if you don't grant the complete removal of the ini files. Is highly advisable you start the emulator from scratch and let it to reconstruct the config files completely.
Once that's done, try the speedhacks, VU cycle stealing and EE cycle rate are your best bet to achieve some performance gain... keep away from dabbling with those other parameters till absolutely necessary (despair case).
Emulating a different computer hardware goes beyond simply translating totally different instruction set (what is by itself demanding around that three times mentioned by refraction). The emulation is a lot easier when the emulated machine is equal or at least resembles the emulating one and that is not PS2 case at all.
Don't be fooled by the apparent weakness of EE (the PS2 CPU), PS2 hardware is far more complex than just it. Where in your common PC the bulk of processing is divided by the CPU and GPU, PS2 uses a different approach including yet two more hardware pieces called VU (for Vector unities).
x86/amd64 based CPUs all have one or few more embedded vector unities you can call float point unities but the bulk of them goes under the GPU. This approach allows for PC games pushing on the GPU almost all graphical processing, as it must be while the CPU is responsible by the general logic flow.
PS2 works differently in that the VUs are not exactly part of it's CPU as aren't part of GS (PS2 graphical engine). The VUs sit midway serving both, making too hard to define and decide which should be using it, EE or GS. What is meant is there is no clear definition about what is general processing task and graphical treatment task, the consequence is the bulk of work goes to the emulating machine CPU.
That's the reason for people saying is nonsense comparing native code with emulation and that's right. Not only because the sheer power necessary for the emulating machine over the emulated machine's power but the performance is affected by the actual emulated machine software (I mean the games here) which can be nicely behaving, making easier to implement optimizations and shortcuts as might be a misbehaving bit** making those optimizations more a hindrance than help.
Better stopping pointing the differences here but you can believe there are many more, all contributing to making direct comparison near uterly nonsense.
So, better is saying in all your posts you told us about the youtube tutorials and things you did, all questionable. which should be reserved as despair resources when everything else failed. At this point reinstalling the emulator might not be enough if you don't grant the complete removal of the ini files. Is highly advisable you start the emulator from scratch and let it to reconstruct the config files completely.
Once that's done, try the speedhacks, VU cycle stealing and EE cycle rate are your best bet to achieve some performance gain... keep away from dabbling with those other parameters till absolutely necessary (despair case).