Some (possibly) New Ideas for RPCS3 - Printable Version +- RPCS3 Forums (https://forums.rpcs3.net) +-- Forum: Support & Issues (https://forums.rpcs3.net/forumdisplay.php?fid=17) +--- Forum: Support (https://forums.rpcs3.net/forumdisplay.php?fid=18) +--- Thread: Some (possibly) New Ideas for RPCS3 (/showthread.php?tid=161420) |
RE: Some (possibly) New Ideas for RPCS3 - ssshadow - 05-15-2014 (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. 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 RE: Some (possibly) New Ideas for RPCS3 - flashmozzg - 05-15-2014 (05-15-2014, 09:43 PM)mushroom Wrote: 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.No it isn't. Binary is code that console can execute. Like .exe (.dll) on pc. Read again. RE: Some (possibly) New Ideas for RPCS3 - derpf - 05-16-2014 (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. 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. RE: Some (possibly) New Ideas for RPCS3 - ssshadow - 05-16-2014 (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. I know, that's why I said "On a really basic level, that is basically what an .exe is, a long list of instructions for the cpu to follow. " It's certainly the most relevant part in this context. RE: Some (possibly) New Ideas for RPCS3 - Ontakeio - 05-16-2014 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. RE: Some (possibly) New Ideas for RPCS3 - Nekotekina - 05-16-2014 Quote:Yes, I mean the whole game not just the code. It makes so much sense so I want to close this thread immediately. RE: Some (possibly) New Ideas for RPCS3 - gamenoob - 05-16-2014 (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. 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. RE: Some (possibly) New Ideas for RPCS3 - derpf - 05-16-2014 (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. As far as we know, PS3 games cannot be polymorphic, so you can well do the fetching and decoding ahead of time. I highly doubt this would bring you much over the current system unless you want to waste a huge amount of memory. RE: Some (possibly) New Ideas for RPCS3 - androidlover - 05-17-2014 If all code can be decoded ahead of time before playing, the emulator can simply work like how ontakeo said, no? Wouldn't that make it faster if it was all decoded ahead of time and cached? Sounds like it would be potentially faster than a dynamic recompiler because the dynarec still has to decode as you play, even if it stores the decoded instructions in RAM. RE: Some (possibly) New Ideas for RPCS3 - flashmozzg - 05-17-2014 don't think that decoding the code is bottleneck right now. |