Multi-core support please!

[Rubidium]

As for single-core systems, just don't do it.

Code duplication == unmaintainability == bugs, therefor not a good solution.

To prove it would be to implement it. You're not seriously suggesting I should pick up the source and do it myself?

Yes, you are FAR more into using Z-buffers and such as I am. Why would I need to learn that to (dis)prove that you are right? Furthermore the drawing is only a very small part of OpenTTD. I can ofcourse hack what you want into OpenTTD, but then I am sure it will be slower on both single and multicore CPUs because I take the lame approach of just adding numbers to all to-be-drawn sprites and then do the thread starting and such.

[Core Xii]

Yes, you are FAR more into using Z-buffers and such as I am. Why would I need to learn that to (dis)prove that you are right?

Well I never explicitly asked you to do it... just throwing ideas into the wild open.

[DaleStan]

Ah. The standard escape route. "I didn't mean 'you' specifically, I only meant 'someone who isn't me'!"

Newsflash: No one work on this project (nor any other) unless that person believes the project has a reasonable chance of providing a good return on the labour.

Since I've seen exactly one person who seems to think this is project is worth the time required, that one person is the one who needs to make it happen. Or does that one person only think it's worthwhile if it's someone else's time that gets wasted?

[Core Xii]

But consider that it takes someone who is already familiar with the project seriously less resources to do it than me.

I'll have a look at it but definitely won't promise anything. There isn't even a main.c, I'm not sure where to begin. Doesn't seem to be any "summary" of the engine either.

[Rubidium]

Drawing means viewport business, so viewport.cpp is the place to start.

[Core Xii]

Right, but it's not much help locating the place that needs reworking if I don't know how to compile the whole thing. ttd.dsp referenced in the wiki is missing and it's quite a mess to figure how to compile it manually.

[d3x_Dark]

Maybe this will help:

I have the same problem with C2D E6750, the CPU is allways at 50% usage (which means, that only one core is actually processing the Openttd, but it runs at 100%).

I started a game, where I constructed zounds of ships (1,700 or so) and the game went terribly slowly... I switched the ship pathfinding algorythm to YAPF and everything runs smoothly with CPU usage of 35%. This algorythm isn't recommended, but I don't know why, maybe it has some bugs in it, but I've played with it for 2 hours or so and the game didn't crash or anything, so I guess, it's ok.

Original and NPF algorythms for Ships slow the game down a lot, try this, if you have built lots of ships and maybe your problems will be solved...

I still can't fast-forward the game in windowed nor full-screen mode (unless I run another savegame, which has less vehicles in it), but the game runs fluently, and that's really all that matters to me...

[Rubidium]

Right, but it's not much help locating the place that needs reworking if I don't know how to compile the whole thing. ttd.dsp referenced in the wiki is missing and it's quite a mess to figure how to compile it manually.

If you would have looked at the 'how to' you could have seen that it was made for a version about 3 years ago, when OpenTTD was still C. Now OpenTTD is C++ and there was nobody with interest to update the Dev-C++ project file (nor the wiki).

[Core Xii]

Guess we're in a bit of a deadlock then, unless someone's willing to bring all the info up to date.

[Rubidium]

There are about 4 other ways to compile under Windows that are supported:
- cygwin + gcc
- mingw + gcc
- MSVC 2005
- MSVC 2008

[Core Xii]

I'd still need to know what to include.

[Rubidium]

The multithreaded multicanvas rendering.

[DaleStan]

I'd still need to know what to include.

You mean, besides what the up-to-date wiki pages for those four compilers say you need?

[CMircea]

Original and NPF algorythms for Ships slow the game down a lot, try this, if you have built lots of ships and maybe your problems will be solved...

Unless YAPF does some magic stuff there, I find it very slow for ships, same for NPF. The problem is that unlike other vehicles, ships can take an ultra mega gazillion number of routes, since every water tile is like a tile with rails is every possible direction. Now go and calculate the best path through possibly a few million tiles in big maps. Good luck. The old pathfinder just gets a simple route there, yes, it can be VERY VERY bad, but it's done very fast.

I still can't fast-forward the game in windowed nor full-screen mode (unless I run another savegame, which has less vehicles in it), but the game runs fluently, and that's really all that matters to me...

Unless you enable the 32bpp blitters or set the color to over 8bpp, OTTD, in full-screen, switches to 8bpp, and that is MUCH faster than doing it in 32bpp, which in windowed mode isn't possible. Now, what slows this further down on both, is the full animation as palette cycling isn't that fast currently. Just disable it, you won't see everything so smooth and water won't animate, but it will run a LOT faster.

[Core Xii]

The multithreaded multicanvas rendering.

I meant what headers/libraries to include.

You mean, besides what the up-to-date wiki pages for those four compilers say you need?

You mean like these? None of them tells what to include in a generic, non- compiler-specific compilation, or where to start (equivalent of main.*).

[DaleStan]

I meant what headers/libraries to include.

Include for what?

(equivalent of main.*).

Yeah, there's no main.*. Because there are at least 3 different main()s, each in a different file. That's why you look more closely at the filenames (think about the name of the project for a bit), or the output of grep, or the doxygen, or the advice that Rubidium already gave you.

[Core Xii]

I'm not going to study an entire game engine based on source code alone.

[Rubidium]

I'm not going to study an entire game engine based on source code alone.

Didn't I tell you exactly what file does the actual drawing and sorting of the sprites, the part that you think benefits a lot when being multithreaded?

[Core Xii]

It's not much use coding something if I can't test it.

[d3x_Dark]

Unless YAPF does some magic stuff there, I find it very slow for ships, same for NPF. The problem is that unlike other vehicles, ships can take an ultra mega gazillion number of routes, since every water tile is like a tile with rails is every possible direction. Now go and calculate the best path through possibly a few million tiles in big maps. Good luck. The old pathfinder just gets a simple route there, yes, it can be VERY VERY bad, but it's done very fast.

I didn't read much about these algorythms, but I'm just saying, what the game does... And the fact is, that the YAPF works a lot faster for me. But it's probably because of the low sea-level, I'm using in most of the maps...

Unless you enable the 32bpp blitters or set the color to over 8bpp, OTTD, in full-screen, switches to 8bpp, and that is MUCH faster than doing it in 32bpp, which in windowed mode isn't possible. Now, what slows this further down on both, is the full animation as palette cycling isn't that fast currently. Just disable it, you won't see everything so smooth and water won't animate, but it will run a LOT faster.

About the 32bpp, I have 8bpp in both, windowed and full-screen mode and the game runs the same in both modes. I used to have 32bpp in windowed mode, but the game was running terribly slow, so I switched to 8bpp and everything's fine, even with a windows resolution 1600x1200 (fact is, that the resolution hasn't got almost any effect on the performance, the game runs the same in 640x480 as it does in 2048x1536). And as far as I've tested it, the full animation feature has nothing to do with game performance whatsoever, it doesn't matter, how many animated things there are at the same time on the screen, or in the map overall... I do have a good graphic card, GeForce 8800 GTX (and yet I'm playing this 15-year old game! ;)), but of course I'm aware, that OTTD performance has nothing to do with graphic accelerators...

Maybe you have diffierent experience with what helps and what doesn't, but this is how my OpenTTD on my PC works and if someone has performance problems with a game filled with ships, "maybe this will help", as I stated in the very beginning...