(05-15-2014, 09:59 PM)ssshadow Wrote:

(05-15-2014, 09:43 PM)mushroom Wrote:

(05-15-2014, 09:24 PM)[Unknown] Wrote: I'm sorry, but it's pretty clear you did not understand my post. I discussed binaries, dynamic loading, and also the decoding stage.

-[Unknown]

Well, stepping by what you wrote it's obvious that what you're saying is wrong:

Quote:Certainly no game binary is 10GB.

http://www.examiner.com/article/file-sizes-revealed-for-final-fantasy-xiii-2-on-playstation-3-and-xbox-360

Perhaps we have a different idea of "game binary" here. Game "binary" is everything that makes up the game on the medium, not the max capacity of the medium itself. You also have a skewed description by thinking that RAM size must be 1:1 with the size of a binary itself, which couldn't make any sense.

Final Fantasy 7 for PSX takes up over 700 MB for disc 1's total binary image, including all code and data of the entire game; PSX has 2 MB of RAM total. Based on your assumption that a binary can't be larger than the size of RAM, how could the Playstation run the game then?

Game binary usually refers to the executable code, not game data which would be sound and graphic files and such.

When you load a game, either a Windows .exe, a .elf, or something else, you always load that program into memory for the CPU to fetch and execute the instructions. On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. But this is only the ".exe" part of a game. Everything else such as graphics gets loaded into RAM/VRAM as it is needed, and removed when it isn't needed any more. This can be cached to ram in order to improve loading times (and a smart OS probably will if the data is loaded/unloaded frequently), but hardly any more than that.

Also, [Unknown] is one of the big guys from ppsspp, assume he knows what he is talking about

(05-16-2014, 12:09 AM)derpf Wrote:

(05-15-2014, 09:59 PM)ssshadow Wrote:

(05-15-2014, 09:43 PM)mushroom Wrote:

(05-15-2014, 09:24 PM)[Unknown] Wrote: I'm sorry, but it's pretty clear you did not understand my post. I discussed binaries, dynamic loading, and also the decoding stage.

-[Unknown]

Well, stepping by what you wrote it's obvious that what you're saying is wrong:

Quote:Certainly no game binary is 10GB.

http://www.examiner.com/article/file-sizes-revealed-for-final-fantasy-xiii-2-on-playstation-3-and-xbox-360

Perhaps we have a different idea of "game binary" here. Game "binary" is everything that makes up the game on the medium, not the max capacity of the medium itself. You also have a skewed description by thinking that RAM size must be 1:1 with the size of a binary itself, which couldn't make any sense.

Final Fantasy 7 for PSX takes up over 700 MB for disc 1's total binary image, including all code and data of the entire game; PSX has 2 MB of RAM total. Based on your assumption that a binary can't be larger than the size of RAM, how could the Playstation run the game then?

Game binary usually refers to the executable code, not game data which would be sound and graphic files and such.

When you load a game, either a Windows .exe, a .elf, or something else, you always load that program into memory for the CPU to fetch and execute the instructions. On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. But this is only the ".exe" part of a game. Everything else such as graphics gets loaded into RAM/VRAM as it is needed, and removed when it isn't needed any more. This can be cached to ram in order to improve loading times (and a smart OS probably will if the data is loaded/unloaded frequently), but hardly any more than that.

Also, [Unknown] is one of the big guys from ppsspp, assume he knows what he is talking about

That's not strictly true as executables also contain data (only executable sections like .text have code). You can very well pack all of the game data into the executable itself, it's just that nobody in their right mind does that beyond small things like icons or .xpm images.

Quote:Yes, I mean the whole game not just the code.

(05-16-2014, 05:42 PM)Ontakeio Wrote: Yes, I mean the whole game not just the code. Did not mean to start arguments but I just meant that the whole code can be fetched and decoded prior to execution and the decoded instructions can be transferred into labels of commands.

When labels of commands are read by emu, appropriate functions can be called to immediately change RPCS3's state without having to decode as you play.

That is what I meant not bytecode, just with another parseable code that would not require instruction decoding of PowerPC code.

(05-16-2014, 07:14 PM)gamenoob Wrote:

(05-16-2014, 05:42 PM)Ontakeio Wrote: Yes, I mean the whole game not just the code. Did not mean to start arguments but I just meant that the whole code can be fetched and decoded prior to execution and the decoded instructions can be transferred into labels of commands.

When labels of commands are read by emu, appropriate functions can be called to immediately change RPCS3's state without having to decode as you play.

That is what I meant not bytecode, just with another parseable code that would not require instruction decoding of PowerPC code.

But on runtime instruction will be changed, How can you possibly decode earlier? Its not like encoding a set of frames(movie), its a realtime application emulation we are talking about.