With every post I've read, J-Snake's opinion on pretty much everything seems to be the exact opposite of mine.

That is interesting, can you name an example for instance?

Hmm, not as easy to find examples as I thought... I just remember butting heads with you over timestep intervals, full screen modes, vsync, and a few other things I think. Hasn't been so much recently, but it looks like most of your posts were in forums I wasn't reading actively. This thread would be another example, of course. I'm not attacking you as a person or anything, it just often seems to me like you live in opposite world.

Let's try this out: What do you think of unit tests?

Bugs do happen at NASA, and they end up destroying very expensive hardware. In practical terms, no amount of engineering can account for every bug in a nontrivial piece of software, and even ones you think are trivial can hide a surprising number of bugs for many years. I'm not sure if I can find it again, but I read an article a while ago about a code analysis tool someone wrote that was run against a ~100-line UNIX program that's been around and widely used for decades, and found something like 5 serious bugs in it that were previously unknown.

With every post I've read, J-Snake's opinion on pretty much everything seems to be the exact opposite of mine. It's kinda weird. I've found a negative version of myself.

Awww, kitties!

One small tweak you might want to make: It looks like you want GL_STREAM_DRAW instead of GL_DYNAMIC_DRAW. I was confused about the difference between these two for a while, but as I understand it, it goes something like this:

• Use GL_STATIC_DRAW if you're calling glDrawElements (or glDrawArrays, in your case) many times per call to glBufferData, without modifying the contents of the buffer (using glBufferSubData or glMapBuffer).
• Use GL_STREAM_DRAW if you're calling glDrawElements once or twice per call to glBufferData, without modifying the contents of the buffer.
• Use GL_DYNAMIC_DRAW if you're calling glDrawElements many times per call to glBufferData, and will be modifying the contents of the buffer between draws.

Dunno if this will make a measurable difference in performance in your case, but it should at least be more semantically correct.

I've had two very different experiences with valgrind (just using memcheck, I'm not familiar with the other tools it includes) on two different projects. In one project, which was a relatively small game written in C, it gave me basically no false positives, and helped me very quickly track down the few errors that were there. There were a lot of warnings I couldn't address, but they were all potentially legitimate problems in system APIs I had no control over, so I just had to ignore them. On the other project, which is a large medical application written in Objective-C, I got so many warnings that it wasn't humanly possible to go through all of them. I spent over a week just adding entries to my ignore list to try to get it down to a manageable level, and finally gave up without getting anywhere. I'm not sure what the key difference between these two projects was, but it was highly valuable for one, and totally useless for the other.

Without it being an argument: it also goes against basic philosophy of C++, like RAII idiom.

Fair enough. I'm not a C++ programmer, so maybe I just have a different way of thinking about things. I'm just extrapolating from what makes the most sense in C.

I was not talking in particular about memory at exit, but memory while running.

Since Zack specifically said "when the game closes" in the opening post, I thought that was all we were talking about. Runtime memory leaks are a completely different thing.

It's clearly a very very big mistake to let the OS clean that, in particular in game devs. It's the kind of thing that hide too much problems. I've recently used a library that was hiding tons of simple to solve problems just by not releasing automatically resources it used. When a fix was added, I could see the damage done on the overall developement process.

This is crazy bad practice. In particular because it looks innocent.

I don't see how it's a mistake if you fully understand your control flow and make the distinction between memory that has a lifespan of the entire program execution, and memory that's allocated and freed before program exit. In the case of a library, it would rarely if ever be appropriate, since leaving something unreleased would impose constraints on the code that was using it. However, say your library has an initialize() and a cleanup() function, and the cleanup() function is explicitly documented as doing nothing other than freeing memory or other things that the OS reclaims on exit. If you want to keep the library loaded and initialized for the entire execution of your program, best practice would be to never call the cleanup() function. If you want to load it, do something with it, then unload it, you cleanup() is there for you to use to avoid leaking.

The reason that explicitly freeing your memory at program exit is bad practice, other than the possible (probably minimal) performance concern, is that it implies you don't understand the control flow of your code. It's overly cautious and essentially a band-aid solution. If you're correctly keeping track of how your memory is being managed, you should be able to confidently determine when you do and when you don't need to free something. Imposing a blanket rule of "always free everything before exiting" will reduce your awareness of control flow. You could argue that not freeing things at exit might lead to a habit of forgetting to free them elsewhere, but I don't think that's the case when it's a conscious, calculated decision not to free stuff.

Yeah it's not always perceptible, depends on the architecture actually, but basically: the bigger your system memory (the one the system allocated, not the one you think you use), the slower the application execution. This have to do with management of the memory that still have to occur (because of the OS managing it behind) even if you aren't able to use or release it.

You can see the problem when the leak is big, relatively to the hardware you use.

Once your program exits, the memory you've allocated doesn't hang around; all of it is returned to the system, even when you don't explicitly free it. If you write a test program that allocates a gigabyte of memory and exits without freeing it, and run it over and over, your system memory usage won't go up at all. Every time the program exits, it'll be back to the level it was at before it started.

Yeah that's why I say "serious" dev. If it's a prototype or something similar it might not be important. As soon as you know you will have to work with the code for more than a week, you should make sure you never leak.

I'd say the opposite. This isn't a leak in the same sense as allocations increasing over the lifespan of your program without being freed. If you have quite a lot of cleanup to do at the end of your program's lifespan, it could potentially cause it to take a noticeable amount of time to exit, whereas if you let the system free your memory for you it'll have no extra overhead.

This is not acceptable at all. It means that you leak memory, making the program execution slower.

How's that, now? I can imagine you might be using a definition of "leak" that includes memory automatically cleaned up at program exit, but I don't see how you're getting from there to making execution slower.

Worst: these leaks that you voluntary let to your OS to cleanup, even when not big, are still "noise" data if you use a tool to detect memory leak.

Now that's a much more valid complaint. So, it'd a tradeoff between wasting time and effort writing and executing unnecessary cleanup code, and wasting time sorting through false positives from valgrind or other memory checking tools.

A platformer with mouse controls for shooting. It's just so awkward to play.

Kinda like Dark Castle? (Which was indeed terribly awkward to play)

And how would I go about deleting the pointer to the list when the game closes?

I'm not familiar enough with STL to answer the rest, but you don't need to worry about this part. The OS will clean up all of your allocations when your program exits. Freeing them yourself just wastes time.

I handle this by using a variadic function for shader initialization, where the caller passes in a list of attribute names and indexes to be bound. This way, the caller knows the attribute locations it needs to use, but doesn't actually bind them itself. Calling glBindAttribLocation in a place other than your shader class seems like it's asking for trouble. I assume you'll potentially have one kind of shader applying to more than one kind of sprite, and you don't want both sprites doing the same binding.

I mean that opengl stores the pixels from top to bottom. If I use negative coordinates I have to use various combinations of positive and negative to match up the sides with the atlas and then the larger atlas will not work.

It should, as long as you're only flipping once relative to the entire atlas. So, you could do all of your sub-atlas calculations, then simply use texture2D(sampler, vec2(x, 1.0 - y)) to get your output. Another option would be to flip your texels vertically before uploading to OpenGL, though that'll give you some extra overhead on texture loading.

Oh yes. It took me quite a while to figure out what was going on, other than the vague feeling that something wasn't right... Really helped the gameplay a lot when I changed it though.

Couldn't you just do

Code:

moveX = is_key_down(RIGHT) - is_key_down(LEFT);
moveY = is_key_down(UP) - is_key_down(DOWN);

No edge cases, no issues with event ordering.

Will

That's a nice simple approach, but the problem I have with it is that if you want to do a fast turnaround, you're almost always going to have a small amount of time when you're not moving. When I was first working through this, it was for a platformer with no acceleration, where it was extremely important to be able to turn around quickly. Having your character stop for a few frames while you're holding both keys (or neither key, depending on how you switch) just wasn't satisfying enough. Guess this depends on the game; anything with a noticeable amount of acceleration would probably be fine with this approach.

It's not that beautiful, but I accidentally made this creepy way of rendering text:

That's really unsettling in an awesome way. I like it.

spent an hour fixing issues with edge case bugs where hte plyer holds down multiple directional inputs (up and down), etc.

Finally decided that if they do something dumb like that, they should just stop moving. That's a much easier solution and works okay. fuck fuck fuck

My character movement has gone through quite a few iterations over multiple games to get everything like this ironed out nicely. In case it helps, here's how I do it these days: Each entity in the world that can move of its own accord keeps position, velocity, and "move" variables. Position is updated by velocity, and velocity is updated by move.

moveX and moveY are integers that can be -1, 0, or 1, and represent the direction being held on that axis. When a directional key is pressed, I set the move variable on that axis to the appropriate value, regardless of what it was before. When a directional key is released, the move variable on that axis is set to zero only if it was the value that would have been set when that key was pressed. So, if the player presses left, then presses right without releasing left, they'll move right, and vice versa. If they press right, press left, and release right, they keep moving left.

The only thing that might be nonideal is that if they press left, press right, then release right, they'll stop instead of moving left. I'm not sure which way makes more sense in that situation, so I didn't try to fix it. The overall idea is to allow new inputs to override old ones in all cases, and not have either direction be preferred over the other when both inputs are pressed.

What does it print

I was going to say that it prints nothing since it crashes on the previous line with a floating point exception, but I just tried it locally and I got 3392, which I presume is memory garbage. I guess gcc is shortcutting the division at compile time. To get it to crash, I had to split it up into int brake = 10; brake /= 0; so that 10 / 0 isn't a constant expression.

That sounds horribly overcomplicated and very error-prone. Why the hell is there an external XML file involved? Unless you need to be able to swap to a different file at runtime for different GUI behavior or otherwise need to be able to edit it without a recompile, that's just going to be a nightmare compared to writing some simple wiring code that ties all of your modules and views together.

If you have a chance to go with a clean slate, that's probably the best option. It sounds like that huge clunky system is already slowing down development, so the sooner it's sent to the moon, the better.

I want a kitten so badly, but I just don't live in the right place to have one. :-(