mechacrash, one common thing you should probably be aware of is the idea of a "texture atlas". What many people do is take several textures they will be using at about the same time, each of which is probably not a power of two image, and fit them jigsaw-style into a single large image which is a power of two. (After packing your images in there will be space left over, which is filled either with some sort of neutral color, sometimes or "extra" texture pixels so that you don't get images "bleeding" into each other.) There are a number of free programs around for packing images into atlases. What you can do once you've made an atlas is just bind your atlas texture once, and then switch between the different textures within the atlas by changing your glTexCoordinates.

I would recommend staying away from NPOT textures even if some of your target systems allow it. It will make your program harder to port later and gain you very little.

I don't think you're looking for something like game maker. If you want a text based engine you most likely want to look for "interactive fiction" (that exact string will turn up a lot of stuff on google) engines, such as Inform. There is a big community for this stuff so tutorials or templates for Inform should be easy to find.

Alternately, really what might work even better, given what you want seems to be less about text parsing and more about algorithmic stuff? I'd suggest just picking up a tutorial for Python. Python is an easy to use "real" programming language that gets you to the point where you are able to do complex text operations fairly quickly. You can run it in the OS X "terminal" (I think there's also a way to make standalone programs) and once you learn it to the point where you can make a text-based game you'll be in a good position to try it with graphical or web stuff.

If you are seeing any of the vector functions come up in the profiler, it's because you didn't compile it to allow inlining. On the iPhone, Chipmunk works best if you compile it as a separate static library, disable thumb compilation, usef -ffast-math and -O3. I've seen as much as a 10x speedup between debug builds and optimized builds.

Thanks! I'll look into that. I have been meaning to ask about this over at your forum

In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects.

Wow! Yet another example of why actually doing profiling is so much better than guessing. I'd have assumed that the cost of function calls would dominate the actual maths by some way.

Well... again afraid to get too far off topic, but it also might be a sign profiling can be misleading.

What I actually mean is that the last time I tried this I found the most time spent in, like, cpv() (a method that just packs two floats into a cpVect structure) and cpvadd() or something. Since these are very simple methods it might be that the function calls were dominating the math-- the fact cpv() doesn't properly speaking do anything might be a clue of that. However if this is what is happening that does just mean I have set up the compiler wrong somehow, because the way I have things set up I would expect both those functions to be inlined. I really need to go back and explore this more, I unfortunately had to move on to something else before I could spend enough time on it to be sure of anything.

(Incidentally if anyone has had a chance to do serious profiling of a Chipmunk program, I'd be curious to hear what your results were.)

mmc - adapting these libraries to use SIMD instructions would be complicated. You could change how the vector maths works in a few places, and the matrix inversion code, but as we're 2d i don't think you'll see huge gains. What would be needed would be to rip out the solver (which is the core component that essentially inverts a big nxn matrix) and put in a new one which does the same work with one less loop, using SIMD.

Hm, okay, interesting.

ODE doesn't look so different to me, though I only know it vaguely. What would say is different?

Well... hm. I'm not sure I can actually justify what I said there It's of course fairly similar in terms of the way the world is constructed and how it behaves (although it does have a few more object types than either chipmunk or box2d seems to-- probably unsurprising given it's supposed to be 3D, although I think you could use the mesh type to create convex objects in 2D, and the "plane" type doesn't seem to have a 2d analogue in chipmunk). It seemed mostly different in terms of the programming interface, which seemed a lot more opaque in certain ways. Like with Chipmunk it feels like if you wanted to raycast you'd describe a ray and it would inform you via callback of a list of objects that collided, in ODE you'd do something like actually creating a ray object, putting it into the space and then testing for collisions with it-- like frequently the only way to get information out of the system is to interact with it. Now that I think about it this is maybe not that much of a difference. It might be just that the ODE programming interface is sort of baroque and I am not used to it.

I have used only Chipmunk and have had a great experience with it. I don't really know much about Box2D, though if we are talking about bullet-point comparisons it seems worth pointing out that box2d seems to be a little bit more widely ported. There is that javascript/actionscript version.

I would be actually slightly curious to see a comparison of Box2D or Chipunk to ODE, the Open Dynamics Engine (assuming one uses ODE as a 2D engine-- I know World of Goo did this). I have not used Box2D but from what I've seen of it it is actually fairly similar to Chipmunk. However I did some experiments with ODE and it seems to be EXTREMELY different.

On the whole floats/doubles thing (please excuse me if I veer off thread topic here)-- one thing I'd actually be slightly curious about is whether anyone has loooked into accelerating a Box2D or Chipmunk style physics engine by doing vector math with SSE or something like it. For example an x,y vector instead of being represented by two doubles could be represented by a single packed SSE register. You would then potentially get to do each vector math operation for the price of a single floating point op. I am thinking about this because I am currently porting a Chipmunk-based game to the iPhone and (although I'm pretty sure I may be doing some things wrong) Chipmunk at the moment is the performance bottleneck. In my preliminary profiling meanwhile I find more or less the biggest contributors to runtime seem to be constructing and performing simple arithmetic operations like adds and subtracts on cpVects. I know that the iPhone has a vector/SIMD unit called the VFP although, infuriatingly, there appears to be basically no documentation yet on how to use it. I don't know what the VFP's limitations are but it seems like speeding up adding a pair of floats would be basically what a chip like that would be made for. (Incidentally in my iPhone code I switched Chipmunk to using floats exclusively, no doubles, and it doesn't seem to make any difference in Chipmunk's behavior. I did this because the iPhone can handle floats as efficiently as it can doubles-- double checking this I find claims that the 3GS specifically is actually much faster with single-precision floats than double-precision ones, although I am not myself testing with a 3GS-- and making this change allowed me to avoid float<->double conversions elsewhere in the code.)

Man, regarding libraries - I wish more libraries would have a tutorial like "make a simple shmup or other game with this library so you know how to use it in most situations! woo!".

Hm.

There are these "screencast" thingies that a number of web CMS engines have on their websites, where they basically film someone making a small website in about ten minutes. These usually double as a quick tutorial and a sales pitch for the engine. It would make a lot of sense to do something like this for some game engines.

So I have a setup like this which I tried to build into a pick-up-and-go package other people can use. Here's the package download and instructions on how to set it up (libraries included are listed at that link). It's a bit bare-bones and it uses OpenGL rather than SDL2D-- although OpenGL is pretty nice for 2D work, and either way it should be relatively easy to adapt that package to using SDL 2D.

I mostly assume you're doing your main development on the mac with XCode, but I also included a quick set of step by step instructions for running things from the Windows side with MingGW/MSYS.

Profiling cache misses:
AMD: http://developer.amd.com/cpu/CodeAnalyst/Pages/default.aspx
Intel has VTune for the same purpose.

If you do cache profiling with AMD's Code Analyst, or Intel's VTune (or I guess Apple's Instruments?), does this give you information that more or less accurately applies to how cache would perform on a chip different from the model or manufacturer of the chip you performed the testing on?

Yeah... I dunno.

There's clearly some really good advice in here and I appreciate the thought about planning for vectorization but...

The article seems to be framed in a funny way. Like I found the dichonomy he sets up between data driven / object oriented programming a bit weird. It seems like the sorts of designs he describes have their place, and so do OO designs. In particular the nice thing about OO of any form is that it tends to make rapid prototyping very easy-- the "data-driven" designs he's describing seem to me like they'd be of the type that would work best if you know everything about your architecture and you're reasonably certain it's not going to change. I feel like I'd be more likely to rewrite parts of a program in this fashion toward the end of a project when optimizing, and less likely to either start out thinking that way or somehow try to form a whole-program design around it. The article though (aside from a little "well, I guess OO is okay for GUIs" at the end) seems to be suggesting that you somehow need to make a choice, or that OO is something you should avoid if you want to do data-driven programming later. Maybe the three pages he had to work with just didn't have room for a more nuanced view, but still I'd hesitate about showing this article to a beginning programmer lest they take its advice a little too literally over the much more important axiom that "premature optimization is the root of all evil"...

Also... maybe this is just me being ignorant but really, how often is poor cache usage the primary bottleneck in a design? It seems like in order to get to the point where cache is a noticeable limiting factor you'll have to have basically optimized everything else first to an insane degree. And can you even test for / benchmark that sort of thing? Won't most every system your game runs on behave differently w/r/t cache?

OK so been playing this for about a week and basically at the end.

This was great, one of like three iPhone games I'd unhesitatingly recommend to someone at this point. Everything works together well. The controls are well suited to the iphone, the level design showcases the controls well, the framing/writing presents the levels well. I like that the levels are subtly designed for replayability.

I would have been a bit curious to see what a version with music would have been like. It would have helped a lot in differentiating the levels, I think. Not sure how one gets around the 10 MB problem. Actually I'm now sort of worried about what I'm going to do about that issue for the soundtrack in my own game. Problematic

FYI One more nitpicky bug report: Twice over the course of playing this I was able to trigger some sort of bug where, while simultaneously moving upward and smashing sideways into a crumbling wall (once via a swing, once via the boots), I was actually able to somehow go up through the ceiling and get stuck there. I was able to walk back and forth inside the ceiling but couldn't get back down.

If you want to learn more about this subject google something like "c++ operator overloading".

That is odd.

Tar is a good idea

If you're transferring mac to mac this would be the sort of situation .dmg would be well suited for.

Also: There are two ways to make .zips on mac. One is to use the command line "zip" tool. The other is to right-click in the finder and say "compress". The right-click compress feature in my experience preserves more of the mac-y elements of the zipped file (sometimes in a weird way that only other macs can extract, like it creates a weird __MACOSX folder if you try to unzip the file on windows).

In some testing just now I tried zipping and unzipping with the command line zip tool and permissions were preserved, but I am on 10.6. I'd suggest trying the Finder zip method and failing that using a dmg?

Hi,

It looks interesting, however when I try to open it I get the error message:

"You can't open the application Go Beryllium! because it may be damaged or incomplete."

I'm using OS X 10.6.1

Does C++0x have any sort of endianness handling as part of the language standard?

Minor bug report?

Go to the game over / level win screen, put the iphone to sleep, wake it back up again. The pause menu will appear on top of the game over screen and neither one will really work right.

I don't even know what Ocaml is

Yeah... I am stupid and briefly got you and increpare mixed up

...Increpare, you may find it interesting to check out the ICFP!

[In general, I have to say I have quite a bit of respect for your porting prowess ].

Well thanks much! Although I note this comment comes after you successfully demonstrate my game doesn't currently work in multiuser mode at all on a whole platform

In my case cross platform cleanliness is an absolute necessity because I develop exclusively on macs and actually have to go to some difficulty to even test on Windows... so it's either I'm crossplatform, or 90% of people don't play the game. Of course this makes it kind of funny when I actually somehow manage to fail to be mac-platform compliant in some way... when I was developing Jumpman I actually initially made the editor totally dependent on having a three-button mouse, and didn't remember until several months in and a playtesting cycle that most normal mac users aren't using scrollmice like I am.

---

So here's actually a cross platform question I've been wondering about awhile: Does anyone know of a cross platform way to do internationalization / languages? I know both mac and windows have APIs where at any time you can get the users' preferred language, and switch out strings based on that preference (I don't know what Linux has). Are there any cross platform APIs that can let you pack multiple languages into a single program and picks the correct language for you based on local OS settings?

Veering a little offtopic but... Glaiel, have you ever heard of Cilk? It is actually surprisingly similar to what you propose there. Like here is a Cilk program:

Code:

cilk int fib (int n)
{
    if (n < 2) return n;
    else
    {
       int x, y;
 
       x = spawn fib (n-1);
       y = spawn fib (n-2);
 
       sync;
 
       return (x+y);
    }
}

Every time you say "spawn", you could potentially be opening into a new thread while execution continues; when you say "sync" execution waits until all spawned work has finished. A "microscheduler" maintains threads of its own and assigns spawned work to threads in an optimal manner (or on a single processor system might just run everything serially). I don't believe it has the sort of notion where you can say something like "sync a" separately from "sync b", but I think you could actually emulate that by carefully putting the calculation of a and b in separate functions, then spawning each.

It all seems really natural and one neat thing about it is that since they define this by just adding a couple of extra syntactic ideas to C, if you #define "spawn" and "sync" as noops Cilk code magically transforms into C.Unfortunately I've never really given it a shot...

I actually learned about this from the ICFP (a Cilk team won one year), which actually Glaiel you especially might be interested in given your stated interest in Ocaml and such things. The early years of the ICFP especially were a great showcase for bizarro research languages.

I think it depends on how much Java you've done.

The thing is C++ can be a good language to start with but it will be awhile before you're at the point where you can make a game. Something like ActionScript on the other hand you reach the point where you have all the elements necessary to do game programming a lot lower on the learning curve.

If you are relatively proficient with Java on the other hand then transitioning to C++ will be easy enough you <i>could</i> jump right in at the game programming level. (Though, if you're coming from Java make sure you use the STL from the beginning.)

You can always split the difference and go with Python. Very Java-like in certain ways (IMO), does not subject you to a lot of the frustrating things C++ does, can interoperate with many C++ libraries, a good selection of existing game libraries.