Transport Tycoon Forums

dominik81 wrote:

AntBUK wrote:Edit: Won't even build a dock just returns misc>cursor 0x0 (0)

That's strange, I don't have problems building docks. Are you sure you clicked on a valid tile?

Absolutely, I am able to build a Lock on the tile and afaik Locks have tighter restrictions as to where they can be built.

I attempt to return to the title screen and I get an out of memory error (cannot allocate 172032 bytes assertion 0 failed, openttd.cpp line 111), but that may be due to having to load the "background" so I'm going to make a quick background screen 64^2 based off my R4 theme just to confirm, as I remember you saying there was problems loading games larger than 64^2.

Edit: Yup, 64^2 works fine on the title screen, also just found it available on QuickJump Also located it on DC-Emu.

I get an error, cannot open file sample.cat? Any ideas?

You still need the original data files to play the DS port

Ah cool, which files?

Depending on which version of TTD you have...

DOS

• SAMPLE.CAT
• TRG1.GRF
• TRGC.GRF
• TRGH.GRF
• TRGI.GRF
• TRGT.GRF

Windows

• sample.cat
• trg1r.grf
• trgcr.grf
• trghr.grf
• trgir.grf
• trgtr.grf

They can be found in the DATA folder of your original installation.

Cheers man, good work, works a lot better than I imagined it ever could already!

The DS is able to show 16 bits of colors so 8 bit graphics shouldn't be a problem, also remember that TTD is originally a DOS game and doesn't need much memory to begin with. OpenTTD, however, is much more complex and needs a bit more than the original.

Working - An airplane route from one part of town to another
Not Working - Crashed when I tried to build a train route to the coal place
Not Working - Crashed when I tried to link the coal route with some coal road vehicles
Not Working - Doesn't save the manager's face

Very good port so far, Can't wait to see how good this gets!

Not Working - Bus route from one part of town to another
Working - Docks and Locks, they work fine for me.

I managed to get it not to crash when building a train network.
Unfortunately, that involved turning off the pathfinding, and it soon became lost with the NTP. Oh well...
Excellent work so far with the game.

I've been thinking about the gui a bit more. What I came up with is having the (16pixel high) main toolbar at the bottom of the screen and the status bar at the top. The reason being that the toolbar needs to be on the bottom screen to be clickable, but it shouldn't divide the viewport in two. I know it's quite unusual for OpenTTD players but many DS games (Theme Park, Settlers) have it that way. What do you think?

@Slye_Fox: Could you make the main toolbar icons into a grf that replaces the original ones? I don't know if that's possible, but else a normal grf file would be ok too.

elf_sander wrote:Quit Game doesn't always work (1/6 attemps actually work) most of the time I get the next error with a freeze:
Free 68k Largest 48K
[Err:] Out of memory. Cannot allocate 65536 bytes assertion "0" failed: file "/media/hdbd1/dev/ndsdev/openttd/src/os/ds/arm9/../../../../src/openttd.cpp" line 111

That's fixed for the next version. It was due to the fact that OpenTTD always allocates a 256x256 map before loading a game.

elf_sander wrote:

PS: I personally don't like qwerty. On my PC I have Neostyle layout.

What kind of layout is that? Can you show me an example?

This is how it looks like.

weaselboy246 wrote:only problem I found was randomly the road between vehicles would flash dirt. like it was just built.

That's in the debug version only. It shows the tiles that the pathfinder has visited. For a real release it will be disabled.
Also YAPF will be automarically disabled in the next release. In fact it will not even be compiled into the game.

Stylpe wrote:I've tried building a rail route too, and see the same behaviour with the trains just going back and forth on hte loading station

That's fixed too.

elf_sander wrote:The DS is able to show 16 bits of colors so 8 bit graphics shouldn't be a problem, also remember that TTD is originally a DOS game and doesn't need much memory to begin with. OpenTTD, however, is much more complex and needs a bit more than the original.

It doesn't really matter that much if a game is 8bit or 16bit as most graphics stuff in most games is done in hardware. Even though TTD was very tight and efficently programmed, OpenTTD is something completely different. In comparison it is very bloated now that I almost which I would base my port on an early revision. Even I am very surprised how well it runs now that I have fixed a lot of things. I played a 128x64 game for over an hour (6 years) yesterday, with 3 AIs and all kinds of vehicles. Not a single crash until year 6.

AlexFili wrote:Not Working - Doesn't save the manager's face

You mean saving the managers face to the config file, right? The problem is, that OpenTTD only saves the config file when you exit the game - or start a new game. I'll have to add a more obvious "save current config" button.

Ah well that explains it. Well, good work so far.

dominik81 wrote:

elf_sander wrote:

PS: I personally don't like qwerty. On my PC I have Neostyle layout.

What kind of layout is that? Can you show me an example?

This is how it looks like.

Ah it's a German style. Great for all Germans, but not so great for the rest of the users Maybe adding a Tab with symbols/special characters would be an option? Or adding mutiple keyboard layouts (that's gonna eat memory, though)

Alexfili: the edit button is your friend, it saves having multiple posts one after the other.

dominik81 wrote:

elf_sander wrote:

dominik81 wrote: PS: I personally don't like qwerty. On my PC I have Neostyle layout.

What kind of layout is that? Can you show me an example?

This is how it looks like.

Could you not have multiple keyboards? Neotype would drive me mad the keyboards what go "ABCDEF...etc." drive me mad as it is

Just a quick note: I didn't mean that the OSK should use Neo. That was simply a side-note to what I am using. A ABCDE... keyboard and a QWERTY one will do. Loading different keyboards shouldn't be a problem memory-wise either.

I probably won't start work on any GUI stuff until the other bugs are fixed though. And that list is still pretty long...

Why put the toolbar on the bottom when the screens are switchable?

and i'm not sure what you want me to do.

Slye_Fox wrote:Why put the toolbar on the bottom when the screens are switchable?

Because having the status bar (which is pretty useless to click) on the touchscreen doesn't make sense.

Slye_Fox wrote:and i'm not sure what you want me to do.

To get the 16x16 icons into the game they need to be in GRF format. So I would need them as a *.grf file. And I think with newgrfs it is possible to overwrite existing sprites. So I was thinking you could specify in the grf file difectly to overwrite the bigger, original sprites. If that's not possible a regular grf file with the graphics will do.

I also altered the zoom icons again and added a "switch toolbar" button.

dominik81 wrote:

Slye_Fox wrote:Why put the toolbar on the bottom when the screens are switchable?

Because having the status bar (which is pretty useless to click) on the touchscreen doesn't make sense.

Slye_Fox wrote:and i'm not sure what you want me to do.

To get the 16x16 icons into the game they need to be in GRF format. So I would need them as a *.grf file. And I think with newgrfs it is possible to overwrite existing sprites. So I was thinking you could specify in the grf file difectly to overwrite the bigger, original sprites. If that's not possible a regular grf file with the graphics will do.

I also altered the zoom icons again and added a "switch toolbar" button.

Hmm ... I wonder whether we could have BOTH icons at the same time in ordinary openttd ... so that when you resize regular openttd window under some certain size, icons will swith to the smaller equivalents. Which would be better than current "stacking"

I like the look of the smaller toolbar.
Just thought I'd let you know, the far left of the DS screen has a few pixels that don't respond to touch activity. So try and keep the windows at least 3-5 pixels away from the left edge. Thanks.

Also, when most people buy an engine for a train, they want to add vehicles right after, but for some reason the buy window closes as soon as you buy a train. It would be nice if the buy window remained open until you press cancel.

Did you read my suggestion about having a random seed?
If the player presses start at a random time, or if you get the random number from the battery life, or date... then you could have a number that was truly random. If you really have no clue about this, I can send you a code snippit from one of my projects, which was also generating random numbers.

I've no idea how to make grf files.