tbh im worried that all these new developments might make it impossible for me to develop/distribute games in the future :/

That's been a growing worry of mine too, but this all seems like a step in the right direction to me, or at the very least doesn't directly make it worse. Is there something you see in it that raises new barriers for distribution?

Well, "verifies" is the wrong word. There's no communication of what the client thinks the player's score is; a score submission consists of a set of inputs and a player ID, and the server computes the score on its own by simulating the play session. I've played a couple of games lately where I wished the leaderboards would let me replay the game sessions of the people above me (specifically for speedruns, so I could see the route they took). I wanted to have this feature in the game I'm working on now, and having the score calculated by the server by resimulating it just seemed like a logical extension of that. Preventing cheating is certainly a nice side effect; the only cheats that will be possible are edited inputs or tool-assisted gameplay, and I'm OK with that.

And why I don't hear about people using clang in favor of gcc/mingw?

I think clang is just now getting to the point where it's a viable replacement for gcc with MinGW. Last time I tried it, it didn't work. Can't remember the specific reason, but it had more to do with clang not being finished than gcc being preferable.

I find it really interesting that bitshifts and bit hacks in general are still used for game dev, even now that we have "unlimited processing power"!

Extra processing power opens up a lot of doors beyond writing less efficient code. It's kind of a pet peeve of mine that software tends to get slower at the same pace that hardware gets faster, so nothing ever gets any more responsive from the user's perspective. Some examples of good usage of extra CPU cycles/RAM: Braid's rewind mechanic, Minecraft's huge world of cellular automata. I'm working on a game with online leaderboards, which verifies submitted scores by running a full simulation of the user's play session based on their inputs. For this to work, my game simulation has to be fast enough to verify a full play session in a tiny fraction of how long it took in real time - specifically, a fraction equal to 1 / the maximum number of players submitting scores at once.

Aside from all that, bit twiddling is sometimes more expressive than other, more expensive ways of computing things.

I finally caved and bought GTA V. I'd read so many conflicting reviews of it that I had to try it out for myself to judge. It's actually...really good. Seriously. Everything has a level of polish that was lacking in the previous games in the series. I'm more invested in the story than I ever expected to be. Still can't say I dig the sandbox aspect of it so much, but taken as a story-driven game, it's holding up like a champ.

http://graphics.stanford.edu/~seander/bithacks.html

+1 for this. Really great resource. For the "too clever by half" concern, I usually reference the URL in a comment next to the function I use from the page, just in case I come back later and can't remember what's going on.

Seems pretty cool.

In SteamOS, we have achieved significant performance increases in graphics processing, and we’re now targeting audio performance and reductions in input latency at the operating system level.

I'm hoping these improvements find their way into desktop Linux one way or another. My limited experiences with it so far have left the impression that it's currently harder to get things to be as responsive as on Windows or Mac OS X.

My first game of Spelunky ever: August 23rd, 2013
My first Olmec victory: September 8th, 2013
My first King Yama victory: September 22nd, 2013

I've logged nearly 100 hours of playtime on Steam. It took a lot of hard work to finally beat it. What a fantastic game! Next goal would be to be able to win consistently during daily challenges...

Code:

trunc(x * 0.001 + 0.5)

The only trick with adding 0.5 and truncating is that it doesn't work for negative numbers - it'll act like ceil() rather than rounding to the nearest integer. That's the reason round() exists. I had to debug this once before in my own code where I assumed adding 0.5 and truncating would be enough...

all "this debate is useless" derail posts are deleted.

Yes please! Those are one of the most frustrating things for me when serious discussions arise. Even if we don't get a dedicated Serious Discussions forum (which I think is a great idea), I'd love to see this rule applied to the existing threads in General and Games.

round(num * 0.001f) is probably what you want in this case. ham and brie's solution is good too.

21000 * 0.001 returns 2.10000000000000E+1
trunc(21000 * 0.001) returns 20

Floating point numbers are pretty awful, aren't they? I've been doing everything in fixed point these days, and it's surprisingly nice. Not nearly as much of a pain as I expected.

If you want to stick with floats, doing as much as possible with powers of two (including negative ones like 0.5, 0.25, etc.) can help keep your numbers rational. 0.001 isn't representable in IEEE 754 without rounding.

Why wasnt there a witch hunt when the guys at Penny Arcade made jokes about sexual abuse in general / pedophilia, or in the case of the silly strip in question, slavery? (they have made offensive strips in the past)

An important point that keeps getting missed or ignored: This isn't about the comic itself, it's about Penny Arcade's reaction to criticism of the comic. If they hadn't responded in such a way to the response to this particular strip, there would have been almost none of this controversy going on. The aftermath of the comic was what brought Penny Arcade's toxic attitudes to light, and the Dickwolves merchandise is the embodiment of it. That's why it's offensive for Mike to say that it was a mistake to pull it.

All this talk about GTA V has made me go back and give GTA IV another try. I bought it ages ago and had never played through more than the first mission or two. I'm really trying to find something to like about it, but I can't. Every character is a terrible person, and not in a clever way that would make me appreciate them for being well-written. Every aspect of the gameplay is mediocre at best, presumably since it spreads itself so thin and doesn't focus on making any one part exceptional. The only reason I have to keep playing is a desire to understand why this game series appeals to so many players. I'm just not getting much of anything out of it.

In contrast, what I've seen so far of the story of GTA V looks at least moderately interesting. I don't want to spend $60 and go through the chore of gameplay to see it firsthand, though. I'll just keep watching LPs to experience it that way.

You'll have to be more specific. What goes wrong when you link to only SDL2.framework? I'm not an SDL user myself, but from what I can see on the website it's most definitely an either-or thing. You can't generally use two different versions of the same API simultaneously. Presumably some of your code is written in a way that depends on legacy APIs, and it'll work if you update it for SDL2? It's surprising that it even compiles and runs in any form at all with both frameworks linked.

Looks like you've linked to both SDL.framework and SDL2.framework. Surely you only want to link to one or the other?

Sounds interesting. More info!

Sure! Details: This is a remake of something I wrote 10 years ago back when I knew nothing about writing clean code, so instead of starting from the tangled mess, I'm doing a full rewrite and reproducing the old game's mechanics from scratch. One of the things it does is push the player to the side if they jump and hit their head on the very left or right edge of a block, as long as their center is outside it. So if you're standing just barely under a ledge and jump upward, instead of colliding and stopping, you get pushed to the left or right and continue upward.

I wrote a reasonably simple collision system before I realized I needed to do this, and the necessary behavior didn't fit in very well with what I'd written. The old game had some kind of hack check for adjacent blocks to the player when they bumped their head, which wasn't going to be satisfactory for the new game. Here's what I ended up doing to solve it more nicely: In the player's collision callback, if the collision occurred on the top side (everything is an AABB), the colliding rect is tested to see if the horizontal center of the player rect is outside it. If so, a speculative collision test is performed for moving the player to the left or right far enough to clear the block above, and if that test passes, another one is performed for moving upward from that position. If that test passes, or the collision occurs later than the first colliding block (meaning there's a second ceiling higher up), the player is pushed to the side and continues upward. Otherwise, it's considered a ceiling collision and the player's upward momentum is canceled.

The reason I found all that necessary was to be sure not to create bugs where you could pass through blocks to the side or above if the player ended up intersecting them after being pushed to the side. I think it should cover all of the bases correctly. Really satisfying to see it all work, as crazy as it seemed at first.

json is super awesome, far superior to XML. If it's just data you're storing, I'd highly recommend it. If you're looking to use scripts too, Lua is probably a good choice for both. Storing your data in a format like the example in your first post seems perfectly sane to me.

I needed to implement something tricky with collisions in the platform game I'm working on, and I came up with a crazy crackpot scheme to do it by checking hypothetical future collisions in a certain case and changing my collision response behavior based on the result. Lots of coding later, I had it working perfectly within a few minutes of tweaking after the first compile. Would've been a painful one to debug if it didn't behave itself!

EDIT: Didn't find much :/ Guess it's off to the drawing board.

How about Chipmunk Physics? I've used it and it's fantastic, though it might not alleviate all of your Box2D headaches. Not sure why you'd prefer a dynamic library to a static one; static libraries are far more headache-free in all cases.