Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Note: this post will not display until it's been approved by a moderator.

Name:
Email:
Subject:
Message icon:

shortcuts: hit alt+s to submit/post or alt+p to preview

Please read the rules before you post!


Topic Summary

Posted by: DuraniumCowboy
« on: August 04, 2017, 09:31:00 AM »

Quote
I know, and the latency is better too, but I was wondering if he went from HDD to NVMe or SATA SSD to NVMe. An SSD is plenty faster than HDD, but the game still got slow. I even tried it on a RAMdisk once (DDR3) and even that did not help

I had a middle grade SSD, a Crucial drive.

Another thing with SATA vs NVMe, is that SATA was designed for spinning disks, so NVMe is the first real standard designed to handle non sequential IO.  My benchmarks show almost x5 IO performance over my old SSD.  Of course, a lot of that likely gets bottle necked somewhere else, as you are at that point sucking out data faster than anything else can really handle.  Still, I was wondering if the ability to parallel, small IO might make database IO better and thus improve turn times.  Or then again, maybe its placebo effect :)
Posted by: Frick
« on: August 03, 2017, 12:16:53 AM »

Worth noting the NVMe is a PCI-e SSD, while your own (and mine) are SATA.

While a SATA SSD still has incredible throughput a PCIE-e SSD is currently the fastest available on the market.  Can often be twice as fast as a SATA.

I know, and the latency is better too, but I was wondering if he went from HDD to NVMe or SATA SSD to NVMe. An SSD is plenty faster than HDD, but the game still got slow. I even tried it on a RAMdisk once (DDR3) and even that did not help.
Posted by: Retropunch
« on: August 02, 2017, 05:06:36 PM »

Whilst I'd obviously like to see as shorter save time as possible, I honestly believe that the most important thing is avoiding in game slowdown and stability.  If it means that saving and loading take a bit longer then I'm fine with that.

Saving and loading are infrequent actions, and they're ones that you can basically be doing other stuff with.  We're not in the days of computers only being able to run one program at a time - checking a few emails whilst it's saving isn't going to kill me, but 5 minute turn times will!
Posted by: Shuggana
« on: August 02, 2017, 10:25:43 AM »

Quote from: Frick link=topic=9117. msg103773#msg103773 date=1501604745
What did you have before? I've run the game solely on SSDs (Crucial BX100/200) for a while now and it still gets really slow after a while.

Worth noting the NVMe is a PCI-e SSD, while your own (and mine) are SATA.

While a SATA SSD still has incredible throughput a PCIE-e SSD is currently the fastest available on the market.  Can often be twice as fast as a SATA.
Posted by: Frick
« on: August 01, 2017, 11:25:45 AM »

On a hardware note, I just upgraded to a high end NVMe SSD drive.  Wow, it makes a difference for all the IO in the game.

What did you have before? I've run the game solely on SSDs (Crucial BX100/200) for a while now and it still gets really slow after a while.
Posted by: Steve Walmsley
« on: July 28, 2017, 01:15:14 PM »

I do a lot of manual editing of the data (especially while programming), so a database makes this much easier.
Posted by: Bughunter
« on: July 28, 2017, 12:39:25 PM »

I don't think the game is structured that way that it could easily handle the full game state in a serializable object, so could be a pretty big change. It rather does several small writes at different times like every time you change something from the gui. For this kind of use a db is actually not bad.. except for the fact that it is (was) Access in this case which is always bad.
Posted by: aimtec
« on: July 28, 2017, 08:39:00 AM »

i dont understand why u would have to use a database for savegames

the easy way is to just use the 'System.  Runtime.  Serialization.  Formatters.  BinaryFormatter'
- create a class 'Savegame' which contains all the objects u want to save
- this class and every class of every object inside this class has to be marked with [Serializable]
- use the binaryformatter to save an object of 'Savegame' into a file
you could even throw everything into an object array and serialize that, but having a 'Savegame' class makes it more readable and adjustable for the programmer

Posted by: DuraniumCowboy
« on: July 19, 2017, 05:33:03 PM »

On a hardware note, I just upgraded to a high end NVMe SSD drive.  Wow, it makes a difference for all the IO in the game.
Posted by: Sappersquid
« on: July 18, 2017, 07:15:45 PM »

If the coordinate issue is strongly in doubt, I would strongly recommend not going polar.   Due to the vast scale difference, truncation and handling of floats at large distances gets to be a mess.   This is one reason KSP originally had to have such small system, and even then, issues with fluidity at high values still caused issues.   Quill18 has a good tutorial about procedural star system creation that really discusses this.   By using integer Cartesian you can avoid that.   You just do you gloat point trig and then cast final results back into integer.
Posted by: Bughunter
« on: June 19, 2017, 07:46:48 AM »

Steve said above he is already using SQLite for the C# version. While I never worked with the embedded version of MySQL I imagine it would be similar, but there seems to be a catch to "free". Looking at the MySQL webpage I think Steve would have to either get a commercial licence from Oracle or release Aurora under GPL. This would be in line with how it works for the regular MySQL server. This also explains that SQLite seems to be a much more popular choice for hobbyist/indie development I guess.
Posted by: tenim
« on: June 17, 2017, 05:07:55 AM »

sqlite is in fact the best solution for c# aurora

4 reasons

* sqlite is the fastest db available (yes, even faster than mysql)
* no need for installing a database server (for all other db-systems like mysql, postgres, oracle this is mandatory), only a dll is needed. 
* very easy sql dialect, recursive cte´s are possbile
* sqlite is public domain

i´m working >17 years with access, sqlite and ms-sql and sqlite is by far the easiest one.   the sql-syntax is very gentle and you can do things easy, which are not possible in ms-ssql or jet-sql
* i.  e.   you can "group by" a column which is in the select a aggregate with the "AS" keyword and there is no need to rewrite the complete aggreate, the alias is enough
* you can group by a single column and there is no need to enumerate all other columns from the select statement like ms-ssql it forces, because this is complete pointless -the result doesn´t
   canges after the first grouped column
* recursive cte´s.   it´s fantastic.   i had a sql-query which builds a tree of items and the longest runtime was appr.   30 seconds.   after the rewrite to recursive variation the runtime was 4 seconds!

tenim
 
 


 
Posted by: littleWolf
« on: June 15, 2017, 04:37:32 AM »

free save is EVIL..   play roguelike (ironmode) :)
Posted by: MagusXIX
« on: June 15, 2017, 03:31:57 AM »

***EDIT** I read through everything (shame on me for not doing that first) and saw that this was covered already, at least a little. Sorry for asking twice. Disregard and carry on.

There is no writing to disk during play - only when you press the Save button.

Would it be too much to request an autosave option/feature? Perhaps every production cycle, or once a month? At least once a year, if possible, please.

I'm the sort of person who is going to forget to press the save button. Every. Time.
Posted by: Senji
« on: June 15, 2017, 01:40:28 AM »

Why you didn't use an in-memory DB ?
You'll make your executions more quickly and one save in file (and you can change the save at every save if you want ^^ )

If you already use it, sorry for the interruption ^^