I'm kind of a little bit iffy as to whether I think creating a second channel for long arguments is completely necessary. most of the arguments I find irritating are of the bad faith nature which the aforementioned guidelines are meant to prevent. but I also feel it could be beneficial in the long run, as do most other people
some of you may know me as "viba"
has PhDs in Eisenlangs and Windows Crap Edition
https://viba.neocities.org/
— viba
- joined
- a very long time ago
recent posts
sorry, rehashing arguments was not my intention, it was just a feeling I wanted to express
someone going around telling people that things they are interested in are "objectively harmful and masochistic" or "regressive propaganda" doesn't seem very nice to me.
it is indeed written in C.
good thing I happened to have already implemented a rudimentary memory allocator which I never ended up actually using.
every now and then I think to myself "maybe C++ isn't that bad". then I instantly remind myself that it is.
i don't even know why I have these thoughts in the first place. I have already concluded that C++ is not a language I will ever have any need or will to use in any case.
maybe you could look at QOI ("Quite OK Image format") (spec)? it's supposed to be quite simple to implement while still providing decent compression. i don't know much about it beyond this though
aha, I have heard vaguely of QOI from quintopia's site. perhaps I should have looked into it more. it seems like it could be quite good.
it appears there has been a recent surge in topics on the apious forum. I shall contribute to this with a topic I have been internally pondering in recent days.
I have been pondering the bootable Caillou OS i have made, and how it's disk access barely works. (well, the whole thing barely works in general, but this is one of the things.) any mouse movement during a disk operation is likely to screw up the mouse and make it not work good. I believe this is (at least partially) because every mouse update sends three packets, with an interrupt being sent for each individual packet. if interrupts are missed, which is likely to happen during disk operations, then there will be confusion as to which packet is supposed to be which. I'm sure there are ways to circumvent this, but I was, and still am, too tired to figure them out. and this issue is just the best case scenario; sometimes disk access just doesnt work at all for some other reason, depending on the system/emulator.
as it stands, all of the image assets are embedded directly into the binary, the entirety of which is loaded into memory at startup. once I had implemented disk access I attempted to put these assets into the filesystem instead. the images would then be loaded and unloaded as needed. however, because of the aforementioned disk access unreliability, this didn't end up working in practice. also since I didn't have the energy to implement directories in the filesystem, these assets would've just cluttered the filesystem anyways.
also, the whole OS had to fit into 492,544 bytes, as this is the amount of contiguous non-reserved memory starting from where the boot sector is loaded. (obviously this is not an absolute hard limit, it's just one caused by my own skill issues.) not like this was a huge challenge though, as the whole thing ended up being half that size anyways. but it does mean that, for instance, an 800x600 PPM image isn't even close to fitting. it's still more than enough to fit a bunch of smaller images such as icons, but you wouldn't be able to, say, have a full desktop background image. obviously PPM isn't going to be very efficient, but I really don't have the brains or energy to implement some compressed image format like PNG, and even if I did, an 800x600 PNG image might still not fit within the limits depending on its entropic entropicality-ness.
I am also hesitant to publish the source code of Caillou OS, as I have already done with Barney OS. this is because the Caillou OS source code is a complete and utter mess beyond any comprehension. I do not want any poor innocent people looking at it and getting the impression that it represents how any sane person should program things. The code is messy and hacky because I just wanted the thing to work, and nothing else. A lot of it is conglomerated into huge single files because I had too much brain fog to separate them into different files. Another reason is that I am interested to see how long it takes for someone to find a secret I have hidden in it. the answer will probably be infinity, since there are probably only going to be like 6 people who ever know about the existence of this weird OS thing.
I have thought about making some sort of means for other people to create things similar to this. maybe some weird contrived programming language, or perhaps a visual interface if I really felt like it. perhaps people would just be annoyed by the arbitrary limitations, namely the 492kb size limit, the lack of audio beyond PC speaker beep boops, the barely functioning disk access, or perhaps some arbitrary restrictions imposed by the language itself... perhaps I'm the only person in the world who cares this substantially about this weird quasi-OS nonsense, so such a utility would have little use. regardless, this just seems like another one of those ideas I have which I will likely never have the energy to do.
I have also thought about what the point to all of this even is. Perhaps it's a marginally fun novelty to see this whole "children show crappy OS" thing realized as an actual bootable OS. but also, perhaps it is simply a much more difficult means of writing a normal computer program. one that makes the program slightly more annoying and inconvenient to run, and have a great chance of having varying issues depending on hardware/emulators. perhaps there is little point to doing this when it is far easier and more worth it in the long run to make these weird fake OS things in LÖVE, as I have already been doing. That being said, it was still quite fun (well, mostly...) to make these bootable things and experiment with low-level programming and x86 stuff, but I'm not sure how much it would be worth it to continue these endeavors much further. but i don't know. maybe it is.
Il existe également une communauté de Vyond notamment connue pour le mème des grounded videos (en français « vidéos de punition »), parodies insolites de personnages de dessins animés se faisant punir cruellement pour un comportement inadéquat. Une grande majorité de ces vidéos sont centrées sur un personnage, par exemple Caillou, Dora l'exploratrice ou bien des personnages crées par la communauté. Généralement, ces personnages se font punir pour une très longue durée, que ce soit pendant un siècle, ou bien pendant des centaines de millions d'années, étant obligés de rester dans leurs chambres pendant cette durée9.
Ces vidéos sont souvent faites dans un but humoristique, alors que les systèmes de synthèse vocale utilisés par Vyond n'arrivent pas à reconnaître certains grands nombres utilisés dans ces vidéos (ils épellent chaque chiffre au lieu de prononcer le nombre normalement), et les onomatopées comme des rires ou des pleurs sont lues littéralement, plutôt que comme des expressions.
purple is closest to vibapink
edit: apioforum purple happens to look pretty close to vibapink actually
imagine doing webdev lol
(i generally disagree with the concept of webdev existing (webdev is malware :trol:))
wait actually "all the hipsters are starting to use it" applies more to Rust than C++ because C++ is like 30 years old
pretend im good at using words for a second......
although tbh there is no programming language that i can justify my reasons for disliking, because i don't have any actual experiences with them. usually they're just languages that all the hipsters are starting to use and which i've sworn on my life to never use because im too Cool and Based for them. this includes C++ and Rust.
if you think multiplicatively (as most human brains do), 2 (TWO) is quite different from 1 (one) (single), as it is DOUBLE (2*x) the value.