The work from asm code to C code is probably the biggest hurdle (but notaz may comment) and from what I discussed with notaz the more DLLs you have, the more work it represents so some games may require much more work than StarCraft, and bear in mind that notaz has been working on this for several months already.
The work from asm code to C code is probably the biggest hurdle (but notaz may comment) and from what I discussed with notaz the more DLLs you have, the more work it represents so some games may require much more work than StarCraft, and bear in mind that notaz has been working on this for several months already.
Notaz has written a custom conversion tool (asm to C).
Let's assume he continues to improve that tool will it be an universal tool then which will speed up other ports as well, or does ever game need a custom conversion tool.
I have StarCraft Broodwar installed at version 1.15.2 on my work computer and it doesn't require the cd to run.
I only ask as this is an old computer and will take 3.5 hours to copy the game folder onto my sd card... also, I'm having trouble finding a place to download the patch.
Edit: Answered my own question. Apparently the patch is not required if you have version 1.15.2
Let's assume he continues to improve that tool will it be an universal tool then which will speed up other ports as well, or does ever game need a custom conversion tool.
Notaz alone can answer that, but it seems it required lots of debugging, so it would not be very safe to assume it can become "universal" anytimes soon
It sounds like notaz did a lot by hand, so I doubt his tools will be a big advantage for other games, but maybe they can be developed further by someone?
The approach is very interesting, both from the technical point of view and from the legal point of view.
Technically:
I wonder if a similar approach would work to do static recompilation of game console ROMs, to get just a bit of extra speed compared to dynamic recompilation. So instead of using an emulator, you would essentially specialize (emulator+rom) into one native executable, where as much of the recompilation as possible is done statically (I guess you cannot get rid of it in general because there could be self-modifying code etc.). If you can get near-native execution in the performance-critical loop bodies, this could theoretically enable "emu-compi-lation" of more game consoles (as long as their hardware is not more powerful than the Pandora's), albeit with potentially a lot of manual game-specific effort if the approach cannot easily be fully automated.
Legally:
What is the legal status of this approach? If the process can be automated then I see no problem (you don't need to distribute any proprietary stuff, only the recompiler tool), but if you have distribute an executable that was somehow derived from a proprietary executable, I'm not sure if that is legally OK. Game companies probably don't mind as long as you don't distribute the game data with it, but still, there is theoretically a problem.
Automatic static recompilation is simple on the paper, but extremely complex in practice. From what I've seen, automatic tools will only get you that far and then you need to solve problems by hand. And it's very hard to know where the problems are, and even when you do know, it's hard to fix them as well.
Legally, many license agreements expressively forbid the user from decompiling the software, so it's complicated here as well.
Just confirmed the web download version is compatible (I bought it specially as i've never played starcraft properly!), just need to add the 1.16.1 patch and you're all set
I would suggest to look at a partially done port of Syndacate Wars done in a similar way...i allready checked the sources but inside there is a block of x86 asm code not converted..so impossible (for me...) to port it.
Just confirmed the web download version is compatible (I bought it specially as i've never played starcraft properly!), just need to add the 1.16.1 patch and you're all set
I would suggest to look at a partially done port of Syndacate Wars done in a similar way...i allready checked the sources but inside there is a block of x86 asm code not converted..so impossible (for me...) to port it.
I would suggest to look at a partially done port of Syndacate Wars done in a similar way...i allready checked the sources but inside there is a block of x86 asm code not converted..so impossible (for me...) to port it.
All source code except the code in src/swars.S is licensed under the GNU General Public License, version 3 or any later version. src/swars.S is a modified disassembled version of the original game's main.exe by Bullfrog. The project is distributed without charge and in good faith that it will be useful to those who purchased the original game but cannot play it anymore because they do not have access to an old DOS system. However, should the original copyright holders complain, we will take down the code they have the rights to.
I would suggest to look at a partially done port of Syndacate Wars done in a similar way...i allready checked the sources but inside there is a block of x86 asm code not converted..so impossible (for me...) to port it.
All source code except the code in src/swars.S is licensed under the GNU General Public License, version 3 or any later version. src/swars.S is a modified disassembled version of the original game's main.exe by Bullfrog. The project is distributed without charge and in good faith that it will be useful to those who purchased the original game but cannot play it anymore because they do not have access to an old DOS system. However, should the original copyright holders complain, we will take down the code they have the rights to.
Yes. I will (and it's easy for me, I don't plan to do anything for now ). The warning seems fair. Anyway, I my (biased) point of view, I think it's better to distribute converted binary to another architecture than processed sources code. As a unfair reused possibility, binary are useless, processed source code can be used.
But lets agree it's a bit a gray area with not much jurisdiction yet...
would it be possible to implement right mouse button emulation, so "touchscreen play" would be possible ? Maybe via a button that is not natively used by starcraft - first thought was the left shoulder button (+ the right for "lefties"), but can't remember wether they are already used in Starcraft or not.
It plays quite ok with that 3x3 command bar on the bottom right, so you can do without rightclick when you get used to it really. Although rightclick could be done somehow, maybe shoulder button like you say. Left shoulder is set up as shift, which allows to select individual units to a group in SC, but that doesn't work on pandora because shift is set up as window move modifier, and wine doesn't see shift press because of that. So it indeed could be reused as rightclick modifier instead.
It only implements the very minimum of what SC needs, so it would almost certainly fail on anything else. Only part of x86 instructions are handled (not all are fully implemented), there is no support for float/mmx/sse (SC almost doesn't use float), it only understands compiler-generated functions (code compiled from hand-coded asm will fail).
do you intend to release your conversion tools or will they stay private? would also be interested how the c source looks like - is that one mega file or were you able to split them somehow?
The tools are on my github already, however they are extremely user-unfriendly and an awful hackjob really.The "source" is huge-ass C file, it takes around a minute to compile. Small sample function:
int sub_401310(int a1, int a2)
{
u32 eax = (u32)a1;
u32 ecx;
u32 edx;
u32 esi;
u32 edi;
As you can see it doesn't look much different from x86 disassembly, the only difference is that you can compile it for other 32bit archs (there is no way it would work on 64bit..)
Notaz has written a custom conversion tool (asm to C).
Let's assume he continues to improve that tool will it be an universal tool then which will speed up other ports as well, or does ever game need a custom conversion tool.
I might theoretically be possible, but it would take infinite time to write universal tool that could handle larger part of games/programs, it's easier just to say it's impossible. And in some cases it's indeed impossible, like for self-modifying code and dynarecs (even SC has a dynarec which had to be worked around..).
I wonder if a similar approach would work to do static recompilation of game console ROMs, to get just a bit of extra speed compared to dynamic recompilation. So instead of using an emulator, you would essentially specialize (emulator+rom) into one native executable, where as much of the recompilation as possible is done statically (I guess you cannot get rid of it in general because there could be self-modifying code etc.). If you can get near-native execution in the performance-critical loop bodies, this could theoretically enable "emu-compi-lation" of more game consoles (as long as their hardware is not more powerful than the Pandora's), albeit with potentially a lot of manual game-specific effort if the approach cannot easily be fully automated.need a custom conversion tool.
It could be done, but again, not in all cases for the same reasons as mentioned above. If you want to target many games it requires too much effort and is certainly not worth it.
What is the legal status of this approach? If the process can be automated then I see no problem (you don't need to distribute any proprietary stuff, only the recompiler tool), but if you have distribute an executable that was somehow derived from a proprietary executable, I'm not sure if that is legally OK. Game companies probably don't mind as long as you don't distribute the game data with it, but still, there is theoretically a problem.
Yes this is a problem.. The tools currently can't do it on their own, it would take a lot of effort to get them to such state. I'm even relying on external program (IDA) for initial disassembly, replacement for that would have to be written. However there are projects like bwapi and vgce, as well as M-HT recompiles mentioned in my first post, they were not attacked by the game companies but they're certainly in the same gray area..
Just confirmed the web download version is compatible (I bought it specially as i've never played starcraft properly!), just need to add the 1.16.1 patch and you're all set
Just confirmed the web download version is compatible (I bought it specially as i've never played starcraft properly!), just need to add the 1.16.1 patch and you're all set
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
