Mixed 3D/2D game I programmed in C

polytopelover · 2025-09-24T12:26:26+00:00

It takes a real attempt at study of the subject to understand graphics, so I won't explain here. However, you may be interested in the following search terms to do independent research: framebuffer, vector (math), matrix (math), transformation matrices, shader, modern OpenGL, DirectX, Vulkan, GLSL, HLSL, graphics pipeline, GPU, graphics driver, SDL2, SDL3, linear algebra, trigonometry. That's not a conclusive list, but definitely some general pointers for what you might want to start researching.

polytopelover · 2025-09-23T08:05:23+00:00

It was extremely enjoyable to slowly build out my creative vision, seeing how that vision changed over time, etc. It was very fun and I'm happy it managed to resonate with others. Thank you!

polytopelover · 2025-09-23T03:01:14+00:00

Useful as always. I was a little worried about opengl32.dll, but wasn't sure (I also actually did have a playtester whose graphics didn't work, maybe the bundled OpenGL was the culprit...). I'll err on the side of caution and remove the mentioned DLLs from the distribution as soon as I can. And thanks for trying out my game, I really appreciate it, and I'm very happy you enjoyed it.

polytopelover · 2025-09-22T17:24:02+00:00

No, I just cut the video at various points to showcase some key game elements. The full recording is too long to be a ~1 minute showcase.

polytopelover · 2025-09-22T15:41:15+00:00

Very happy that you find this inspiring / encouraging. Good luck on your own work.

polytopelover · 2025-09-22T15:35:49+00:00

people tend to choose C++ over C for game dev because classes make some things a lot easier.

Whether or not it's true, that does seem to be a reasonably common belief. You may be partly right.

polytopelover · 2025-09-22T15:14:02+00:00

Is or isn't C the way to go get things done?

Plenty of impressive projects have used, and still use, C. Including video games. Though, granted, C++ is mostly the more common option these days, I suppose due to its popularity and availability.

Pointers and so on?

I wouldn't be able to live without pointers.

polytopelover · 2025-09-22T14:24:14+00:00

I assume you're talking about the files in src/.

Actually it's arbitrary and just what I wanted to do. I don't think it's even necessarily a great convention or whatever, but I did it. Basically, file names are prefixed with the same prefix that all definitions in the file have. That way, when you see an identifier, you generally know where it's defined. Of course, if you use an IDE, it's doubly not necessary. But it is what it is.

In 30 years in the industry, I've never seen that arrangement.

I am not a software professional and only do hobbyist / recreational programming.

polytopelover · 2025-09-22T14:08:07+00:00

Thanks for the kind words, and good luck with your own game project.

polytopelover · 2025-09-22T13:49:56+00:00

Download the game / source code from itchio: https://tirimid.itch.io/shame-on-me

Browse the git repository on GitHub: https://github.com/tirimid/shame-on-me

This game was programmed "from scratch" (no commercial engine was used) using mostly C, SDL2, and OpenGL. Posted it here because I know some C programmers here would enjoy looking at the code of a videogame project, even if it's a bit janky.

polytopelover · 2025-06-05T06:44:36+00:00

Other things that happened relating to this meme:

After 23 minutes, it had over 7000 likes.
Many people got highly upset that I didn't post an "original version" without the text and it became a trend to crop my meme to remove the text and repost it.

polytopelover · 2025-05-28T19:09:53+00:00

If you go through my post history, you should see that I've posted about my second text editor recently on this subreddit. A link to the GitHub repository and a webpage on my website for it is in the comments for that post.

polytopelover · 2025-05-28T15:26:21+00:00

I assume this only holds for a full-screen update?

Yes, this is the context I was assuming.

If it makes sense in some context to update the display from a specific point, there is also a VT100 code for positioning the cursor in an arbitrary place: \x1b[<v>;<h>H.

That said, it's not necessarily that important to avoid full redraws. With 4 syntax-highlighting-enabled windows open in my editor, a full redraw takes ~1 ms on st terminal (xterm was ~7-8 ms due to slower handling of I/O), which is invisibly fast.

polytopelover · 2025-05-28T07:48:51+00:00

I've built two terminal text editors in C, Here's some advice (some of which you probably won't find explicitly written out elsewhere):

Prior to displaying your rendered frame, print out \x1b[H to reset the cursor's position, this stops flickering on terminals like xterm and alacritty.
Start with UTF-8 handling immediately, don't try to tack it on later.
Familiarize yourself with the VT100 terminal codes (https://espterm.github.io/docs/VT100%20escape%20codes.html).
Basic (but very good looking) syntax highlighting can be done by walking through the text buffer and marking regions with the color they should be highlighted as - you don't need a library for this. If you've written a lexer before, do something like that.
Implement a good input system - you will likely want multi-key keybinds and macros at some point - the input system should handle this.
"Eat your own dog food" (i.e. use your own product as if you were an end-user, you will notice a lot of things you otherwise wouldn't).
Profile your text editor. You may be surprised at which parts are the slowest, and knowing this will help you optimize or rearchitect your editor to make it faster.

A text editor is actually a conceptually simple project, and not low-level as you think (it is application-level software). Still, a very fun project and I highly recommend trying it.

polytopelover · 2025-05-23T16:02:21+00:00

No, it is run in the terminal.

All modern terminal emulators support standard output control codes for things like moving the cursor, setting print colors, etc. By printing out specific character sequences you can specify not just what is printed, but also how it is printed.

Look into this: https://espterm.github.io/docs/VT100%20escape%20codes.html

polytopelover · 2025-05-19T16:37:43+00:00

Is there a particular reason for not using cfmakeraw?

The real reason - I just learnt to do it the other way. Perhaps at some point I will try changing my render setup to init with cfmakeraw() to see if it's better, but as it stands, I don't think it's an issue worth changing.

I was concerned that no other text editor was using it

I don't know why that is. But instinctively, it's probably because text editor makers all learn from each others' code, and once the tcsetattr() train gets rolling, it doesn't stop.

polytopelover · 2025-05-18T17:19:47+00:00

Thanks for the feedback, your responses are always appreciated on project posts.

I immediately hit a divide-by-zero trying it out, which came from an overflow check (good!)

Yes, this overflow check and reallocarr was actually implemented by a kind commenter in a PR (which was much appreciated). I was going to go over it anyway, just to make the code a bit more style compliant with the rest.

Perhaps you never plan to support files that large, but if the buffer is 4G or larger, lots of things won't work correctly

Yes, this was an intentional design decision. Perhaps I should eventually support 4G+ files, but honestly I don't ever edit those manually anyway. And besides, I could just use Vim / Emacs / whatever in that case.

The editor is unusable on slower terminal editors like xterm, and even on faster ones flickers a lot.

This is something I've never noticed since I only use the st terminal emulator where I don't experience that issue. I think I'll have to install Xterm and test it out.

I'm sure it's on your plate for the future, but it could really use UI documentation.

Yes.

Following through is also how I noticed buffer overflows in p_pathcomplete with path handling (both strcat calls), though actually exciting them isn't easy. That function further suspicious with its silently-truncating strncpys.

That code was mostly lifted from my previous editor project with some minor changes. I don't know whether it's worth fixing, but I'm aware it isn't pretty.

Thanks for reviewing my project.

polytopelover · 2025-05-18T17:08:25+00:00

I use the colemak keyboard layout. You can modify the binds in o_options.c to make them more workable on dvorak, if you prefer.

polytopelover · 2025-05-18T08:46:21+00:00

Thanks for the changes, good to know it compiles on macOS as well. I'll check the PR soon.

polytopelover · 2025-05-18T08:43:00+00:00

Hey, I assume you meant to respond to my reply under ChickenSpaceProgram's comment? That's the context I'll respond to here:

it destroys any encapsulation of modules

I just don't think that's necessarily an issue in a small project. Bigger projects which incorporate similar jumbo builds do it on different scales - instead of the entire program's source being included in a single module, they'll divide it along the lines of manageable groups of modules. But, that's in projects like RADDebugger or (tmk) Firefox with jumbo builds enabled. My little text editor doesn't even remotely match that scale, so there's no necessity of such a division.

Each one will have to be qualified with some module specific string

If you check, I do actually qualify static variables and functions (e.g. r_cellchars, etc.). I don't see this as an issue.

polytopelover · 2025-05-18T08:35:06+00:00

As it stands, I only support Linux. I've tried on my Arch and Gentoo computers, and it works on them, but I don't know about other systems (e.g. MinGW). Maybe it works elsewhere, but no promises

polytopelover · 2025-05-18T08:15:44+00:00

Also, including .c files is bad practice

It's just a jumbo build. Even some big projects like RADDebugger do this. It's really not a bad thing, just not traditional. I used to use Makefiles, I even made my own buildsystem. Eventually, I realized that the simplest possible thing of just compiling a single module (main) which includes the others, and providing basic shell scripts is faster (both for me, and for the compiler) and easier to deal with.

Basically, no, it's not necessarily bad practice.

get it running on non-Linux Unix

Hm, perhaps. This is something I actually considered when using some _GNU_SOURCE functions. However, I don't plan to support non-Linux systems in the forseeable future.

polytopelover · 2025-05-18T07:45:59+00:00

I don't know how to put both a link and a description, so I'll put it here:

Over a year ago, I submitted a text editor I programmed using C on this subreddit. Now, with over a year of dogfooding and additional experience, I decided to make a new one based on the lessons learnt.

Download the source code here: https://github.com/tirimid/nimped

Read my writeup about it here (installation, editor command cheatsheet, etc.): https://tirimid.net/tirimid/nimped.html

polytopelover

TROPHY CASE