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:
  • 3 Vote(s) - 3.67 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Some (possibly) New Ideas for RPCS3
#34
(05-18-2014, 12:01 AM)derpf Wrote:
(05-17-2014, 09:53 PM)ssshadow Wrote:
(05-17-2014, 07:33 PM)gamenoob Wrote: Are you asking that, people should de-compile game code to something workable and then recompile to x86? That is an enormous task. And it is not generic either,you have to work for every game. Basically porting a huge collection ps3 games.

Isn't this what the SPU recompiler already does? I see a ton of .log files with x86 assembler in them Wink

I think he meant statically (and I doubt RPCS3 is going to suddenly gain a static PPU recompiler), whereas the SPU recompiler is a JIT.

I grab the executable, let it run and analyze the ppu-spu instructions, data pointers . I got all instructions, then I trace it back to something high level language aka decompiling. Then depending upon runtime platform(x86, arm etc), I recompile these. And finally run it to host hardware. Yes it is static thing. The problem is: every game will have different instructions. So you have to do it for every game. The catch is: a system of similar raw power or less should be able to emulate ps3 pretty nicely.

There is another "probable" problem. I said "probable" because I am not sure of it. Lets consider an unity3d game, on which there is a script. Consider the pseudo code snippet of this script:

Code:
if(boolA){assemblyFuncA();}
else if(boolB){assemblyFuncB();}
else{assemblyFuncC();}


Here there are three function. For simplicity, lets consider the inside content of function is pure assembly. So depending upon situation(the bools), different set of instruction will run. When game engine compile the whole game project, one or multiple executable is formed. Lets consider you are analyzing this game. Which one can you do?

Case 1: we grab the executable, we can decompile it. We can get all the "function's inside instructions".
Case 2: We grab the executable, we let it run. When appropriate condition is met, proper set of instruction will run. For example: if "boolB" never happens in an instance of emulator(with respective game title running), instructions within "assemblyFuncB()" will never be collected either. So how can you decode in this case 2?


If you can do case 1, then prior decoding will be great. If not, then I guess we have to do something else.
Reply


Messages In This Thread
Some (possibly) New Ideas for RPCS3 - by Ontakeio - 04-24-2014, 09:46 PM
RE: Some (possibly) New Ideas for RPCS3 - by notq - 04-25-2014, 12:16 AM
RE: Some (possibly) New Ideas for RPCS3 - by gamenoob - 05-18-2014, 10:51 AM

Forum Jump:


Users browsing this thread: 1 Guest(s)