mocha

im gay lol

i make games and software and other software

regrettably dutch

pfp by @lif3_0n_m4rs on twitter

A small animated 88x31 button. The text says 'lisanne.gay'. periodically eyes appear that briefly observe a moving cursor


Last.FM Recently Played


this account is part of the m,cai ringbug

↑up↑
here
↓down↓


posts from @mocha tagged #not-quite-projectposting

also:

mocha
@mocha

today godot has defeated me


mocha
@mocha

my process time is through the roof but i cant pinpoint what its actually doing. visual profiler says CPU & GPU are within acceptable range & script time does not seem to add up enough to go > 16ms. though the shitty IK probably does deal a lot of damage. idunno man i dont really know what to make of what the profilers and monitors are telling me



ive worked on a bunch of projects that depend on in-game scripting languages as the main focus and almost always run into a thing where none of the existing offerings let you do step-by-step execution. Like usually you input a string and then that gets run and then you get whatever the result of that was. but that sucks most of the time!! like if you let the user write anything that runs forever then ur game just breaks. being able to call the interpreter to do the next step would be so chill. then infinity wouldnt really matter, or if it did you could just limit to either X seconds or X amount of time. you could also run the interpreter in a thread but out of all the offerings ive seen i never saw an interface to cancel execution. also that would not work at all if you for instance want to limit the speed of execution, other than trying to inject sleeps or whatever into the code which is a nightmare.

like i get that this is not a problem for what these kind of libraries are usually used for, stuff like plugins and mods or whatever, but it would be nice to just get a little deeper control in what it must already be doing under the hood. i got frustrated about this enough one time that i spent 3 months building my own interpreter for a custom scripting language and it sucked and was so slow and the project exploded in scope and never got anywhere lol.
anyways writing ths because im currently using lua for the 3ds engine thing and i realized that the way i changed my approach to how script evaluation works could totally allow for infinite loops lol. which would almost certainly freeze everything up :P maybe i could start a thread inside of lua that throws an error after X seconds or something idunno lol



its VERY COOL. ive been keeping my eye out for them for a long while and im so very normal about them. SMALL and CUTE and REWRITABLE and OPTICAL but also MAGNETIC. wow. fucking slay as hell sony

anyways. players/recorders are :: expensive. originally i was looking for a netmd one that works with USB and such (VERY expensive) but it turns out only some can read back data over USB (through an exploit) so it doesnt really matter actually ? like primarily i would have these dudes for data storage & retrieval.

ok actually quick side ramble about MD-Data

so turns out sony made a seperate format for doing data storage on minidiscs. like theyre separate kinds of minidiscs. u cannot use normal ones. and u need a special MD-Data reader/writer. im not really sure because its hard to find information on but it kind of just seems like this is kind of arbitrary? the "no normal md's allowed" thing i mean. 99% of players did not allow sending data from disc to pc so the special reader/writer makes sense.

anyways like the reader reads some kind of header when a disc is inserted that tells it what kind it is and stuff and then it just refuses to write to it. maybe its to avoid md players attempting to play data stored on the md but that seems silly. maybe there is a technical reason for it but it sure does seem like some arbitrary limit

anyways so. im cooking up an idea where instead of getting one of those specific reader/writers that works with the (very cool and awesome and foss) Web Minidisc Pro application over USB i just get any player that allows recording & then just plug the mic & headphone auxes into a PC's headphone & mic ports.

then i can write a little application to convert a binary file into audio & play that so it gets recorded onto the minidisc, and to read just listen to the mic thats connected to the players headphone port & convert the input back to binary file. that shouldnt be too hard given that "convert thing to sound and back" is like worlds most solved problem ever.

only annoying thing would be that the computer would not be able to select a track to record onto. that would be a convenient way to differentiate files but i guess the whole fs could be stored into a single track. that would mean ud have to re-write every file thats already stored + the new files when u want to add new files though

oh also also. not really related to anythin but it seems like a lot of players have a 3.5mm audio/TOSLINK combi port which is really funny. toslink is neat so i may finally get to mess with that a little

anyways. much to thinkg about. i love u minidisc



mocha
@mocha

despite my better judgement i wrote down a lot of ideas for a game project thats way too big in scope to actually be feasible. id love to do it but theres 0% chance id finish it before losing interest or burning out. also itd involve a lot of 3D asset creation which im soo shit at.

but now i have half of a concept doc i guess. to look at. or something. society if unlimited time and brain and skill 🏙️


mocha
@mocha

not only would this project be at a scale ive never successfully completed, itd require solid work in pretty much all the fields im garbage at (alongside what would probably turn out to be worlds messiest codebase);

  • 3D modelling
  • audio stuff like foley
  • environments / color stuff / shader things

this is a very "wow this would be awesome" kinda thing to have completed but it would for sure just plain suck to make. id get sent to the "MAKING MY DREAM INDIE GAME (episode 2845928429) - rendering a cube" pits for 10000 years