Tue Mar 23, 2021 7:00 am
Tue Mar 23, 2021 10:38 am
Tue Mar 23, 2021 11:30 am
Tue Mar 23, 2021 12:43 pm
Tue Mar 23, 2021 1:37 pm
Graf Zahl wrote:Only if these actors were invisible to everything else and ran on their own stat queue that'd also have to be invisible/inaccessible to everything else.
Tue Mar 23, 2021 2:23 pm
MartinHowe wrote:theoretically, if demos are not needed (I never watch them nor record them) and for SP only
MartinHowe wrote:does the playsim still need to be deterministic and if so why?
Tue Mar 23, 2021 2:34 pm
Blzut3 wrote:Overall though if one were creating a Doom like engine from scratch I do think there's a lot that could be done differently from GZDoom to increase performance before even reaching for multithreading. One of the things I've heard of other engines doing is splitting actors into multiple objects in memory based on what values are used together so that CPU cache line utilization is higher and iteration is more predictable. For example you might have the x/y coordinates of an actor as a object so that 8 of them can fit into a cache line when trying to find actors within a radius. Certainly would be possible to retrofit something like this into GZDoom, but it would be a lot of work to do right.
Tue Mar 23, 2021 3:14 pm
Graf Zahl wrote:so time savings are doubtful.
Tue Mar 23, 2021 3:24 pm
Tue Mar 23, 2021 4:05 pm
Blzut3 wrote:Demos are actually useful for performance comparisons and debugging as well. For example a stubborn to reproduce bug might be possible to capture in a demo vs manually repeating the actions over and over again. I know this isn't the point of your thread, but people associating demos only for entertainment purposes is kind of a pet peeve of mine.
Blzut3 wrote:Have all actors independently, based on a read only snapshot of the world, decide what their "move" is for the tick (this "move" would include any damage inflicted on other actors), but instead of actually writing out the changes they would be placed onto a per thread queue. Then once everything has been decided one thread commits the changes dropping any conflicts.
Tue Mar 23, 2021 4:27 pm
MartinHowe wrote:On a general note, regarding motivation, I've been putting off buying a newer computer for ages as my current rig works fine for most things; playing mostly 1990s maps and a fewer more modern ones, you'd think dual 2008-era quad-core Xeons, 16GB of quad-channel server-grade memory, and a GF 550 Ti, on Linux so no MICROS~1 bloat to waste CPU cycles on, would have been enough. Then, this Sunday, I tried to play Planisphere 2 (
Tue Mar 23, 2021 11:25 pm
MartinHowe wrote:This is not quite what I would have imagined and is definitely more sophisticated that the 'nearly asynchronous with mutexes and such' I would have thought of; I have only once in my varied IT career written multithreaded code and that was using helper stuff in .NET, so all this is quite an eye-opener for me.
MartinHowe wrote:Looks like that lovely Ryzen 9 3950X I was thinking of buying, with 16 cores, won't help me that much against the Spawn of Hell
Wed Mar 24, 2021 12:57 am
Blzut3 wrote:MartinHowe wrote:Looks like that lovely Ryzen 9 3950X I was thinking of buying, with 16 cores, won't help me that much against the Spawn of Hell
Even as someone that loves playing with old hardware and making it do things it really shouldn't be doing, my advice is go mid range and upgrade twice as often. Since it's not really something that shows up in spec sheets people forget that the platform architecture as a whole evolves with the years, not to mention new instruction sets and IPC improvements. Obviously there's a limit to how far down the product stack this advice applies, but when it comes to the 3950X I do think that's in the territory of: if having 16 cores is not going to save yourself time today, don't buy it.
Wed Mar 24, 2021 1:58 am
Graf Zahl wrote:I think the drawbacks of such an approach will overweigh in the end.
Wed Mar 24, 2021 4:22 am