I built a small ECS that uses dense arrays for components but the entity list per component pool is always as long as the largest entity-id. Is there some nifty trick to keep the entity-arry dense as well? Not *really* a concern but if I have 1000 entities in the world and only one of them has the CoolComponent then there is an array in the CoolComponent Pool with 1000 entries and only one is being used.

Why does Quake get all the fame for being the first "true" 3D game? Tomb Raider 1 also came out in 1996 and was as much 3D as quake. I actually think Tomb Raider is the better game 😬 (don't kill me).

Saw this clip of Uncle Bob saying he doesn't write/read code anymore but just uses Grok.

What more proof do you need that he was selling snake-oil all along?

OK, fuck it. I am going to write a new game engine in very little small sessions. Put it on youtube. It probably will be bad and cannot match what current frontier models build and is going to take much longer. But it will be fun. I am going to use code from books, though, when the license permits it. Source will be mentioned so people can read the books. And I am going to use a ton of libraries.

I don't believe in this "model harnessing stuff". I get in a very nice flow-state when programming. But I believe AI now matches my programming abilities. Fully aware that I shouldn't write this publicly because it doesn't help to find a job. But I think it is the truth. Sure, in theory I am a better match to use those models for coding than someone who isn't a programmer in a work-environment. But I don't think this is fun/rewarding/etc. Maybe do something else and just code as a hobby?

I am feeling bummed out. I had written some code the last few days and got to learn SDL3 gpu a bit to use compute shaders on all platforms. All the stuff I did is being done faster and better by AI. I let claude opus 5.5 create a base sdl3 gpu compute shader template for me and it even did all the glsl -> spirv-cross -> dx/msl on compile (if set) and link it into the source as binary blobs. Stuff that I hadn't done yet. The code is sound. What's my purpose now?

C programmers:

What C standard are you using? Leaving out the minor versions and C23 didn't fit in this poll ;)

In comments please say why.

007 First Light, built on glacier engine, runs without hickups on my PC. Many unreal engine games from many years ago (jedi fallen order comes to mind) don't, at all. Why?

Looking for a gamedev/graphics job in Munich. Most comfortable in C/C++ on desktop (Linux/Win/MacOS) + OpenGL and Vulkan. Experience in Python/Perl/Java/Bash. But can do pretty much anything you throw at me.

If you know anyone, I'd appreciate a DM :)

Thanks a lot!

I guess this must be my last commit for this year.

It was fun. Bye.

RE: https://mastodon.gamedev.place/@pythno/117222732418275794

I take it back. I'd rather struggle with Python than let the earth burn.

Also: Just because *I* don't enjoy it, others may get the same zen-state-feeling I get when coding in C.

Taking that away from someone is not what we should do, I think.

I don't blame anyone using AI, though. Stamping people with my own morals is also not what I want. Unless you put out f'ed up stuff into the world like DHH does in his blog-posts.

Watching the apple event. I guess that is what the young folks call "cringe" ;)

Also there are parts in the code that are convoluted and just not good. The comments make no sense at all sometimes. I don't get the hype about it. I find local, small models more useful for very particular, small things, if at all. I'd love to know other people's experiences.

So I baught the base Claude subscription today because I wanted to see what Claude Opus 5 can do. I told it to build a networked game, like the one I built over the last week. Yes, it works. But badly. The jitter is very noticable. I explicitly told it multiple times what the issue could be and it "fixed" it. It never worked well. I tested this by running the server on my VPS and connected multiple client. It just isn't good enough. What are people smoking when they tell me "coding is solved"???

In the past I thought that explicitly passing an allocator to a function is inconvenient. I still find it a bit "ugly". But the thing is, you can now know what kind of memory that thing touches/needs by just looking at the header-file, eg:

int init_door(Door* door, Arena* persistent);

I know that the door entity will consume memory as long as the program runs.
And I know it probably can be referenced by other things without worrying about touching memory I don't own (anymore).

This is going to be a very unpopular post but here I go:
For me, Python is a language that is ought to be written by AI. I have written a ton of non-trivial python code over the last few months and I just hate it. Main problems:
- "Pythonean" way of eg. accumulating data into a list: I have trouble reading those one-liners.
- No static typing: I just need types. Types are incredibly useful for reading/writing/debugging code.

I love to write C/C++ and I don't let AI near it.

Anyone interested in participating in a new book that follows into the footsteps of the "Game Programming Gems" series?
Looking for industry veterans and/or experienced enthusiasts. @TomF @demofox @Doomed_Daniel @floooh @reduz @dotstdy @Donzanoid @sol_hsa @pekkavaa @kwramm @bero @sascha @rcl et. al. come into mind.

In times of AI generated stuff a resource that one can trust is more important than ever.

@TomF Oh wait, we talk about fixed sized arrays? Well, ok, then... ;)

Ugh, people rage about the main character in Naughty Dog's new Intergalactic character. Because she is... I don't know? Of color? Asian? They claim that studios make women "ugly". Not sure if I am late to the party but this seems a thing right now. I think she looks amazingly beautiful. Great character design right there.

Planning a Doom3 MD4 Exporter for Blender. But I figured this will almost be entirely written in C having a thin interface between Blender and my C program. Writing Plugins entirely in Blender's Python API is just not cool. And way to slow.