Writing a game engine in pure C: The Graphic Initialization
prdeving.wordpress.com
Writing a game engine in pure C: The Graphic Initialization
1–10 of 129 posts
Re: Writing a game engine in pure C: The Graphic Initialization
#2Reading the title my mind immediately went to
mov ax, 13h
int 10h
Re: Writing a game engine in pure C: The Graphic Initialization
#3For more inspiration I'd check out the Quake engine source. It's quite the masterpiece. There's also been some modernization over the years by LordHavoc of the DarkPlaces engine https://icculus.org/twilight/darkplaces/ - I'm constantly impressed how well the HD remaster on DarkPlaces looks on modern 4k hardware.
Re: Writing a game engine in pure C: The Graphic Initialization
#4Seems like it is going to take a long time to get to a fully functional game if this is the second article and they're only just calling SDL_CreateWindow.
Re: Writing a game engine in pure C: The Graphic Initialization
#5Alternative title of this article: "Self mutilation"
Re: Writing a game engine in pure C: The Graphic Initialization
#6Reading the title my mind immediately went to mov ax, 13h int 10h I'm old.
I'm not that old, I would have used a higher level C function to call the bios
(And use VESA modes like 640x480x256 - thank Deity for DJGPP)
Re: Writing a game engine in pure C: The Graphic Initialization
#7Seems like it is going to take a long time to get to a fully functional game if this is the second article and they're only just calling SDL_CreateWindow.
One post a week is about as fast as most people can go if they are into nuts-and-bolts technical topics and they are trying to juggle work and life and other demands on their time. That's about the best I could ever manage when I used to be blogging as I learned DirectX. And that was using C#, so you didn't have to boil the ocean and implement all your own fundamental data structures as you go (see the previous post in this series).
It's four and a half years into Handmade Hero at this point :-)
Re: Writing a game engine in pure C: The Graphic Initialization
#8Starting with state management in the first post is a different approach I wouldn't normally expect.
That being said I don't know what it is but I prefer writing games in C. I experiment with higher level languages and use them for rapid prototyping. However, and maybe its simply nostalgia, I always come back to C.
And it's not even my favorite language by a long shot. For practically everything else, save for systems programming, I prefer languages like Common Lisp and (more recently) Haskell. Imperative programs are notoriously difficult to comprehend and maintain but there is something about game programming specifically that C leverages which makes it a good fit for game engine development; the mix of pointers and machine-sized types perhaps? I'm not sure. But it works really well.
Re: Writing a game engine in pure C: The Graphic Initialization
#9Reading the title my mind immediately went to mov ax, 13h int 10h I'm old.
Oh man, the memories. It was such a revelation discovering how much faster it was to POKE pixels directly into memory in QB rather than use the PSET built-in. And then much of that knowledge was directly transferable to Turbo Pascal and later C.
it really boggled the mind that it was possible to blt a sprite in rows rather than a pixel at a time, and under the hood, the computer was actually copying 4 bytes per instruction. Anyone else remember implementing the 320 row offset as the sum of two bit shifts? By the early 2000s, I seriously doubt that was any faster, but we all did it anyway for "performance".
And don't even get me started on palette hacks— redefining the 256 colors into bars of dark-to-light runs of a single colour, so that you could do smoke or halo effects by just shifting every affected pixel by one or two in either direction.
I don't know if he's around these days on HN, but a shout-out to Mark Sibly (Blitz) for bringing a lot of this stuff to the QBasicNews forum back in the day.
Re: Writing a game engine in pure C: The Graphic Initialization
#10Seems like it is going to take a long time to get to a fully functional game if this is the second article and they're only just calling SDL_CreateWindow.
Well, the point is to learn how to build an engine with modern capabilities (those that you are supposed to use with C++ like namespaces, methods, ECS architecture, networking...), SDL is just a tool to not having to write the whole window/input/media/opengl logic from scratch.
I could write a SDL tutorial and make a game in 3 hours; it's not as interesting i think, for me the objective is not to write a game but to explain how engines works and desmitify them a little :S
But you are right, it'll take a daaamn long time. I've the third and the forth parts almost ready, covering the engine architecture itself, the private scene scope and the image->texture->sprite stuff but i havn't started yet with ECS, fs, configurations, physics, networking... this field is really extense.