OpenTTD for PocketPC (dev)

J@Master · Post by **J@Master** » 23 Oct 2004 09:55

I ported OpenTTD to PocketPC. (Source 0.3.4)
I did a lot of:
#ifdef WINCE
...
#else
...
#endif
in the Win32 part.
But the display is much smaller (240*320) so i had to change the GUI a lot (not finished yet).
It could be done by #if, too. But it does not look very nice.
Questions:
Can I submit the the code and the binaries anywhere?
The last version i posted on a german forum. It was loaded more than 1000 times. I don't think, that I can do it at that place anymore.

Post by **orudge** » 23 Oct 2004 11:21

Just post them here as an attachment. If you get an error while trying to upload, let me know and I'll give you some FTP space to put them on.

Darkvater · Post by **Darkvater** » 23 Oct 2004 12:19

It depends how much you commented in win32.c If it is really a lot, it is better that you make a seperate file that only has the WinCE functions. Same goes for the gui.

The question is of course how to handle changes then later to the win code and the gui. I seriously doubt that any developer will change code for the WinCE part since none of us has such a machine. It would then be dependent on you for future support.

asuras · Post by **asuras** » 25 Oct 2004 10:19

Will there be a QVGA version on OpenTTDmobile?? The current OpenTTDmobile is quite difficult to play in Qvga mon.

CheesePlant · Post by **CheesePlant** » 28 Oct 2004 12:02

It might be a shot in the dark here, but if openttd was made in java couldn't it work on any mobile device, such as PDA's and mobile phones, quite pointless really imagine ttd on a phone eek.

Celestar · Post by **Celestar** » 28 Oct 2004 12:14

Haha Java.

Should you code it in Java, it would hardly run smoothly on a 3 GHz CPU, especially not when maps are larger/more complex

Celestar

Kebabrov · Post by **Kebabrov** » 28 Oct 2004 22:05

while we're bashing java, let me take this opportunity to say i hate it too

now back onto topic... i might have to go buy a pocket pc now. i've played all the games on my mobile to death

worldofklaus · Post by **worldofklaus** » 07 Nov 2004 19:35

Will there also be a version for PalmOS? If yes, does anyone know how much memory I'm gonna need? (got a Tungsten T 144 MHz)

Bjarni · Post by **Bjarni** » 07 Nov 2004 23:12

Just wondering. How is the mouse interface?
And is it playable. I mean I would not spend a lot of time playing a game based on a good idea if the interface is bad, specially not if I got a computer and the computer version of the game got a good interface

ThorRune · Post by **ThorRune** » 08 Nov 2004 23:54

Bjarni wrote:I mean I would not spend a lot of time playing a game based on a good idea if the interface is bad, specially not if I got a computer and the computer version of the game got a good interface

What if you are on a bus, or on a plane? The point of a pocket PC is that it fits your pocket, and you can take it WITH!!!!! you anywhere you go.

Bjarni · Post by **Bjarni** » 09 Nov 2004 00:05

ThorRune wrote:
Bjarni wrote:I mean I would not spend a lot of time playing a game based on a good idea if the interface is bad, specially not if I got a computer and the computer version of the game got a good interface
What if you are on a bus, or on a plane? The point of a pocket PC is that it fits your pocket, and you can take it WITH!!!!! you anywhere you go.

I know, but it still have to be somewhat decent. And I asked how the mouse are handlet in this port. It is not like I do not want a Pocket PC port, it's more like I wonder how it will become decent.

PurdueGuy · Post by **PurdueGuy** » 15 Nov 2004 15:33

This would be sweet! Finally, a pocket pc game worth playing. I'm rather sick of solitaire, and don't want to fork over a bunch of money for the other crappy games availible for PPC.

samson · Post by **samson** » 15 Nov 2004 17:41

Should you code it in Java, it would hardly run smoothly on a 3 GHz CPU, especially not when maps are larger/more complex

If you mean the awt/swing lib you are right. If you mean whole java you are totally wrong.

Hadez · Post by **Hadez** » 15 Nov 2004 18:23

samson wrote:If you mean the awt/swing lib you are right. If you mean whole java you are totally wrong.

I think Java must be ages slower than normal binaries if it´s to be "emulated" (it has to run under some engine)...

Archonix · Post by **Archonix** » 15 Nov 2004 19:05

It isn't emulated, though. It runs on a virtual machine, but that doesn't necessarily make it any slower. Most of the games on mobile phones are run on java and they don't suffer from it since the VM they're running on top of is pretty efficient.

DaleStan · Post by **DaleStan** » 15 Nov 2004 19:24

And who exactly is going to run this game on a mobile phone?
*waits for hands to go up*
I won't argue speed, and I agree that Java is more portable, but can we at least keep this remotely realistic?

BTW: That $NOT_EMULATED Java VM? What is it? AFAIK, your choices here are "phyical" and "emulated". "Virtual" implies not physical, and you just asserted that it's not emulated, so I guess there must be a third option here that I don't know about.

EDIT: something else I forgot:
Who's volunteering to recode the current codebase into Java? The languages may be similar, but they're NOT the same, and it'd be a substantial bit of work to re-write OTTD in Java.

Hadez · Post by **Hadez** » 15 Nov 2004 19:26

I couldn´t remember that word

- sorry for misunderstanding.
How can, effectively written though, the JavaVM run no slower than a binary program? That VM has to parse the code, remember all variables, it "emulates" the processor in fact! I´m going OT, so just my last (we´ll see) words: Java isn´t a good way to program OTTD in.
Edit: Sorry, I was slower than DaleStan now

samson · Post by **samson** » 15 Nov 2004 20:27

That $NOT_EMULATED Java VM? What is it? AFAIK, your choices here are "phyical" and "emulated".

C is also running under a "Virtual Machine" - also called as "Operating System".
That is the portable Trick - Java got his own "Operating System".

I dont think this is OT, cause me as a plam user also want to play ottd

thorkia · Post by **thorkia** » 16 Nov 2004 03:02

Yes Java has it's "own operating system" but it has to interface with the operating system (be it Win, Mac or some *nix variant), which adds a layer.

Every layer that is added slows down exuction time.

Here is my point:

Let's say any native compiled code for Windows takes 20ms to interface with Win, and Win takes 10ms to interface with hardware, that would mean you have a 30ms execution time...

Now with Java, your program has to interface with the VM,which we'll assume is really efficient and it only takes 2ms, then the VM interfaces with Win another 20ms, and then Win with the Hardware for another 10ms... For a total of 32ms. Longer than the native code.

So even if the VM is ultra effecient, and interpreted of emulated code on a VM will never be as effecient as native compiled code because of the interface.

The only way around that is if you give the VM direct access to the Hardware, by passing the OS. In which case, you might as well use the VM as the OS, instead of your Win, Mac or *nix variants.

DaleStan · Post by **DaleStan** » 16 Nov 2004 04:13

thorkia wrote:Let's say any native compiled code for Windows takes 20ms to interface with Win, and Win takes 10ms to interface with hardware, that would mean you have a 30ms execution time...

Now with Java, your program has to interface with the VM, which we'll assume is really efficient and it only takes 2ms, then the VM interfaces with Win another 20ms, and then Win with the Hardware for another 10ms... For a total of 32ms.

And then you have the really fun cases. Where the CPU being emulated (in this case, the JVCPU) supports instructions the host CPU does not. Then the VM first has to translate the vCPU instruction into hCPU instructions (and it always increases the number of instructions[0]), and then we commence the "interface with Win/Mac/*nix, which interfaces with the hardware" procedure. And I won't even touch functionally identical instructions with different machine code for host and virtual CPUs.

google://gcc palmos binary download

[0] A native compiler can decrease the number of instructions, because that's a one-time process. A VM, however, doesn't have the time to try to optimize; that'll slow things down even more.

Transport Tycoon Forums

OpenTTD for PocketPC (dev)

OpenTTD for PocketPC (dev)

Who is online