Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 02 Oct 2013
Offline Last Active Yesterday, 09:59 PM

Posts I've Made

In Topic: Some programmers actually hate OOP languages? WHAT?!

29 January 2015 - 06:48 PM

Still... what might "well-coded" games in C look like? Or would it be quite close to a game in C++ but mostly just without the encapsulation given by things like access modifiers, and semi-advanced concepts like templates?

Being someone who is currently coding a game in C for the lulz, I think I can answer this.


The structure of code is quite different than what I'd do in C++, but the same basic concepts apply. For instance, a lot of systems have system_init() and system_deinit() functions instead of constructors/destructors. There are no classes with methods, but there are structs for holding data and functions which act upon the data of these structs. Templates don't exist, but you can implement the majority of what templates are used for with macros. Compositing can be done with structs.


Polymorphism doesn't exist per se. I've seen my fair share of home made polymorphism in C, but I believe it's not really necessary. Most of the time you can composite. 

In Topic: Programming

29 January 2015 - 04:20 PM

Spiro speaks the truth.


I started a project as a somewhat average programmer with some artists, but I chose a game that was so far out of my league we had to can the entire thing after a few months. I disappointed everyone on the team.


One of the team members wrote me a really long and hurtful message. Spraying salt on my skinned body would have been less painful than some of the things he said, but it was the truth. He felt extremely passionate about what we were creating, and he blamed me for being an incompetent idiot for throwing the entire thing away and wasting everyone's time.


Trust me, you do not want to go through that pain. I learned my lesson the hard way.

In Topic: first players problem with 1vs1 network game.

21 January 2015 - 08:41 AM

I don't think there's much you can do about that, but is it really a problem? The majority of online multiplayer games don't rely on connecting with random people, they're usually played by people who know each other beforehand. They'll coordinate themselves.


I don't know your game, but you should probably have a single player mode if it is a game that can be fun to play alone. Also consider adding a tutorial mode to teach the player how the game works.

In Topic: Generic events - Enforcing the correct function signatures.

20 January 2015 - 04:45 AM

Thanks for the input! That's very interesting. I can confirm that it compiles under C99 mode on both GCC and clang, but it fails to compile using a C++ compiler.
I played around with my idea a little more to see how far I can really go, I found that it actually is possible to do what I seek with the GCC compiler extension Typeof. Changing the macros to the following will somewhat enforce coherent function signatures:

#define EVENT_DUMMY_FUNCTION_SIGNATURE_CHECK1(event, arg1) do { \
            void (*func)(const struct event_t*, TYPEOF(arg1)); \
            (void)(func == event_internal_func_##event); } while(0);

#define EVENT_FIRE1(event_name, arg1) \
    VECTOR_FOR_EACH((event_name)->listeners, struct event_listener_t, listener) \
    { \
        listener->exec(event_name); \

#define EVENT_H1(event, arg1_t) \
    void event_internal_func_##event(const struct event_t* evt, arg1_t arg1); \
    extern struct event_t* event

#define EVENT_C1(event, arg1_t) \
    void event_internal_func_##event(const struct event_t* evt, arg1_t arg1) {} \
    struct event_t* event = (struct event_t*)0

Where TYPEOF is:

#define TYPEOF(x) __typeof__(x)

This forces the arguments passed to EVENT_H(), EVENT_C() and EVENT_FIRE() to match, or a compiler warning is generated.


I can't say I'm particularly proud of this macro wizardry I've created and it probably belongs in the coding horrors, but it works. I'm pretty sure it would also work with an MSVC compiler with decltype, although I think that's only for C++ code.


For the complete implementation of my event system, see here:


In Topic: Generic events - Enforcing the correct function signatures.

19 January 2015 - 09:08 AM

I don't believe C is expressive enough to capture what you are trying to do. The C APIs I have used appear to favour the idiom of a single callback function signature with a void pointer for the variable data. The callee is expected to cast the pointer to a structure of the appropriate type (often indicated by a integral "type" parameter).

Would you recommend adopting the favoured technique in place of what I'm currently doing? I'm guessing it has a reason, but I can't really see what that reason might be.
What's also bothering me is I can't find any information on these "generic" function signatures. I'm not sure what to call them:

typedef void (*func1)();     /* this function allows any number of arguments with any type */
typedef void (*func2)(void); /* this function does not - it only accepts void */

Is this a compiler bug?