Author Topic: Aurora C# Screenshots  (Read 145793 times)

0 Members and 1 Guest are viewing this topic.

Offline GodEmperor

  • Commander
  • *********
  • Posts: 312
  • Thanked: 30 times
Re: Aurora C# Screenshots
« Reply #60 on: March 24, 2016, 06:28:25 AM »
No. It'll still exist. Performance will continue to  fall as there are more ships, and NPC and inhabited planets to account for.  How much it'll slowdown is the question. And it may still be by a lot.
Well of course there will be slowdown but the problem is the scope of it.
There is a difference between game where it gets pre-mortem spasms once more than ten systems are explored and one NPR is discovered and a game where you can have two hundred systems with seven NPR's with some slowdowns.
."I am Colonel-Commissar Ibram Gaunt. I am known as a fair man, unless I am pushed.
You have just pushed me."
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Aurora C# Screenshots
« Reply #61 on: March 24, 2016, 02:59:42 PM »
You would see benefits on all machines, not just new ones.  The the main problem seems to be that he is storing everything on the hard drive right now.  That slows things down massively.

Any machine with RAM (which is all machines that are able to function at this point) should notice significantly improved performance due to the much faster memory lookups.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Aurora C# Screenshots
« Reply #62 on: March 24, 2016, 03:28:37 PM »
It should be a lot faster - not only because of the switch to RAM - but also because of C# will be able to use modern CPU/GPU structure. If Steve can get it to use GPU computation power you would need a 10.000 system galaxy and several hundred NPRs to start feeling a slowdown.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Aurora C# Screenshots
« Reply #63 on: March 24, 2016, 04:28:48 PM »
He would need to do a total rewrite specializing it to GPU computation, and it would be limited in the number of GPUs it could work on.  I doubt he will be doing that.
 

Offline jem

  • Warrant Officer, Class 2
  • ****
  • j
  • Posts: 50
  • Thanked: 4 times
Re: Aurora C# Screenshots
« Reply #64 on: March 24, 2016, 04:54:54 PM »
He would need to do a total rewrite specializing it to GPU computation, and it would be limited in the number of GPUs it could work on.  I doubt he will be doing that.

You have a lot of that already built into the libraries and the compilers. Sure it is not as effective as hunting bytes in basic but it is going to be a big difference.
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Aurora C# Screenshots
« Reply #65 on: March 24, 2016, 05:57:58 PM »
Yep, there are libraries who give you that functions. But it might be a pain to realize... .
 

Offline sloanjh

  • Global Moderator
  • Admiral of the Fleet
  • *****
  • Posts: 2805
  • Thanked: 112 times
  • 2020 Supporter 2020 Supporter : Donate for 2020
    2021 Supporter 2021 Supporter : Donate for 2021
Re: Aurora C# Screenshots
« Reply #66 on: March 25, 2016, 10:32:04 AM »
You would see benefits on all machines, not just new ones.  The the main problem seems to be that he is storing everything on the hard drive right now.  That slows things down massively.

Any machine with RAM (which is all machines that are able to function at this point) should notice significantly improved performance due to the much faster memory lookups.

Steve did a pass several years ago where turn processing happens in memory, and the results are stored to DB at the end of the turn, so I don't think this is the (primary) problem.  AFAIK, there are two issues:

1) Sensor detection ("is A within B's detection radius") is an N^2 algorithm (where N might even be the number of ships, not TG), and everything else is at least linear.
2) The intercept/movement algorithms are not set up to only go to smaller time steps for movers that need them.  In a perfect world, the future paths of all movers would be calculated as curves in space-time that terminate when they reach their current destination.  The program would then look for points where these curves pass within detection range of each other to figure out how big the next time step should be (allowing bigger time steps).  If the close approach event is a non-interrupt event, none of the movers should be updated - things should just go to the next close approach point.  If it is an interrupt, only those movers whose orders change should be recalculated (in terms of the curve + intersection analysis) - the rest of the movers should be left alone.  This would cut down on a subtle N^2 (or possibly worse) where each event costs O(N) of processing time, and the more ships exist, the shorter the time between events.  This would be VERY complicated to code up though, especially working out the math for planetary intercepts.  In actuality, for each increment a time step size is chosen to be some fraction of the turn length, then analysis is performed to see if a smaller time step is needed (especially if missiles are flying).

I don't foresee either of these issues being fixed by the transition to C#.  I'm not sure if/how the Pulsar crowd is handling issue #2.

OTOH, it is impossible for Steve to take advantage of multi-threading with VB6.  The detection/intercept code has lots of opportunities for parallelism though, so he should be able to easily take advantage of multi-threading by e.g. using the thread pool.  If Steve could use the GPU for the "is A in detection range of B" calculation, then it MIGHT also give a big boost, but that's a lot harder and more iffy.

John
« Last Edit: March 25, 2016, 10:41:29 AM by sloanjh »
 

Offline TMaekler

  • Vice Admiral
  • **********
  • Posts: 1112
  • Thanked: 298 times
Re: Aurora C# Screenshots
« Reply #67 on: March 25, 2016, 11:07:04 AM »
There are certain "static" things which might be calculated while the user is interacting with the game. Precomputing some things in the background. These precalculations (like positions of planets, asteroids, etc.) could then simply be used to shorten the calculation time during time forwarding.
 

Offline db48x

  • Commodore
  • **********
  • d
  • Posts: 641
  • Thanked: 200 times
Re: Aurora C# Screenshots
« Reply #68 on: March 25, 2016, 03:56:43 PM »
Those are all great ideas, but as a programmer myself I'd hate to speculate on where most of the time is spent. (Except that we know detection is a large part of it or there wouldn't be so many options for tweaking how that works :)

Profile first, then optimize.
 

Offline Shuul

  • Sub-Lieutenant
  • ******
  • S
  • Posts: 108
  • Thanked: 28 times
Re: Aurora C# Screenshots
« Reply #69 on: March 26, 2016, 06:59:28 PM »
Is it possible that this new version will make possible to play without the need to install some libraries etc.?
As I dont have admin rights on my laptop and have like 70% of work time in business trips i would really appreciate this addition.
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Aurora C# Screenshots
« Reply #70 on: March 26, 2016, 11:07:50 PM »
There's usually a compiler setting to include all the needed libraries, I think that can really baloon an executable file though.


e:  Also not sure if that would work in this context or not.
 

Offline Steve Walmsley (OP)

  • Moderator
  • Star Marshal
  • *****
  • S
  • Posts: 11672
  • Thanked: 20455 times
Re: Aurora C# Screenshots
« Reply #71 on: March 27, 2016, 12:14:15 PM »
The first screenshot of the new class design window. Class design is now working within C# Aurora and as you can see, the class window has undergone a more radical overhaul than the tactical window. The main differences are:

1) All class types are now shown on the left in a tree view, organised by hull type. You can filter obsolete and civilian designs
2) Available Components are also in a tree view, organised by component type. You can open and close sections as needed. Scrollbars will appear if needed. You add new components using this tree by double-clicking (amount based on radio-button selection).
3) You can flip between available components and components in the current design (see second screenshot). You remove components using this tree.
4) Instead of showing a line of details for each component, clicking on the component (in either Race or Class lists) shows a more detailed description in the lower centre.
5) The box to the right of the component description box is for design errors.
6) Any green text is editable, so you can change armour and deployment time, plus adjust the range bands and tracking speeds used to show the capabilities of beam weapons and beam fire controls.
7) A list of ships in the class is shown in the lower right. There will be a much more detailed list on another tab.
8) Many of the VB6 text boxes no longer exist on this view, either because they have been removed because they duplicate the main display, are no longer necessary, have been handled differently (lack of power is now a design error) or moved to a different tab (showing the crew calculation) because they are less important. This allows a much cleaner view with only the required information.

There are a few minor changes to class design.
1) Ships are no longer rounded to the nearest hull space
2) Range Modifiers are shown in full rather than a number. So in the case of this ship, a range modifier of 30,000 km means the weapon has a range of Max Damage x Range Modifier. The range was always calculated this way but not shown as obviously on the display
3) Internal HTK has been added to the display next to armour and shields
4) 'Damage Control Rating' is now DCR
5) The 'To Hit' chances (in the display) for beam fire controls are based on the Range Bands and Target Speed set on the right side of the window
6) Beam Weapon damage fall-off (in the display) is based on the selected Range Bands.

This window is still a work in progress but the design-related work is mostly complete. The results of class design (with the above exceptions) are matching VB6 Aurora. I need to add some other tabs, including fighter and ordnance assignment, more detailed component information, rank assignment, etc.. I'll post screenshots as I complete them.

One other interesting advantage of C# Aurora is that I have separated the data from the display, which means you can have multiple class design windows open at once :)


 
The following users thanked this post: Demonides, Xeno The Morph, QuakeIV, db48x

Offline Vandermeer

  • Rear Admiral
  • **********
  • Posts: 961
  • Thanked: 128 times
Re: Aurora C# Screenshots
« Reply #72 on: March 27, 2016, 03:56:41 PM »
The best thing about this for me is that the designs get sorted after classes. My last Tau based game I abandoned because I had so many different ship types created, that after some pause I could not find my way through the naming scheme anymore. With this it should be no problem anymore.
playing Aurora as swarm fleet: Zen Nomadic Hive Fantasy
 

Offline QuakeIV

  • Registered
  • Commodore
  • **********
  • Posts: 759
  • Thanked: 168 times
Re: Aurora C# Screenshots
« Reply #73 on: March 27, 2016, 05:35:47 PM »
The best thing about this for me is that the designs get sorted after classes. My last Tau based game I abandoned because I had so many different ship types created, that after some pause I could not find my way through the naming scheme anymore. With this it should be no problem anymore.

Complete agreement.
 

Offline Rich.h

  • Captain
  • **********
  • R
  • Posts: 555
  • Thanked: 55 times
Re: Aurora C# Screenshots
« Reply #74 on: March 27, 2016, 05:58:07 PM »
Very nice though I am curious about one thing. I have noticed that some of these (this latest example being a perfect one) are a blue background with white text. If that the way it will be for everyone with no alternative? I would much prefer an option to have as current a white sheet with black text.