Samperson

I watched the leaked, unfinished version with missing VFX and random fully-integrated 1X BET (NO RISK BET) ads, and it changed my life

i'm definitely aware that physical merchandise falls even more into the 'not worth it' category of hassle than usual lately, but say i still wanted to try for some specific reason

hey artists: how do you deal with merch (specifically small things like pins) given the Everything rn
i'm pondering a project
do you handle distribution yourself, or go through a partner? and who Doesn't Suck in this space?

(if someone says redbubble i'm canceling the project)

good morning forum. what do you guys think of my new signature?
it's so sad he's dead
___________________________________________________

i say this to the young ones in my Audience
this one goes out to the Demographic

yeah yeah whatever your voice matters™, but your hands also matter

i just think every ounce of constructive pushback, that isn't just Posting, matters
and you won't see most of that Online, because this is the Posting place

but if you're able, look at local resources and see how you can contribute. there's always an imperfect, under-resourced org that needs help

which is also a grim way to pitch childcare but ya know. we're here now

bc plugging a baby into the Hell Machine does *solve problems*, right?
the baby gets to be occupied, and the parents have their baby pacified
it's just grim bc of its downstream consequences
...which is where access to things like childcare programs become important as alternatives?

it will be tough to develop a better future if we're giving all kids a machine that's not very good, but CAN jangle infinite keys, and is *just* useful enough to stop you from developing resilience or ability to deal with any problem on your own
this won't be solved with a Scalding Hot Take tho

the main intrinsic incentive humans have to Not regress into a pure receptor for stimuli, is that doing so seems to leave people feeling perpetually helpless, angry, and depressed

unfortunately that doesn't inherently lead one to acquiring the tools and will to pull oneself away

i have a lot of optimism about what's possible Despite It All, but i will say that largely depends on the next generation still being like. functionally literate and capable of decisionmaking without an LLM telling them what to do

so i desperately need parents to not drop the ball on this one

It's definitely easier for me to point at things in retrospect and complain, and I don't envy Unity's obligation to the mountain of legacy code built on these decisions

I feel like wrapping an operation in GetVertices/SetVertices is relatively painless for the common case, and much faster than re-making it on every get and every set?
Especially because vertex operations are rarely one-off.
I agree with the rest of your points, though!

For sure - I would just clarify that my issue isn't the allocation, my issue is just syntactically hiding a heavy copy behind a property accessor
If it was just the GetVertices() API, I'd be happier, because when reading the code, it more clearly signals that Work Is Happening there

When it comes to resolving the tension between performance-awareness and ease (esp. for beginners), or trying to create an on-ramp for users to become more conscious of their code... I do dig the way the Project Validator surfaces and flags a lot hidden perf issues in Unity's API use

For sure. I def lean towards the more extreme side nowadays, but part of that is the specifics of my Unity use. Realistically it's case-by-case?

That's also true! At minimum, bucking the naming convention amplifies the problem

(and you don't even have to be using Burst or Jobs to get the benefit of dodging older APIs + all the work they hide)

Unity - Scripting API: MeshData

We're getting a lot of saner APIs now, thanks to Burst and Jobs, and I still need to really sit down and deeply learn more of them.
Even when it comes to dealing with meshes, there's now a suite of equivalent functions, allowing you a lot more clarity on memory use
docs.unity3d.com/2020.1/Docum...

A lot of this comes from 10+ year old code, and I think it's as simple as: early on, convenience was king.
It's smaller to just write mesh.vertices[0] = mesh.vertices[1]; instead of having to Know about the work that goes into that.
It just means that you don't get performance by default?

Unless I'm blending in with another studio's practices, I usually just write a GetVar() and SetVar() function if I need to do any computation when accessing a value?
Part of it is just personal taste, and it's not stylish, but... I want clarity on heavy operations

I mighta fucked up the syntax. But it's the same on the backend - .varProp becomes a call to either getter or setter function (depending on whether you're reading the property or assigning to it)

Which keeps a lot hidden from users of that code!

Properties are functions! So in the IL, they generate accessor functions. You can replace

Type varName { get; set; }

with

Type _varField;
Type varProp
{
get
{
return _varField;
}
set
{
// do some computation on value
_varField = value;
}
}

THIS RIPS

WHAT?

(Though .Length is also a public-get private-set property, presumably to stop you from altering it directly, I assume the compiler can optimize no-frills read-write stuff?)

But like you're saying, you'd have no way of telling that was going on just by reading the code.

I'm totally with you haha
And it's even rougher than that. .Length isn't the problem because to even *get* there, it goes through mesh.vertices - which allocates a new vertex array - and then reads the .Length off *that*.

It's in the condition of the loop itself: `i < mesh.vertices.Length` re-allocates the entire array just so it can check how long it is - a number which will never change!

If something is Doing Work, it should look like it, right?
Isn't it good if it's ugly to repeatedly re-allocate a mesh's worth of data? That should be more annoying to type than just doing it once and caching the result?

This drives me nuts.
If you're wondering why I've become so annoyingly dogmatic about never using properties, this is it.
It becomes so hard to get a basic understanding of the performance characteristics of any code, just by reading it