perhaps run pngcrush on your pngs?

Status update:
I learned of the existence of pngcrush, and then of ImageOptimizer for OS X which is an awesome piece of software (auto-optimizes pngs using also other thingies like AdvPng and OptiPNG).
I let it crush all the images in my game which is pretty png-heavy (44 mb) during the whole morning.
Now I'm back home, I feed the crushed images in the game... and XCode complains that they aren't OK because they are already png-crushed.

And that means that XCode ran pngcrush on my pngs from the very beginning! DAN DAN DAAAAAAN 

So, another useless attempt, but the more you know 

Yeah, there's a compiler or target setting or something for this.

I have to turn it off because Apple's pngcrushed pngs don't work with my parser library.

STL objects work perfectly, you just need to use them properly

STL, like much of C++, has a way of turning little mistakes into big mistakes rapidly

It is going to be a very long time before WebGL can be used for anything serious. If you jump to WebGL now you will be restricting yourself even more than if you stick with XNA, your game will be supported in like 3 browsers and it's questionable whether some of the browsers you most want to reach with HTML5 (mobile?) will EVER support it.

Moreover, I think you should focus on just getting your current game working. If this is your first game (?), it's more important to get the experience under your belt of seeing something to completion and learning what you need to learn about game design rather than anything technical, and switching platforms could sidetrack you badly from that. There's no guarantee that the skill set you've been building up with XNA will transfer, especially to something exotic and mostly-untested like HTML5/WebGL. You will be learning a lot of stuff from scratch.

If you really want wide compatibility, for your next project looking into either Flash 11 (when it's ready) or Unity (which runs in MORE places than WebGL currently, and would be a much smaller jump from XNA, small enough that "porting" your current code might even be possible without uprooting the project completely).

Is it going to be weird that the screen is off-center now? Esp. since the 3D effect seems to only work if you're staring at it very directly head-on.

Well, I guess now I know not to buy a 3DS, because there's going to be one with two sticks in a year and a half.

You should be testing against < paddleBox.size().  You're writing off the end of your vector, and probably screwing up something internal to it.  When the vector destructs, that's probably where it's crashing.

Oooh.

And if this is it, it could possibly explain why it only comes into play if there are two paddles-- maybe the paddles are being allocated right after each other in memory.

I'm basically at the point where whenever I see really mysterious crashes I first wonder "are there any STL objects in the immediate vicinity?", because they seem to mess stuff up hard when you corrupt their internal structures.

You see after I close the game I am presented with 'Pong.exe has stopped working'. This only happens when I have two instances of the pong paddle. Not when I have two instances of the ball, just the paddles.

This sounds like your paddle class has a destructor which is doing something incorrect. Like perhaps the destructor is freeing something which is a shared resource rather than having a lifecycle bound to the object. Then when the destructor runs twice you wind up double-freeing.

Have you yet run the program in the debugger?

I don't have a destructor for the classes because the class does not have access to any of the programs resources.

The class contains no pointers or static member so there is nothing that could connect one class to the other.

When I run the program in the debugger there are no problems.

EDIT:
here is the class source
http://ideone.com/WM66j
http://ideone.com/P3eNj

Well you've got a vector in there, so there's still *a* destructor running (although not one that can access shared resources like I proposed earlier)

Things I'd be curious about.

- Where and how are you deleting the paddle when you're done
- Crazy thing. If you comment out std::vector<SDL_Rect> _paddleBox; and all lines accessing that member (maybe return dummy data from getCollisionBoxes()) do you still get the crash? This will of course prevent the program from "working" but you should be still able to replicate the crash or not.

(Another thing: What if you *added* a destructor, and put a printf in it or something? How many times do you see the printf emitted? I'm still very curious about some form of double free.)

You see after I close the game I am presented with 'Pong.exe has stopped working'. This only happens when I have two instances of the pong paddle. Not when I have two instances of the ball, just the paddles.

This sounds like your paddle class has a destructor which is doing something incorrect. Like perhaps the destructor is freeing something which is a shared resource rather than having a lifecycle bound to the object. Then when the destructor runs twice you wind up double-freeing.

Have you yet run the program in the debugger?

Polycode works fine on Linux, I've used the Linux target. However you may have to compile stuff yourself to make the Linux version work atm.

What about Monocle?

LodePNG? Hm, definitely curious about the stb_image thing.

I've replaced the old CoreImage loading with stb_image and...

 

It is some 2 time slower in loading! Loading a 960x640 image takes up to 710 ms, that's nearly a second!
I have tried disabling BGR to RGB converting and alpha unpremultiplying, I even tried loading from memory... but it remains too slow.
Loading times have doubled and loads that were unnoticeable now are annoying.

I could have attempted a careful performance analysis to find its bottleneck and correct it, but burning everything with fire was easier 
Hg revert --all, to me!

LodePNG is also pretty slow, I think.

You have to remember that a library which is designed to have compact code and fit in one file is probably not a library designed for speed!

yeah, it is a nice little file of awesome. I recall that there was something exactly like that but that loaded PNGs, but I can't remember the name 

LodePNG? Hm, definitely curious about the stb_image thing.

and maybe random events?

Marines mowing everything down under god's eyes with M4's may get repetitive.  

An interesting potential left-field direction to take this: Maybe you have a limited amount of ammo from the start of the game.

And once it is gone it is gone. Period. No one can make c4 or machine gun ammunition in ancient rome.

So if you run out blasting and blowing thigns up in level 1... well, you'll be dead by level 3.

There's a bunch of such engines. There's a minimal one in my sig, I've been impressed lately with Polycode.

What is it you want out of an engine?

When I first started using dvcs, I was worried because many of the people I saw who had made the switch wound up spending an enormous amount of time precisely fiddling with their dvcs setup and practices disproportionate to the time savings they got from the tool. I was hoping I could use the tool in a minimal manner that prevented falling into this trap.

Now I'm seriously looking at writing mercurial plugins

Why not find an open source 2D game engine, and take it apart to see how it works?

[And integrating some forgetfulness would add immensely to the realism.]

Only allowing the "known world" to be used in path-finding would be pretty trivial. The tricky part would be how the AI decides which unknown hallway to try next if the region between its position and the target were unknown. And integrating some forgetfulness would add immensely to the realism.

Yeah, that would be awesome. What would be especially great, I think, is if NPCs could actually get lost. Like put metadata on the map describing parts of the map which look "similar", or coloring parts of the map with how visually repetitive that part of the map is. This would allow you to make it so that the "twisty little passages, all alike" ish a part of the map is less well the pathfinding works because the NPC briefly gets confused about where on the map they are, or maybe their "forgetfulness" increases in those parts of the map, just like would happen with a human player.

Though I'm still not certain whether, if a NPC were behaving this way, it would be obvious to a human observer that the NPC was doing so.

Just a random passing thought...

So you think about pathfinding in video games. Regardless of what pathfinding strategy you use, there's something in common: The NPC needs to get from point A to point B, so the instant it realizes it needs to do so it starts intently walking directly along the shortest path to B (even if B is on the other side of a wall and it shouldn't be able to see B's exact position...).

In short, the NPC behaves as if it has access to the level geometry. It behaves like it's working off of a perfect overhead map.

That's not how anything would behave in the real world. In the real world, someone like a security guard would know the complex they work in as well as if they had a map in their head, but many NPCs it seems like ought to be having to build a map in their heads as they go-- they'd be aware of any parts of the map they've line-of-sight "seen", but no more. And they shouldn't necessarily be able to make some of the mental leaps a pathfinding algorithm would (for example, maybe a wolf in an MMORPG shouldn't be as good at pathfinding as a human-- I originally started thinking about this watching our dog try to navigate around some clutter by the back door).

I'm just curious-- has anyone ever seen a game that actually approached pathfinding like this? Something like forcing individual pathfinding actors to "discover" the map by traveling it instead of just giving them access to the level data from the start. I'm wondering whether implementing pathfinding this way in a game would make NPC behavior seem more realistic, or just make it seem buggy...

Really REALLY need to start documenting my processes better

Like "how EXACTLY did I make this package?"

Or "how did I start this server, last time?"

Or "where, if ANYWHERE, did I save my logs?"

Interesting thanks.

2. Clang on windows might be a problem because of support of the standard library. Complex topic but to sumup : there is an almost finished wip about making CLang be able to compile with the C++ standard library shiped with Visual Studio.

Huh. Interesting, but this only helps me if I have access to Visual Studio right?

What I really want is something like the mingw libraries, which will allow me to use POSIXy APIs but then build for Windows. I'm mostly indifferent to access to "real" win32 as long as I can get stuff like SDL to work.

3. Clang command line attributes is the same than gcc (until v3.x) so it's easy to just check if it works.

Woo

Also with the idea of being told "don't use uintptr_t to store pointers" D:

Enjoy not using the windows api at all then


(as awesome as that would be its unfortunately not gonna happen)

It's really quite feasible for C++ garbage collection to coexist with the Windows API.

WinAPI is a C library, so all allocations come from malloc, presumably.  A garbage collected C++ environment can use a different allocator than malloc, and the garbage collector only considers pointers that come from that allocators memory space, which would be separate from C malloc.

Ada already does something along these lines with it's storage pool system.

Interesting, but I think his point is that the older windows APIs often provoke you into doing things like storing pointers to objects in the integer "user data" slot of event callbacks?