Which programming language did you choose and why?

[Rewrite]

Code showdown

your full state seems to be global and persistent, there is no reason to pass those raw pointers around, its not gonna help you
there, i saved you a million keystrokes and eyestrain

you have bad data-logic separation, even for my tastes (someone who doesnt give a fuck), not very data driven

constants should be constant

you muddle functional separation boundaries, eg game_render() should not read data/check highscores and decide something, it should render...

overall a passing grade, but its far from good

 

[Burning Bridges]

Let's not get anal, but using printf in a paint method is indeed very, very bad. That's a classic case of a bottleneck.

I personally only do if(bool), switch-case and occasionally checks for nullptr there. Members should be assigned only when something changes, not in the paint() either.

As to the passing of pointers, I just use static variables. Some people dont like it but it makes code much shorter and you dont have to constantly add nonsense to the functions.

Like
class Program
{
public:
static MainWindow* mainWindow;

then I can access it from anywhere with Program::mainWindow-><public member>

Otherwise you also need to check if a pointer is nullptr, otherwise it may sooner or later crash. Of course you can skip that step if you think your code is always perfect, but it usually isn't gonna work. The basic idea is that a program should function normally when pointers are nullptrs. Not everything of course, but NULL is not so uncommon in informatics.

 

[Tramboi]

Code showdown !

Good plain C-code.
I disagree with the others, keeping things as parameters is good (it will help refactoring and parallelism), and I see no problem with the *s*printf usage in the rendering function.

Regarding code/data separation, that's something you should build incrementally. So when you're feeling you hardcode too much... just abstract away.

 

[OndrejSc]

Real programers use > edit program.exe

 

[Twiglard]

Real programers use > edit program.exe

Real programmers use A:\> DEBUG program.exe

 

[Burning Bridges]

I see no problem with the *s*printf usage in the rendering function.

Calling a whole block of I/O functions in a render loop?

I have not measured it, it's probably quite fast but the ms add up. Calling the render function n times with sprintf and without and measure the runtime with a precision timer I assume the version with I/O could be 100s of times slower.

Of course you need to measure it first but it looks like a real beginners mistake.

 

[Twiglard]

Calling a whole block of I/O functions in a render loop?

sprintf(3) doesn't involve any system calls. And rendering text (preferably using a bitmap font) has to be done every frame, in immediate mode. You literally have to do it or the text overlay won't display itself.

 

[50726f73706572]

It's tempting to post code from one of my game-oriented projects. But that carries too much risk.

Instead i'll complain about how worthless everything I do is in C++.
I have about 20 or so important files i've made that are generally usable in any project.

But when I start a new project I usually don't feel secure in whether or not I could finish it. Not the way some people have giant function repositories they draw from.
What I have is:

-Text manipulation and i/o
-Randomness related stuff.
-My own math library.

My math libary has 2d,3d point classes and a set of floating point comparison functions. That's about it. I like to keep very bare bones.

As of late i've been bloating my code with templates out of envy for what other "languages" do better.
I've stayed my lane quite a lot and prefer more C-style (with classes) approach.

C++ just takes too damn long to make the program you want to make.

If you don't have reusable code i'd recommend against it for anyone who isn't an academic, working on very small projects, or working on a huge project such that long development time is expected no matter what.

Using C++ for the sake of it is something only worth doing once or twice. You can hang your participation trophy on the wall and stay away from this shit as long as possible.
Due to a lack of high level functionality my programs always feel like they start a grade or two behind, and they are all developed in isolation.

Maybe it's a non-sequitur to desire the language to help us with our pet projects, as if syntax is some magical cure for just doing the work.


I'm too old to change my ways. Time to suffer some more.

 

[Krice]

C++ just takes too damn long to make the program you want to make.

It doesn't. Modern C++ is not that low level language after all in that you don't need to code anything generic, it's already there. I was just modernizing my RNG module and long gone are the days when you had to search the internet for some shady low level C code for mersenne twister or whatever. Now it takes like 4-5 lines of code and that's it. RNG done. I don't even remember when C++ was a roadblock in development, it's mostly the content like creating a RPG system which seems to be the bane of my existence.

 

[Rewrite]

Modern C++ is not that low level language after all

I was just modernizing my RNG module

lel

In C/++ you HAVE to think about data representation. In high level langs you dont. Its just slower to write.

The irony:

 

[Rewrite]

And rendering text (preferably using a bitmap font) has to be done every frame, in immediate mode.

Sure, but ideally not in the way it is done there, if you wanna fite about it.
If you wanna really be nitpicky and write a high perf engine, you would not sprintf different text to the same location. You would not do multiple render calls with 4 args with floats.
Thats needless overhead, data dependency and cache thrashing.
Even SDL that he seems to use does frame construction and blits all in one go (as far as I remember...).

 

[Krice]

Its just slower to write.

You sound like a linux programmer. They learn keyboard shortcuts and use command line, because some things are 0.002% faster to write. But in reality how "slow" or fast it is to write code has almost nothing to do with software development. It's 99% design and implementing features and at that stage your game engine is probably as ready as it can be. It's just that most people who post here never made an actual game. So they can't know what they are talking about, it's so clear from what they say.

 

[Burning Bridges]

But in reality how "slow" or fast it is to write code has almost nothing to do with software development.

In your reality perhaps.

 

[Tramboi]

And rendering text (preferably using a bitmap font) has to be done every frame, in immediate mode.

Sure, but ideally not in the way it is done there, if you wanna fite about it.
If you wanna really be nitpicky and write a high perf engine, you would not sprintf different text to the same location. You would not do multiple render calls with 4 args with floats.
Thats needless overhead, data dependency and cache thrashing.
Even SDL that he seems to use does frame construction and blits all in one go (as far as I remember...).

Man this is an *amateur OpenGL engine*. We don't have the code of WO_text_draw_xy but the sprintf won't be the issue, that's for granted.
Cache thrashing is not even an issue considering the level of abstraction there, for once in a frame code.
Leave the man alone, he's writing the correct stuff considering what he wants to achieve.

 

[Hag]

Thank you all guys for taking time to review my poor beginner's code.
Yeah, it's a WIP, lot of room for improvement (there is basically no kind of optimization whatsoever), but it runs smoothly and is playable so for now I'm good with it. Pretty easy to add new stuff and to find my way around.
Concerning the passing around of the GW/GV/GD pointers, I wanted to avoid global or static vars, so I went with shoving all game data in those structs. Looked like a good idea at the time, now it is getting a bit cumbersome.

 

[Tramboi]

Concerning the passing around of the GW/GV/GD pointers, I wanted to avoid global or static vars, so I went with shoving all game data in those structs. Looked like a good idea at the time, now it is getting a bit cumbersome.

It's still a good idea. There's more to programming than terseness
(Nobody would do C or C++ if it was the case)

 

[Hag]

Yep, but I am not pleased to have to pass the three of them all the time. They were supposed to represent each some specific context, but I got it wrong and it went messy. In retrospect, only one point of entry to the whole data catalog would have worked the same for added clarity.

 

[Burning Bridges]

why don't you make then public static? the whole passing of pointers is a terrible disease anyway.

or do you have multiple instances of GameWorld*?

 

[Hag]

why don't you make then public static? the whole passing of pointers is a terrible disease anyway.

Good question. Not sure why, maybe the way I learnt (I suffered early exposure to C++ and Java), maybe some kind of fetishism for pointers, maybe it's the way I like to see things organized.

or do you have multiple instances of GameWorld*?

For now, only one of each GameStuff struct. But now that you talk about it, since each GameStuffs set holds the whole game state, structure, assets and few rules, I could with little work switch instances on the run and change the game altogether.
Not sure on why I would do that though.

 

[Burning Bridges]

For a few functions it makes no difference, but in a real project you have hundreds.

In the end you can probably do whatever you like, but it should be consistent. Nothing is worse than when someone changed patterns within one project.

Imo passing the pointer makes only sense if you have different Gameworlds and want to separate which one you mean. If you have only 1 in the whole program both the call and the function signature are redundant. Basically 3 times as much text for the same thing plus passing a pointer that you already know (that's irrelevant in terms of performance though).

This gets even cascadingly worse if the calling function has no access to the pointer itself, and needs to be passed the pointer itself, and so on. That's why I generally stopped passing pointers if there is only 1 instance anyway.

basically what I would do is:

class Game
{
public:
static GameWorld* GameWorld;

and then use Game::GameWorld->.. where I need it

may not be what you learn in university, but it works great

 

[Rincewind]

Leave the man alone, he's writing the correct stuff considering what he wants to achieve.

Upon further reflection, I agree with Tramboi here.

 

[Rincewind]

why don't you make then public static? the whole passing of pointers is a terrible disease anyway.

Not so fast. Although not too sure how common it is to unit test code in gamedev, in general software development writing pure functions are very much preferable. Then the output is only reliant on the input you're passing in.

Moreover, like Tramboi pointed out, passing in the pointers makes parallelisation possible. Even if you're not parallelising the code itself, you can unit test pure functions in parallel easily. With functions relying on global data (public static is really just global data in disguise) you must test things in series, resetting global state between tests.

Plus it's too much mental overhead; suddenly your functions start mutating shit outside their scope. It's very easy to create a mess that way, and I can tell you with 100% certainty that in better non-gamedev circles non-pure functions and mutation of global data is avoided like the plague (local is fine, and sometimes "extended local" necessary, e.g. in a file/class/module scope... which is a "mini global", but sometimes necessary for performance). Basicaly 0% of people would get away with it during a code review where I work.

 

[Krice]

In your reality perhaps.

Well, I know that when I was a beginner I also thought there is something wrong with C++. "If only it had.. " etc. but now as a master level programmer I know it's not true. In my mind most programming languages are doing the same thing, only slightly different way. Which is obviously true, because that's what they are doing. Everything that sucks comes from us people, our inability to create programs and games. We can also logically confirm this by noticing that some people do succeed where others fail.

 

[Rincewind]

but now as a master level programmer

 

[Burning Bridges]

why don't you make then public static? the whole passing of pointers is a terrible disease anyway.

Not so fast. Although not too sure how common it is to unit test code in gamedev, in general software development writing pure functions are very much preferable. Then the output is only reliant on the input you're passing in.

Moreover, like Tramboi pointed out, passing in the pointers makes parallelisation possible. Even if you're not parallelising the code itself, you can unit test pure functions in parallel easily. With functions relying on global data (public static is really just global data in disguise) you must test things in series, resetting global state between tests.

Plus it's too much mental overhead; suddenly your functions start mutating shit outside their scope. It's very easy to create a mess that way, and I can tell you with 100% certainty that in better non-gamedev circles non-pure functions and mutation of global data is avoided like the plague (local is fine, and sometimes "extended local" necessary, e.g. in a file/class/module scope... which is a "mini global", but sometimes necessary for performance). Basicaly 0% of people would get away with it during a code review where I work.

Ok. Maybe I should have explained that I use this in a somewhat different way. I would normally only want to get a pointer the eg the GameState object because I need to know some of its properties, but not to change the properties. Changing them should indeed be done by functions.

We should not circumvent encapsulation but it's very annoying if you lets say you want to check 1 flag to have write an entire architecture that passes pointers to objects hierarchically. So the idea is to put the flag into an object that can be reached from everywhere without some other object providing a pointer.

Of course one would have to see the code but I have definitely seen programs where the functions were totally overloaded with parameters that basically just expose stuff because it was unreachable. The ultimate decision about how to do stuff should always be "what is the point of doing xy", and if I pass the same pointer millions of times just so I couldn't possibly have a second one I don't see it. If I pass a pointer I want to specify that I mean that particular object because there is more than 1. Whereas if I know that the value of the parameter is always going to be the same then why pass it.