Altazimuth

I made it seemingly work on Eternity. Get devbuilds at http://devbuilds.drdteam.org/eternity/ Congrats on the release! I guess yell at me if it's secretly broken in EE, but it seemed OK.

Had I_Error issues in multithreaded builds. I have fixed this, and it'll be working fully starting from the next devbuild. In other news this somehow eluded me till now. Great mapset. Thoroughly enjoyed.

Oh god I'm reproducing it. I'll look into it. EDIT: Fixed

Yeah. Try turning that off. I think it might cause issues of some unknown variety.

What does your final page of video options look like?

Thanks! Props to ceski, Edward850, and InsanityBringer for helping point me in the right direction to help alleviate stress on threads. In other news the devbuilds are working again, so please get builds from there if you want. https://devbuilds.drdteam.org/eternity/

I've been trying to sort this out. Recent libpng updates have caused devbuilds to not work. I tried to fix it but failed to do so prior to the scheduled time last night. Hopefully it'll be sorted by next time. In the meantime have a manual build from me. Eternity_Master_2606a1.7z

It's live! The new DRDTeam build (about 19 hours from now) will have this officially in. Yes, I lied, I couldn't wait. Earlier today I made an important change that means that it scales far better with number of threads, both performance (faster) and CPU usage (lower). A sensible maximum at this stage is the number of physical cores your processor has. I did see some gains past that point on my 7950x but not that huge. I haven't tested this on a processor with E and P-cores and frankly I'm scared of what'll happen if I do.

@ceski Found an issue with r_sprprojstyle which I have since fixed. I'm not going to upload a new build since I plan on merging into master tomorrow.

I gave a stab at an incredibly simplistic attempt but couldn't quite figure out how to resolve rendering issues easily enough to bother. It seemed like some sort of persistent data was causing sprites to not render in the zones between the render context where the load balancing was happening. I'll probably pester GooberMan when he's freer.

I've decided I'm pretty happy with how things are, even without load balancing. I plan on merging this into master in 1.5 days, unless anybody has any major reports.

Edward850 got a Steam Deck and his crap experience using it to play Eternity prompted me to drastically improve the out-of-the box controller experience for that. You could try a devbuild if you want, though there's still stuff that needs improving (certain numeric fields only take input via kb). Either way it's much better than it used to be.

Yeah honestly for the guy who ironed out all these multithreading kinks I really don't know what I'm doing to a large degree. Initial set-up was based on Rum & Raisin code and then the vast majority of it was coming up with novel solutions to issues reported to me by ThreadSanitizer. It should be beared in mind there's no thread joining here, just setting an atomic bool to true and releasing of a semaphore (at which point the threads will spin). The whole communication between the threads happens on the render end here, and on the main thread's end here.

Just the start/end of threaded rendering. I might be using terminology incorrectly here, to be fair. Any synchronising within the render threads should be at a minimum. All texture caching and such were moved outside rendering. Allocations are all for thread-local heaps, last I checked. There is a mutex for the global zone heap, but basically nothing uses it from within the render threads.

Not sure how I'd figure out how to do this. Would require some wide-scale rewrites and even with that done I'm not sure I'd be confident in any sort of heuristics I could use to figure out what the best thread count it. I think NUTS is largely slow due to just how many monsters are thinking, rather than being rendered. It's definitely a combo but IIRC the thinking takes up way more time, meaning that faster rendering isn't gonna help toooo much.