Marzepansion

I'm a game dev, so my perspective on this can be biased, but my honest opinion is if games are too expensive for you to buy, go pirate them. That's exactly the situation places like Argentina are in now. Let us westerners subsidize the cost of development until your country gets back on track and you are able to buy more than just staple goods (40% of Argentina is considered living in poverty or worse).

This goes for people in poverty anywhere in the world tbh even in the West. Piracy doesn't really move the needle much (but do try to support indie devs if you can)

Nope, the announcement trailer was made in Unreal, they've confirmed it's in Unity.

Here's their official twitter account confirming that: https://twitter.com/colossalorder/status/1633060715132080130

It's using unity game engine. I'm a graphics programmer in the industry and at my current and last workplace I made tech for games studios (i.e. I dealt with performance of easily 100 games a year at one point). Unity by far was default the worst to deal with due to the limited tools to fix issues that were inherint to the engine. Note don't take this as me saying unity is a bad engine, it's just that it isn't a performant one. Its focus is elsewhere (accessibility and ease of development, things it excels at).

So yes, you can definitely assume that, in fact I'd assume one core for the simulation unless they wrote an entire new architecture to replace unity's functionality (you'd still be locked to single thread sync points, but that's manageable). It's a hassle most don't deal with as it's a lot of work to struggle against writing code like unity wants you to write it.

I worked in a studio that exactly did that a decade ago, and it was painful and frankly a huge upfront dev cost that takes a long time to pay off.

She could've fallen off the stairs or had a heart attack, it doesn't absolve Hamas of their generous contribution to the death of this person.

Absolving and defending kidnappers is such a disgusting take

What the hell are you talking about good and evil for?

Have I so far defended Israel's response? No, and I don't actually agree with their response either. The proper approach wasn't to escalate and as they are in the position of power they have that choice. That still doesn't mean I'll go in threads defending actions that have lead to baby murdering, something so vile and heartless that only a blind ideologue could ever defend it or use it as a "but they were worse" argument.

Blind ideologues might hate it, but sometimes the two sides are shit, and in the case of IDF and Hamas, they both are, and Palestinians are in between. That still doesn't give anyone the right to kill children.

No you are ridiculous for thinking what you wrote isn't somehow interpretable as that.

You write:

no need to justify this, the scale of dead kids is still tipped HEAVILY towards Palestinians

95% of all victims of this conflicts are palestinians. lets stop pretending the numbers are similar.

But somehow this isn't a justification on literal dead children. Yeah sure buddy. Could've lead with "well there's no excuse, but there have been far more dead Palestinian children in this conflict", instead you wrote that drivel. That's why I'm saying you're both side-ing literal baby murder.

"well we're really just evening the dead baby numbers" with the implication that that even remotely makes this justifiable.

No, I'll never support anyone who murders babies, be it whatever side or reason. You coming in here and defending baby murdering screams "both sideing" baby murdering as something that's even remotely defendable. It isn't, do some self reflection, same to whoever felt the need to upvote such messed up worldview.

For years I've been arguing for the plight of Palestinians, but to hear such disgusting arguments from someone who holds the same goal (freedom of oppression for Palestinians) and spouting that without shame is on par with those who deny the apartheid policies of Israel (I'd argue it's worse, but at this point it's the shit Olympics of opinion, and they're all on the podium).

Because half-assing the implementation is the way to go

Let's deliver a broken version of accessibility in 10 minutes, that's much better.

No, simply adding "colour filters" isn't a fix either, and if that was the fix then a game wouldn't even need to do that, there are plenty of apps that can already do that, a game doesn't need to do anything for that (similar to how your screen warmth can change when it becomes night), reshade as an example of something that can do just that.

But thinking about the problem is ofcourse too hard, it's easier to whine about it and act like you know how simple it is. But when we implement accessibly we do think about it, because people with accessibility issues deserve to get something that actually helps rather than the "10 minute solution"

It's disingenuous to pass off ww2 as a current event though.

Pretty standard really. You don't want contributions to the codebase come under questionable copyright concerns, or the original creator to revoke the code 4 years later causing huge headaches potentially.

You typically have to sign these types of CLA's whenever you need to contribute to any serious project. I've had to do it for Google and Microsoft recently, and I've done it for various other open source projects as well.

Still that shouldn't concern users/gamedevs as they don't contribute to the engine code typically. Only if they want to upstream changes back into the engine publicly they would need to sign it ofcourse

You raised an issue that the other bulletpoint has the solution for, I really don't see how these are "key differences".

In Rust there always only one owner while in C++ you can leak ownership if you are using shared_ptr.

That's what unique_ptr would be for. If you don't want to leak ownership, unique pointer is exactly what you are looking for.

In Rust you can borrow references you do not own safely and in C++ there is no gurantee a unique_ptr can be shared safely.

Well yeah, because that's what shared_ptr is for. If you need to borrow references, then it's a shared lifetime. If the code doesn't participate in lifetime, then ofcourse you can pass a reference safely even to whatever a unique_ptr points to.

The last bulletpoint, sure that's a key difference, but it's partially incorrect. I deal with performance (as well as write Rust code professionally), this set of optimizations isn't so impactful in an average large codebase. There's no magical optimization that can be done to improve how fast objects get destroyed, but what you can optimize is aliasing issues, which languages like C++ and C have issues with (which is why vendor specific keywords like __restrict exists). This can have profound impact in very small segments of your codebase, though the average programmer is rarely ever going to run into that case.

I participated in this, have to say it was fun and it's been a thing I've said for years could make (at least) linear algebra lessons more interesting to young people. Shaders are the epitome of "imagery through math", and if something like this was included in my linear algebra classes I would have paid much more interest in school.

Funny now that this is my day job. I'm definitely looking forward to the video by IQ that is being made about this event.

To explain some of the error pixels: the way you got a pixel on the board was by elaborately writing down all operations in details (yes this included even simply multiplications), the goal wasn't if the pixel was correct or not, and depending on the location of your pixel the calculation could be a bit more complex, as long as you had written down your steps to get the result as detailed as possible.

More than likely simple mistakes were made in some of these people's calculations that made them take a wrong branch when dealing with conditionals. Hopefully the postmortem video will shed some light on these.