3 ms·

Having a policy to have to extend something is proper bad already. For actors likely you need lock-free queue and much preferably a bounded one - so each messag

by xxs 6y ago

Having a policy to have to extend something is proper bad already. For actors likely you need lock-free queue and much preferably a bounded one - so each message is a CAS (very likely uncontended) and there is an upper limit how much stuff can be enqueued. I do believe there are tons of incredible horrid code (esp. when it comes to concurrency) - but most games tend to use already established engines, less likely to have glaring concurrency design blunders.

monocasa 6y ago
I mean, yeah, you don't make a choice like that without making a lot of other terrible choices too. Like I said "horrendously misunderstood the actor model". And as you seem to be picking up on, they had a very C++98 view at best of how inheritance should work. In case it's not clear to anyone reading along: if you find yourself doing anything like this, take a long, deep look in the mirror; you're almost certainly making the wrong choice. Best I can say is that the architect learned from some of their choices in the years since from the resulting consequences. However, that code is still out there. The engineers have tried to rewrite since then, but it turns out that rewriting isn't adding new features. I don't agree with the company's calculus on the matter, but that's a tale as old as time. And you'd be surprised how many games aren't written well. Writing a game engine is a bit of a rite of passage among young coders, and a surprising subset of those actually ship. In my experience, a lack of maturity in the field and (we'll be courteous and say) 'questionable' threading models (and as you point out inheritance models too) go hand in hand. The point at the end of the day is that Wine users (like Windows users) expect the runtime to do the best it can even against terribly written applications. The users want to run that code, it isn't going to be fixed, so anything Wine can do better to paper over the (incredibly obvious to someone skilled in the art) deficiencies of that code is in their users' benefit.
girvo 6y ago
I wouldn’t be so certain with regards to game engine code quality. Game dev is about producing playable art; code “quality” isn’t a massive focus. In this particular example you’re probably right though, because performance does matter to game dev, and that would be a horrific architecture perf wise

by xxs 6y ago

monocasa 6y ago

I mean, yeah, you don't make a choice like that without making a lot of other terrible choices too. Like I said "horrendously misunderstood the actor model". And as you seem to be picking up on, they had a very C++98 view at best of how inheritance should work. In case it's not clear to anyone reading along: if you find yourself doing anything like this, take a long, deep look in the mirror; you're almost certainly making the wrong choice. Best I can say is that the architect learned from some of their choices in the years since from the resulting consequences. However, that code is still out there. The engineers have tried to rewrite since then, but it turns out that rewriting isn't adding new features. I don't agree with the company's calculus on the matter, but that's a tale as old as time. And you'd be surprised how many games aren't written well. Writing a game engine is a bit of a rite of passage among young coders, and a surprising subset of those actually ship. In my experience, a lack of maturity in the field and (we'll be courteous and say) 'questionable' threading models (and as you point out inheritance models too) go hand in hand. The point at the end of the day is that Wine users (like Windows users) expect the runtime to do the best it can even against terribly written applications. The users want to run that code, it isn't going to be fixed, so anything Wine can do better to paper over the (incredibly obvious to someone skilled in the art) deficiencies of that code is in their users' benefit.

girvo 6y ago

I wouldn’t be so certain with regards to game engine code quality. Game dev is about producing playable art; code “quality” isn’t a massive focus. In this particular example you’re probably right though, because performance does matter to game dev, and that would be a horrific architecture perf wise