Edit: I put my initial post in here to have the first post updated with the current version.
-----------------------------------------------------------
Hi everyone!
Some might remember me, I was an early OpenTTD developer and helped shaping this game between March 2004 and spring 2005. Well, I'm back. With a Nintendo DS port! You might have noticed me lurking around in #openttd with some weird questions...
I've been working on the Nintendo DS port for almost a month and twice I was close to giving up. The hardware is extremely limited and this is my very first project for the DS. I'd say it must probably be the most difficult port to write out of all the systems OpenTTD has been ported to. And it's far from being fully playable yet.
Here are the details of my very first version running on hardware:
- - it's more or less only a "proof of concept"
- only the bottom screen is used
- "mouse input" with the touchscreen
- starts with a random 64x64 map
- lots of things make the game crash, e.g. building railroad tracks
- you can't use parts of the gui due to limited screen size
- starting takes 45 seconds
- one game day takes 2 seconds (that's full speed I think)
- no sound
- no network
Some technical implementation details:
- - using SDL turned out not being feasable so I had to write my own video driver
- the game binary is 1.7 MB, which leaves only 2.3 MB main memory
- the screen surface (48 KB) has to be in main memory due to 8bit writes
- the whole sprite data (300 KB) has to be in main memory as well (8bit writes are the reason again)
- optimizing struct Spritecache for 16bit enabled me to store sprite information for up to 7372 sprites in VRAM (144 KB)
- when the game is running approximately 244 KB of memory are free to use
- approximately 384 KB of VRAM are free to use
As you can see memory clearly is the main concern for this port. I have already squeezed every possible bit out of the hardware. One further improvement would be to write an own blitter that only does 16 bit writes, enabling me to directly use VRAM (freeing 48 KB of main RAM) and making use of the second screen as well.
To make OpenTTD enjoyable on the NDS I think I will have to fork it and make it independent from the main branch. Then it would be possible to prune lots of things unnecessary for the DS to reduce the binary size and memory usage. And even adapting the GUI for the DS would then be an option. I was even thinking of forking it from an older version of OpenTTD which used less memory. Currently the NDS port is based on revision 11485 (ca. 0.6.0beta1).
It's still a very long road ahead to make OpenTTD playable on the DS and unfortunately I don't have much spare time to work on it. I'll release an alpha version as soon as I need testers.
-----------------------------------------------------------
I've been working hard to track down the crashes over the past few days. You can't believe how great a relief it is that I finally got rid of them. (It's pretty frustrating to work on the same thing for days without any progress at all. And in the end it's only a change of 4 lines...)
For the current version I activated both screens and you can swap the top and bottom screen with the left shoulder button. You can still overlay the console for debug purposes. But most importantly: You can build tracks and trains!
The station GUI is crashing at the moment though. So no stations yet.
Wolf01 wrote:are you planning to return an active OTTD developer?
No, not for OpenTTD in general. I barely have time for the DS port and couldn't spare any more. But if the port would go into trunk you might see one or the other patches being carried over from the DS port.
AntBUK wrote:You thought about adding an option to use a RAM expansion like the one that comes with the Opera browser?
A RAM expansion might even be compulsory when I release it. I haven't done any testing with it yet but the problem is that external RAM is pretty slow compared to main RAM. A EZflash 3-in-1 sitting ready on my desk waiting for the point where I have to test it.
Rubidium wrote:In my opinion there can be enough room in OpenTTD to make a compile time configuration option for low memory/small binary size. Also making the current windows useable at very low resolutions is something that I've been working on every now and then in OpenTTD myself to 'aid' people who want to port it to a small device, such as a Nintendo DS or a Windows Mobile or a Symbian.
You can't really compare a single-purpose, hardware-relying console like the DS to a multi-purpose device like a Symbian or even PSP. The DS is very different, not only in appearance (with two screens) but also concerning the hardware. Instead of a fast processor it has three very distinct graphics engines. A program not tailored to those wastes most of tho power.
Rubidium wrote:However, the primary reason for not doing the branch is that it becomes easier for other porters to use 'just' standard trunk with 'low memory' mode for their small devices instead of a (maybe) outdated version of the DS port. It will furthermore make keeping the DS port synced with main OpenTTD version much simpler as all kinds of API changes will be done for you by the people who are performing the changes.
Tbh, when I was thinking about a fork I don't even consider keeping it synched with the trunk. That would be the whole purpose of forking, to keep it independent of any changes to main OpenTTD.
There are advantages to both and I will try to keep it compatible with the trunk for now. But I'm pretty sure there's no way around forking at some point in the future. To quote someone from the gbadev forums: "What this means is that, largely unmodified, OpenTTD will probably never be happy on the DS."
I'm currently playing games like ThemePark, Settlers, Zoo Tycoon and Sim City on the DS to get some ideas of good layout and control schemes. I'll list just a few examples of what has to be modified in the OpenTTD port which came to my mind:
Cosmetic changes:
- a "draw track" tool to draw tracks with the stylus. Eliminates the need of 5 (!) different build track buttons.
- the "build vehicle" window (and similar windows) should appear so that all informational elements (cost, speed, ...) are on the top screen and the interactive elements (select train, sort, ...) are on the bottom.
- remove some buttons (fast forward probably won't work anyway), move some functions (save/load, sound options) to a seperate window that opens when pressing "start"
- remove newspaper window and ticker, instead only a transparent overlay ticker
Internal changes:
- separate sound core and make all sound processing run on the second processor
- rewrite blitter for 16bit writes so that all video stuff can go into VRAM
- ensure that all writes to _spritecache_ptr are 16bit so we can move it to VRAM
- make pools (like station pool) fixed size and map them to a fixed location (maybe on external RAM expansion)
- use a background map and/or Object Attribute Memory to display some stuff, e.g. menu icons. (in this case the 16x16 icons would come in handy for a tiled map)
- maybe use hardware scaling for zoomed out view (unlikely)
- get rid of some non-vital code: all newgrf code, the pathfinder and AI would be candidates
- maybe even make the map size static again
Those are only very few examples. To make OpenTTD fun on the DS a lot has to be changed. It's no surprise that commercial companies usually rewrite a game from the ground up when "porting" to the DS. Of course, everything "could" go into the trunk with conditional #defines and I'll try my best but it might get ugly.
looks like i may be stealing it 
) to let us save the games, if its implemented. . Some hardware has auto-patching built in, but I don't trust it and prefer to do it myself 
