Update on Progress

[vorpal+5]

On launch, there will be resolution requirement of 1400 x 900. I might create a small version of some windows in the future but I'm not sure how many current laptops still use 1366 x 768.

According to Steam HW survey it seems that about 14% of all gamers run resolutions below 1400 x 900 for November 2019 ( Although shrinking every month with 2560 x 1440 gaining users the fastest ).

https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam

Latest survey tells also that only 1.14% of users have only 1366x768

[vorpal+5]

(..)
Considering that C# Aurora is doing far more work than VB6, I am more than happy with the current performance. I've been playing Battletech recently and the AI mechs literally take about 10 seconds each to decide where to move and fire

Awesome performance indeed. I have read in the BT forum, from one of the main modder of Rogue Tech that the AI in BT is very slow because it makes a systematic analysis of all possible moves for each mech and vehicle. And the faster the mobile, the more it becomes computational intensive.
Clearly some AI programmers went with the brute force approach 

[alex_brunius]

Latest survey tells also that only 1.14% of users have only 1366x768

Odd. My list shows over 10%.

[Kiri]

There is a 1360x768 and 1366x768, curious:
1360 x 768 : 1. 63%   -0. 03%
1366 x 768 : 10. 79% -0. 34%

according to that list ~15. 44% of steam gamers have a primary display resolution of smaller then 1440x900 with the two thirds of those using 1366x768.

It is a long time since I saw anything below 1920x1080, so I am surprised about those smaller things still being sold as one poster send previously.

[Jorgen_CAB]

At some point you just have to deal with the fact that you can't deal with it or in this case small monitors if it means you feel constrained in the development area and need to cut your losses. Such resolutions is really low today.

If it mean additional development time and compromises needs to be made I don't think catering to such low standards are really meaningful.

If it on the other hand can be relatively simply "fixed" then why not.

[QuakeIV]

I mean even if its the same window but with scroll bars on both axes to let you pan it around, most laptop people would probably accept that as a decent attempt at accommodating them.

[papent]

I second the scroll bars on both axis, for the smaller screen resolutions. My travel laptop has X768 resolution because it is ultraportable and the impression i get from browsing electronic shops near me that a lot of small form factor laptops are still stuck at the low resolutions. 

[Tuna-Fish]

The main time sink is movement orders. There are currently 316 fleets underway with a total of 1047 outstanding orders. While acting on those orders for all 316 fleets only takes about 0.05 seconds, in a one day turn there are 48 increments, each with a movement phase.

And if that ever starts to feel too much of a drag, I think the movement orders might be a decent target for parallelization. Assuming that fleets do not mess with the data of other fleets not in the same system, it might boil down to splitting the list of all fleets into a map of systems to lists of fleets in each system, and then using Parallel.ForEach on the map. Transitions between system might require an extra step, and if fleets do look up the data of other fleets not in the same system while moving, everything gets a lot more complicated.

[Steve Walmsley (OP)]

The ultimate issue is that Aurora is a hobby project designed for a large, multi-monitor PC desktop. It was never intended to function on a small screen. It's not a commercial project so I am not trying to make it compatible with as many different setups as possible.

C# is more flexible than VB6, but realistically I need to either design separate windows to fit the smaller resolution, or include code that resizes and moves everything around on the existing windows. Then I need to remember to include the 'small window' changes every time I change something.

Again, this is a hobby project, so I tend to work on the functionality that appeals to me most. I'm not saying I won't tackle smaller windows at some point, but it don't be a priority over something like Diplomacy, especially as the proportion of sub 1400x900 laptops is relatively small and presumably shrinking over time.

[Steve Walmsley (OP)]

The main time sink is movement orders. There are currently 316 fleets underway with a total of 1047 outstanding orders. While acting on those orders for all 316 fleets only takes about 0.05 seconds, in a one day turn there are 48 increments, each with a movement phase.

And if that ever starts to feel too much of a drag, I think the movement orders might be a decent target for parallelization. Assuming that fleets do not mess with the data of other fleets not in the same system, it might boil down to splitting the list of all fleets into a map of systems to lists of fleets in each system, and then using Parallel.ForEach on the map. Transitions between system might require an extra step, and if fleets do look up the data of other fleets not in the same system while moving, everything gets a lot more complicated.

As you mentioned, fleets can change systems during a turn, possibly more than once. They also move in order of initiative (reaction in C#). Movement is very complex already with over a hundred different order types, plus I would need to share data across threads, track new ID assignments, etc, and each thread adds a small overhead. Multi-threading is also much harder to debug. Given the relatively small potential benefit, I don't want to spend time on that extra complexity in preference to adding functionality. Finally, the movement code is setup to cycle by fleet, not system, so it would require extensive re-coding anyway.

[dr125]

The ultimate issue is that Aurora is a hobby project designed for a large, multi-monitor PC desktop.  It was never intended to function on a small screen.  It's not a commercial project so I am not trying to make it compatible with as many different setups as possible.

C# is more flexible than VB6, but realistically I need to either design separate windows to fit the smaller resolution, or include code that resizes and moves everything around on the existing windows.  Then I need to remember to include the 'small window' changes every time I change something.

Again, this is a hobby project, so I tend to work on the functionality that appeals to me most.  I'm not saying I won't tackle smaller windows at some point, but it don't be a priority over something like Diplomacy, especially as the proportion of sub 1400x900 laptops is relatively small and presumably shrinking over time.

I completely understand, this is after all your project.  Though if possible, the scroll bar at least on the surface seems like a relatively easy addition compared to redesigning the windows in total. 

[Steve Walmsley (OP)]

The ultimate issue is that Aurora is a hobby project designed for a large, multi-monitor PC desktop.  It was never intended to function on a small screen.  It's not a commercial project so I am not trying to make it compatible with as many different setups as possible.

C# is more flexible than VB6, but realistically I need to either design separate windows to fit the smaller resolution, or include code that resizes and moves everything around on the existing windows.  Then I need to remember to include the 'small window' changes every time I change something.

Again, this is a hobby project, so I tend to work on the functionality that appeals to me most.  I'm not saying I won't tackle smaller windows at some point, but it don't be a priority over something like Diplomacy, especially as the proportion of sub 1400x900 laptops is relatively small and presumably shrinking over time.

I completely understand, this is after all your project.  Though if possible, the scroll bar at least on the surface seems like a relatively easy addition compared to redesigning the windows in total.

That is what I tried in VB6 before creating the smaller windows. I remember it being a lot harder than it sounded

The best idea I can think of is some hot keys that give a window negative coordinates, so you can just move the window relative to your desk top without scroll bars or re-designed windows. If I could get that to work, that would be a lot easier because I would never need to update it.

[dr125]

That sounds like the best of both worlds, easier for you and playable by many more regardless of resolution. 

[TMaekler]

How about the issues in terms of language and windows settings? Will we still need a launcher to use Aurora on other settings than UK, or will these be gone because of C#?

[Steve Walmsley (OP)]

How about the issues in terms of language and windows settings? Will we still need a launcher to use Aurora on other settings than UK, or will these be gone because of C#?

TBH I have no idea. Until you mentioned it, I hadn't thought about it