If you are a dedicated artist, you can find a programmer to collaborate with you easy. If you are a musician, well... maybe you can find a collaborator, if you're good enough and you search for awhile. But if you have... great ideas? As has been pointed out, sorry, there is no market for this. Almost any programmer has more ideas than they have time to act on, already.

Try the following programs: Stencyl, Click N' Play, Ren'Py. Any of these programs will let you make games *without knowing how to code*. Many of them will let you prototype ideas, and if you have those prototypes you can at least take that to someone and use that as something to show them, a way to try to talk them into helping make it into something larger. (Unity is almost in this category, it will require code at some point, but if you can come to a coder with "look at this fantastic 3d map/world i made in Unity" maybe they'll want to help you make a couple navigation scripts.)

BTW, indie/freeware team projects are **HARD**. It is hard to put them together, hard to get things done, and the teams are extremely unstable. You are most likely to succeed if you can find a way to do projects as a 1-person team.

stb_vorbis is an ogg vorbis decoder, single .c single file (so, supremely easy to integrate into your program) and is public domain.

http://nothings.org/stb_vorbis/

Same site also has a fantastic image decoder library i have used and zlib and truetype libraries I haven't, all with similar integration/license properties.

The crazy setup process for PlayN is beyond what is normal for Eclipse, so don't judge Eclipse based on what PlayN requires you to do.

Sounds like the Android Developer Tools/NDK

- I am not aware of any cross compilers that target mac but run on non-mac.

What about Code::Blocks + MinGW? Available on Mac?

What is this "xcode" I heard so many times in discussion about Mac? Some compiler/IDE?

Mingw is available on mac, I think Code::Blocks is also. However Mingw targets windows only, that is what Mingw is, it's gcc that creates windows binaries.

As rivon said XCode is Apple's IDE. It is required to make iPhone applications, and in my experience making SDL apps on mac without using XCode is a huge hassle (bc you want to use the SDL project's templates set up with their weird magic). You don't have to actually run XCode the GUI app, you can use xcodebuild, but you'll want to be building from the SDL project's xcodeproj files.

- If you wrote C++ and SDL and you didn't do anything nutty like use strcpy_s / wchar_t / winsock, mac port should be basically set up an xcode project and recompile.

- DO NOT WAIT UNTIL YOUR PROGRAM IS DONE TO DO YOUR FIRST MAC TEST BUILD. There will always be minor complications with headers or I don't know. Build early and build as often as is practical.

- I am not aware of any cross compilers that target mac but run on non-mac.

- Virtualization might be an option. I would not worry about yourself testing differences between the virtual and real mac as long as you have testers with real macs. If it were me, would not bother with hackintosh, that sounds like potentially a lot of work.

- Another option might be get a shell account on a friend's mac. This is probably at least as silly as virtualization, though.

- The cheapest mac mini on store.apple.com is $600. I find used mac minis as low as $150 (although that's for a g4, probably not what you'd prefer). This is probably a less silly option.

- I cross compile from mac to windows, and I find not having a test windows machine in the building does not prevent me from working. However, it does occasionally mean minor debugging can become very time consuming.

Thinking about induction is a good way to learn to think about recursion, which is a practically useful technique. Also understanding the concept of invariants is often useful, and if you don't essentially understand proof by induction you can't think sensibly about invariants

At a vaguer level the practice of programming is essentially the art of breaking down large problems into smaller ones, and this is a potentially more important skill to spend time cultivating than learning to write a quicksort or whatever

These are my linker commands: -lmingw32 -lSDLmain -lSDL -lSDL_image -lSDL_ttf -lSDL_mixer -lglu32 -lopengl32 -lGLee

Don't you want those in the opposite order? I thought with gcc an -lLibrary makes its symbols available to any library listed to the left of it. So -lmingw32 should be rightmost?

sprintf_s is indeed a Microsoft variant of sprintf. However I expect MingW and Code::Blocks to support minimal windows.h functionality and would be very surprised they don't compile out of the box. I am myself compiling GLee with mingw and I don't have this problem, although if I just randomly stick a sprintf_s into my code this does not work.

Also, my copy of GLee.cpp does not contain the code you quote. What version of Glee.cpp are you using...?

I think you should find a code::blocks forum. This is a

Uh, let me try again.

So I think the note in the faq about the "glXGetProcAddressARB" error implies it's something that's never supposed to happen, and that if you contact the developer they'll figure out why it's happening and try to get it fixed. Maybe this is something about the compiler you're using.

Personally, I've never used binary versions of glee, I just toss glee.c and glee.h into my program. Of course when you did that you got that sprintf_s error.

How much C/C++ are you familiar with? sprintf_s is a standard c function (on windows). If you don't see it, that implies you aren't bringing in the standard windows library. You need to figure out where that lives and get it linked in. The fact you're using GCC may be an issue here as sprintf_s may not be in the GCC standard libraries (because sprintf_s is a microsoft extension). You may be able to get Glee to use plain sprintf instead of sprintf_s. If you can describe your situation a little better maybe someone can help, surely you're not the only person to use Code::Blocks with Glee. I don't know what to tell you though since I don't have any of this software in front of me.

[stdio.h]

EDIT: I DIDN'T READ CLEARLY, PROBABLY EVERYTHING IN THE POST BELOW IS WRONG.

So, I'm getting a compilation error when I include GLee. Google says I probably just need to include stdio.h, but I figured I'd post about it just in case. Can't test it right now/don't have internet on my dev computer.

I'm including GLee.c and GLee.h into my project files and just compiling them natively from source rather than linking to the GLee.lib file that is included with the latest distribution of GLee. This is mainly because I got a bunch of compilation errors for glXGetProcAddressARB when I linked to the lib, and the readme suggests just compiling from source in that case:

One more note:
The binary version might complain about missing glXGetProcAddressARB
on the linker stage, but if you get this error, use the source
version and email me (lousyphreak [at] gmx.at).

I'm running GCC version 3.4.5 with SDL version 1.2.15 and my IDE is Code::Blocks svn 7932 although I also get the error when compiling through a previous version of Code::Blocks with the same GCC version.

Here's the error, btw:

obj\Debug\GLee.o||In function `_GLeeGetExtensions':|
G:\Matthew\Duet CPP\Duet Editor\GLee.c|20227|undefined reference to `sprintf_s'|

Wait. GLX? Didn't you say you're compiling on Windows?

GLX is the Linux opengl extensions. GLEE should be taking your commands and then translating them into calls to either GLX (on Linux) or wgl (on Windows) or whatever Apple uses, depending on OS. If You're seeing anything about GLX at all, then the fact you're running GCC is probably confusing it and making it think you're on Windows. You probably need to define Windows or WINDOWS or _WINDOWS or some crap.

You say you're running with GCC, you mean like, mingw, or cygwin? Or does Code::Blocks pack in its own GCC or something.

Porting flashpunk to LUA would be pretty neat

One thing-- you might be overthinking it.

What do these 2D graphics look like?

If these are like, pixel art images, and your color manipulation means retinting a fixed sprite from blue to red, you can (and probably should) just do this by retinting in CPU and uploading new textures.

- Short block of sample code on the internet solves my problem precisely.
- NO LICENSING INFORMATION INCLUDED

  It keeps happening

I think it depends what you mean by "OpenGL 3". I could interpret this three ways.

1. Using opengl 2.x style shader-based rendering rather than fixed-function stuff.
2. Using the OpenGL ES style stripped down API, as OpenGL 3 requires.
3. Using the new features added between OpenGL 2 and 3, like geometry shaders.

There are advantages to doing (1), even in 2D; you can get neat shader effects, like blurring, easily. You'll lose support on some older computers. However it's also possible, if you're just a bit careful, to write OpenGL 2.0 that just just degrades to fixed function 1.x with fewer special effects. This is something worth exploring *IF* you have a specific effect you want, not worth exploring otherwise.

I don't think you want (3), especially not for 2D. If you choose not to use 1.x use 2.x, not 3.x.

I think you want (2). OpenGL ES is mostly just a subset of OpenGL. If you avoid using immediate mode, and eschew legacy fixed function stuff when in 2.x code) you are writing OpenGL ES. Writing ES-compatible OpenGL is basically no harder than writing straight OpenGL, and by doing so you are saving yourself an enormous amount of work if you later choose to port to an embedded device like a phone. Of course, if you choose to use something like SFML instead of writing direct OpenGL (IMO a good idea) you don't have to worry about any of this.

I do not think C++ is good for a beginner.

Because of the way C# works, anywhere you can use C# you can use simpler languages like javascript.net or unityscript.

I think the important thing at your stage is not to worry too much about the language or the tools and just try to get to the point where you're comfortable writing a significant, structured program in some language.

"You're saying that if you leave SDL.framework out of the app bundle and force it to load from /Library, not only does it compile, you don't get the SDL_PollEvent or crypto++ crashes?"

It compiles no matter what, but yes, it runs perfectly if SDL.framework is ONLY located /Library/Frameworks.

If SDL.framework is located in BOTH /Library/Frameworks AND the app bundle, it crashes with EXC_BAD_ACCESS.

If SDL.framework is NOT located in /Library/Frameworks, the program refuses to start at all, asking you to check with the developer if the program is compatible with this version of OS X.

That is fricking weird.

Humor me-- what happens if you build, then go to the directory with your app and type

diff -r YOURAPP.app/Contents/Frameworks/SDL.framework /Library/Frameworks/SDL.framework

(adjusting YOURAPP as appropriate?)

Yeah I was saying System/Library just off the top of my head. The setup you describe sounds correct.

Can you give me a specific answer on this question?

"You're saying that if you leave SDL.framework out of the app bundle and force it to load from /Library, not only does it compile, you don't get the SDL_PollEvent or crypto++ crashes?"

Also: Are there any sdl.framework-s elsewhere on the system, maybe in ~/Library, which you find if you spotlight?

I re-made the project and re-imported everything and now it compiles and runs fine.

Welp!

False alarm. We're (mostly) at the same place we were before. I somehow was leaving SDL.framework out of the app bundle, making it load from /Library/Frameworks as it did before.

On the plus side, Crypto++ is no longer giving me grief.

Wait, I don't understand.

You're saying that if you leave SDL.framework out of the app bundle and force it to load from /System/Library, not only does it compile, you don't get the SDL_PollEvent or crypto++ crashes?

If so is certain, as Jack said you have a version mismatch.

You have apparently two copies of SDL.framework around. One is in your System/Library. The other is somewhere else on your hard drive. You have somehow set your Xcode project to load from the somewhere-on-disk library, and you probably set your header search paths to the system library. When you compile, xcode is getting confused and using part the system library and part the other library, and there are crashes.

You want to find SDL.framework in your xcode project listing, and get info to see where it really is. Whereever the SDL.framework that *isn't* in system library is, delete it. then remove SDL.framework from the xcode project and re-add it, this time making sure to add the System/Library one. Then CLEAN build. I bet this will solve your problem.

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).

Right, I'm familiar with the drill. So... how could I go about ensuring this happens?

1. Make sure the frameworks go into the application bundle
2. If the framework that gets copied into the bundle is something other than the system one in library framework, I'd actually suggest removing any copies from library frameworks (so that xcode uses the framework you are trying to put into the application bundle for headers instead of accidentally using the system framework, this happened to me once and it was obnoxious to debug).

EXC_BAD_ACCESS in pollevent i could imagine being a number of things, but if you're ALSO getting crashes in crypto++? That sounds to me like a more serious problem where probably memory is getting corrupted early. This could be something like importing a framework incorrectly, it could also be something totally unrelated to SDL (i.e. maybe heap gets corrupted and this causes SDL to crash, rather than SDL corrupting the heap).

I'm intrigued by this but I have no idea where to begin.

Possibilities here off the top of my head include
- a mismatch between the headers of the SDL version and the binary of the SDL version you are using (I have seen this happen if you get your framework configuration REALLY messed up)
- some subtle compiler difference in your own code-- for example maybe msvc is initializing variables zero and is gcc not

if i were in this situation-- and i really, really don't think this answer will be very useful, but-- what i would try to do is get debug symbols for crypto++ (I assume this would be easier than debug symbols for SDL), figure out where in crypto++'s code it is crashing, and try to identify why. if a structure that ought to be sound is corrupt, try to breakpoint at an earlier point in the code where it is not yet corrupt and set a memory breakpoint on the structure which later becomes corrupt. this will tell you which piece of code where is messing up the heap.

this would be easier if it were breaking in your code instead of in crypto++ :/

Update:

Noticed something interesting in GDB logs.

http://pastie.org/3772361

If I remove the frameworks out of /Library/Frameworks, the game refuses to open, OS X complaining that the game's not compatible etc etc.

If I remove the frameworks out of the application bundle... the game runs! Until it crashes at Crypto++, anyway (keep in mind that's a statically linked library, not a framework, as that's all I could find for it on OS X).

This is not surprising, if you have run the SDL installer it has hidden a copy of SDL.framework deep in the bowels of /System/Library/Frameworks or somesuch.

However you want your game to load the framework from inside the bundle because otherwise it will run on your computer but then not other people's (because they have not run the installer).