• 0 Posts
  • 24 Comments
Joined 1 year ago
cake
Cake day: September 28th, 2023

help-circle

  • From later in the article (emphasis author’s)

    Earlier in this article I intimated that many of us are already dependent on our fancy development environments—syntax highlighting, auto-completion, code analysis, automatic refactoring. You might be wondering how AI differs from those. The answer is pretty easy: The former are tools with the ultimate goal of helping you to be more efficient and write better code; the latter is a tool with the ultimate goal of completely replacing you.


  • I personally think MOBA should be used to broadly describe a style of game rather than what’s done while playing it. I know that when Riot coined the term, they were referring to games like DotA, LoL, etc.; to me the whole approach to a match’s flow is echoed similarly enough throughout multiple games, that applying the term MOBA to other games is a logical extension.

    To me a game is a MOBA if:

    • The way to interact with it is primarily designed around playing with other players online (the M and O of MOBA.)
    • The goals of the players are against the goals of other players — ie. it’s competitive rather than cooperative (the B of MOBA.)
    • Any player at the beginning of a match has access to all the same options as any other player. This one is a little more vague, but as the A in MOBA stands for arena, I imagine it like a group of gladiators standing before a communal weapon rack that they’ll all pick from; no one has any options that the others don’t have access to.

    Following these criteria, something like Overwatch is a MOBA, as is DotA, and ironically LoL isn’t as you have to unlock options meaning you don’t satisfy the arena condition. To differentiate games like DotA, Smite, Awesomenauts, Deadlock, etc., I prefer the term lane-pusher as that’s a lot more specific and understandable.

    Does it really matter what it’s called? Not really. I mostly just do it so I can feel superior to Riot for coming up with a vague term that is applied, how I deem, incorrectly, while also excluding their own game from the term that they made to describe it.






  • I would recommend going and watching the pannenkoek video because it is so good.
    The quick version is that it has been known to be possible to clip through the wall to get to the door, but Mario has to be in the walking state to open it. Since the floor directly under the door hitbox is all covered by wall, and the part that isn’t covered by wall doesn’t have a floor directly below it, it seems like there’s no way to actually be in the walking state to open it.
    However, by abusing an exploit where Mario finishes his turn around animation the same frame he leaves the ground, the transition to the freefall state is overwritten by the transition to the walking state; this lasts one frame until a check is run next frame — which properly puts him in freefall. Timing the turn around right lets you be past the wall and walking, so you can open the door.








  • I’m sure there were other consoles that did it, but the one I remember is the NES; it had a physical switch on it for channel 3 or 4, and you had to have your TV tuned to the respective channel to get the game to show up. As to why that was necessary on a technical level, I’m not sure. But it was a thing you had to do.



  • A lot of the complexity came from around various scenarios you could be in; my goto whenever people would ask me “Why can’t someone just make printer firmware simple?” is that you could, if you only wanted to copy in one size with one paper type, no margin changes, and never do anything else.

    There’s just so many different control paths that need to act differently; many of the bugs I worked on involved scaling and margins. Trying to make sure the image ended up in a proper form before it made it to hardware (which as more complexity, ran on a different processor and OS than the backend so that it could run realtime) when dealing with different input types (flatbed scanner vs a document feeder, which could be a everyday size, or like 3 feet long) different paper sizes, scaling, and output paper. I mainly worked on the copy pipeline, but that also was very complex, involving up to, something like, 7 different pieces in the pipe to transform the image.

    Each piece in the pipeline was decently complex, with a few having their own team dedicated to them. In theory, any piece that wasn’t an image provider or consumer could go in any order — although in practice that didn’t happen — so it had to be designed around different types of image containers that could come in.

    All of that was also working alongside the job framework, which communicated with the hardware, and made sure what state jobs were in, when different pieces of the pipeline could be available to different jobs, locking out jobs when someone is using the UI in certain states so that they don’t think what’s printing is their job, and handling jobs through any of other interface (like network or web.)

    That’s the big stuff that I touched; but there was also localization; the UI and web interfaces as a whole; the more OS side of the printer like logging in, networking, or configuration; and internal pages — any page that the printer generates itself, like a report or test page. I’m sure there’s a lot more than that, and this is just what I’m aware of.