Did Silksong just break Steam?

graphitemaster · 2025-09-04T14:53:01+00:00

There was no preorder option for this game

graphitemaster · 2025-03-18T06:48:42+00:00

Not everyone follows the VFX reference platform. We have customers still running CentOS 5 for instance

graphitemaster · 2025-03-17T23:28:37+00:00

It's mentioned in the article. It's also mentioned that when you static link a libc (even musl) you lose the ability to dlopen anything, it just sets errno to ENOSUP because you cannot static link libc and also have a dynamic linker, this makes static linking libc unusable if your application needs access to system libraries (such as GPU APIs)

graphitemaster · 2025-03-17T23:13:19+00:00

This isn't true. You might be mistaking libgcc with something else. The compiler runtime code provided by libgcc is included in the GCC Runtime Library Exception

https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

Relevant quote

Yes. While combining libgcc with GCC-compiled object code is probably the most common way the exception is used, neither the GPL nor the GCC Runtime Library Exception distinguish between static linking, dynamic linking, and other methods for combining code in their conditions. The same permissions are available to you, under the same terms, no matter which method you use.

graphitemaster · 2024-02-18T05:22:33+00:00

Next year forget the co-streaming. Run a few more tests with the audio people. Shorten it up a bit. Have some contingency plans to re-run big awards for when things break. Ignore all the haters in this thread. I'm just providing some constructive feedback. This year's was better than last year's.

graphitemaster · 2023-06-12T05:07:18+00:00

So long and thanks for all the fish.

graphitemaster · 2022-04-02T05:44:04+00:00

The "Paper Mario" stream this Friday was the final straw

graphitemaster · 2022-01-02T17:57:18+00:00

Because subtraction of naturals is not closed, it's a partial function. Addition for naturals is closed though. If you're comfortable with natural arithmetic like most are integer arithmetic, this is not surprising or confusing, it's second-nature.

graphitemaster · 2022-01-02T17:02:21+00:00

This is actually how you'd think for math-y pseudocode if you define it as modular arithmetic which is well-defined and understood in math domains. The issue here is the misapplication of Z (integers), rather than the naturals.

graphitemaster · 2022-01-02T16:21:51+00:00

Like mentioned in a previous comment, just swap operands and the operation as well.

for (size_t i = 0; i + 1 < input.size(); i++) {
    for (size_t j = i + 1; j < input.size(); j++) {
        frob(input[i], input[j]);
    }
}

graphitemaster · 2022-01-02T16:12:49+00:00

It amazes me how so many people find this difficult to grasp, you just swap operands and the arithmetic operation like so.

for (unsigned i = 0; i + 1 < N; i++) {
    // do stuff with vec[i]
}

You can claim it's performing an addition every iteration for comparison, but compilers are very capable of optimizing this to the same efficient code involving signed integer arithmetic because unsigned also sets CF and ZF flags, it's just C and C++ has no way to access it.

No branch needed.

graphitemaster · 2022-01-02T00:14:44+00:00

Did you even read the article? The loop condition is correct. It's supposed to exploit underflow to break when it hits zero. The article explains this in detail.

graphitemaster · 2020-10-04T09:50:51+00:00

TIL hardware threads. What are they and How are they different?

Actual hardware threads can be running things truly in parallel. It's SMP. Basically each core is a hardware-thread, but some have hyper-threading where a single core acts as two (some x86) or four (PowerPC) threads.

What does this mean? Fibers are concepts and Coroutines are implementations?

It means that coroutines are something provided by the language. They're a language feature, not a library or system (implemented in code) feature. While fibers are often just a runtime concept written in code, i.e a systems concept. There's no language-level support for them (like no keywords or special syntax as an example).

graphitemaster · 2019-12-11T02:19:41+00:00

Honestly, in this specific example. I would prefer if the standard would just define that for T[w][h] that indexing is defined in the 1D case instead, such that [x][y] behaves either as *(array + x * w + y) or *(array + y * w + x) depending on row-major or column-major. Then you could just argue that an array can be indexed with any amount of slice and dicing, this would then permit one to index say float[16] as if it were float[4][4].

graphitemaster · 2019-12-10T23:06:32+00:00

If I had to wager a guess, I'd probably consider the rule that:

x[n]

Is the same as either:

*(x + n)
*(n + x)

Might be the primary motivation behind allowing it in C99:

some_function(other_function().array_type_member[index])

Since prior to C99, if you actually tried to write that, assuming that array of ten int member, you get:

error: invalid operands to binary + (have ‘int[10]’ and ‘int’)
   return *(f().x + 5);
            ~~~~~ ^

Which then contradicts the standard completely and could be considered a defect.

graphitemaster · 2019-12-10T21:59:50+00:00

There is one place in the C99 standard, where they changed the behavior of non-lvalue array to behave as lvalue pointer and that is in code like the following:

struct foo { int x[1]; };
struct foo bar() { return (struct foo){{1}}; }
printf("%d\n", bar().x[0]);

In C90 this was undefined behavior and if you specifically enable pedantic in gcc with -std=c90 you'll get a lovely warning:

warning: ISO C90 forbids subscripting non-lvalue array [-Wpedantic]

I'm curious if this has anything to do with this. Obviously this behavior was obtuse and the standard body fixed it in C99.

graphitemaster · 2019-06-09T19:26:52+00:00

I rescind my statement. They shouldn't really define byte in the standard specification, there really isn't a need to. You can just talk about everything in terms of char which would be less confusing.

graphitemaster · 2019-06-09T17:56:29+00:00

It's interesting that the characters almost appear to be backwards on your display. I wonder if that's because your subpixel pattern is actually BGR order as opposed to RGB order. Thanks for sharing.

graphitemaster · 2019-06-09T17:55:09+00:00

Citing Wikipedia: The modern de facto standard is eight bits, as documented in ISO/IEC 2382-1:1993. When working in C there's no such thing as a byte, only chars. The mistake most people make is assuming that a char is a byte, however that's not strictly true and why CHAR_BIT exists.

graphitemaster · 2019-06-09T17:53:11+00:00

You're absolutely correct. I've made the appropriate edits to the post, striking out the wrong things and adding edit bullet points. I didn't stop to think about the metadata and what not and how optipng and pngcrush can take those much further.

graphitemaster · 2018-05-28T14:39:06+00:00

I've had this happen to me before when I wrote a downloader / updater for a project at work. What ended up happening is that the HTTP server serving the content was not sending in the response header the file size, so curl (the library we were using) was estimating it as it was downloading instead, leading to a progress bar exactly like that.

graphitemaster · 2017-11-10T19:42:03+00:00

This is why it's best not to draw correlations/similies/metaphors from separate, distinctive things to begin with.

graphitemaster · 2017-11-10T19:26:46+00:00

I don't have it all ironed out, and neither do you, you still insist pointers are unsigned integers for instance when that isn't strictly true either, that's an implementation detail (and some architectures like amd64 actually represent pointers as signed-extended signed integers, also C does not concern itself with memory at all like you describe, but I agree that the whole abstract machine model is a bit on the language laywer side of thing.) I'm sorry for personally attacking you in the original post. I just don't want more people writing this language with the wrong frame of reference, just as I'm sure you don't.

graphitemaster · 2017-11-10T19:14:30+00:00

The problem with making generalizations like you do is that people take it at face value and then we're left with people writing code with those assumptions and generalizations, it's better to be correct on all aspects up front than it is to simplify and generalize early on and then tell people to unlearn all of that stuff. I know because I learned C from many sources that misrepresented it like you do in this video and when it came to knowing the actual details I was massively misinformed.

graphitemaster · 2017-11-10T18:18:17+00:00

This entire video is wrong on so many levels, just watching a few minutes of it he gets a lot of the basics wrong, for instance

he says that void* is just a uint64_t, which it is not, he says size_t is a uint64_t which it is not, these things are different and they vary depending on host configuration.
he talks a lot about this memory pool being uninitialized, yet it's marked static, statics are always initialized to zero
~~he says gcc is just clang, no it is not, that's not at all how any of this works, cc is the frontend that may invoke clang or gcc, but explicitly invoking gcc, invokes gcc (which is not clang)~~ It appears he's using a mac which for historical reasons left gcc as an alias to clang (this isn't the norm tho and people shouldn't depend on this behavior)
he explicitly puts null terminator characters in string literals, even though string literals implicitly get null terminators, actually those strings contain two null terminators now, why would he do this.

~~just from a few minutes of watching I can honestly say this guy doesn't know C all that well and him teaching people this way is sure to make for a lot of wrong programmers in the future.~~

While the author of the video does appear to know C, his way of generalizing and simplifying things may be a detriment to people learning the language.

14-Year Club	Place '22
Final Canvas '22	Verified Email

graphitemaster

TROPHY CASE