namark @namark@qoto.org
Joined Jan 2020
The point is that @Terry got thoroughly roasted here from all sides to a golden brown crust, trying to prove something through the incredible, state of the art, forensic technique of licking every pixel of every frame of that video, uncovering literally nothing that matters, while imagining himself being the sherlock of all holmes, for no other reason that to defend his homies, cause that's all that matters: homie - saint, not homie - death. Then a bunch of nazis came along to wipe of his tears and invite him to a circle-jerk.
Meanwhile you trying your hardest to be all above this petty squabble, somehow still managed to discredit yourself by implying that the nonsense he was trying to push here is a valid, or even convincing argument and that "it's just that anyone involved is too think to consider anything".
@philipwhite In my experience since the grid approach is usually all about convenience/simplicity, a close to a square shape also makes it convenient for artist to work on the atlas directly using ordinary image editors. Otherwise if you are using atlas generating tools, you'll usually go with some kind of packing algorithm, which will usually trim any sort of padding from each asset and store it as an offset, making even monospace font glyphs worth packing. That's why you won't commonly see long thin atlases, and when they do come up they are often themselves packed into a bigger atlas, which would be squarish either for packing purposes or convenience of manual editing.
If untrimmed 256 glyph monospace font is all you need, no reason to make it square.
Since when is animal behavior considered normal for a human? And how many of us are athletes and how many consult biochemist on what their body is built for? (if you do, be ready to discover that they were not build for anything what so ever, and the builder was drunk, high and had no thumbs)
Most peoples stance for meat is in essence the same as the stance presented here against it, personal preference/opinion, and if your argument is "I'm an animal, and you are not a biochemist" you're doing it wrong. Your run of the mill "I don't care", "fuck you" or "I love killing animals with my bare hands and eating their flesh raw" hold more weight.
@alex here, for what it's worth, is at least genuine.
long complicated poll, you will not be paid for this
@georgia@dickkickextremist.xyz well, the vector operations don't really fit a truth table, but I can give an example with just 2 elements:
With first operand being (true | false), second - (false | true), here is what each operation would do:
1. reduce both vector with disjunction
for first: true | false = true
for second: false | true = true
return the conjunction:
true & true = true
2. this one is equivalent of algebraic/symbolic expansion:
(true | false) & (true | false) =
(true & true) | (true & false) | (false & true) | (false & false)
except that it also performs the conjunctions to get a matrix/vector that still represents a disjunction:
(true | false |
false | false)
this is the final result, no further reduction.
3. conjunction of first elements of the first and second operands:
true & false = false
onjunction of second elements of the operands:
false & true = false
and final result just a vector/list that no longer represents a disjunction:
(false, false)
... I just realized, I won't be paid for this either ._.
long complicated poll, you will not be paid for this
For a vector of booleans representing a disjunction, considering these 3 binary operations:
1. Reducing conjunction. Reduces both operands and return the conjunction as a single boolean. Trivial, logical and sane.
2. Expanding conjunction. Returns a matrix representing a disjunction of conjunctions of all pairings of element from each operand (kind of a halfway symbolic computation). Somewhat complicated (essentially matrix multiplication), but still logical, if a bit insane.
3. Element-wise conjunction. Returns a vector containing the conjunction of corresponding elements of two vectors. This vector no longer represents a disjunction unless explicitly converted to original type. Kind of a masking operation. Illogical and insane.
Which operator would you prefer for each?
@philipwhite It's a way of having a generalized transformation abstraction, in an environment where matrix multiplication is cheap (and higher level abstraction are not available). It's pretty much the same rational as grouping rotation, scaling, skewing together. In the example, all the matrices can be combinations of various basic transformations in any order, and it all can be chained together easily with just one operation, without you additionally having to keep track of a set of vectors, and apply them through a different operation in correct order (because subsequent rotation/scale/skew affects translation, you can't just add one at the very end).
As a simple example consider these transformations:
translate right 1 unit,
scale by 2,
translate left 1 unit,
scale by 0.5
With separate translation vector it will look like this:
scale0.5 * (scale2 * (pos + right1) + left1)
With translation as matrix:
scale0.5 * left1 * scale2 * right1 * pos
Much easier to comprehend, but also if you give these some descriptive names, and later (even at runtime) want to change one transformation with another (or a combination of others), the expression itself doesn't change, so it is a generic expression. In the former case, especially if you want to add some extra transformations in the middle, it can get really hairy (and impossible at runtime).
Depends a lot on the use case. Do you want the vectors to be huge (usually used in "struct of arrays" configuration) or small ("array of structs") or both?
I've worked with a "small vector, in place only, explicit copy" library before, since couldn't trust the language used to optimize anything, and have to say it can be a real pain sometimes, both to write/read through all the explicit copies (which also encourages you to use some unnatural expressions, like -2+5, instead of 5-2), and occasionally to debug a problem that turns out to be a missing copy. My advice would be to provide both, mostly use the copying versions, and only optimize performance sensitive code with in-place versions. I would suggest names like add, subtract, multiply for in-place versions (mimicking assembly) and plus, minus, times for copying versions (mimicking operators and the way equations/formulas are read).
For huge vectors (which I don't have as much experience with), while it is a good idea to enforce explicit copy, I'm skeptical whether providing this kind of one function per operation interface is a good idea itself. Usually if you are passing through a huge vector like that (or several), you want to do as many operations as possible at once (even if there is no special instruction), so you'll end up needing some lazy evaluation optimization, which can get really complicated (potentially even deprecating the explicit copy restriction), in contrast to the more common and straight forward map/zip approach.
@amiloradovsky@functional.cafe
quick search revealed: In ancient times you were allowed to assign to it for shenanigans that are no longer necessary.
re: g++ error
Guess I never even tried const after noexcept myself, but would expect a different error if that's not allowed.
re: g++ error
constexpr applies to the function and means "compiler may execute this at compile time if it feels like it or has to" and it applies to the function. This error seems to be about the "this" argument, the special hidden argument every member function has, that you can qualify with const/volatile/ref(&)/rvalue_ref(&&) after the parameter list, usually before noexcept (though not sure if that last part is a hard rule). Default is reference (not const, not volatile, not rvalue).
Examples:
// const ref
bool operator==(uter) const;
// rvalue ref
bool operator==(uter) &&;
// explicit ref to overload rvalue ref
bool operator==(uter) &;
namark
boosted
After encountering a public domain tileset on itch.io that appealed to me so much that I'm now considering experimenting with game development, I decided to start compiling a list of game assets on Itch.io that are under Debian-compatible licensing terms.
(i.e. Not the usual "don't redistribute or sell alone or in assets packs" terms which violate the FSF, OSI, and Debian definitions of Free and/or Open.)
https://itch.io/c/845926/libre-game-assets
(The description also lists other sources like OpenGameArt.)
@tuxcrafting if you're not afraid of threads (which you should be) there are ways. Your timer could be a thread that sleeps for/until certain time and then calls back.
If need a ton of timers, maybe better to set up an update loop, that every "min_timer_duration" advances all timers (that are just durations) and invokes the callbacks of those that expire. Doing this on main thread you can almost get away without concurrency, but unfortunately still need at least one other thread to handle IO, cause it's blocking.
Then go down the rabbit hole.
@tuxcrafting I present variety of well fermented poisons:
1. galaxybrain RSI
2. alt-f4 thesis
3. french warhammerpunk
4. russian bum simulator
@philipwhite are you doing any sort of caching? I think, cairo is just vector graphics so it won't do it for you, and a terminal emulator most of the time should be just copying memory(cached renders of glyphs) not constantly re-rendering glyphs. With that I think even the CPU can do 60 fps full-screen with reasonable font size (assuming optimized memcpy). You'd probably need similar setup with opengl as well, because that's the best approach there too (though probably wouldn't be able to reuse any code... so mental setup). The difference is that with CPU the further optimization would be trying to identify and exploit patterns, like consecutive characters, and rendering them in one go, while with GPU you will be mostly optimizing the pipeline, that is figuring out how to update the cache of glyphs that is now in GPU memory without noticeable hiccups.
It's more subordination than sense of duty. When things go south and you are lost and confused, you listen to the one who sounds most confident in what they are saying, and that often times is something along the lines of "the demon spawn on the other side that caused all the hardships you faced till today, will not stop at anything to destroy everything that is human, therefore we must spare no efforts to eradicate it", of course twisted and disguised in some sort of an acceptable way (simplest form would be "they think this way"). Can't really fight for something, can only fight against something. Any doubts will be dismissed, because we are such control freaks that in our confusion we would much rather accept that everything is black and white and that someone else (our great leader) sees those colors, than that we're in a mess that no one can figure out. Afterwards we rationalize and glorify to save our faces. The sad part is that those who didn't(won't) behave in this way, probably didn't(won't) survive for long either. That's the beauty and wonder of natural selection for ya. The bittersweet part is that we have our ways around it, our thoughts and ideas surviving and multiplying despite (and sometimes through) even our most inglorious deaths.
@georgia@dickkickextremist.xyz
@tuxcrafting
they don't go hand in hand, proprietary software is kicking ISA compatibility forward under a gunpoint, and every time it stumbles it gets a whipping to get it to go faster, while crying and moaning, barely alive from the numerous wounds it sustained.
"it had to improve while keeping backward compatibility, so the instruction set couldn't really be changed" only true for proprietary software, and this is why first things you see ported to new architectures are usually foss (other than maybe manufacturer's/designer's own stuff that is prepared before release).
Even just assemblers can do a lot to make life easier for you, so source vs binary distinction existed before higher level languages became popular. Disregarding that, they did become popular long ago, so whatever assembly code remains doesn't really explain why x86 is still "today's most successful line of CPU chips"
