..:: PCSX2 Forums ::..

(07-25-2010, 07:08 AM)Dangerousd777 Wrote: [ -> ]I see, there are many challenges involved. An interpreter is very accurate but is is also very slow.. if your in real-time terms, but what if you could interpret the entire game code overnight or something and then be able to translate all of it to assembly so that when you ran it on your PC it would only have to read the interpreted code and it would be much faster than recompiling to assembly in real time.

That solves the architecture problem of the games, once they're in native machine code they might not need emulation... or they might still require emulated hardware, but as long as you didn't have to recompile or interpret the game as you went along, it would be at least twice as fast.

You cant interpret the game overnight, as somebody would have to be playing it, moving around, using all items, using all possible attacks in battle against every possible enemy (talking about ffx) and then saving the interpreted commands in lets say an sql table. The next time you would be playing the game instead of interpreting again, it would find the needed command in a table, but that may take more time then actually interpreting the command.

On the other hand, its hypothetically possible to make an emotion engine to intel assembler code converter (big speedup, but time and space consuming). Did anybody try to do this? I mean, if the interpreter is nearly finished, this should be a possibility.

Quote:You cant interpret the game overnight, as somebody would have to be playing it, moving around, using all items, using all possible attacks in battle against every possible enemy (talking about ffx) and then saving the interpreted commands in lets say an sql table. The next time you would be playing the game instead of interpreting again, it would find the needed command in a table, but that may take more time then actually interpreting the command.

On the other hand, its hypothetically possible to make an emotion engine to intel assembler code converter (big speedup, but time and space consuming). Did anybody try to do this? I mean, if the interpreter is nearly finished, this should be a possibility.

Your right, but what I mean is instead of storing all the locations in a large database, rather you would make an x86 executable. If you went straight through the code line by line down to the bottom you would cover every single possibility within the game. The interpreter should be coded to optimize the code for execution on x86 processors, which would be instead of blending instructions basically which is what the EE core does, you would be separating them and running them parallel to each other in different threads. (It's supposedly improbable to be able to do this with the emulator because the core architecture performs on a 'combined thread' basis rather than a singlular-thread level like x86 does, and all you would have to do to optimize it is to designate the instructions to run independent of each other)

That is a limitation *only* with the PS2 Emotion Engine however, x86 CPUs have excellent speed when it comes to running a single thread.

And true, it is *very* possible to convert any code to any other code if you are able to recompile or interpret it [basically if it's *understood* by the converter then all your basically doing is decoding and encoding]. The interpreter for the IOP seems very effective, it only halves my framerate, but the interpreter for the VU1 or EE on FFX completely slow down my framerate.

I use the interpreter for the IOP because it's quicker than disabling speedhacks, then I can nail those tricky overdrives like Wakka's or Auron's.

Basically we're talking about recompiling or interpreting all the code of a PS2 game line-by-line (offline, not using emulation) to produce a working program for x86 processors. You would have to skip all of the game's resources and focus only on the executable code.. that'll speed up the process because what's the point of sorting through texture and sound files?

It's still difficult to figure what your going to do with all of the game's resources like the FMVs, sound and textures... if you create a separate x86 executable to 'read' those PS2-exclusive formats like you would using Windows Media Player to play music in the backround of a game which music volume you muted because you got bored of all the 'ding-ding-dings' and integrate them into the other's x86 execution or run independently of.

Still though, the fact your emulating shows it's possible! (Your just recompiling all the code in real time and having your PC 'pretend' to be a PS2)
Your creating a virtual machine... remove the need for a virtual machine by re-encoding the game executable and possibly resources for x86 and you literally translated all of it and have yourself a PC port if it's working. How will you change the resolution and everything? You'll have a separate executable like you do for some games which will change the execution parameters for the game.

How do companies usually port their games to different systems? It's that process which they use to port games from console to PC that we need to know about (know any games that were first on the PS2 and got ported eventually to PC? I do... Metal Gear Solid 2: Sons of Liberty [I have the PC and PS2 ports... it's like one of my fav games ever], plus you have all the options that you didn't in the original version)

Then if it were native, you would only need like a Pentium III to run the code. The PS2 'blends' instructions for computational efficiency but I believe if you just ran them separately you could do much better on PC architecture, while you would also be able to scale upwards in the amount of cores or threads run if needed.

The PCSX2 team is planning to add quad-core support, although you cannot have 'out-of-order execution' with the PS2 core.. so I would say you just isolate every unit (EE core 1, IOP core 2, VU0 core 3, VU1 core 4) and synchronize them the best that's possible. If you isolated them on a quad core @ 3-4 ghz you could get decent speeds [albeit maybe quarter or fifth realtime at best] just using all interpreters.

We need to find the method of console to PC porting for *most* instances in the past. Perhaps even the inverse of this operation holds some clues.

It is possible to make that converter, and it would consume only 5-15% more space for most games (considering were not inflating the size of the resources, just maybe the code). It would have to find the equivalents of instructions on the EE for x86 though, but that can't be too difficult... you could do almost anything with Assembly.

My guess is this site has some clues too: http://www.goingware.com/tips/getting-started/

It's about the compiler.. That's really all we need is a compiler, but it's going to take someone who is familiar with the PS2-exclusive code to write one.

(07-25-2010, 10:40 AM)Dangerousd777 Wrote: [ -> ]Your right, but what I mean is instead of storing all the locations in a large database, rather you would make an x86 executable.

Thats too slow due to HDD seek time, you would need to put the whole database in your RAM or some kind of super fast next-gen SSD.

Quote:It's still difficult to figure what your going to do with all of the game's resources like the FMVs, sound and textures... if you create a separate x86 executable to 'read' those PS2-exclusive formats like you would using Windows Media Player to play music in the backround of a game which music volume you muted because you got bored of all the 'ding-ding-dings' and integrate them into the other's x86 execution or run independently of.

You dont have to do anything to the resources, as long as they have the software that enables you to read them (thats in the game code) they present no problem.

Quote:How do companies usually port their games to different systems? It's that process which they use to port games from console to PC that we need to know about (know any games that were first on the PS2 and got ported eventually to PC? I do... Metal Gear Solid 2: Sons of Liberty [I have the PC and PS2 ports... it's like one of my fav games ever], plus you have all the options that you didn't in the original version)

The company thats making engines buys pc->ps2 software from sony
and then implements it in their engine. Later they sell it to other companies, who can choose for which platforms to compile the game they created.

Quote:Then if it were native, you would only need like a Pentium III to run the code. The PS2 'blends' instructions for computational efficiency but I believe if you just ran them separately you could do much better on PC architecture, while you would also be able to scale upwards in the amount of cores or threads run if needed.

Maybe, we cant be 100% about the speeds since EE does some floating point calculations better then a CPU of equal speed.

Quote:The PCSX2 team is planning to add quad-core support, although you cannot have 'out-of-order execution' with the PS2 core.. so I would say you just isolate every unit (EE core 1, IOP core 2, VU0 core 3, VU1 core 4) and synchronize them the best that's possible. If you isolated them on a quad core @ 3-4 ghz you could get decent speeds [albeit maybe quarter or fifth realtime at best] just using all interpreters.

Where did you hear this about quad core?

Its very hard to do a good sync in gaming, since the threads have to wait for one another at least 40 times per second (40fps is considered ok) for a game to be enjoyable. Note that directx11 supports multithreaded rendering, so maybe we'll see some mt rendering in gsdx11 or some other plugin.

(07-25-2010, 01:40 PM)Viperus Wrote: [ -> ]Thats too slow due to HDD seek time, you would need to put the whole database in your RAM or some kind of super fast next-gen SSD.

You dont have to do anything to the resources, as long as they have the software that enables you to read them (thats in the game code) they present no problem.

The company thats making engines buys pc->ps2 software from sony
and then implements it in their engine. Later they sell it to other companies, who can choose for which platforms to compile the game they created.

Maybe, we cant be 100% about the speeds since EE does some floating point calculations better then a CPU of equal speed.

Where did you hear this about quad core?

Its very hard to do a good sync in gaming, since the threads have to wait for one another at least 40 times per second (40fps is considered ok) for a game to be enjoyable. Note that directx11 supports multithreaded rendering, so maybe we'll see some mt rendering in gsdx11 or some other plugin.

Seek time can be improved by storing only the parts needed of the program in RAM, and reading the rest as you go along.

True, but I don't know anybody these days with Pentium IIIs, just Athlon and Pentium 4.

And I heard about the quad core on their google code homepage, they said they will add it later, 'if possible'.
http://code.google.com/p/pcsx2/

the quad core thingy is the there for long time now.... dont expect it soon or something like that.... also from as far as i have read its not that easy to do it so they dont work on it yet

(07-25-2010, 03:19 PM)iakoboss7 Wrote: [ -> ]the quad core thingy is the there for long time now.... dont expect it soon or something like that.... also from as far as i have read its not that easy to do it so they dont work on it yet

Want to know my bet? It's not *easily* possible... there can't be any out-of-order execution... only if you could split up all 4 units and synchronize them as tight as possible, but your not going to be able to scale upwards in the amount of threads.

Compiling the game in x86 machine code (assembly) or [to assembly then] C/C++ would actually be more feasible, considering you could port console games to PC if you have the right software... or if you don't then if you could code a compiler then it could be done.

Still though, I don't know how that guy who was having an issue with his memory card managed to get 40-50 FPS on a Pentium 1.8 @ 2.7 ghz... Although he has a massive amount of plugins, I'm sure with the right optimization I could get most games running at least 30 FPS (in framerate or execution speed)

The next game I'm testing is Ace Combat 4: Shattered Skies. I haven't tried it in nearly a year and I used it with 0.9.6 I believe... Once the speedhacks were added to PCSX2 I noticed but until the latest version they were pretty ineffectual for even the games that didn't challenge PS2 hardware.

For me a game can't be much more than 20-30% slower than realtime (42-48 FPS), and when it comes to rendering.. I don't care if I only see half frames at real-time execution speed, because you only notice it much when the framerate drops below 30. I've never been much a person centered on framerate, but I do like image quality. (anisotropic filtering and hardware anti-aliasing do wonders.. especially combined modes between multisampling and supersampling [internal resolution upscaling])

Playing these games brings back memories... if they weren't playable they would just bring a hint of frustration.

(07-25-2010, 03:19 PM)iakoboss7 Wrote: [ -> ]the quad core thingy is the there for long time now.... dont expect it soon or something like that.... also from as far as i have read its not that easy to do it so they dont work on it yet

If gabest makes a gsdx11 plugin and figuers out how to use the multithreaded rendering they added in dx11 (and you buy a dx11 compatible graphics card) its very possible. However, 4 threads without the use of dx11, that is problematic.

(07-25-2010, 09:53 PM)Viperus Wrote: [ -> ]If gabest makes a gsdx11 plugin and figuers out how to use the multithreaded rendering they added in dx11 (and you buy a dx11 compatible graphics card) its very possible. However, 4 threads without the use of dx11, that is problematic.

If Gabest makes a GSDX11 plugin... DirectX 11 is pretty much useless for me considering that direct compute and tessellation are nothing to really get all riled up about [at least not yet].

Windows XP has always been kind to me, especially since it only takes a third of the HDD space of Windows 7 [I used Windows 7 it was good but I'm fine with XP for now]

Anyways, multithreaded rendering only helps if your running the emulation fast enough to need multiple threads for rendering. If PCSX2 doesn't support any more cores, we can't expect that to be possible unless dual cores become 50% more efficient then they already are (an extra instruction a cycle instead of just 2).

However I don't think we'll really see any more dual cores just more quads and six core processors.

(07-25-2010, 10:00 PM)Dangerousd777 Wrote: [ -> ]Windows XP has always been kind to me, especially since it only takes a third of the HDD space of Windows 7 [I used Windows 7 it was good but I'm fine with XP for now]

Anyways, multithreaded rendering only helps if your running the emulation fast enough to need multiple threads for rendering. If PCSX2 doesn't support any more cores, we can't expect that to be possible unless dual cores become 50% more efficient then they already are (an extra instruction a cycle instead of just 2).

However I don't think we'll really see any more dual cores just more quads and six core processors.

Win7 has about the same I/O performance (Vista has lower lol) as WinXp plus it has a lot of improvements. DX10,11, aero, almost all drivers are installed automatically, they fixed a lot of tiny "bugs" that annoyed me in xp, way better wifi support and they practically never crash.

Playing FFX at 1920x1200 and high antialiasing could use more threads. Their statement about not using more then 2 cores probably didnt take multithreaded rendering into consideration.

Curent multithreaded games do this : 1 core does the AI, controls and sound, the other does the rendering, in some cases the 3rd core does physics. In most cases, the rendering core is at 100% while the others are 20-60% (on average PC). PCSX2 is doing something like that. Thats not "true" multithreading. Very few games use "true" multithreading, Lost planet being one of them. Having 2 more cores in lost planet gives you a considerable fps boost (they use their own, non dx11 related multicore rendering).



This is what i consider "true" multithreading.

Ah, your right true multithreading makes a huge difference. I'm trying out Ace Combat 4 and I'm only getting about 15-20 FPS in gameplay... (25-40 in speed with speedhacks but there isn't much improvement) which would make this playable on a fast dual core but this game is almost as hard as MGS3 to emulate. Glitchy as hell too (the GSDX plugin doesn't render correctly)