X-com: Ufo Defense V1.0.1

[M-HT]

Edit:
To elaborate, I'm recompiling directly from X86 instruction set to ARM instruction set. So it is possible to rewrite the recompiler to recompile the X86 instructions into another instruction set, but I wouldn't call it portable.

to be precise, what kind of recompiler ? a true static recompiler ?

What's the difference between a true static recompiler and a non-true static recompiler ?

 

[sepulep]

It's not portable to other processor architectures.
X86 linux version exists as part of the development, but there's no point in releasing it, because on PC X-COM is perfectly playable in DOSBox (or DOSEMU in linux).
The only reason for statically recompiling it for GP2X is, that it's not playable otherwise (too slow in dosbox).

Edit:
To elaborate, I'm recompiling directly from X86 instruction set to ARM instruction set. So it is possible to rewrite the recompiler to recompile the X86 instructions into another instruction set, but I wouldn't call it portable.

I see..well, like I said before I was pretty impressed by the smoothness of it all. With dosbox it is ok, but your version in many ways 'feels' better. Secondly I would imagine that a 'native' version would lend its self better to hacking to improve gameplay (like some guy did/ is doing for the XP version), or graphics etc.

Anyway, I hope you don't think I am complaining or anything - It is great work!!

BTW, how did you implement mouse&keyboard inputs and sound and graphics? Did you implement SDL equivalents of calls made by the program or is does it work on the basis of hardware emulation?

 

[hlidegp2x]

to be precise, what kind of recompiler ? a true static recompiler ?

What's the difference between a true static recompiler and a non-true static recompiler ?

is you recompiler just a translation from x86 to arm per instruction (like a dynarec except for it is generated offline) ? or has a good analysis for block and register usage so it can perform more global optimization ?
or do you produce a C file to compile ?

 

[sepulep]

..
I downloaded timidity, and copied it to the root of SD card, eg. \timidity.

Then copied timidity.cfg into \ufo, added a line in like so:-

dir /mnt/sd/timidity/

But still not music? Anyone got this working?

yes - it works as advertized. maybe-- did you check the configuration file Ufo.cfg? (music setting)

 

[M-HT]

It's not portable to other processor architectures.
X86 linux version exists as part of the development, but there's no point in releasing it, because on PC X-COM is perfectly playable in DOSBox (or DOSEMU in linux).
The only reason for statically recompiling it for GP2X is, that it's not playable otherwise (too slow in dosbox).

Edit:
To elaborate, I'm recompiling directly from X86 instruction set to ARM instruction set. So it is possible to rewrite the recompiler to recompile the X86 instructions into another instruction set, but I wouldn't call it portable.

I see..well, like I said before I was pretty impressed by the smoothness of it all. With dosbox it is ok, but your version in many ways 'feels' better. Secondly I would imagine that a 'native' version would lend its self better to hacking to improve gameplay (like some guy did/ is doing for the XP version), or graphics etc.

Anyway, I hope you don't think I am complaining or anything - It is great work!!

BTW, how did you implement mouse&keyboard inputs and sound and graphics? Did you implement SDL equivalents of calls made by the program or is does it work on the basis of hardware emulation?

Most of the code is assembler code generated by the recompiler, so that's not much help to the hacking.

Mouse:
X-Com is polling the mouse coordinates and mouse buttons status (via int 0x33), so I'm just supplying SDL mouse coordinates and buttons status.

Keyboard:
X-Com is querying and reading keys via c functions kbhit and getch, so I'm emulating keyboard buffer with SDL keys and I replaced the c functions with my functions.

Graphics:
X-Com is writing graphics data to frame buffer at address 0xa0000. I redirected the writes to my buffer and I'm periodically (60 times/ses) writing it to SDL video buffer.

Sound:
X-Com is using DigPak for sound and music, so I replaced the interface with my implementation (using SDL_mixer).

is you recompiler just a translation from x86 to arm per instruction (like a dynarec except for it is generated offline) ? or has a good analysis for block and register usage so it can perform more global optimization ?
or do you produce a C file to compile ?

I'm producing arm assembler code.

I'm using static register allocation (that's one reason why my recompiler works only on 32bit code with flat memory access) - 10 x86 registers (eax, ebx, ecx, edx, esi, edi, ebp, esp, eip, eflags) + 1 temporary register for memory addresses + 5 temporary registers for calculations and other usage = 16 arm registers.

I'm doing some analysis for flags calculations - I'm only calculating them when necessary and I'm using arm flags whenever possible - 6 x86 flags (sign, zero, carry, overflow, parity, adjust) vs 4 arm flags (sign, zero, carry, overflow).
Complication is, that some instructions give inverted carry flag than the same instructions on x86 and some instructions are reading it inverted than x86 instructions. So I'm also inverting it only when necessary.
This part requires some manual input. Sometimes the recompiler can't decide (when an instruction at the start of the block needs some flag) and sometimes it's impossible (when one instruction reads original carry flag (but doesn't change it) and the next instruction reads the inverted carry flag).

 

[Tag5]

Thinking about it, the background music does not play on mine but it does not really bother me. The sound affects is the priority so I can hear those aliens movement around the level.

 

[senquack]

The music works great in both XCOM1 and XCOM2 and I've never had a problem with it myself..

Try copying the sound.cfg in this link into your SOUND/ subfolder overtop the existing one:

CODE
http://www.mediafire.com/?lzdnvmxmnjl

 

[Tag5]

The music works great in both XCOM1 and XCOM2 and I've never had a problem with it myself..

Try copying the sound.cfg in this link into your SOUND/ subfolder overtop the existing one:

CODE
http://www.mediafire.com/?lzdnvmxmnjl
Got this file now, will put it on the GP2X at home later on today.

 

[tombott]

Will be checking this out.

Many thanks.

 

[Monk]

Civilization is not compatible with my static recompiler.
DosBox is your only help here.

Okay - just wondering what other older DOS games would be compatible?

The ones using dos extender - usually indicated by the presence of the file dos4gw.exe.

But in addition to some possible technical difficulties, there are other aspects to consider. For example:
- Controls - if the game can't be controled by the gp2x controls, there's no point in doing static recompilation
- Display - if the game uses higher resolution than gp2x then resizing can make the game unplayable (e.g. the text becomes unreadable, etc."]
- Sound - working sound isn't always guaranteed, so if you need it for the game to be playable, then you're out of luck
- Speed - if the speed requirements of the game are too high, then even static recompilation won't make it playable on gp2x[/quote]Oooh, interesting - as Pickle pointe dout, Dark forces uses dos4gw.exe...

and so dodes a "Collector's Edition" of TIE fighter on CD. It's curious that the CD collector's X-Wing doesn't SEEM to have that file... maybe it's on the CD, I can check if required.

The original Tomb Raider seems to use it too, as does the "Alien Trilogy" FPS game.

Hmmm... ?

 

[espontaneo]

I really don't get how you have managed this - and I wouldn't normally beg, but please port it to the dingoo!

or pass your secrets onto someone else to do it...

Hey slaneesh - *nudge* *nudge*...

 

[M-HT]

The problem is, that dingoo has a CPU with MIPS architecture and not ARM like GP2X.
This would require to change the recompiler to support MIPS architecture and that is really a LOT of work.
And even if someone did this, I'm not 100% sure that you would get acceptable speed on dingoo.

So a port to dingoo is extremely unlikely.

 

[espontaneo]

Yeah I realize it's not a quick job, on the other hand the person who did this would be a beloved big fish in a smaller dingoo shaped pond - especially with a whole bunch of games potentially being compiled with this method.

Performance shouldn't really be an issue though, surely?

Did you engineer the recompiler completely yourself? Impressive!

Oh well, anybody want to buy a dingoo? I guess I'm buying a wiz!

and I really shouldn't spend any more money...

 

[daedalia]

Could this process be used on the PC version of Turrican 2?

http://www.hotud.org/component/content/article/43-action/21440

I know the Amiga one is emulated very well on the Wiz, but if it is possible then I would like to give it a go, the PC version is just so beautiful on the Wiz screen and DOSBox is just a little slow. I have a LOT of free time to use up.

And thank you for UFO on the Wiz, really appreciated.

 

[M-HT]

Could this process be used on the PC version of Turrican 2?

http://www.hotud.org/component/content/article/43-action/21440

I know the Amiga one is emulated very well on the Wiz, but if it is possible then I would like to give it a go, the PC version is just so beautiful on the Wiz screen and DOSBox is just a little slow. I have a LOT of free time to use up.

And thank you for UFO on the Wiz, really appreciated.

I took a brief look at it and it doesn't seem possible.

 

[Tag5]

Could this process be used on the PC version of Turrican 2?

http://www.hotud.org...43-action/21440

I know the Amiga one is emulated very well on the Wiz, but if it is possible then I would like to give it a go, the PC version is just so beautiful on the Wiz screen and DOSBox is just a little slow. I have a LOT of free time to use up.

And thank you for UFO on the Wiz, really appreciated.

Good luck...