modular design + threads *WARNING: LONG POST*

[toholio]

You probably think the world never existed before Linux, but believe me, there actually were computers and operating systems

Why would you assume I'm running Linux?

[p***ing contest]
I'm willing to bet my operating system's development started earlier than your operating system's (and it certainly started before Linux).
[/p***ing contest]

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

No.

If you're going to refuse DaleStan's advice and not keep up to date why should we believe anything you say?

When I used Windows in 1994 it didn't have any concept of threads but that doesn't mean I run around claiming that Windows XP doesn't. I wouldn't assume that development stopped just because I wasn't looking in the intervening years.

[DaleStan]

If you're going to refuse DaleStan's advice and not keep up to date why should we believe anything you say?

/me offers to recalibrate and/or replace toholio's sarcasm detector.

Mine went off, anyway.

[toholio]

/me offers to recalibrate and/or replace toholio's sarcasm detector.

Mine went off, anyway.

Mine tingled, but after reading some of the other posts in the thread I just couldn't be sure.

[Archonix]

Anyone know where I can get a copy of OS2?

Anyways... is it me, or has this thread died a death?

[Bjarni]

Anyone know where I can get a copy of OS2?

Anyways... is it me, or has this thread died a death?

I already said that we should get back to modular design talk instead of OS talk, but then people just continued the OS talk

[Archonix]

Anyone know where I can get a copy of OS2?

Anyways... is it me, or has this thread died a death?

I already said that we should get back to modular design talk instead of OS talk, but then people just continued the OS talk

I guess there's not much more to say on the subject. Modularity == t3h g00dness (as they say), but it requires a lot of work to implement in a program that was previously non-modular. My own advice would be to get OTTD to a certain point, where all its features are pretty much sorted and bug free, for a given value of bug free, and freeze development on that branch. Then begin adopting a new modular approach for the next major release. Unfortunately there are a lot of problems with that approach, not least developer inertia, and users demanding to know when the next version will be complete.

There you go; an executive summary. Now... how do you fix those problems?

[CobraA1]

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

That's why this exists:
http://www.tt-forums.net/viewtopic.php?t=23216

Like it or not, OpenTTD may start switching to C++, even if we have to fork from the "primary" project.

Sorry, Bjarni, in the end the decision may not be yours.

[Bjarni]

Like it or not, OpenTTD may start switching to C++, even if we have to fork from the "primary" project.

Sorry, Bjarni, in the end the decision may not be yours.

I replied to rewriting all the code to C++, which will be a huge task. Nobody plans to do that.

As for C++ additions, we will have the problem with the nightly build server. It can't handle C++ code as it is now. It might do that in the future, but until then, I would not start writing C++ code. The question is if C++ should be worth more than the nightly builds.

I never claimed that OpenTTD will never contain C++ code. We just have to be realistic about it (and not turn this into something like windows vs linux)

[orudge]

Anyone know where I can get a copy of OS2?

If you seriously want a copy of OS/2 (I assume you don't, but you never know), PM me.

OS/2 is a nice operating system in a way, it's just not been greatly developed in recent years. There's still a large community supporting it, producing such great software for it as OpenTTD.

Anyway, back to the thread...

[CobraA1]

As for C++ additions, we will have the problem with the nightly build server. It can't handle C++ code as it is now. It might do that in the future, but until then, I would not start writing C++ code. The question is if C++ should be worth more than the nightly builds.

I'm not saying we'll do so, or that it's easy - but because of the open source nature we can say "forget the devs" (and the nightlies) and spin off our own fork if we care to create our own version of OpenTTD .

I've always imagined myself creating my own version of OpenTTD. I don't have the time or resources to do so now, but hey, maybe someday.

I do agree, though, that rewriting the whole thing would be a huge task, it should be done incrementally instead of all at once.

[DmitryKo]

/me offers to recalibrate and/or replace toholio's sarcasm detector.

Yep, sarcasm is an art lost

Why would you assume I'm running Linux?

I didn't

If you're going to refuse DaleStan's advice and not keep up to date why should we believe anything you say?

Because anything I say is not related to implementation details of various operating systems, especially those I'm not interested in keeping track of.

When I used Windows in 1994 it didn't have any concept of threads

Well, Win32 API had threads right from the start (even since it was the API for OS/2 3.0), and Windows NT 3.1 was released in Summer 1993. POSIX standard surfaced no earlier than 1995.
Actually threads were heavily marketed by MS folks as a brand new way to improve responsiveness of Win32 applications:
http://msdn.microsoft.com/library/defau ... winthr.asp


Now, can we get back to the topic, pretty puh-lease...

[toholio]

Why would you assume I'm running Linux?

I didn't

So why did you follow my initial post with "You probably think the world never existed before Linux, but..."?

Because anything I say is not related to implementation details of various operating systems,

Oh? So "multithreading is OS-specific in the first place, because it's not supported on UNIX" is not related to the implementation details of various operating systems?

POSIX standard surfaced no earlier than 1995.

The POSIX standard may not have been finalised until 1995 but it was being worked on long before then (random usenet evidence from 1990). It was also not the first implementation of threads for UNIX systems.

Now, can we get back to the topic, pretty puh-lease...

/me fights the urge to get in the last word and loses

[Archonix]

POSIX standard surfaced no earlier than 1995.

The POSIX standard may not have been finalised until 1995 but it was being worked on long before then (random usenet evidence from 1990). It was also not the first implementation of threads for UNIX systems.

lets not forget that threads were implemented way back in the 1970s, on MULTICS, under the name of "processes".

Threads as we know them are a reimplementation of MULTICS processes.

Now, can we get back to the topic, pretty puh-lease...

/me fights the urge to get in the last word and loses

Hah! Meeeee!

Now that we've established that, his billness didn't invent threads, and that threads aren't an OS-specific thing, I think we can get back to the discussion.

[DmitryKo]

So "multithreading is OS-specific in the first place, because it's not supported on UNIX" is not related to the implementation details

Yes, it is basically an implementation-specific feature. That's why I did mention it.

Now that we've established that, his billness didn't invent threads

No one here said threads were invented by Microsoft, and even then the credit would go to Dave Cutler.
But I'd like to notice that most really innovative things get rarely invented by large companies, but mostly through cooperation with academic scientists (well, except for Xerox PARC )

I think we can get back to the discussion.

Yes, indeed! So, here's some things I'm personally intersted in taking a closer look at, but no earlier when all the features in the current milestone are finished and some careful rethinking of current code modules could be applied:

1) different GUI concepts: I guess most functionality of current GUI modules can actually be removed to a sorts of "Game Actions" module, so some different input schemes and user interfaces could be tried with ease - someting like a portable pen and joystick UX for handheld users, a different simplified buttons/windows layout that's closer to today's real-time games, maybe some game console ports etc.;

2) different graphics driver: OpenGL/ES 32-bit color accelerated sprite renderer - screen-coordinates only at first, but maybe limited support for a "true" 3D world and graphic effects could be added in the future, to enable features like smooth zoom levels, a different viewpoint perspectives, night/day effects; maybe clouds, smoke, water reflections etc. (the sprite overlay wouldn't require much changes, but 3D world does require some re-modularization);

3) partial conversion of performance-limited code from table lookups to scene-graph like data arrangement (let's call it "enrailment" because something similar is already used for trains ), so that even larger maps and more up-to-scale cities and structures are possible without severe performance degradation;

4) dual monitor support (depends on 1);
5) 3D stereo-friendly; some support for in-game 3D models as a distant goal (depends on 2).

These are the things that would worth code restructuring efforts IMHO.

[bobingabout]

1) different GUI concepts: I guess most functionality of current GUI modules can actually be removed to a sorts of "Game Actions" module, so some different input schemes and user interfaces could be tried with ease - someting like a portable pen and joystick UX for handheld users, a different simplified buttons/windows layout that's closer to today's real-time games, maybe some game console ports etc.;

2) different graphics driver: OpenGL/ES 32-bit color accelerated sprite renderer - screen-coordinates only at first, but maybe limited support for a "true" 3D world and graphic effects could be added in the future, to enable features like smooth zoom levels, a different viewpoint perspectives, night/day effects; maybe clouds, smoke, water reflections etc. (the sprite overlay wouldn't require much changes, but 3D world does require some re-modularization);

3) partial conversion of performance-limited code from table lookups to scene-graph like data arrangement (let's call it "enrailment" because something similar is already used for trains ), so that even larger maps and more up-to-scale cities and structures are possible without severe performance degradation;

4) dual monitor support (depends on 1);
5) 3D stereo-friendly; some support for in-game 3D models as a distant goal (depends on 2).

the OGL would help for 32bpp support, because if we had a graphics processor doing the graphics, we could allow variant, and mixed CCs, instead of greyscaling then re-colouring the parts where a remap is.
and duel screen support, allowing 2 screens of different sizes would be brilliant.

also, the ability to turn off OGL, i wouldn't be very happy if i could no longer run OTTD on my K6-2-550. which unfortunatly, would then requre a different graphics rendering method for the 2 modes, where the OGL version would look way better. would mean doing a bit of processesing to the graphics as the game loads it into RAM.

[DmitryKo]

i wouldn't be very happy if i could no longer run OTTD on my K6-2-550

I'd guess the minimum requirements would be very forgiving, basically an DirectX 7 card like GeForce2 MX or Radeon 256 (and all newer NVIDIA boards and many ATI boards can still work in a 3.3V AGP motherboard like yours, although it doesn't make much sense).

a different graphics rendering method for the 2 modes where the OGL version would look way better. would mean doing a bit of processesing

Yes, 32-bit graphics would have to be dithered down, but then there could be 8-bit paletted versions included for compatibility.
It doesn't necessarily mean OpenGL renderer would look any better than a software renderer though

[bobingabout]

i wouldn't be very happy if i could no longer run OTTD on my K6-2-550

I'd guess the minimum requirements would be very forgiving, basically an DirectX 7 card like GeForce2 MX or Radeon 256 (and all newer NVIDIA boards and many ATI boards can still work in a 3.3V AGP motherboard like yours, although it doesn't make much sense).

my K6-2-550 is on a board with an intergrated AGP graphics card, but no AGP slot, only 3PCI and 1 ISA, i can't remember what the graphics is, but it does not have OGL, only DX, i've tried it before.

[XeryusTC]

3) partial conversion of performance-limited code from table lookups to scene-graph like data arrangement (let's call it "enrailment" because something similar is already used for trains ), so that even larger maps and more up-to-scale cities and structures are possible without severe performance degradation;

Actually there is being worked on that, Celestar is still busy with his proof-of-concept but it is taking shapes. I've seen an early version running which only had a simple terrain (my system meets the requirements Celestar made to run it smoothly) and I've seen screenshots of a later version with some basic texturing for land, shores and sea. It is _NOT_ sure if it is going to be implemented there is only being worked on, you CAN'T blame me is it is being implemented.

[DmitryKo]

my K6-2-550 is on a board with an intergrated AGP graphics card
it does not have OGL, only DX

Then you'd be better off with software true color renderer, when it's done.

3) partial conversion of performance-limited code

I've seen screenshots of a later version with some basic texturing for land, shores and sea.

Huh... these two parts don't really connect, do they

Celestar is the man if he's trying to get a true 3D world over the current source code, even if the efforts are at the prototyping stage... hope it doesn't end like several other rewrites

[Darkvater]

Let me clarify this OGL-rewrite that some seem to have called it. It is not! Celestar is doing it for his own fun and there are no plans whatsoever of switching or adding an OGL driver to OpenTTD.