convoluted connor a changé de compte pour @notwa@cybre.space :
80b3e936f186f59b

convoluted connor @notwa@witches.town

quick and *very* non-exhaustive test shows MM only(?) has ~25% more code and compresses a couple percent better.

would you have paid the price of dedicated decoding hardware to fit 30% more code in your NES game? i wonder…
if my interest in this persists, i might try this with megaman 1. it's a bigger cart to begin with, so it might take a lot more work to trace all of its subroutines, or maybe i'd just source the disassembly going around.

the answer is not quite 30%. i used Golomb coding here, but Huffman yields a very similar result.

also this code is kinda bleh (i even just spotted a var called 'asdf' and an off-by-one) but i don't feel like working on it anymore tonight.

let's find out much compression of opcodes (not including their immediate operands) would reduce the code size of Super Mario Bros.
gist.github.com/notwa/1aba32c1

i could make a bunch of toots about this analysis of opcodes in Super Mario Bros., but instead, i think i'm just gonna post the python notebook once i clean it up a little.

using C is like, "check out this thing I made!" and it's some janky looking thing that falls apart as soon as it leaves my hands. "sorry, do you have a working toolchain with a recent compiler? how standard-conforming are your header files? did you build all the dependencies? are you any good with shell scripts? you know what, forget it."

maybe this year I'll try moving away from C, even if I don't venture too far from home. C will always have a place in my heart, but having to work with it isn't something I wish upon others.

software hate Afficher plus

software hate Afficher plus

software hate Afficher plus

augh i'm so bad at putting names to melodies. i'm just gonna guess whatever i just heard was a cover of an sm64 song

I don't know what's going on but I think that's okay.

something interesting is that, if you are gonna use x/17 for coordinates, 255/17 is exactly 15 and 65535/17 is exactly 3855. seems like this works for any 2**(8*Z)-1

i was thinking about using integers for some grid-based distance stuff just for sanity — and perhaps portability to retro consoles…
the 24/17 one is nice, because you can do 12/17 and approx invsqrt(2). only problem is dividing by 17 when the time comes.

random observation: 17/12 is just slightly over sqrt(2), and 24/17 is just as close but slightly under instead. there's an absolute error of 0.00245 in both cases, and both are ~6 times more accurate than a simple 14/10.

something I've been considering is making a reference of math functions and their basic properties for creative applications. often times I can visualize the f(x) curve I need in my head, but then I have to remember what functions even produce curves like that. they'd be roughly normalized too so you can pipe them more easily