C++
Moderator: OpenTTD Developers
C++
Since my report that opening new windows can cause old ones to be closed was marked as "not a bug", I've been looking into re-designing the window system to get rid of this limitation.
Would re-writing the windowing system in C++ be acceptable? Doing so would get rid of some of the awkward bits currently in there, like the use of the WP() macro and and the dependancies on pointer size and structure padding.
Would re-writing the windowing system in C++ be acceptable? Doing so would get rid of some of the awkward bits currently in there, like the use of the WP() macro and and the dependancies on pointer size and structure padding.
There is a branch for this, it's called cpp_gui IIRC.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)

OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone

OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone







- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
XeriusTC is right. The effort is already underway. Branch cpp_gui.
As the name implies, it is doneby changing actual C based gui system to a more elaborate c++ version.
Not just a simple limit would suffice. Redo the whole thing, the right way.
As the name implies, it is doneby changing actual C based gui system to a more elaborate c++ version.
Seeing at how the branch is going (although it may seems dormant right now), i would say it does not look so easy.My plan is to remove the limit entirely. It's not hard.
Not just a simple limit would suffice. Redo the whole thing, the right way.
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
I think your copy/paste system is broken. You might want to look into that.belugas wrote:XeriusTC
And how is "realloc the window stack every time you run out of space" either inappropriately simple or too hard?belugas wrote:Seeing at how the branch is going (although it may seems dormant right now), i would say it does not look so easy.My plan is to remove the limit entirely. It's not hard.
Not just a simple limit would suffice.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Well, now that I've looked at the existing code, removing the limit still looks easy. Injecting sanity into the GUI class hierarchy, on the other hand, looks hard.belugas wrote:XeriusTC is right. The effort is already underway. Branch cpp_gui.
As the name implies, it is doneby changing actual C based gui system to a more elaborate c++ version.
Seeing at how the branch is going (although it may seems dormant right now), i would say it does not look so easy.My plan is to remove the limit entirely. It's not hard.
Just removing the limit gives some unwanted sideeffects like asserting when it tries to open too many viewports. This should really be done the right way.Carnildo wrote:Well, now that I've looked at the existing code, removing the limit still looks easy. Injecting sanity into the GUI class hierarchy, on the other hand, looks hard.
There is some issue with _active_viewports (in viewport.cpp) being a bitmask (so no more windows are possible than bits in the bitmask, which means 32 for int32 or 64 for int64)Bjarni wrote:Just removing the limit gives some unwanted sideeffects like asserting when it tries to open too many viewports. This should really be done the right way.Carnildo wrote:Well, now that I've looked at the existing code, removing the limit still looks easy. Injecting sanity into the GUI class hierarchy, on the other hand, looks hard.
I have submitted patch that changed the limit to 60 from 25 (http://bugs.openttd.org/task/925) - it's not unlimited, but raises the limit considerably and is near maximum you can get without some larger rewriting or assertion bugs (aka it worked without problems).
60 should be enough to bridge the limit till someone rewrite the thing completely ...
However, the patch has not been (yet) accepted, but you are still welcome to apply it yourself, test it and if you find any bug, report it (best to do it in the bugtracker directly).
If you need something, do it yourself or it will be never done.
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
Sorry XeryusTC... I can't get that Y into place, it seems...DaleStan wrote:I think your copy/paste system is broken. You might want to look into that.belugas wrote:XeriusTC
Because it is not simply a matter of reallocating the window stack. It does a lot more. Please look at the branch to find outDaleStan wrote:And how is "realloc the window stack every time you run out of space" either inappropriately simple or too hard?

Simply reallocating the window stack is not the right thing to do, here. A new kind of stacking is required. Like what we did for XTDWidget. We could have simply incraesed the limit of widgets per window from 32 to 64. Instead, we made it so that the windows do now have an unlimited number of widgets. THAT is the right approach
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Maybe best will be to increase the limit, then go working for rewriting the code to remove the limit at all ... before the final rewrite is done, at least temporary remedy exists ....belugas wrote: 32 to 64. Instead, we made it so that the windows do now have an unlimited number of widgets. THAT is the right approach

If you need something, do it yourself or it will be never done.
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
-
- Engineer
- Posts: 123
- Joined: 16 Nov 2006 16:52
- belugas
- OpenTTD Developer
- Posts: 1507
- Joined: 05 Apr 2005 01:48
- Location: Deep down the deepest blue
- Contact:
Nope. History shows that temporary fixes have a very long life... So unless the fix is the good one, do not mess around with bogus fixesBilbo wrote:Maybe best will be to increase the limit, then go working for rewriting the code to remove the limit at all ... before the final rewrite is done, at least temporary remedy exists ....

Sorry
It really should not. Rest assureTomsomethingcon wrote:wouldn't being able to open more windows, slow the game engine down, more ?
[Edit] On second thoughs, it might take a slightly bigger chunk of cpu cycles. But as to know if it would be noticeable, i guess only time will tell[/Edit]
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
Well, if the fix is made good, game will slow down only when so many windows are actually opened and something (like a vehicle) is moving in it.Tomsomethingcon wrote:wouldn't being able to open more windows, slow the game engine down, more ?
just my thought
If you open huncerds of windows with vehicles, you can expect some slowdown ... till you close them

If you need something, do it yourself or it will be never done.
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
Who is online
Users browsing this forum: No registered users and 12 guests