Simutrans 86.03.2

[prissi]

Fixing a bug that made rendering very slow on bigger screens. Also some other small bugfixes. If you have an 86.03.1 installed, you will only need the executables.

http://64.simutrans.com/simuwin-86-03-1.zip
http://64.simutrans.com/simulinux-86-03-1.zip


The graphics are still the same as 86.03.1:

64 base pak: http://64.simutrans.com/simupak64-86-03-1.zip
64 food chain: http://64.simutrans.com/food64-86-03.zip
64 waste chain: http://64.simutrans.com/waste64-86-03.zip

EDIT: Fully compatible pak128 including new trams:
http://128.simutrans.com/download/05_05_27/pak128.rar

New alpha german test version:
http://64.simutrans.com/german-86-03.zipbase + passenger/mail
http://64.simutrans.com/germancar-86-03.zipcars industry
http://64.simutrans.com/germandrink-86-03.zipdrinks
http://64.simutrans.com/germanpharma-86-03.zipmedizine
http://64.simutrans.com/germanwaste-86-03.zipwaste

no compatible winter or japan pak at the moment



Release of 86.03.2

25-May-2005 (prissi)
CHANGE: station_coverage_size now saved with a savegame. For old map, default is 3.
FIX: opening the minimap on faster systems yield FPS>1000. hopefully fixed (+ default refresh=2)
FIX: retire messages now appear
FIX: outdated or future vehicles now display with a blue bar instead crashing in a depot
FIX: finetuning number of trucks for AI
ADD: parameter "-fullscreen" for command line resp. "fullscreen = 0/1" in simuconf.tab

[toholio]

http://64.simutrans.com/simuwin-86-03-1.zip
http://64.simutrans.com/simulinux-86-03-1.zip

But no MacOS X package... And if you go looking for the sources to see what breaks/is missing when compiling under OSX you find out that the source isn't available. Way to go guys, a fantastic way to encourage development.

(I'm guessing you've had this conversations dozens of times before).

[prissi]

In the source many structure are saved like fwrite(f,sizef(bexch),1,&besch);.
This will break on MAC OS and many other machines. Also many declerations are just int, not with proper size. Many places will break, almost every file will need a rework, some for the loading/save (scatterd in 30+ files).

I am planing to by a MAC, so this might change. And many people asked to compile this for a MAC. Some even got the source. We never heard of them again.

This is possibly because Simutrans source is at least 3 times OTTD code size ~5MB, 600 files 130000 lines, with some very heavy C++ everywhere. It takes about a month to understand it, to make useful changes. Therefore, the team decided not to make it open source, but to rely on people who do some long term contribution. OTTD has many patches, contributed by someone and then completely forgotten/no longer maintained (like the passenger destinations), and also incompatible parts.

I would be the last to discourage people. Anybody who can contribute is wellcome. We just want some long term commitment. We just want to know who contributes. Actually, about 20 people have a more or less current source. But never more than one or two contributed.

Actually, I am still open for OpenSource, but the last time the teams discussed it, the majority felt no advantage and voted against. And I dislike to become just a code integrator and or spend my time on debugging someones code.

[DaleStan]

This is possibly because Simutrans source is at least 3 times OTTD code size ~5MB, 600 files 130,000 lines, with some very heavy C++ everywhere.

Huh? Have you ever checked out the OTTD source?
The OTTD source tree has 300+ files, totalling 10.74 MB, and with almost 120,000 lines in the root directory alone. Over 200,000 lines total. And no pretty C++. The whole thing is in C.

5MB, 600 files, 130,000 lines is not exactly my definition of "at least 3 times OTTD code size".

Yes, I'm being fair. I left the GRF files and the sound/music files out of the OTTD counts.

[SHADOW-XIII]

maybe he meant 'pure-new' code
I doubt there is more 10,000 lines of code in 0.4 OTTD release not from TTD

[prissi]

Of course, I checked the sourcecode of OTTD, before I post it. (And probably implementing a night cycle for me.) All *.c and *.h files (less than 300) are together zipped 940kB. About 40% size code line are definitions using macros (i.e. bloated up) which are not part of the simutrans code, like everything in table/. If I count this, then the source of simutrans is easily 10 times with the sources for the grafics. But both grow of course.

But with benchmarking, you always get what you want

However, for the understanding of the code, I personally think that OTTD is lacking comments at so many places. Furthermore, there is not even a *.h for every *.c, making it very difficult to find a function. Also some C++ seems in there, or what is something like that:

Code: Select all

_tile_type_procs[GetTileType(tile)]->tile_loop_proc(tile);

Imho, this is as C++ as it can get ...

Also there are very many functions just returning an index, i.e.

Code: Select all

void ChangeTileOwner(TileIndex tile, byte old_player, byte new_player)
{
	_tile_type_procs[GetTileType(tile)]->change_tile_owner_proc(tile, old_player, new_player);
}

These could be inlined (with big impact on performance) if there are just header files.

Actually, if this code look like this, because it was written by many people, than this is a good argument against OpenSource. (And honestly, to the final nightly, also only selected people contribute anyway.)

(Very Offtopic: Looking at the sourcecode of OTTD, I start worrying, if there is not a wall, when all this bit here and there thing breaks and one has to completely start again.)

Anyway, this sounds very negative. I like OTTD, I like Simutrans, and I think both can inspire the other what to do next. I.e. OTTD still has a much more "I am the boss" feeling, is more portable and is network capable. (Simutrans will probably never be, because there are much more random sequences that depends on player input.)

On the other hand, OTTD graphics are as bad as the original, even though a much better grass could be done in 256 colors, I am sure. And OTTD has no strategic depth, I found it way to easy.[/code]

[DaleStan]

All *.c and *.h files (less than 300) are together zipped 940kB

But "all the *.c and *.h" files are not sufficient to build OTTD. There are no localized texts in those files. *NONE*.
With the exception of the data/ directory (which is only required if you want to actually play OTTD), everything that appears in svn://svn.openttd.org/trunk is required for some portion of the build.

Code: Select all

_tile_type_procs[GetTileType(tile)]->tile_loop_proc(tile);

Is perfectly valid C.
_tile_type_procs is an array of pointers to TileTypeProc (a typedef'ed struct). tile_loop_proc is a pointer-to-function member of TileTypeProc. No C++ here.

I hate carriage returns more than anyone else I know, but I have to hand it to the OTTD devs for that line. It's an impressive example of conservation-of-vertical-space, but it's not C++.

Furthermore, there is not even a *.h for every *.c, making it very difficult to find a function.

grep? Nope. Never heard of it. Must be useless.

[prissi]

Probably I should not aswer this, but:

To compare filesize etc. I just compared code. If I include all translations it is very easy to beat OTTD, since the japanese font would be alone 2MB. And this ist BW.

And I know how to use grep (but I rather use fgrep by the way).

And it is very bad style, not to accompany a *.c file with a *.h file with it functions. Bad style, read K&R, if you do not believe me. Instead in OTTD all declerations are sometime done just where you need them in the files (bloating them too) and in some cases apparently not even done at all, if it is just an int.

Using function pointer and callback is of course valid C. (And needed by MS windows ... ) But this is better done in C++, because there you get all the error checking also from the compiler and other nice stuff too (correct types, variables ... )

You know, I am programming for 20 years, I made commercial programs, had my own company. So I did also larger projects. If one of my companions (or now one of my students) gave me that kind of code like OTTD, I would make him an overhaul.

To conclude, I think most part of OTTD code are not nice to read and requires a heavy overhaul. You can of course disagree.

But this is getting far off the topic.

[charlieg]

prissi: The advantage of it being open source is that somebody can check out the source without having to ask for it. This lowers the barrier for a prospective developer. Not everybody likes making formal contact before digging into the source for a project.

Also the fact that its not open source attaches a stigma that will put off many open source developers.

[eis_os]

Even if people blame me again.

prissi:

Actually, if this code look like this, because it was written by many people, than this is a good argument against OpenSource.

It's not a fault of Open Source Programming that there isn't any Comments in OpenTTD. It's the nature how it was created.


Comments?

If you translate ASM Code (that you don't fully understand on some parts) and convert it into C, the C code you get isn't very nice. Neither did you spent time on commenting of Stuff. Some parts of the code uses goto and labels because the internal logic is based on how a processor or asm works, not how you would design good c code. (well the code changes now overtime, somehow I get the feeling the lost of the old Code was by design)

I can't say TTDPatch is better on the Commentary part, most stuff is not commented, but it has worked until today quite good.
(Neither do I spent time on commenting so someone simple can convert it to c)

[orudge]

This is possibly because Simutrans source is at least 3 times OTTD code size ~5MB, 600 files 130000 lines, with some very heavy C++ everywhere. It takes about a month to understand it, to make useful changes. Therefore, the team decided not to make it open source, but to rely on people who do some long term contribution. OTTD has many patches, contributed by someone and then completely forgotten/no longer maintained (like the passenger destinations), and also incompatible parts.

Is a lot of the Simutrans source still in German? Certainly, the latest source I have, from 2002/3 sometime, is mostly in German and not that easy to follow really. I managed to hack a finance window and music support into it, though.

[DaleStan]

If one of my companions (or now one of my students) gave me that kind of code like OTTD, I would make him an overhaul.

I'll grant you that the OTTD code isn't always pretty, but that line doesn't seem like a good example. What's the correct way of writing that line, given the restriction "It must be C"?

The reasons I hack on the OTTD source are (1) to fix bugs that apparently only manifest on my computers[0], and (2) to improve patches other people post. Without the source, I can't do either of those.

[0] Each of two computers was effected by exactly one of the two bugs. Neither computer managed to reproduce the bug exhibited on the other.

(And fonts are graphics, not texts. But "lies, damn lies, and benchmarks." Moving along.)

[prissi]

Probably, as some kind of concluding remark, I would admit, that probably any neccessarily advanced code is not easy to understand. Simutrans certainly is (even if there are more comments and one must read german), and OTTD is too, for other reasons.

And ok, that line is not a problem with good prototypes and everything. However, the extensive use of globals (likely inherited from the ASM source) and the internested structures (this bit meaning that) I personally see a points where this project can badly suffer or makes extension quite hard. Apart from the lack of comments.