modular design + threads *WARNING: LONG POST*

[richk67]

I recall that sector-based game engines like Doom, Quake and Duke3D have their game levels partitioned into binary trees of sectors (BSP)

I recall that Doom, Quake, Duke3D had multi-million dollar development teams of many full-time coders, designers, artists, testers (what a job!!), etc. etc..

You cant expect beautiful design from OpenTTD - a program with a handful of part-time volunteer coders, working from a disassemble of a C program. Unless you want to fund us to all go full-time on redesigning it, of course!

[DmitryKo]

(and multithreading [...], because it's not supported on UNIX)

Any more bullsh^Winsights?

to be continued

please not

You're a very kind person. And BTW, f... Linux.

[Darkvater]

(and multithreading [...], because it's not supported on UNIX)

Any more bullsh^Winsights?

to be continued

please not

You're a very kind person. And BTW, f... Linux.

Well, let's not get carried away here. While Tron is a bit harsh here, please don't go spread FUD (Fear Uncertainity and Doubt) about things you have no idea about. So both, cool down

[XeryusTC]

First of all Unix supports threads, they are called POSIX threads, or pthreads for short. Linux and Unix support them both, windows can support them with an additional library.
And threads shouldn't be used to split every task off from the main loop, they are mostly used for tasks that rely on hardware that isn't used very often but can form a bottleneck. If you try to split the engine up into the most CPU consuming parts it would only go slower because of the overhead. And putting the GUI into its own thread is a really bad thing, you will need a lot of mutexes every time it needs information to fill a window causing other threads to wait or in the worst case it can even cause a deadlock.
Different threads for music (if used) is an idea, but not necessary. OTOH splitting AI up into a different thread might prove to be useful if GPMI is implemented into the main OpenTTD trunk. I have been fiddling around with GPMI for a few days now and it is kind off irritating if I cause a endless loop through carelessness or just plain stupidity and can't do a thing and can't kill the game.

Caching an entire route so you wont need pathfinding is bad too: if only one thing in the network changes it needs te be re-calculated for all the trains in the network at the same time; lane load balancing wont work because all trains will try to enter the same lane causing a traffic jam, this is exactly the opposite what you tried to do with the lane load balancing.
I would go for the KUDr way, cache the weight of a piece of track between two signals so the path only needs re-calculation when the train enters a junction in stead of every tile.

[DmitryKo]

I recall that Doom, Quake, Duke3D had multi-million dollar development teams of many full-time coders, designers, artists, testers (what a job!!), etc. etc..

Doom and Quake engines were coded by John Carmack, except for some minor parts, and Build engine was a freelance work of Ken Silverman (who used Visual Basic for prototyping ). Anyway, multi-million dollar games are not the only software that is allowed to use smart coding tricks, isn't it?

You cant expect beautiful design from OpenTTD

Read my posts please - I don't expect anything besides some feedback..

[DmitryKo]

putting the GUI into its own thread is a really bad thing, you will need a lot of mutexes every time it needs information to fill a window causing other threads to wait or in the worst case it can even cause a deadlock.

Indeed. But on the other hand, the interface doesn't have to poll the game data intensively.

Given that the number of UI windows is finite, comparing to the number of game entities, I guess the engine could just prepare the statistics for the enities requested by the GUI (no matter threaded or not), and do it at a very modest rate, maybe once or twice in a second at best.

Separate rendering/viewport states wouldn't need much polling as well, and even less if there's a kind of view frustum culling.

Caching an entire route so you wont need pathfinding is bad too

I never meant caching entire routes for each single vehicle or eliminating tile-based pathfinding completely . I was rather thinking about a graph of all the possible arcs that can ever make a route, something like "arc 1 is a road that connects tile x and tile y, rather free", "arc 2 is a unidirectional rail track that connects tile X and tile Y and has bidirectional semaphores at both ends, rather crowded" etc.

So when a vehicle is given an order, the pathifinder just looks through the top-level graph nodes associated with the current station/dock/airstrip etc. and determines if the destination station/dock etc is reacheable, then creates a route that consists of all the arcs (waypoints) it needs to pass. When a road is removed, a station is created etc. only the affected arcs need to be modified. And if there's a traffic collision, sepahore locked etc., the vehicle can intiate a search for alternative routes.

if only one thing in the network changes it needs te be re-calculated for all the trains in the network at the same time; lane load balancing wont work because all trains will try to enter the same lane causing a traffic jam, this is exactly the opposite what you tried to do with the lane load balancing
I would go for the KUDr way, cache the weight of a piece of track between two signals so the path only needs re-calculation when the train enters a junction in stead of every tile.

Yep, that's what I'm basically talking about

OTOH splitting AI up into a different thread might prove to be useful

The current player AI isn not clever enough to be CPU-intensive

[MeusH]

I don't have anything against the OTTD code. Just use search (grep) function frequent and everything will be fine.

Quake code is really similiar. Belive me, I've made mods for it. As easy as coding for OTTD.

[toholio]

and multithreading is OS-specific in the first place, because it's not supported on UNIX

*cough*

What?

Where do people get these insane notions?

[Bjarni]

and multithreading is OS-specific in the first place, because it's not supported on UNIX

*cough*

What?

Where do people get these insane notions?

well some people will even lie to make their favorite software/hardware/car/whatever better than everybody else's. It's not the same as we should listen so such nosense. Don't believe everything you read

[thomasdev]

hi, just requesting some comments on my thoughts how it would look if everything was written in c++. Just some thoughts, no new game or something like this...
just general design with the focus of high extensibility

[Bjarni]

hi, just requesting some comments on my thoughts how it would look if everything was written in c++. Just some thoughts, no new game or something like this...
just general design with the focus of high extensibility

you know, OpenTTD is written in plain C, which means no objects at all and we don't plan to change that

[DmitryKo]

how it would look if everything was written in c++. Just some thoughts, no new game or something like this...

The Next Mainstream Programming Language: A Game Developer’s Perspective (Tim Sweeney, Epic Games) (pdf)

[thomasdev]

you know, OpenTTD is written in plain C, which means no objects at all and we don't plan to change that

i know and DO NOT want to submit a patch

[thomasdev]

The Next Mainstream Programming Language: A Game Developer’s Perspective (Tim Sweeney, Epic Games) (pdf)

nice pdf, thx for sharing the link

[DmitryKo]

and multithreading is OS-specific in the first place, because it's not supported on UNIX

What? Where do people get these insane notions?

I can tell you that - I've got it from reading the manual for a UNIX System V R4 (I recall it was FreeBSD). You probably think the world never existed before Linux, but believe me, there actually were computers and operating systems

well some people will even lie to make their favorite software/hardware/car/whatever better than everybody else's. It's not the same as we should listen to such nosense. Don't believe everything you read

Oh common, I'm too old for fanboyism... It's a honest mistake on my part - the last time I checked, there were NO threads in UNIX SVR4 and its derivatives, and that was, I think, 1994 I didn't follow it closely since then - good if IEEE got them rolling, but honestly, I could care less

[DmitryKo]

how it would look if everything was written in c++

As for your scheme, there basically should be much more level of inheritance - that is, a basic "station" class that gets extended to bus/truck, rail, airport, a basic "vehicle" class, "industry" class, "terrain" class etc.

[thomasdev]

how it would look if everything was written in c++

As for your scheme, there basically should be much more level of inheritance - that is, a basic "station" class that gets extended to bus/truck, rail, airport, a basic "vehicle" class, "industry" class, "terrain" class etc.

youre right, why did i only used interfaces ...

[Bjarni]

well some people will even lie to make their favorite software/hardware/car/whatever better than everybody else's. It's not the same as we should listen to such nosense. Don't believe everything you read

Oh common, I'm too old for fanboyism... It's a honest mistake on my part - the last time I checked, there were NO threads in UNIX SVR4 and its derivatives, and that was, I think, 1994 I didn't follow it closely since then - good if IEEE got them rolling, but honestly, I could care less

Actually I meant it more in general than just you (even though I didn't make it very clear). I have met a whole lot of people, who claimed windows to be better for really stupid reasons. One of the best is that a mac can't boot if you rename all the files in the system (like windows can survive that). I find it just plain stupid, but it goes both ways. I have also met a guy, who thought the solution to everything was to switch to linux and gcc, even when it came to a C code that failed to compile due to a missing ";". That's not good either.

I think we should get back to the topic instead of talking about who made a mistake

[DaleStan]

the last time I checked, there were NO threads in UNIX SVR4 and its derivatives, and that was, I think, 1994

May I advise you not to spout computer related "facts" that were true twelve years ago? I've gotten into trouble spouting "facts" that were true just a few months ago.

[DmitryKo]

May I advise you not to spout computer related "facts" that were true twelve years ago?

No.