#c programming

[mystery-incorporated-whore]

BRB gonna invent hypercube C

It's a time-agnostic programming language

You can run code last week

[cool-retro-term-official]

PROGRAMMERS OF ALL KINDS AND SHAPES, PLEASE UNDERSTAND THIS

A code that doesn't have comments, even if it's well written, is not always very good code. When you want to optimize your code, you're might have to write ugly stuff sometimes ! Look at what data oriented design can produce for example. When optimization introduces unreadability, even if everything else is amazingly written, you need to add comments.

Anyway, use your cli tools on me plz, im cool, im pretty, look at me, blip bloop, blip bloop ❤️💾

[lisheart25]

[forever-stuck-on-java-8]

Over the past half century, An unknown number of masters of sophistry have pulled their effort into developing the C compiler. The compilers ability to optimize exceeds all limits accessible to the human mind. The compiler will make your terrible mess beautiful and performante. Put your faith in the compiler, it is a better programmer than you will ever be.

[castur1]

Programming? On my Tumblr?

It's more likely than you think >:3

So anyways here's an early tech demo for a lil project I've been working on. I'm making a game in pure C without any external libraries or game engines or whatever, writing everything from the ground up. Why? To see if I could. And also because I hate myself.

This bad boy's got low-latency audio output with a custom audio mixer and WAV file loading, input handling (keyboard + mouse, no controller support yet), and a basic graphics renderer (with BMP file support), as well as some other fun little features. It's built on the Windows API but all the platform code is isolated so that the game can easily ported. And what grand creation shall I make with this? ...Tetris. I'm planning to make a Tetris clone. Lol.

Oh, and the tetris remix you hear in the background? Wrote that myself. Music was never my strongest subject but I am determined to make everything by myself.

That is all.

[a-fox-studies]

November 22, 2023 • Wednesday

5 hours of focus today! We're making progress with the syllabus :3 4 days until exams begin. I feel only a little prepared, hopefully I become more confident soon.

🎧 Forever Winter - Taylor Swift

[etoastie]

Where does the undefined behavior go?

In the square hole!

[bynux]

My gender is a poorly written C program, in which a target 35–60% of the dedicated memory is assigned to femininity, 10–20% to masculinity, and the remaining 20–55% defaults to androgyny.

Its goal is to maintain a state such that femininity is at least the plurality, if not the majority, of the memory space, but occasionally it fails to do that for code reasons? idk I didn't program it and it's not open-source ._.

Observe:

[root@bryn ~ ]$ genderinfo Bryn's Current Gender Composition Femm - 40% [WARN] (LOW) Masc - 15% [ OK ] Andr - 45% [WARN] (HIGH) Closest estimation - enby, femme-leaning [root@bryn ~]$ _

[fuckmarrykillpolls]

[bedlam-moon]

designing a c compiler that when it hits undefined behavior:

emails zip bombs to the c standards committee

formats your hard drive

[gameeditor2]

"C programming man"

💻If you spend hours coding, fighting bugs, and living on coffee, this song is for you.

🎧 Listen here:https://youtu.be/Ldoe3feFlQE?si=FVDQkwCsCwxhMX-T

[cool-retro-term-official]

today's gender is a segfault caused by some obscure library you don't even rember linking.

[creamsicle-art]

Game Development in Raylib - Week 1

Recently I've been getting into retro game development. I don't mean pixel art and PSX style game development, those are nice but they don't quite scratch the itch. I'm talking about developing games with retro tools. Because of this, I decided to give Raylib a try.

For those of you who don't know, Raylib is a C framework targeted at game developers. Unlike Godot, which I used for my previous project Ravager, Raylib is not a game engine, it doesn't offer physics, scene management, or any kind of graphics more complicated than drawing textures to the screen. Almost everything that makes a game a game, is something you have to do yourself. This makes it ideal to scratch that "retro" itch I've been feeling, where everything has to be made on my own, and a finalized game is a fine tuned engine entirely of my own creation. Raylib offers bindings for almost any language you can think of, but I decided to use it's native C.

Setting the Scene

Since Raylib is so barebones, there's no concept of how the game should be built, so the first thing I had to do was define my engine architecture. For this initial outing, I decided to build a simple Scene+Actor system, wherein at any given time the game has one Scene loaded, which contains multiple Actors. I settled on this mainly because it was simple, and my experience with the C language was very limited.

Since Raylib didn't have any concept of a Scene, naturally it had no way to build them. While I could just hardcode all the entities and graphics in a scene, that would be unmanageable for even a basic game. Because of this I was forced to invent my own way to load scenes from asset files. This gave me the opportunity to do one of my favorite things in programming, defining my very own binary file type. I won't get into it too much right here and right now, but in this format, I can define a scene as a collection of entities, each of which can be passed their very own long string of bytes to decode into some initial data.

The main drawback of using binary files instead of a plaintext format is that I can't write the level files by hand. This meant that I had to write my own level editor to go along with my custom engine. Funnily enough, this brought me right back to Godot. The Godot engine offers some pretty powerful tools for writing binary files, and it's editor interface automatically offers everything I need in the way of building levels. It's sort of ironic that my quest to get away from modern engines lead me to building yet another tool in Godot, but it sure as hell beats building a level editor in C, so I don't really mind all that much.

Getting Physical

After getting scene management out of the way, I moved on to the physics system. My end goal here is making a simple platforming game, so I wanted a simple yet robust system that allows me to have dynamic-static physics that allows for smooth sliding along surfaces, and dynamic-dynamic collisions for things like hitboxes. For the sake of simplicity (which seems like it's going to become my catchphrase here) I decided to limit physics to axis aligned rectangles. Ultimately I settled on a system where entities can register a collision box with the physics system and assign it to some given layers (represented by bit flags). Then entities can use their collision box to query the physics system about either a static overlap, or the result of sweeping a box through space.

Raylib offers built in methods for testing rectangle overlap, so I didn't have to worry much about overlap queries, but the rectangle sweeping method is something a little more special. The full algorithm honestly deserves it's own post, but I'll give the basics here. The core of the algorithm is a function that determines where along a movement a given rectangle touches another rectangle, and that edges of the rectangles touched. It makes use of the separating axis theorem to determine when the shapes will start and stop intersecting along each collision axis. If the last intersection happens before any have ended, then the shapes do collide, the axis they collide on is that final axis, and the time of collision is the time of the final intersection. Looking back I could easily extend this algorithm to any arbitrary shape, but that's for next time I do this.

Going Forwards

My plan for this game is to build a minimal metroidvania style game. The target playtime is probably going to only be around 30-45 minutes. In the following week I plan on building out my Godot level editor, and working out a system for scene transitions and managing sound effects. I hope to by done by the end of November.

[owo-mochji]

hey wanna hear about the crescent stack structure because i don't really have anyone to tell this to

YAYYYY!! THANK YOU :3

small note: threads are also referred to internally as lstates (local states) as when creating a new thread, rather than using crescent_open again, they're connected to a single gstate (global state)

the stack is the main data structure in a crescent thread, containing all of the locals and call information.

the stack is divided into frames, and each time a function is called, a new frame is created. each frame has two parts: base and top. a frame's base is where the first local object is pushed to, and the top is the total amount of stack indexes reserved after the base. also in the stack is two numbers, calls and cCalls. calls keeps track of the number of function calls in the thread, whether it's to a c or crescent function. cCalls keeps track of the number of calls to c functions. c functions, using the actual stack rather than the dynamically allocated crescent stack, could overflow the real stack and crash the program in a way crescent is unable to catch. so we want to limit the amount of these such that this (hopefully) doesn't happen.

calls also keeps track of another thing with the same number, that being the stack level. the stack level is a number starting from 0 that increments with each function call, and decrements on each return from a function. stack level 0 is the c api, where the user called crescent_open (or whatever else function that creates a new thread, that's just the only one implemented right now), and is zero because zero functions have been called before this frame.

before the next part, i should probably explain some terms:

- stack base: the address of the first object on the entire stack, also the base of frame 0

- stack top: address of the object immediately after the last object pushed onto the stack. if there are no objects on the stack, this is the stack base.

- frame base: the address of the first object in a frame, also the stack top upon calling a function (explained later) - frame top: amount of stack indexes reserved for this frame after the base address

rather than setting its base directly after the reserved space on the previous frame, we simply set it right at the stack top, such that the first object on this frame is immediately after the last object on the previous frame (except not really. it's basically that, but when pushing arguments to functions we just subtract the amount of arguments from the base, such that the top objects on the previous frame are in the new frame). this does make the stack structure a bit more complicated, and maybe a bit messy to visualize, but it uses (maybe slightly) less memory and makes some other stuff related to protected calls easier.

as we push objects onto the stack and call functions, we're eventually going to run out of space, so we need to dynamically resize the stack. though first, we need to know how much memory the stack needs. we go through all of the frames, and calculate how much that frame needs by taking the frame base offset from the stack base (framebase - stackbase) and add the frame top (or the new top if resizing the current frame in using crescent_checkTop in the c api). the largest amount a frame needs is the amount that the entire stack needs. if the needed size is less than or equal to a third of the current stack size, it shrinks. if the needed size is greater than he current stack size, it grows. when shrinking or growing, the new size is always calculated as needed * 1.5 (needed + needed / 2 in the code).

when shrinking the stack, it can only shrink to a minimum of CRESCENT_MIN_STACK (64 objects by default). even if the resizing fails, it doesn't throw an error as we still have enough memory required. when growing, if the new stack size is greater than CRESCENT_MAX_STACK, it sets it back down to just the required amount. if that still is over CRESCENT_MAX_STACK, it either returns 1 or throws a stack overflow error depending on the throw argument. if it fails to reallocate the stack, it either throws an out of memory error or returns 1 again depending on the throw argument. growing the stack can throw an error because we don't have the memory required, unlike shrinking the stack.

and also the thing about the way a frame's base is set making protected calls easier. when handling an error, we want to go back to the most recent protected call. we do this by (using a jmp_buf) saving the stack level in the handler (structure used to hold information when handling errors and returning to the protected call) and reverting the stack back to that level. but we're not keeping track of the amount of objects in a stack frame! how do we restore the stack top? because a frame's base is immediately after that last object in the previous frame, and that the stack top is immediately after the last object pushed onto the stack, we just set the top to the stack level above's base.

[zoeythebee]

So not super visually interesting, but what i've added is actually very interesting.

Basically I had no way to neatly define actions. I had three seperate places where the player could theoretically get an item. And as the project would grow there would be more and more of these. Which would just be huge switch statements that would be almost identical to eachother.

Secondly, in this game many actions take time. For example digging a bush would take a few seconds. I needed a way to hold onto an action, and then send the player into a loop where they would work for the allotted time. And once that was up actually complete the action they were assigned.

Thirdly, I am in C. Which means there is no way to generically define objects with their own method. Like I can't attach a "dig" method to a tile object and just call it. So in C I used a collection of enums and function pointers.

This is the code that shows it off

So every action has an 'action_add' function. That accepts an action, and some parameters. Where we add the action to an array, and add the required data to the actions data buffer. Which we do with some fun pointer shenanigans.

Also yeah I know there is a few inefficiencies here don't worry. The realloc and memcpy lines at the end is where the real magic happens.

And then do_action takes an action. Iterates through it's actions array. Pulls out the required chunk of data, and passes it into a function pointer.

The function it runs in this case being,

Blammo! Generic action handlings! Now whenever I want the player to destroy a tile and get an item I can handle it with much less code. The only draw back is this whole system requires some book keeping. But I am reasonably sure if something breaks it will be fairly obvious what is going wrong. And the fix may just being slightly rearranging some arrays.

I feel very clever hee hee.