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

Why I Write Games in C

jonathanwhiting.com

Post reply on HN
Print view View original

211–220 of 303 posts

Re: Why I Write Games in C

#211

Post by BatFastard »

mikeash wrote: post #178
BatFastard wrote: post #173

Flash is not dead. It's the ONLY plugin left that works in all desktop browsers, and works on Mobile phone. Facebook supports it, more and more who have started in HTML5 have lived to regret the day. For many years I was a C++ snob who totally dismissed Flash, but now I really enjoy actionscript I am working with a client who is write a phone app in Flash because of the low level cross platform abilities and it is aw…

Flash doesn't work in most installations of desktop Safari, nor does it work on iPhones. Many others are fleeing it because of massive ongoing security problems with it. If you're content with the audience that remains then great, but it's far from "all."

Flash has many colors now, on mobile phones its called Adobe AIR. And it just won the mobile tech of the year award as CES.

Re: Why I Write Games in C

#212

Post by ksk »

cies wrote: post #89

Because he claims that reducing the possibility for bug is a main concern I feel two languages, in his nicely written write-up, are left out: Rust -- low-level like C, fast like C, more modern than C, specific ways to reduce categories of bugs (borrow checker), promotes a more functional way for programming Haskell -- not as low-level as C, but pretty fast (best possible performance was not his main concern), many wa…

Do you have any examples of AAA games (or even major indie ones) that use Rust or Haskell?

Often I find that when people recommend a technology for game development, no professional game studios ever seem to use them. I'd love to be proven wrong though...

Re: Why I Write Games in C

#213

Post by orthecreedence »

scrollaway wrote: post #70
ivanca wrote: post #39

Earlier quoted context omitted.

I did, it is so abstract to pretend you can do better that there is no way to discern. He didn't even mention "unity" in his post, thats just ridiculous in 2016, but yeah, keep down voting, your implementation of 2d graphics, sound, collision, physics, plugins, marketing, sprites, menus is gonna be so much better than hundreds of engineers at unity withing 10 years straight.

You have an attitude problem. First of all I've worked with Unity myself and I know how nice it is. It's not the end-all-be-all of game development and it's not suitable for all genres. Second, like someone else said, this is about a language - not a framework. Unity locks you into C#. Third, the guy says himself 'I absolutely DO NOT mean to say "hey, you should use C too".'. He's not forcing you to write games in C,…

When I first learned to program, I made some nice little fun apps, compiled them to executables, ran them, and sat back. But something wasn't right. I knew that the code I wrote was doing something, and I knew that it was doing what I told it, but I didn't know why.

What is in this binary executable that makes the computer print "hello world"? I started digging. I found assembly. I found disassembly. I got into cracking and exploits. SoftICE. Unlimited ammo in games. Patching. Sniffing serialzz in shareware. Etc etc.

My point is, if I had just been happy with

    printf("Hello, world!\n")
and moved on, I wouldn't have the incredible understanding I do now for what goes on under the hood. I wouldn't know what an executable is, or how to bend it to my will. This knowledge has always been powerful for me.

Game programming is like this too. You can install Unity and make a basic game, hell maybe even make a few bucks off it. But what the hell is happening under the hood? What if you need to do something Unity isn't capable of? Where does that leave you?

Maybe some people want to just make a game and be done with it. But I like to know why what I built is actually working. It's worth the time it takes. OpenGL extensions, FBOs, triangulation, etc are all complicated and hard to understand, but once you know how it all works you know what's possible and what isn't, and you don't need a (proprietary!!) framework making that decision for you.

Re: Why I Write Games in C

#214

Post by hellofunk »

jbeja wrote: post #199
alekratz wrote: post #154

Earlier quoted context omitted.

Have you never had a project larger than 10 files?

I use Clojure which have a repl base workflow, I never need to compile anything to test my code and the feedback is instant.

You always compile your function, var, or file before seeing changes in Clojure. But, compilation is usually quite fast since you are linking against precompiled binaries in your dependencies, unlike, for example, header-only sources.

But to say you never compile anything in Clojure is wrong.

Re: Why I Write Games in C

#215

Post by exDM69 »

charlieflowers wrote: post #93
exDM69 wrote: post #69

Earlier quoted context omitted.

A technique commonly used in C, for example in the Linux kernel. You embed "links" to other nodes in your structs, and find the struct from the link based on offsetof. Linux kernel uses linked lists and red-black trees this way. Probably other data structures too. Intrusive containers are cache friendly and typically require no dynamic allocations (in addition to allocating the data itself). See the link in the post…

Interesting. At first I thought you were claiming this technique made linked lists cache friendly. After looking at it, I have concluded you meant merely that the next and prev pointers are near your data. Am I understanding you correctly?

Yes, there's one pointer chase less when you don't have a pointer from the link node to the data, but you can get it with offsetof. This can save a significant number of cache misses in some algorithms.

Re: Why I Write Games in C

#216

Post by steveklabnik »

dunkelheit wrote: post #205
Rusky wrote: post #171

Earlier quoted context omitted.

That bug was almost a year before Rust 1.0 was released. At this point, Rust is being used in production outside of Servo- for example Dropbox is even using it for their core data storage code. It's certainly not as old-and-boring stable as C, but it's a lot closer than you'd think.

And that bug was less than a 1.5 years before now. And Rust is at version 1.5 now. And all changelog entries since version 1.0 (which was released 8 months ago) mention "multiple bugfixes". Of course, that's all subjective, but for me these facts all scream "rapid pace of development, expect multiple annoyances and a couple of major bugs for your particular use case". Dropbox is using Rust in production? Great news!…

As a member of that core team, I would expect that we will pay just as much attention to any company that plans on using Rust in production. We're very interested in supporting companies using Rust, and making sure t works well.

Re: Why I Write Games in C

#217

Post by lagadu »

orthecreedence wrote: post #213
scrollaway wrote: post #70

Earlier quoted context omitted.

You have an attitude problem. First of all I've worked with Unity myself and I know how nice it is. It's not the end-all-be-all of game development and it's not suitable for all genres. Second, like someone else said, this is about a language - not a framework. Unity locks you into C#. Third, the guy says himself 'I absolutely DO NOT mean to say "hey, you should use C too".'. He's not forcing you to write games in C,…

When I first learned to program, I made some nice little fun apps, compiled them to executables, ran them, and sat back. But something wasn't right. I knew that the code I wrote was doing something, and I knew that it was doing what I told it, but I didn't know why. What is in this binary executable that makes the computer print "hello world"? I started digging. I found assembly. I found disassembly. I got into crack…

> What if you need to do something Unity isn't capable of? Where does that leave you?

I'm not trying to be glib, and I know that's not the answer you're looking for but it would leave them switching to Unreal or any other engine most likely, not going "down" the complexity scale.

Re: Why I Write Games in C

#218

Post by hellofunk »

sklogic wrote: post #185
Rusky wrote: post #174

Earlier quoted context omitted.

C++11 and 14 make it possible to avoid or ignore much of the complexity of old-style C++, but they also introduce plenty of complexity of their own and they don't deprecate any of the old stuff. It's not a myth.

Yes, but now you can safely use a nice and clean subset without ever touching any dark corners.

There are a few new dark corners in modern c++ ... Enough to inspire Scott Meyers to fill a new book of advice just for the new idioms. C++ is powerful but complex no matter how you look at it.

Re: Why I Write Games in C

#219

Post by weavejester »

0xcde4c3db wrote: post #206
weavejester wrote: post #123

Are GC pauses really significant? I can understand there being problems if you have to churn through gigabytes of world data, but the author's games don't appear to be on that scale.

They often are if specific care is not taken to minimize garbage in the game loop, particularly in resource-constrained environments like some console and mobile platforms [1]. In GC languages, this often means deliberately avoiding common idioms that perform allocation under the hood. The threshold for a noticeable pause is much lower for action games than it is for general applications. 100ms is often used as a rul…

I can see that you'd probably have to take care on mobile and older platforms, and with resource-heavy games. But I have difficulty imaging that there'd be much issue with anything else, as long as the code wasn't overly terrible.

Do you happen to know of any benchmarks, or non-anecdotal evidence?

Re: Why I Write Games in C

#220

Post by bluecalm »

raverbashing wrote: post #6

I understand the want for simplicity in C (and Go gets closer, but has its issues), however, it seems in the end it drags you down. Just having the C++ ability to have objects doing things is very helpful. But yeah, C++ has the ability to get very complicated But it's your choice to have "complicated C++". Limit yourself to some functionalities and it's much more manageable. Use basic STL and keep it simple (also C++…

>>Just having the C++ ability to have objects doing things is very helpful.

There is a school of thought that it's the opposite of helpful. They would say it's better to have functions doing stuff with data (either taking it as input and returning as output or modifying some structures which should be mutable). "Objects doing things" don't fit to that model.

Post reply on HN