sherclod holmes @wallhackio@cat.family

hey @coriander do you play fantasy football

my greatest character flaw is that i liked danganronpa

my favorite genre of steam review is the guy with >4000 hours in the game who does not recommend it

@amy @monorail nvm get fucked

@amy @monorail holy shit

somehow didn't talk about the soundtrack which is absolute heat

Gameplay

• Lived up to the hype, it actually is that good
• Had a very smooth difficulty curve, the game teaches the player brilliantly. its incredible how tractable and readable the final levels are
• Levels are really designed as puzzles, at least from the lens of Mark Brown's concept of "The Catch" (https://www.youtube.com/watch?v=zsjC6fa_YBg&t=157s). In this case, the extremely readable and clear level design demonstrates a straightforward path through the level, and "the catch" is that the gold/ace medal demands a time that can't be achieved with that path
• Getting ace medals is more about finding one or two good shortcuts than technical execution, i wouldn't have minded if the game asked a little more out of me for ace medals
• the secret "red medals" are a very nice feature though and the few I've gotten were really tough, i like that a lot (see attached video)
• searching for hidden items in the later levels starting getting tedious once the levels became large and played with verticality
• other than the last point this is right up there with base game celeste for some of the most "perfect" level design i have ever seen. but i am psychopath and still wished it was harder

Narrative

• the game is a pastiche of early 2000's anime slop, beach episode and all
• VERY horny
• while the premise is compelling, the Bullshit Anime Dialogue takes away from the tension that the premise could have had (is this intentional? there is a surprising amount of talent in the writing room (one of the writers wrote We Know the Devil???????, the other writer is a writer director and storyboarder with credits on Fiona & Cake, Infinity Train, and Ok KO)
• despite the amount of lore the worldbuilding is completely nonsensical (is this intentional?)
• i did enjoy Red and White's flirty dialogue in the second half of the game, they have good chemistry
• the second half of the game is about the need for forgiveness, not because the offending party deserves it, but because forgiveness can be freeing for the forgiver
• i didn't hate the story but i didn't like it either. won't surprise if in the next few years we start getting "The Story of Neon White is GOOD actually" video essays

hey @coriander is this how you met yukon
https://x.com/gatinarios/status/1956147899357712862

never mind my run sucks
https://www.youtube.com/watch?v=6_AdCspxOaQ

It's not perfect but I'm still happy with this run

My purpose in life is to see cool emojos and then beg @aescling and @Lady to add them to our instance

like is this not an insane place to hide something
https://www.youtube.com/watch?v=ghGZ0Ji1H2U

okay was this not absolutely outrageous to find

@coriander

Hi all I just discovered the greatest thing ever:
https://youtu.be/GOnwBq0hBZY

Hi @vaporeon_, a while ago we talked about the fact that references were introduced to C++ in order to enable operator overloading. You asked why you have to introduce references to enable this and I said that you didn't and it was an unnecessary complication.

I've been thinking about this and I don't agree anymore.

In C++, operators used with class types are syntactic sugar for method calls:

#include <iostream>

class NumWrapper {
public:
    int val;
    NumWrapper(int n) : val(n) {} 
    NumWrapper operator+(NumWrapper& r) { return NumWrapper(this->val + r.val); }
};

int main() {
    NumWrapper l(3);
    NumWrapper r(4);

    std::cout << (l + r).val << "\n";
    std::cout << l.operator+(r).val << "\n";
}

So why not make the overload method take pointers instead?

class NumWrapper {
public:
    int val;
    NumWrapper(int n) : val(n) {}
    // why didn't c++ implement operator overloads like this?
    NumWrapper operator+(NumWrapper* r) { return NumWrapper(this->val + r->val); }
};

Well, imagine we used an rvalue as one of the + operands. Then a pointer to an rvalue would be passed to the overload function. rvalues normally have their addresses hidden from the programmer (you can't give them to &). Then operator overloading would circumvent this feature and allow the programmer to access the address of an rvalue.

I currently believe that references were introduced so that C++ could have a pointer-like language construct that does not expose the addresses of rvalues.