OpenTTD for PocketPC (dev)
Moderator: OpenTTD Developers
OpenTTD for PocketPC (dev)
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.
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.
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.
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."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
-
- Engineer
- Posts: 72
- Joined: 02 Aug 2004 11:15
- Location: United Kingdom
-
- Engineer
- Posts: 119
- Joined: 09 May 2004 18:40
- Location: Munich, Bavaria
- Contact:
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 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
Alcohol is not the answer, it just makes you forget the question.
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.ThorRune wrote: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 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
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.
*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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- Hadez
- Traffic Manager
- Posts: 217
- Joined: 22 Jul 2004 21:25
- Location: Jablonec nad Nisou, Czech republic
- Contact:
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
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
C is also running under a "Virtual Machine" - also called as "Operating System".That $NOT_EMULATED Java VM? What is it? AFAIK, your choices here are "phyical" and "emulated".
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
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.
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.
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.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.
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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: No registered users and 14 guests