Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing a game engine in pure C: The Graphic Initialization

prdeving.wordpress.com

Post reply on HN
Print view View original

31–40 of 129 posts

Re: Writing a game engine in pure C: The Graphic Initialization

#31

Post by the_af »

AceJohnny2 wrote: post #30
obituary_latte wrote: post #22

Interested people may also be interested in Handmade Hero[0]. The game is being developed — from scratch, engine and all — in real-time and streamed by Casey Muratori. It’s cpp technically, but he uses very little and sticks to mostly C if I remember correctly. [0] https://handmadehero.org/

Handmade Hero is an impressive endeavor, but by now it's got over 500 1-2h sessions. That's a lot for anyone to catch up on. Have there been any efforts to write episode summaries/articles on the techniques he demonstrates?

I'm not following Handmade Hero, but out of curiosity: why does it matter how many sessions are there? It's not like watching Game of Thrones where people can spoil it for you. You can follow the tutorial at your own pace :)

Re: Writing a game engine in pure C: The Graphic Initialization

#32

Post by rzzzt »

mikepurvis wrote: post #9
mhd wrote: post #2

Reading 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 instr…

y (I think the bit shifting and addition trick would still win over an IMUL.)

Edit: also, wasn't there a way of (ab-)using LEA to do some of this?

Re: Writing a game engine in pure C: The Graphic Initialization

#33

Post by buba »

AlexMax wrote: post #29
agentultra wrote: post #8

Starting 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 system…

I have some recent experience with doing game programming in C and while I think the experience was overall positive, I'm not sure that I would do it again unless my aim was portability. I found that when my project grew to a certain size, I started running into many cases where I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance. This pattern…

interesting, i'd suggest you to follow the blog, iv'e already implemented something like a dynamic array in the first post and will have to implement some other "modern" things in the near future, it's awesome what you can do in C89

Re: Writing a game engine in pure C: The Graphic Initialization

#34

Post by buba »

obituary_latte wrote: post #22

Interested people may also be interested in Handmade Hero[0]. The game is being developed — from scratch, engine and all — in real-time and streamed by Casey Muratori. It’s cpp technically, but he uses very little and sticks to mostly C if I remember correctly. [0] https://handmadehero.org/

handmade hero is a piece of art, upvote

Re: Writing a game engine in pure C: The Graphic Initialization

#35

Post by buba »

Sir_Cmpwn wrote: post #19

Personally, I prefer GLFW over SDL: https://www.glfw.org/ GLFW just goes from zero to OpenGL context ASAP, plus input events. With SDL I found that their drawing primitives are too limiting for my needs, and if you want to do any custom drawing at all, you need to abandon their drawing primitives entirely and just write GL codel. At that point, GLFW makes more sense. SDL does have a few other nice things like audio s…

my first idea was to use glfw indeed, but i took SDL cause it's easier to set up and it gives me audio, image loading/parsing and input.

The project will not stick to SDL anyways, the idea is to use it as a high level API, not to build a game with SDL. I would like to use this engine for PSP also, and i'll have to take SDL out and put osLib in. problems for future me...

Re: Writing a game engine in pure C: The Graphic Initialization

#36

Post by vvanders »

AlexMax wrote: post #29
agentultra wrote: post #8

Starting 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 system…

I have some recent experience with doing game programming in C and while I think the experience was overall positive, I'm not sure that I would do it again unless my aim was portability. I found that when my project grew to a certain size, I started running into many cases where I needed many implementations of some base type, the kind of pattern that lends itself well to classes and simple inheritance. This pattern…

In all my gamedev I've found that the best structure was how Lua does meta-tables.

You can then use that simple mechanism to implement inheritance, component based design, message passing or whatever structure makes the most sense for your game design. I'm personally tend to lean towards component based for reusability and performance but that's by no means a hard-and-fast rule.

Re: Writing a game engine in pure C: The Graphic Initialization

#37

Post by dang »

bananatron wrote: post #5

Alternative title of this article: "Self mutilation"

Could you please not post unsubstantive comments to HN? We're trying for a bit better than internet default here.

https://news.ycombinator.com/newsguidelines.html

You might also find these links helpful for getting the spirit of this site:

https://news.ycombinator.com/newswelcome.html

https://news.ycombinator.com/hackernews.html

http://www.paulgraham.com/trolls.html

http://www.paulgraham.com/hackernews.html

Re: Writing a game engine in pure C: The Graphic Initialization

#38

Post by theossuary »

AceJohnny2 wrote: post #30
obituary_latte wrote: post #22

Interested people may also be interested in Handmade Hero[0]. The game is being developed — from scratch, engine and all — in real-time and streamed by Casey Muratori. It’s cpp technically, but he uses very little and sticks to mostly C if I remember correctly. [0] https://handmadehero.org/

Handmade Hero is an impressive endeavor, but by now it's got over 500 1-2h sessions. That's a lot for anyone to catch up on. Have there been any efforts to write episode summaries/articles on the techniques he demonstrates?

Every video on his website has pretty great annotations placed on top of them which describes every section of every video, and all the questions at the end of session QA.

Go to https://handmadehero.org/watch and scroll down the previous episodes section.

Also all the episodes aren't as long as they look, a large chunk of the time is on the QA at the end. That said it is a huge investment at this point, but definitely worth it. Some of his high-level ideas are great, and I've learned a lot.

Re: Writing a game engine in pure C: The Graphic Initialization

#39

Post by enriquto »

mrec wrote: post #25
enriquto wrote: post #21

Earlier quoted context omitted.

are there any concrete, tangible advantages of glfw over freeglut? I see the glut api as the paragon of usefulness and simple elegance, and I'm really curious how glfw can be any better than that.

I haven't used glfw, but from the docs it leaves you in control of the main loop, whereas glut takes that over and only offers you callbacks. When I used glut (many many years ago) that was sometimes annoying. glfw doesn't seem to have a function to draw teapots though, which should really rule it out as a serious contender.

legacy glut does not allow loop control, but freeglut does
Post reply on HN