OpenTTD for PocketPC (dev)

OpenTTD is a fully open-sourced reimplementation of TTD, written in C++, boasting improved gameplay and many new features.

Moderator: OpenTTD Developers

J@Master
Engineer
Engineer
Posts: 14
Joined: 05 Sep 2004 15:42

OpenTTD for PocketPC (dev)

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.

User avatar
orudge
Administrator
Administrator
Posts: 24026
Joined: 26 Jan 2001 20:18
Skype: orudge
Location: Banchory, UK
Contact:

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.

User avatar
Darkvater
Tycoon
Tycoon
Posts: 3053
Joined: 24 Feb 2003 18:45
Location: Hong Kong

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.
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."

asuras
Engineer
Engineer
Posts: 7
Joined: 21 Oct 2004 10:17
Location: Hong Kong

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
Engineer
Engineer
Posts: 72
Joined: 02 Aug 2004 11:15
Location: United Kingdom

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.
The cruelest dream is reality.

User avatar
Celestar
Director
Director
Posts: 574
Joined: 02 Jul 2004 10:56
Contact:

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
Engineer
Engineer
Posts: 39
Joined: 20 May 2004 18:36

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
Engineer
Engineer
Posts: 119
Joined: 09 May 2004 18:40
Location: Munich, Bavaria
Contact:

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
Tycoon
Tycoon
Posts: 2088
Joined: 08 Mar 2004 13:10

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

User avatar
ThorRune
Tycoon
Tycoon
Posts: 5762
Joined: 09 Oct 2003 14:00
Location: Nordland, Norway
Contact:

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.
Alcohol is not the answer, it just makes you forget the question.

Bjarni
Tycoon
Tycoon
Posts: 2088
Joined: 08 Mar 2004 13:10

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.

User avatar
PurdueGuy
Transport Coordinator
Transport Coordinator
Posts: 318
Joined: 27 Sep 2004 03:31
Location: West Lafayette, Indiana

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
Engineer
Engineer
Posts: 11
Joined: 30 Sep 2004 09:14

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.

User avatar
Hadez
Traffic Manager
Traffic Manager
Posts: 217
Joined: 22 Jul 2004 21:25
Location: Jablonec nad Nisou, Czech republic
Contact:

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
Chief Executive
Chief Executive
Posts: 733
Joined: 01 May 2003 17:29
Location: Manchester, UK
Contact:

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
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

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.
Last edited by DaleStan on 15 Nov 2004 19:40, edited 1 time in total.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

User avatar
Hadez
Traffic Manager
Traffic Manager
Posts: 217
Joined: 22 Jul 2004 21:25
Location: Jablonec nad Nisou, Czech republic
Contact:

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
Engineer
Engineer
Posts: 11
Joined: 30 Sep 2004 09:14

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
Traffic Manager
Traffic Manager
Posts: 130
Joined: 25 Nov 2002 03:19
Location: Toronto, Ontario, Canada

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
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser

Post Reply

Return to “General OpenTTD”

Who is online

Users browsing this forum: No registered users and 1 guest