#147034 - load*,8,1 - Thu Dec 13, 2007 4:15 pm
OpenTTD is an open source clone of Chris Sawyer's Transport Tycoon Deluxe. The base code was released in 2004 by Ludde (famous author of ScummVM) and has since then been greatly improved by the community. I myself worked on OpenTTD as a developer for almost a year back in 2004.
With some knowledge of the source code I've been working on porting OpenTTD to the DS as my very first homebrew project. Today, after fiddling with it for almost a month I'm proud to announce that I finally got it running on hardware.
Image 1 Image 2
It's not really fun to play (yet), easily crashable, and therefore more or less only a proof of concept. I had to put many restraints on it, to make it running at all. For now it is only using a 64x64 map, without sound and parts of the gui can't be used because they're off screen.
My main concern for further development is memory though. The binary is currently 1.7 MB and I have to store a copy of the screen (48 KB) in main memory as well because the game does 8bit writes to the screen. Also all of the sprite data (currently using a cache of 300 KB, more would be better) had to go to main RAM. I only managed to put some sprite information in VRAM (up to 128 KB) and I use bank E for the screen. Rewriting the blitter might enable me to make better use of VRAM.
But still memory is a big problem. A standard size map would require 576 KB RAM. And that's not counting all the additional memory needed for more trains, towns and industries on the map.
Therefore my question to other developers who did ports to the DS: Do you think I should continue working on this? Or is it just too big a game to port and I will run into a dead end eventually anyway?
#147035 - theli - Thu Dec 13, 2007 4:18 pm
oh .. that's awesome :)
i've looked into porting openttd for some time but then gave up that idea because of memory issues ....
i'm glad someone is working on it :)
#147048 - Sunray - Thu Dec 13, 2007 7:40 pm
Awesome!
Maybe a memory expansion card should be required then, like Quake 2?
#147050 - sonny_jim - Thu Dec 13, 2007 8:15 pm
Using the memory expansion would probably quite good in this case as the main problem with it is that it's horrifically slow compared to main RAM and last time I played TTD I didn't need 60+ frames per second.
#147078 - yellowstar - Fri Dec 14, 2007 2:55 am
*Post removed concerning what to do
when one doesn't have the data files of TTD for OpenTTD *
Last edited by yellowstar on Fri Dec 14, 2007 8:54 pm; edited 1 time in total
#147086 - OOPMan - Fri Dec 14, 2007 8:25 am
I would be very disappointed if this project was dropped. Understandbly, it may seem a little daunting at the moment, but I would image that with a judicious dose of optimisation and code-pruning you could get it running very happily on the DS.
If OpenTTD is anything like The Ur-Quan Masters (The open-source port of Star Control 2), then the code is most likely written with cross-platform PC compatibility in mind. This means the code is not as tight as it could be and targets a PC-style system with memory to spare.
What this means is that, largely unmodified, OpenTTD will probably never be happy on the DS. However, with the application of various optimisation techniques I would imagine it can be made to run, and run well at that.
Remember, PC games are generally a bit wasteful when it comes to memory. Even older ones suffer from this problem to some extent. This is not something that can't be fixed, though...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#147096 - petterhj - Fri Dec 14, 2007 12:59 pm
I said this in another thread, but OpenTTD seems at least highly portable, and not *that* resource demanding. It runs on PocketPC, my smartphone (m600i) and my Palm. I really hope this isn't dropped. Thanks and keep up the good work!
#147110 - Dark Knight ez - Fri Dec 14, 2007 5:12 pm
Nice project...
As for memory and VRAM technical stuff: could you elaborate some more on how the graphics and such work? From your story I can't tell if you could cut down on graphics, are already using BGs, how palettes are set up and what-not. I'll see if I can give useful comments after having more detailed information.
As far as binary itself goes, you would probably be the best person to be able to judge what can and should be cut out (or rewritten) to free up some memory, being familiar with the code and all.
I can't comment on how well this'll work out in the end or if you should drop it or not... have not really done any porting myself, but like I said, I'd be happy to discuss alternatives of memory and VRAM usage.
_________________
AmplituDS website
#147227 - load*,8,1 - Sun Dec 16, 2007 4:18 pm
| sonny_jim wrote: |
| Using the memory expansion would probably quite good in this case as the main problem with it is that it's horrifically slow compared to main RAM and last time I played TTD I didn't need 60+ frames per second. |
I'll have to test using a memory expansion. But if it is much too slow, the framerate will be a problem. If I remember it correctly everything is calculated per tick. For example vehicles don't move according to how much time has passed but instead a fixed amunt every tick.
Also the huge map array is accessed a lot. I'd rather not want to put it into expansion RAM.
| OOPMan wrote: |
| [...] the code is most likely written with cross-platform PC compatibility in mind. This means the code is not as tight as it could be and targets a PC-style system with memory to spare. |
The codebase started out pretty tight, since the original game even ran on a 386. But during the past years it became more loose with all the new features. E.g. map size used to be static at 256x256. Now it can be any power of 2. Reverting some of these (for a DS porf unneccessary) changes might be an idea.
| Dark Knight ez wrote: |
| As for memory and VRAM technical stuff: could you elaborate some more on how the graphics and such work? From your story I can't tell if you could cut down on graphics, are already using BGs, how palettes are set up and what-not. I'll see if I can give useful comments after having more detailed information. |
The paletted raw sprite data (8bpp) is stored along with some information (e.g. passenger capacity for the vehicle.) This is loaded from files in the grf file format. Not only the pixels, but also some of this data is 8bit, therefore the whole chunk had to go to main memory. (But only the most recently used sprites are kept in memory, else they are loaded from flash card.)
The blitter then writes the sprites to the proper location in the screen surface. Those writes can be 8bit, therefore I can't use VRAM. I might be able to rewrite the blitter to do 16bit writes, I did't check yet.
Every now and then the video driver copies the modified portions (dirty rects) to VRAM. Currently I use a 8bit extended rotation background for this (mode 5). The 256 color palette is stored in BG_PALETTE. (OpenTTD btw uses palette rotation for some animations. )
In my latest version I'm using both screens for a bigger resolution of 256x384. I'm using two banks of VRAM for this even though the data is only 96 KB. Is it possible to use only bank A, store a 256x384 array there and make the sub screen point to bankA[256x192]? (I hope you understand what I mean.)
#147229 - simonjhall - Sun Dec 16, 2007 4:40 pm
Ooh, this looks pretty cool! Been playing Sim City DS recently and I'd forgotten how much I like this type of game ;-)
_________________
Big thanks to everyone who donated for Quake2
#147233 - Lazy1 - Sun Dec 16, 2007 8:04 pm
When I started using external ram for Mini vMac DS it was slow as hell but after caching the GBA slot there was only a small drop in speed. (2-4 FPS)
#147238 - Dark Knight ez - Sun Dec 16, 2007 10:14 pm
| Quote: |
| The paletted raw sprite data (8bpp) is stored along with some information (e.g. passenger capacity for the vehicle.) This is loaded from files in the grf file format. Not only the pixels, but also some of this data is 8bit, therefore the whole chunk had to go to main memory. (But only the most recently used sprites are kept in memory, else they are loaded from flash card.) |
You might be a lot better off by loading in the sprite (pixel!) data into Sprites VRAM; keeping the actual graphics data seperated from the information data, so to speak. A lot could be done to make this work nicely and a lot faster than software rendering, I believe.
| Quote: |
| The blitter then writes the sprites to the proper location in the screen surface. Those writes can be 8bit, therefore I can't use VRAM. I might be able to rewrite the blitter to do 16bit writes, I did't check yet. |
Is it impossible to restructure graphics more to fit the 8x8 tiled backgrounds- (and sprites-) system? Anyway, rewriting it to 16bit writes would at least shave off 48kb of RAM use. Not a whole lot, but sure.
| Quote: |
| In my latest version I'm using both screens for a bigger resolution of 256x384. I'm using two banks of VRAM for this even though the data is only 96 KB. Is it possible to use only bank A, store a 256x384 array there and make the sub screen point to bankA[256x192]? (I hope you understand what I mean.) |
No. A VRAM bank can only be allocated to EITHER the main screen OR the sub screen. In your current setup this restriction doesn't even matter to you though.
_________________
AmplituDS website
#149062 - load*,8,1 - Mon Jan 14, 2008 2:36 pm
I have an early preview version out now. You can download it from the OpenTTD forums.
I rewrote the blitter (although that still needs some work) and by removing a 440KB global variable I freed enough memory to increase the sprite cache and have bigger maps running (up to 128x256). It still crashes in all kinds of places but the most serious/mysterious crashes seem to be fixed.
I only tested it on my R4DS which does auto-DLDI-patching thus I'm not sure if and how well it runs on other cards. Any reports are welcome.
Remember that this is still a very early development version. I think I'm done with the most annoying part of the process and soon I can start making OpenTTD fun on the DS.
#149063 - OOPMan - Mon Jan 14, 2008 3:01 pm
Sounds good :-) Keep up the hard work :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#149077 - bean_xp - Mon Jan 14, 2008 9:57 pm
Nice job. I just tested this, aside from the crashes obviously, and the need for a DS specific interface, it is most awesome. Any plans to incorporate the approximate 90 pixel between screens in the rendering?
#149512 - load*,8,1 - Mon Jan 21, 2008 11:41 am
I just released my next version, Alpha 4. The download can be found in the thread at the OpenTTD forums.
Changes in this version:- based on r11899
- added a start icon and description
- the random seed works
- loading original TTD saves disabled (256x256 too big for DS)
- press A anytime (even after crashes) to toggle the console
- Fix: trains can load and unload now
- Fix: road depot window (and similar) doesn't crash any more
- Fix: YAPF is completely disabled now. If the player enables it or it is enabled in a savegame, an error message is displayed and it is turned off
- Fix: saving games with bigger maps is now possible. Due to this savegames have to be uncompressed. Still 256x128 maps is the biggest possible due to memory limitations.
- Reduced viewport memory. crashes due to not enough memory available shouldn't happen so often any more.
- The game bow the start menu at the beginning
- Added a 128x64 version of the title screen savegame
- Added a key combination for the cheat menu
- Some bugs not mentioned should be fixed due to general improvements
Have fun!
PS: How can I get my forum nickname changed?
#149596 - Sh4wn - Tue Jan 22, 2008 6:28 pm
Damn this looks very very cool! Please keep on going!
@At nick change, ask an admin
_________________
http://www.return1.net :)
Pocket Physics Sharing Site
#149613 - yellowstar - Tue Jan 22, 2008 8:17 pm
The game options, and patches changes aren't saved. They're always
the same on startup. Changing them works for one session, but on
the next power-on, they're reset.
Sometimes it crashes - without any console or anything. Nothing responded and ect. It happened several times. The first time I don't remember what happened, but the second was when a new train reached a split track.(It had to decide which way to go)
It really crashes randomly - once at that train, another when checking fianances, and yet another when viewing the NewGRF settings.
With the previous version, it would always fail to load on my DS-X, but
now it works.
When loading, it says something about "Invalid chunk size", and something about an save.
There's a bug with viewports.(Like the bus viewports)
It would be best be explained if you saw it for yourself. Buy some buses,
send them on there way, switch between the viewports, and watch what happens. This can also be reproduced by opening an already existing and moving bus's viewport.
There's bugs in the map. When just looking at it, you can see some
black vertical bars. These also appear when moving around with map,
via the D-pad, but not with the stylus. Also, the white rectangle isn't
smooth with the D-pad, as with the stylus.
OpenTTD is great, and so is this DS port. Keep on going!
#149648 - load*,8,1 - Wed Jan 23, 2008 11:13 am
Thanks for the bug report, I appreciate it very much.
| yellowstar wrote: |
| The game options, and patches changes aren't saved. |
Yes, in OpenTTD on PC they are saved when you quit the game. But on the DS you simply turn off the system. Will be fixed in the next release
| yellowstar wrote: |
Sometimes it crashes - without any console or anything. Nothing responded and ect. It happened several times. [...]
It really crashes randomly - once at that train, another when checking fianances, and yet another when viewing the NewGRF settings. |
I don't get these crashes. Could you send me a savegame that crashes shortly afterwardsẞ
| yellowstar wrote: |
| When loading, it says something about "Invalid chunk size", and something about an save. |
Did you copy over all the files from the archiveẞ Not just the new .nds fileẞ
| yellowstar wrote: |
There's a bug with viewports.
There's bugs in the map. When just looking at it, you can see some
black vertical bars. |
That's because the nds blitter is not complete yet. It'll be fixed once I have decided how to arrange VRAM.
| yellowstar wrote: |
| Also, the white rectangle isn't smooth with the D-pad, as with the stylus. |
What do you mean by thatẞ
#149683 - yellowstar - Wed Jan 23, 2008 9:25 pm
| load*,8,1 wrote: |
| yellowstar wrote: | Sometimes it crashes - without any console or anything. Nothing responded and ect. It happened several times. [...]
It really crashes randomly - once at that train, another when checking fianances, and yet another when viewing the NewGRF settings. |
I don't get these crashes. Could you send me a savegame that crashes shortly afterwardsẞ
|
That's (very likely) impossible to do. There's no way,(that I know of)
to reproduce these crashes, in the same circumstance.
I could try, but it would be very difficult to get a savegame at the right
time and ect.
One time, it crashed shortly after I loaded a savegame. I didn't even do anything between the crash and load!
On one of these crashes, it brought up the debug console when I pressed A. It was doing stuff with vechiles, slots, and VRAM.
| load*,8,1 wrote: |
| yellowstar wrote: | | When loading, it says something about "Invalid chunk size", and something about an save. |
Did you copy over all the files from the archiveẞ Not just the new .nds fileẞ
|
Yes. This happened every time I booted the game with this version,
ever since I first played this version.
| load*,8,1 wrote: |
| yellowstar wrote: | | Also, the white rectangle isn't smooth with the D-pad, as with the stylus. |
What do you mean by that? |
Startup the game, load a savegame, and open up the map. There's a white rectangle which displays where you are on the map. Try moving around the map with the stylus. It closely and smoothly follows the stylus.
But, when moving around with the D-pad/arrow keys, not so. You still move around, but not much. You still move around on the playing field,
but not much on the shown map. You only move on the map after you move a certain distance. But, even after you reach that point, it's still not correct. The rectangle only moves after moving that particular distance,
and again, again, again, again...
A simpler way to describe it is, it jumps around to wherever you are on the map, after moving for a while.
#150609 - load*,8,1 - Fri Feb 08, 2008 1:53 pm
Update! The next version, Alpha 5 is out.
Changelog for Alpha 5:
- based on r12083
- Major new feature: stereo sounds effects!
Sounds require additional memory. Currently up to 200KB might be used for the sound samples. Therefore crashes due to memory shortage (especially on bigger maps) could be more frequent.
Music is still not working due to the lack of a ARM7 midi library
- sounds are also played for tiles on the border of the screen
- config options and patch settings are now saved
- more comprehensible error messages when files from the original game are missing
- screenshots in BMP format are working (normal and giant)
(the debug console won't be drawn onto a screenshot)
- added a loading screen and a an exit screen
- code cleanup to fit OpenTTD project structure
The download and a list of bugs which I'll keep updated is in the initial TTD forums post.