Posted by: QuakeIV
« on: February 12, 2021, 01:55:47 PM »Notably that might up the complexity if he needs to formulate different task lists for the worker threads for each system.
This assumes that movement orders aren't inter-dependent to eachother, which as far as I know is true.
It would be interesting to know what is the main thin that slows down the game... my games usually slow down to 4-5 seconds and stay there for a rather long time. I don't think this is an issue or anything just would be interesting to know for future optimisation what is the main thing that slows down the game?
Movement orders is the greatest time-sink.
If you had an immortal Steve who spent all day pressing random buttons on his keyboard, how long would it take for any given feature to be added?
Alternatively, if you had an arbitrarily high but still finite number of Steve's randomly pressing buttons on his keyboards, how long would it take for one of the Steve's to add any given feature?
Yes, the basic coordinate system is in kilometres, but it goes down to 8 or 9 decimal places, so the position of a ship or any other object is known to fractions of a millimeter.
Exact weapon impact tracking when???
Yes, the basic coordinate system is in kilometres, but it goes down to 8 or 9 decimal places, so the position of a ship or any other object is known to fractions of a millimeter.
It would be interesting to know what is the main thin that slows down the game... my games usually slow down to 4-5 seconds and stay there for a rather long time. I don't think this is an issue or anything just would be interesting to know for future optimisation what is the main thing that slows down the game?
Movement orders is the greatest time-sink.
It would be interesting to know what is the main thin that slows down the game... my games usually slow down to 4-5 seconds and stay there for a rather long time. I don't think this is an issue or anything just would be interesting to know for future optimisation what is the main thing that slows down the game?
If everything were done using 64 bit integers, the minimum distance could be decreased dramatically!
Assuming everything is signed, 32bit integers can represent up to 2^31. At 10,000km spacing, that gives us a max distance from the center of the coordinate system (presumably the primary) of 2.3 lightyears. It's probably reasonable to want to be able to go at least a lightyear, so no less than 5000 km spacing is appropriate.
With 64bit signed integers, if we want to go 1 lightyear out, we can use a spacing of about 1mm.
Using 64bit integers, a game could theoretically track the exact impact position of every weapon battery based on the direction they were fired and the position of the weapon on the ship. Though, honestly, I might go with floats anyway since my expectation is that computers have more FPUs than integer units and so it would possibly be faster. And 64 bit floats have plenty of precision at reasonable distances. But I haven't tested it in detail.
I'm fairly sure from my explorations of the DB that distance is not limited by the integer size. Coordinates in the DB are stored as floats, and the actual space between ships is not constrained to being a multiple of 10,000 or any other value as far as I know (maybe 1 km). The 10,000 km minimum range is mostly an abstraction for gameplay purposes as well as a small compromise for some degree of realism (as literal 0 km range never occurs).
From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay. At that point 64-bit probably becomes much more economical since memory requirements would go up.
On the other hand multithreading would also boost it significantly although it would be much harder to achieve without breaking everything at this point in development.
The game only accesses the DB on load and on save. Everything executes in RAM only.
Multi-threading isn't useful because the game executes most actions in order, not simultaneously, because those actions depend on knowing other actions. For those things that could be executed simultaneously, such as orbital movement or detection, they are very fast anyway so adding the complexity of Multi-threading only really adds scope for hard-to-track bugs.
From what I understand the game spends around half it's time messing around with massive queries to the DB, if you want performance improvements I would advise optimizing there and loading more stuff direct to RAM during gameplay. At that point 64-bit probably becomes much more economical since memory requirements would go up.
On the other hand multithreading would also boost it significantly although it would be much harder to achieve without breaking everything at this point in development.
Quote from: Steve Walmsley link=topic=12430. msg148508#msg148508 date=1612654080Quote from: Star Watchman, of Yeshua link=topic=12430. msg148504#msg148504 date=1612652162Hello,
When can we get the 64-bit C# version of Aurora? I want to be able to build massive, massive, mega ships without limitations with like integers n stuff
Thanks
Sal
Could you help me by highlighting which data types have higher max values in 64-bit vs 32-bit?
um double, long, er um bigInteger
That's what I can think of off the top my head
(Lol you troll me too hard, some more memry would be cool)