d62585 No.28812
Does anyone make games in pure c anymore? I know both SDL and SDL2 can work with pure c but I never see any tutorials on it and I never hear about any new games (AAA, indie, or amateur) written in pure C code.
____________________________
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28815
>>28812
>I never see any tutorials on it
http://lazyfoo.net/SDL_tutorials
Feels like a bit too hard for me to follow though. I guess these tuts were made for someone like you.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28816
>>28812
you can do it, it'll just take you a much longer time.
for 2d I recommend just Love2D.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28817
>>28816
>tfw this meme will never die
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28819
>>28815
I meant SDL tutorials for pure C, not C++.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28820
>>28812
Why would you want to?
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28821
C++ has many more features, like libraries for multithreading and datastructures like maps and vectors. That's why people don't want to use pure C.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28830
>>28817
You can't write a AAA game in C within 2 years. Prove me wrong.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28832
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28833
>>28832
no, dead as usual.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28836
>>28812
No. Games generally lend themselves to "object oriented" design. In addition: memory management. Memory management in C is a bitch. At its best, object constructors, destructors, and assignment operators in C++ hide the complexity of memory management for a small performance loss. As soon as I want to allocate heap memory, I generally want to not use C.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28837
I make all of my games in pure C, you can look at my last game here:
https://ika.itch.io/redsky
>>28836
Just because lots of programmers are scared of C doesn't mean that people don't use it for things.
This is the C code I wrote today for my new game's texture system. The idea is that data structures that are used to help with the drawing code will all have pointers to textures in the game, so by making all of the textures part of a linked list, I can easily track them down when I have to free all the memory.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28838
>>28837
ha, just look at that, my code had a memory leak. Now granted it would be incredibly rare for the texture system in openGL to somehow fail and still be able to run the game in a usable state, but it would have leaked the bitmap_t... embarrassing...
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28839
>>28838
That's my point exactly. In C++, you would probably have wrapped your texture in a shared_ptr, which automagically tracks the reference count and can be passed around like a normal pointer.
And... does your gfx_t struct have pointers to functions? Basically, you're doing object-oriented programming in C. That goes back to my previous point: you're doing OOP already. Just use a language that natively supports it.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28840
>>28839
>structs with pointers to functions is basically OOP
what? You might as well call using separate files/libs OOP.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28841
>>28839
I don't think having that kind of overhead is worth it. You don't need to have some really complicated system that constantly checks pointers and makes literally everything slower when you can just look at your code and then fix it... that's not a kind of trade that should be made.
gfx_t has pointers to functions because I am using two different graphics API's so this saves code space. instead of:
if(gfx->flags == GFX_USE_OPENGL){
glr_new_texture(gfx->renderer,flags,bm);
}
else if(gfx->flags == GFX_USE_VULKAN){
vkr_new_texture(gfx->renderer,flags,bm);
}
else{
//ERROR
}
I can use one call. There is literally no other use case in my code for this kind of programming... I am using polymorphisim. Not OOP.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28842
>>28841
> You don't need to have some really complicated system that constantly checks pointers and makes literally everything slower when you can just look at your code and then fix it.
> some really complicated system
The thing is, it's not really complicated. The point is to hide accidental complexity. One of the aims of software engineering is to manage complexity, and OOP gets pushed because it does a good job of that. C++ is full of features that help manage complexity. You say that it is trivial to find an error in this 5.000 line toy game engine of yours, but finding those errors ceases to be trivial when you are looking at 100.000 lines or more of source.
>>28840
He has bound the functions that operate on data with the data being operated on.
gfx->new_texture(gfx, flags, bm);
That is a method call that explicitly passes the "this" pointer.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28843
>>28842
It IS complicated, except you don't see it in your code. Its like calling a win32 function, which could execute thousands of lines of code, which you don't see either. The overhead is still there. My error never left the scope of the function, so its not hard to figure out where it happened. You are blaming the tool and not the programmer... Once you structure your code around managing your own memory, and make leaks easy to see, like that one, its not hard to find them. You can see that my code uses the kind of spin-up .... spin-down method of programming that linux uses, i can see where all the memory is allocated and free'd.
gfx_t is purely being used for polymorphisim. While some parts of my code are easy to translate into classes like what C++ does, others are not... its really a right tool for the right job kind of thing. Porting my code to C++ wouldn't actually make it any better... It would just mean that I have access to a whole bunch of optional overheads like shared_ptr that I don't want to use.
I think that its really bad to think about memory management with the idea that you leak things to free them from the heap- it makes me cringe when instead of explicitly free'ing something you just "implictly" let the garbage collector / smart pointer / whatever figure out the mess you just made.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28847
>>28843
> except you don't see it in your code
Exactly: you build small, uncomplex things that you put together in uncomplex ways that come together to form complex behavior. You don't need to know what a win32 function does to use it. The overhead is irrelevant. I am blaming the programmer for refusing to use tools that will improve their productivity. You are doing things by hand that this other tool would do for you.
> instead of explicitly free'ing something you just "implictly" let the garbage collector / smart pointer
The thing with the "smart" pointer is that you do explicitly free the memory. There is nothing implicit about it: there is just a separation of concerns so that you don't have to intellectually manage all of the accidental complexity of the program all of the time.
> It would just mean that I have access to a whole bunch of optional overheads like shared_ptr that I don't want to use.
To reanswer your question:
> Does anyone make games in pure c anymore?
No, because the management of AAA games wants the productivity boost of better tools and they know not to succumb to premature optimization: make it work now, make it work fast later.
Granted, if you are comfortable writing in C: no one is going to stop you. Just realize that eventually your code will contain "an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp".
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28850
I use C++, it's really much better for game dev. If you're making any sort of library, a C interface is probably better so that more people can use it, but C++'s RAII and type safety are invaluable. I say this as somebody who loves C and uses C primarily at work.
There is really no technical gain to developing a game in C instead of C++ unless you are also targeting embedded or obscure platforms, or for some reason want your game APIs more easily bindable from other languages (even then, you could just target a C linkage from C++). The only real reason to use C in this domain is if you like using it better.
You're making a game here, not a networking library or some other general-purpose thing where C really has tons of advantages because you want it to work on every system and to bind to every programming language.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28851
>>28847
>You are doing things by hand that this other tool would do for you.
It is about how much control you want... If I didn't care about control I would write in python.
>you do explicitly free the memory.
It is implicit.... lets say I delete all references to the pointer. Now there is a hidden call to "free_my_object"
>To reanswer your question:
Your answer was disproven by example. "Does anyone make games in C anymore?". I showed him a game that I made in C in released in 2017. The AAA games point is irrelevant because the question is not in the scope of "does anyone make AAA games in C anymore?"
>Just realize that eventually your code will contain "an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp".
No idea what you mean by this.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28870
Object model is perfect for games.
Pure c moderate game code will look like a total mess.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28920
I'm making a game in C, I don't know if I would be able to make my game if I used OOP instead of functional programming.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28925
>>28920
>I'm making a game in C, I don't know if I would be able to make my game if I used OOP instead of functional programming.
>I'm making a game in C, I don't know a goddamn thing about programming.
I fixed that for you.
If you're doing functional programming in C, then god help you please kill yourself. You are probably doing procedural programming. The only difference between procedural programming and OOP, as implemented in C++, is a switch of thinking from operations ON objects to operations OF objects.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
d62585 No.28930
>>28925
Not using classes lets me move conditional code outside of the object's method so when I'm looping over an array of an object I only need to check the conditional once than for every object.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
56e07e No.28942
>>28930
And OOP prevents you from doing that because...?
Don't blame a whole programming paradigm when it's just you who doesn't know how to wrap his mind around it. Doesn't matter what kind of condition you are writing, you can always implement it on the caller rather tham the callee, and sometimes, that's even the only option.
I will give you one thing OOP does worse: you really have to trust your compiler a lot if you want to have a supremely performant loop over an array of data. Calling a method may induce a small overhead due to all the stack shifting stuff it has to do to make way for the function. Some languages (like C++) accept the inline keyword for extra speed, but it's not always an option.
When people comment on how JIT is often faster than native code, it's usually because JIT can do runtime profiling of your program, and decide on runtime whether some code needs to be inlined in some places or not, amongst other things, whereas static compilers may only either make wild smart guesses in some places or default to the best general use case. Again, you have to trust your JIT a lot to do this for you, but point is, who gives a fuck about a few nanoseconds every five minutes?
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
f6171f No.28943
YouTube embed. Click thumbnail to play.
>Does anyone make games in pure c anymore?
If you mean pure 100% c, it's on the console. They even use assembly on the console.
>AAA
Insomniac games and Ubisoft
As far as Indie, I know frictional games wrote their engine in C and added support for a scripting language, which I still consider as C because it's using something they built in C.
>>28836
This dude is full of shit, vid related.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
50d3a9 No.28995
>>28943
> Doesn't use multiple inheritance or templates because he doesn't like them.
> Expects me to believe he is an expert in anything.
> They even use assembly on the console.
These aren't the days of the SNES anymore: as he says, these days the bulk of the work is in C++ and only performance-critical portions are written in C or assembly. These days, code optimizers are so good that the only cases for assembly are A) dangerous optimizations that the developer knows are safe but no optimizer would make, or B) targeting very specific hardware configurations.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
55a17a No.29013
>>28995
At least the NASA guy had good excuses:
> Management wasn't comfortable with C++, as they had mostly done C
> Thought that multiple inheritance and operator overloading would confuse their C programmers
> It sounds like management didn't know that templates and the STL were different things
> HE didn't want to use templates or the STL do to the memory constrained environment: to limit generated code size.
Their is also a video from a guy from Ubisoft Montreal (with a bad Canadian-French accent) that goes into their alternative to templates. Their way reduces code size, and thus cache misses. He advocates using as little abstraction as possible as any abstraction incurs cache misses in v-table lookups.
It is funny how both of the video game guys had the same message: L2 cache misses are a performance problem.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
67e7bc No.29023
>>28812
You program in C (and lower) if you really want to milk the shit out of the system.
Besides, OOP is considered cancer of the programming by many people.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
12e5ce No.29025
>>29023
OOP is only considered "cancer" by imageboard shitposters and other Internet memers.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
9b860a No.29029
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
9b860a No.29030
>>29025
To start with:
> Brian Will - Object-Oriented Programming is Bad: https://youtu.be/QM1iUe6IofM
> Brian Will - Object-Oriented Programming is Embarrassing: 4 Short Examples: https://youtu.be/IRTfhkiAqPw
> Brian Will - Object-Oriented Programming is Garbage: 3800 SLOC Example: https://youtu.be/V6VP-2aIcSc
You can find more videos and articles anywhere. Just search for "oop is <synonym of 'bad'>". Or let me do it for you: https://www.google.com/search?q=oop+is+bad
If you're a fan of "shitposters" you can read some stuff here (http://harmful.cat-v.org/software/OO_programming/) but I wouldn't call these articles very informative.
In short, Object-Oriented Programming is a needless obfuscation of how computers work and so far it has done nothing but harm. I wouldn't be surprised if it turnes out that OOP is one of the resons Fizz Buzz is still a thing.
Next time, spend some time reading before spewing nonsense.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
bf0a60 No.29042
>>29030
I wouldn't say OOP is bad. There are problems which naturally lend themself to OOP. Their are problems which can be done efficiently in OOP. Then, there are problems which are either FORTRAN programs in C++ or end up implementing half of Common LISP.
Really, the problem is that some people are given a hammer and so everything looks like a nail. This isn't a tool problem, it's a human problem. I argue that OOP is considered bad due to shitty programmers who would be shitty no matter what language they were using.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
12e5ce No.29051
>>29030
>this video is distinctly a minority position on programmers
>In short, Object-Oriented Programming is a needless obfuscation of how computers work and so far it has done nothing but harm.
If this is what you understand about OOP, then you are obviously confused. OOP is not necessary to obfuscate anything. Straightforward procedural programming does not imply non-obfuscated system.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
9b860a No.29067
>>29051
>If this is what you understand about OOP, then you are obviously confused.
It's just my experience with it so far.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.
bf0a60 No.29078
>>29030
>Object-Oriented Programming is a needless obfuscation of how computers work
>>29067
>It's just my experience with it so far.
So, anon, what do you think of functional programming. If anything obfuscates "how computers work", it's that theoretical crap. And as C++ comes from C, it does OOP in a very close-to-the-metal way. Most of the "magic" comes in standard libraries, which are themselves written in C++.
My problem with OOP (and I've said in this thread that OOP isn't bad) is following the chain of logic. This is your average debugging experience with OOP:
> go into method call
> method calls superclass method
> superclass method calls superclass method
> which in turn calls a superclass method
> finally, an attribute is incremented
> return
> return
> return
> return
So, when you want a deep understanding of what the hell is going on, there are a lot of layers. It's frustrating. Note that this layering can be done in procedural code: I work on a bastard codebase of legacy C that does (it also implements ad-hoc OOP). Generally, though, if the code is well programmed (granted, it rarely is), you don't need to know or care what goes on in that invocation. The name of the method should clearly indicate all externally visible side effects of the call. The purpose of OOP is to hide the complexity, so that ever more complex programs can be written. Think like a bash script: you don't need to know about opendir(), readdir(), DIR*, or struct dirent when writing a bash script; that complexity is hidden from you so that you can achieve the task at hand. OOP is supposed to do that. When it is done right, it's awesome. When it is done poorly, it's hell.
Disclaimer: this post and the subject matter and contents thereof - text, media, or otherwise - do not necessarily reflect the views of the 8kun administration.