- User Since
- May 10 2022, 1:35 AM (82 w, 12 h)
Jan 31 2023
I wrote this primarily in order to use it for writing D4775 with sensible member names.
@phosit I removed the emergency GC because the JS engine already does that when it hits 100%. I don't think there is anything to be gained by running it at 75%. That's just throwing away 25% of the JSContext ram.
Jan 9 2023
@Stan No, i didn't change the logic from what it was before regarding overwriting m_ComponentsByInterface
Jan 3 2023
Seems to me you overwrite m_ComponentDataByInterface with the latest constructed component.
Sorry, my mistake. I should have said that the interfaceId allows the wrapped version to be used seamlessly with the core logic. It does not enable using the compiled version with one entity and a wrapped version for another. It allows wrapping components in general, which then must be used by all entities. I agree that it seems logically suspicious, but I haven't thought of a way around it.
Dec 28 2022
@phosit There are two containers because there are two id numbers per component type: ComponentTypeId and InterfaceId. InterfaceId can be thought of as component type category. If for example a mod provides a custom position component for some unit types that replacement component would have the same InterfaceId as the original position component but a different ComponentTypeId. This allows messages for the position component to be passed to either the original or the custom version.
Dec 23 2022
Components are stored in the ComponentDataHolder, which is used in ComponentDataByInterface.
Dec 22 2022
- I agree but I don't know how to write it that way.
- Unless I am misunderstanding you that is already the case.
Nov 23 2022
Nov 4 2022
Nov 3 2022
Nov 1 2022
@lyv Right, we cannot use player id here, only client id.
Change clientId to client in comment.
Oct 31 2022
@vladislavbelov Ah, right.
Oct 30 2022
Oct 29 2022
Last commit was a mistake, this one reverts it.
Oct 27 2022
@Stan Ok. I'm in the pacific time zone and usually available around noon.
Oct 26 2022
This is where the tradeoff between animation lag and simulation lag is: under high load we must allow frame rate to drop in order to maintain simulation speed. I have a plan in mind for running dynamically budgeted slices between animation frames to keep frame rate up under less stressful situations but haven't prioritized it because if we can thread simulation there is no need for it.
Oct 24 2022
I'm still fairly confused.
I'm now confident that my previous speculation was correct and that we don't have a problem here. @elexis thought that clientId isn't being sent with each command message but it is, it's just unlabeled.
I'm not entirely sure what you're referring to here
Oct 23 2022
Tested by running two instances. Seemed to work fine, but I can't test a situation where multiple players are issuing commands on the same turn that way.
Oct 22 2022
Elexus pointed out to me that this could break determinism via order of command processing. A deterministic sort of all commands each turn would be required to resolve it. I'm currently thinking the best option is to sort by the raw text of the commands by storing them in a priority queue.
Wrong diff command.
wrong diff command.
Oct 21 2022
wrong diff command again.
wrong diff command?
Wrong diff command?
Don't know what the problem is here, I'm generating the diff the same way I always have...
Change host to clientId in log in NetClient.cpp.
Change host to clientId in log in NetClient.cpp.
Moved slice call to turn manager.
Oct 20 2022
Hey all, sorry to take so long to get back to you.
Sep 15 2022
No worries, do you need me to upload again?
Sep 13 2022
Added time units (seconds, milliseconds) to variable names.
Aug 27 2022
Space after if.
Aug 26 2022
changed 1 to 1u, updated copyright year.
Aug 21 2022
Removed m_LastGCTime, changed a comment, added gcInProgress.
Aug 18 2022
What about the comment on timer_Time?
changed some int to u32
Didn't mean to submit yet, diff isn't ready, sorry.
Not a problem at all, I appreciate the time you put in to get it right :)
Aug 15 2022
uint32_t changed to u32.
Ok, that's another task to add to the to-do list then. It should give a significant result in terms of graphics smoothness as well as freeing up some more time for simulation to run.
Since the patch is about timing i don't see how to test it without introducing a race condition.
uint32_t changed to u32
Aug 14 2022
Add some includes, use timer_Time.
Reduce simulation thread load by ~10% (maybe a bit less, can't think of a way to test) and network traffic by 10-18%, depending on player APM. 500ms indeed sounds like too much. But 200 might have been an over-correction. The difference from 2 turns per second to 5 turns per second is ~1/3 second, but the difference between 5 and 4 is 1/20 second. I think this is small enough to not make a big difference.
Aug 13 2022
Changed type of gcPressure to double, changed type of gcBytes and gcMaxBytes to uint32_t, as well as m_HeapGrowthBytesGCTrigger and m_LastGCBytes. Added some const. Edited some comments.
Slice runs fewer times because it's time budget is typically higher. The total amount of RAM consumed should remain the same.
Replaced the constant 200 with the variable turnLength in Simulation2.cpp. Edited comment.
Space after if.
Copyright year, trailing white space, comment format.
Aug 12 2022
Use range based loop in graphics/mapWriter.cpp
Aug 10 2022
No I haven't tested multiplayer.
Formatting, range based looping, avoid stack allocation in Game::IsFinished.
Aug 9 2022
I haven't deeply read the code for source/lib/allocators/* or the code which uses them so I don't know.
changed range based loop to std::for_each in destructor.
Aug 8 2022
@Stan some of it will be coming from avoiding unnecessary copying, passing by reference. The theoretical complexity cost of removing the capacity limit is negligible. I would want to do more runs and average them together before I trusted that number to mean anything beyond that it hasn't gotten any worse. But I'm too tired to do that right now.
@Stan %12.7 👍 (based off one run)
Hello @jprahman, thank you for your help! I think there is more performance to be found, some in network and some in SpiderMonkey GC. Hopefully some more in territory calculations. After those we may want to try multi-threading. A lagless TG might be possible :)
Added more tests, made ComponentDataHolder::Pools return a reference, renamed AllocFunc to ConstructFunc, use for_each in ComponentDataHolder::Destruct, use range based loop in ComponentManager::ResetState.
Jul 28 2022
version control fail.
Changed uint_32 types for vector indices to size_t. Supposedly the type should be std::vector<std::byte*>>::size_type, but I haven't been able to get that to work.