Pc games to be ported


sukhi2011

Active Member
Joined
Apr 26, 2011
Messages
845
Age
46
Location
Birmingham
We have had few games on pandora such as doom,quake 3 and many others,is there any chance of getting the ones below ported to our beloved console:


1. Sonic adventure dx


2. Sonic heroes


3. Sonic riders


4. Sonic & sega all stars racing


5. legacy o kain defiance


6. chaos legion


7. resident evil 4,5


8. super street fighter 4 arcade edition


9. metal gear solid 2 substance


10.halo 1,2


Can this ever happen or do they need to be opensource projects.
 
5HFJA.png



The wiki is your friend http://pandorawiki.org/Port_requests
 
Last edited by a moderator:
No source, no port, no exception! And there's no way in Hell any of those companies would open-source their stuff.
 
Last edited by a moderator:
8. super street fighter 4 arcade edition


I'm sorry that one made me laugh =)
 
why is this thread funnier to me than the nds emulator threads?
 
Maybe you should ask the devs of those games. They might if you say please.
 
Last edited by a moderator:
I can't believe that after being active in handheld communities for as many years as you have been you're actually asking this.
 

I have one problem with that diagram - the box that says "Is it an open source program?" where "No" goes straight to a "Can't be done" box. I point you at XCOM on the front page of the website at the moment, or any one of a million emulated games. It should really have another question there, something along the lines of:


"Can the program be emulated sufficiently by a currently-available emulator that has successfully traversed this flow-chart?"


Without that, you are truly stuffed, but if it *can* then it's possible to emulate an environment in which it could be run (but of course the emulator would need to pass the "desktop computer" speed test itself too. And the XCOM things are basically a wrapping of the original executable using an emulated-environment (sometimes doubly-emulated across an intermediate pseudo-platform) - though it's even a little more complicated than that.


Of course, there would have to be a suitable disclaimer that it's even more unlikely to work, or at least to work *legally* in that case too.
 
X-COM is not under an emulator, it's done via static recompilation. As I understand it, though, doing that is a bitch, and not always possible.
 
There's also rewrites. If someone asked "Can you play Baldur's Gate" this flow chart would lead to no, but we do have the open source engine rewrite GemRB.
 
X-COM is not under an emulator, it's done via static recompilation. As I understand it, though, doing that is a bitch, and not always possible.

Isn't source code required for static recompilation though?
 
Isn't source code required for static recompilation though?

No.

Just to add detail.. Static Recompilation is a crazy method which essentially reverse engineers the code from the binary.. I can't say I'm too familiar with how it's actually done.. I know it can't be always done.
 
Last edited by a moderator:
Isn't source code required for static recompilation though?

No.

Just to add detail.. Static Recompilation is a crazy method which essentially reverse engineers the code from the binary.. I can't say I'm too familiar with how it's actually done.. I know it can't be always done.

Really? That's pretty darn cool then.


So - if I had a native X86 Linux compiled program, would this allow me (or someone) to 'static recompile' it to Linux on ARM? (Performance issues notwithstanding.)


Where is a good place to start reading up on this?
 
Really? That's pretty darn cool then.

So - if I had a native X86 Linux compiled program, would this allow me (or someone) to 'static recompile' it to Linux on ARM? (Performance issues notwithstanding.)


Where is a good place to start reading up on this?

The main mechanism is the same as with dynamic recompilation. The only difference is that instead of recompiling blocks as you try to execute them you recompile blocks in advance. This means that you need to know every branch target. It also means that you can't handle any kind of dynamic code, which includes self-modifying code but also extends to anything that's not located in-place from where the binary was loaded. So anything that is decompressed, loaded, or moved around in any kind of way.


Because of indirect branches you can't directly compute all branch targets by traversing a control flow graph from the start of program execution. Heuristics can help you determine the possible targets for an indirect branch, but they won't always work. Of course, there's nothing illegal about recompiling dead code or data that isn't even code at all, it'll just bloat your result. So it pays to be liberal with what you consider may be a branch target. But most serious static recompilations will manually fill in some of the difficult branch targets, making it a process that only works for one particular program rather than a general emulator.


If you really want you can recompile the entire program and allow every possible branch target. On platforms like x86 with big byte-variable-length instructions this becomes very unfortunate because it means you'll have a lot of overlapping variations in order to handle every possible byte alignment. You'll also end up with a huge translation table. More importantly, since every instruction as an entry point you can't really do any kind of propagation optimizations between instructions, including basic ones like dead operation elimination. So this probably isn't a good idea.


The thing is, static recompilation doesn't have much potential to be faster than dynamic recompilation to begin with. The only thing you definitively save on is having to check if a block you branch to exists or not. It's often said that static recompilation can perform broader scope optimizations than dynamic recompilation, but nothing is stopping a dynarec iteratively recompiling blocks as more of their targets are resolved, and it may be possible to follow direct branches recursively as well - you can't optimize over indirect branches in both cases. In practice you won't find a lot of whole program optimization attempted for a static recompiler unless it's generating code for a high level language and leaving the rest to a compiler, in which case it probably won't end up very good anyway.


Either way you do it, for Linux to Linux you're best off performing user mode emulation instead of system mode, that'll make the biggest performance difference.
 
Last edited by a moderator:
I just love reading Exo's posts, my eyes are glued as my brain explodes (while trying to understand things way above my head!)
 
Back
Top