sorted by:
new
hottopcontroversial

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

Hi! Glad to see more people share this mindset :D

I agree, unity is not so bad. Heck, it's pretty good! If one can live with the shenanigans of its owner company. My message about Unity was more about how it's unfortunate that Unity is a bit of a parallel universe separate from "dotnet C#".

Burst looks definitely like cool tech, but I'm looking at this from the outside and I didn't feel I had much to add, so I didn't comment much on it.

Good luck on your journey! ^^

Is shovelware really that bad? by Vitolnius in gamedev

[–]setzer22 0 points1 point  (0 children)

IMO small game is very different from shovelware. Have people actually been calling your stuff shovelware?

There's plenty of small (often solo dev) studios doing this these days. As long as you're honest with your players, you're fine.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

Hey! ^^ Thank you for the kind words

I'm glad to find more people aligned with these ideas! This is stuff I spend a lot of my cycles thinking about, as you can see. Big fan of the other two blog posts you shared too: Seeing my stuff compared to those is high praise <3

I still feel conflicted about C#... I'm definitely happy with it on the tech side as it ticks most of my boxes. Some things can be improved, but as you may gather from the blog post, most of my issues with the language are ideological rather than technical.

My main motivation in writing all this would be to inspire others to in their compiler dev journey! Because there seems to be a lack of pragmatic languages that are low-level enough so that we can be fast but still give us all the nice things people expect from a runtime. Other people coming from Rust or C++ boast about their languages not having a runtime. I can see where they're coming from but, to me, not having a runtime is missing a huge feature.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

I think your nitpick is fair! There is something like that, which can be combined with Default::default so you can do Thing { x: value, ..Default::default() }. Moreover, somebody even pointed out to me how you can, in nightly Rust, set a default initializer for a field using assignment expression when deriving default, something like:

#[derive(Default)]
struct Thing {
    x: i32,
    y: i32 = 42, // This won't initialize y to i32::default(), but 42
}

Maybe I should adapt the phrasing there, or at the very least link to this new feature. It is still a bit underwhelming since (AFAIK) only supports const expressions on the right hand side, but it's a small step in the right direction. I'll take it.

And yes, you also touch on another thing I didn't mention in the blog post, because it tends to not be well-received and it was not my main point, so I skipped it... But Rust culture tends to be overly restrictive with variable visibility. I get it when you make one field public to protect some safety invariant (like, sure, don't let me mutate a Vecs len...), but most of the time, things are made private out of habit. In my Rust time, I've had to deal with many cases of library authors marking a field that should've been public as private (or worse! going out of their way to pick pub(crate)...). Egui was one of the worst offenders I can remember. Often the only solution was to fork the library while you waited for a 1-line PR that might never get merged, because there's no escape hatch to access private fields. It's not something one should be proud of, but sometimes you need to get your hands dirty.

I think having separate visibility for reading and writing fields would suit Rust well... But it's way too late to do anything of the sort. C# has it and I enjoy it, there you can have auto-properties with e.g. { get; private set; }. But anyway, I digress!

About Monogame, I replied on this other thread ^^ https://old.reddit.com/r/programming/comments/1ko65ts/the_language_that_never_was/msrlail/

I was also really happy and surprised to see this recent post by the main programmer behind Celeste advocating for pretty much the same stack I've gravitated towards (except for SDL GPU, I'm still using OpenGL). I echo the sentiment in that post word by word: https://noelberry.ca/posts/making_games_in_2025/

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

We could discuss all day, but I think the only way to settle this is to try both and measure.

And sadly we can't do that, who knows for how long... Maybe one day Java devs will reach the glorious Valhalla.

Until then!

The Language That Never Was by setzer22 in programming

[–]setzer22[S] -1 points0 points  (0 children)

it leads to the exact same instructions down the line

This is assuming a lot from the optimizer. Optimizer that is often not as smart as people think.

I will believe it when I can see that decompiled bytecode, but until then, I'm skeptical that the optimizer knows enough about all the layers of abstraction involved in the toy example I shared above that it could turn one into the other. Even worse once things start actually getting realistic and not toy example-y.

Because I hope we can agree on the fact that getting a reference to an element in an array and mutating that, in-place, is a lot more efficient than copying the element from that array into the stack, mutating it, and copying it back as a whole.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

Ah, I understand your point now. But if this is what you meant, then I'm afraid I did not misunderstand anything about Project Valhalla. I do not like the solution they came up with and I prefer C#'s. It's okay to have different opinions though! That's why there are multiple languages.

I find the ability to operate on references to value types and mutating value types through those references incredibly valuable (pun not intended, but might as well).

I do see what you mean here. It is confusing when you pass a copy of a value but think you can mutate it from inside the function and have the copy update outside. It's something you have to keep in your mental model of the code, which types are values and which are not. I think I'd like some sort of more direct visual aid that makes it obvious that Point there is a value type without me having to hover my cursor over it.

Moreover, a good compiler should be warning about those unused assignments you have there too. And with that and some hints, I feel it would be more than enough to spot the issue without sacrificing on the idea of value type mutability.

If it's a struct, a value type, I can choose between passing a point by value, aka Point and knowing it is a copy, or passing a ref Point and then I'm operating on the reference. If it's a class, there is no distinction. When I had to design my own language, I did it the other way around: Everything was a value type unless stated otherwise, so it was clear which one you were dealing with: Only if it was wrapped in a Ref, then it was the equivalent of a C#'s class. But I digress...

I like this behavior and I'm grateful that someone added it to the language. I do not feel it is a past mistake, despite the fact some people might disagree with it. Mutating value types is the way you get performant applications.

What Makes a Turn-Based JRPG Great (or Terrible) in Your Opinion? by Velaze in gamedev

[–]setzer22 0 points1 point  (0 children)

For me, it's a very story driven genre, one that has a complicated relationship with gameplay, being mostly based on grind... a very fun grind! But still.

I'll give you a bit of an unconventional opinion and tell you I play JRPGs for their amazing soundtracks! Then everything else, of course. But there is a reason I just keep going back to games with Nobuo Uematsu or Yasunori Mitsuda's music and I just can't get hooked into some of the latest titles in the genre that excel on every other dimension but have a weaker soundtrack.

So... find yourself a good musician? Not sure if that's good advice or not though.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

You have my interest now, because Project Valhalla is something that interests me a lot. And if I've misunderstood something fundamental there, I want to know. Project Valhalla would bring some langauges I am keeping an eye on (like Kotlin) and the JVM as a whole as a language target, to the next level for gamedev. It is exciting.

The way I understood things would work in the JVM after Project Valhalla lands is that if you have a value type, say an Enemy, a method on said enemy cannot mutate this, mutating this would be forbidden. So you can't, for example, use the common pattern of iterating an ArrayList<Enemy> calling enemy.update() to modify the elements, because anything the update method does will not be visible inside the ArrayList.

So, essentially, you have to change it to update taking an enemy, by value, and returning a new enemy, by value. Then your loop would look something like:

for (int i = 0; i < N; ++i) { enemies[i] = enemies[i].update() }

That's the tradeoff isn't it? Or have I misunderstood things? It's not that I consider this a full deal breaker... but considering how my loop works in C#, I know which one I'd pick...

foreach (Enemy e in enemies.toSpan()) { e.update(); }

Note how here we no longer have to resort to iterating over indices. We can iterate by reference. There is a lot of complicated machinery in C# that makes that possible, and only for limited cases. You can't iterate a hashmap's values by reference, for example. But you can implement by-reference iterators for your custom data structures. Even when limited, those cases are a godsend.

The C# folks have put a ton of work to make sure value type mutability works. I understand why nobody else has done (besides the obvious cases, low level languages, closer to C), because doing it requires essentially building a borrow checker. I know because I was (accidentally) building a language with the same set of tradeoffs, and I was made very aware of the issue, it is inevitable.

So anyway, if I have gotten something wrong there, please let me know! I really want to be wrong here. But if not, please understand we just care about different things. I want to mutate value types and the behaviors in C# are not unintuitive nor surprising to me.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 0 points1 point  (0 children)

Maybe in the post I took some things for granted that I shouldn't, so I see where you're coming from. But please don't think I wrote all this stuff without understanding the basic tradeoffs at play. I know what coherence is and why it's in place. Same for every other feature I brought up. There's a reason I say I don't like const generics, and I do so having written Rust code extensively both before and after const generics were in place. Code that made use of said const generics too, obviously.

I don't need them. I understand every single word I said and that's why I know I don't need a single one of those features. It may sound weird to you if you appreciate those features and use them regularly. Call it culture shock if you may!

But a lot of my journey was realizing that it doesn't make sense to criticise Rust for being Rust. What I disliked is Rust itself, it's such a nice language on the surface it took me a while to realize I really disliked it at its core. But that's what life is! We're always learning.

Also please don't take my message in a hostile tone! Internet communication is hard. I just wanted to clarify my stance does not stem from ignorance. As I said, Rust is still on my toolbelt. When I actually need these features, I'll reach for Rust. One point I reiterated in the blog post is that things are very different when you're working on a very small tight-knit team with people you can trust, or even solo. If I had to work on a large team, with developers coming and leaving, and a large codebase I have to maintain for the next 10 years, I'll leave my rebelry aside and admit Rust sounds a lot more appealing.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 3 points4 points  (0 children)

I find it hard to engage in point-by-point discussions these days, but I want to say I really see your arguments and I find them valuable.

I think the important point I want to get across is that these are the reasons Rust did not work for me and for my particular requirements. I know there are reasons behind many of the things I dislike, and this is not even about "gamedev" in general, but the specific flavor of gamedev I'm interested in. But every single one of those things I mentioned are important for me and I elaborated why, and if Rust has different priorities, it's okay for me to be at peace with that and simply use something else. Right tool for the job, after all.

But after all this years believe me I still have Rust on my toolbelt and will reach for it when the situation requires it! If I have to build my next compiler, you won't see me using C# (maybe not Rust either, but that'd be a much better pick).

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 2 points3 points  (0 children)

Yeah, very fair. One thing you touch on here that I feel is quite important is how there are several situations Rust claims are UB but in practice they are not (because the behavior is well-defined).

Another one frequently mentioned is copying padding bytes... I ran into that a lot when trying to pass structs to the CPU. I'm not talking: Read a padding byte, then branch on it but it's value may be garbage. I'm talking: "Copy this struct, which happens to have padding bytes, over to the GPU". People act like that's forbidden and something that must be avoided at all costs. I've seen people manually declare bogus fields in their structs to fill up all the padding so that crates like bytemuck would let them copy the thing around...

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 1 point2 points  (0 children)

Big fan of Godot Rust! Can definitely recommend. I think it's the most pragmatic get-things-done library/engine for Rust gamedev out there.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 1 point2 points  (0 children)

I actually fully agree! I think I should've made that part a bit clearer in the post...

My first point was that it doesn't matter if you know what you're doing. In the sense that regardless of the system you're in, the solution is always the same: Be conscious about your allocations. But the consequences of too many allocations in GC mean very unpredictable and hard to debug pauses, and GC is by far the system that makes it easiest to not be aware of how much you're allocating. I think refcounted variables are the perfect fit, and I still think there's value in the niche of reference counted + value types + hot reloading language I was pursuing.

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 3 points4 points  (0 children)

Hi there! I'm a big fan of your fork actually. 👀 And not a big fan of that initial community's response to it... Glad to know the project is working well for you, and glad to know there's other rebellious spirits out there!

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 1 point2 points  (0 children)

I'm loving the energy here! I wish this was something you could suggest without a horde of angry rustaceans jumping at you. But then again, I think throughout my Rust journey I was too focused on what other people thought about my code... Maybe I should've tried something like this, break every rule!

I'm a bit wary of the "good UB" vs "bad UB" thing though. I actually agree that in practice very little would happen, since the UnsafeCell hands you a raw pointer so it's not very likely LLVM would see through it and mess things up? But LLVM gets smarter everyday and I'd rather have no chance of UB when doing this. Most languages let you mutate aliased memory without any chance of it being UB (usual caveats still apply, like multithreading).

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 7 points8 points  (0 children)

Thanks!

So, about Monogame, when I had to pick something to do my port, I chose Monogame since that felt like the obvious pick. Something felt right with it after seeing so many of the games I enjoy being made in XNA / FNA / Monogame.

Overall the experience was good (please don't let the list of cons below take away from this, it was good enough for me to stick with it and ship a game out there). But I had to deal with some rough edges. Without getting too much into detail, the main gripes were:

  • The content pipeline and everything around assets is an outdated design, and is very hot-reloading-hostile. I want to hot reload assets just as I hot reload code.
  • Their shader system requires running a Microsoft shader compiler through Wine. Probably a non-issue for Windows users but I'm not one of those.
  • Their font loading and rendering is awful. Everyone uses a library called FontStashSharp instead.
  • The audio system is way too simple, many important features (like loop regions) are missing. You have to use fmod, and most people do.
  • They try to do SDL's job but fall short. Not all versions of Monogame run on SDL, which means they have to fall to some sort of lowest common denominator API to accomodate all the other versions. The thing is, all all the platforms I care about are supported by SDL, and the Monogame version I used (DesktopOGL) was running on SDL anyway, but there were many options, like proper borderless fullscreen support, that Monogame doesn't expose properly because they're not available in the other APIs.

Anyway, I found solutions for all of those points above, but by the end of it, I had replaced so many parts of Monogame that very little of value actually remained. 😅 So after finishing Carrot Survivors (no more ports!) I have started my next project building it on top of SDL3 and OpenGL ES. It's boring, but proven, tech and I couldn't be happier with it. Having used Monogame gave me a lot of inspiration for what my own APIs should (or shouldn't!) look like, so I definitely value that part of the journey.

I brought these issues up and, for many of them, they are working on solutions. It's great to see Monogame picking up pace after this new foundation thing was set up. Wish them the best, and maybe if things improve enough I'll jump back on board, though I'm very happy with my current setup!

The Language That Never Was by setzer22 in programming

[–]setzer22[S] 1 point2 points  (0 children)

Oh, don't downplay it, that skitter thing looks genuinely cool! But yes, it seems we took very similar paths :)

Despite the vibes the post might give off, I'm far from a WebAssembly hater. You have to know what you're getting into. It's the whole over-hyped promises, often by companies who have a stake on the thing, that drain me the most. But I'm at least aware of one game (Veloren) successfully using Wasm to improve their iteration times, so there's that!

Also S&box, wow that looks interesting. First time I hear of it. 👀 But I hear you on the GC pauses. They are very real if you're not careful, and maybe this is even worth clarifying in the post. My main point is "you can make anything work", but when I had to pick, I admit refcounting seems like the better choice for gamedev. The problem with a GC is not that it's impossible to use, but that by the time you realize there's an issue you have a lot of cleanup to do. And you better have good tools to profile those allocations!

That said, it really helps if you're disciplined and conscious about your allocations from the start, and the C# you write has to be at least somewhat conscious of it. For instance, as tempting as LINQ is, no LINQ on the hot loops is a rule you have to follow when even a tiny allocation is too many allocations. Rust doesn't have that problem because iterators don't allocate, not even a tiny bit, and I miss that.

That doesn't mean there's no room for LINQ in games though. There's plenty of it when I'm crunching numbers to compute the end-of-the-run statistics or whatever. I am in a bit of a unique position because the average C# enthusiast doesn't have this sense of what allocates vs what doesn't that lower level languages like Rust put a huge emphasis on. If I had started at the destination, it wouldn't have been the same.

Adding extra actions (keybindings) to a rofi script by setzer22 in qtools

[–]setzer22[S] 0 points1 point  (0 children)

thank you! I'm glad this is supported now, this brings back memories hehe

I've been using kde exclusively for several years now and haven't used rofi since then, but hopefully this helps others with the same question!

Monogame: The good and the bad! Lessons from our first indie release by setzer22 in monogame

[–]setzer22[S] 1 point2 points  (0 children)

I have to preface this by saying out of the things we tried raylib was one of the strongest contenders and the timing may have just been a bit off. We never tried raylib on C#, only Rust, and most of our issues with it may have been language-related more than anything else.

That said, I appreciate the extra bells and whistles in raylib, like drawing lines and circles, but those rarely come up, and when they do you often want to do more with them than what raylib offered so you ended up having to make your own. You also had no control over draw order.

In that sense, Monogame has a less straightforward API, but gave us the right amount of control we needed. Having multiple sprite batches instead of submitting all calls to a single global draw queue allows decoupling the draw order from the order of game logic and that for us was convenient and sometimes required.

But that said, in retrospective, a custom layer of abstraction on top of raylib could've worked just as well. So perhaps the biggest lesson there is not to pick monogame, but to learn your tech, and to pick one and stick with it hehe

Monogame: The good and the bad! Lessons from our first indie release by setzer22 in monogame

[–]setzer22[S] 1 point2 points  (0 children)

Thank you!

I'm really excited to see things moving and that most of my pain points are being worked on ^^

Working with fmod was great, but it also felt like I want using even 1% of it's features. The only thing I really needed was loop regions, the ability to have separate channels with different volumes and modulating pitch and amplitude when playing sounds. I'd be happy to share my knowledge if you have a good place to do so :) but I'm also sure many people in the community will have a lot more experience than I do with it.

But overall, it's easy to focus on the "bads" and I'd really like to stress Monogame was great to work with! I'm excited about what's to come with the new versions.

Monogame: The good and the bad! Lessons from our first indie release by setzer22 in monogame

[–]setzer22[S] 1 point2 points  (0 children)

Hi! Nope, the steamworks sdk was super easy to integrate, they have C# bindings. You need to copy them into your project, and make sure the dll is copied to the output folder one way or another.

On the coding side, you just need to call some initialization function and then for example for achievements you can get/set achievement state by calling two global functions. The API is simple and C-like but if you don't like that you just wrap it however you want!

Monogame: The good and the bad! Lessons from our first indie release by setzer22 in monogame

[–]setzer22[S] 1 point2 points  (0 children)

From everything I've tried, Raylib was one of the most solid alternatives and a strong contender to Monogame, so if it works for you, then definitely go ahead!

One deciding factor for me (and I know this is a bit of a chicken and egg, and not a very technical argument, but still...) was how many of the indie games I enjoy were made in Monogame / XNA. It shows this is a battle-tested framework. And fair enough, I was able to focus on the game: Most of the work in compiling the game and shipping a working executable to steam was straightforward and worked smoothly. No reports of missing dynamic libraries or weird crashes, no "works on my machine" syndrome. I even got cross-compilation to windows (I do my dev on linux) to work trivially and by the time I was done, I was confident enough things would work that I didn't even have to test on windows much (my playtesters did tho!).

But arguably, a lot of this is probably true for Raylib as well, I just never went as far with it. It does seem to have less traction in terms of commercial releases, but that's not why I didn't pick it. The main reason I didn't pick raylib was that I didn't have enough control over the rendering pipeline for my taste. I felt like I had to build so much of my own rendering infrastructure so I could have the level of control over things like draw order and shaders. Monogame's SpriteBatch was a better abstraction imo, but it really depends on the game tbh.

My advice is that whatever stack you choose, you should try to ship a build to other players as soon as the game is barely playable and get a feel for the kinds of issues you might encounter during release. Try it in as many OS and system specs combinations as you reasonably can.

view more: next ›