TIGSource Forums

PLEASE SEE MY UPDATE IN "ANNOUNCEMENTS" (http://forums.tigsource.com/index.php?topic=18837.0)

==========

So after I finished my last game (http://runhello.com/) I released a package of sample code I called Jumpcore (http://msm.runhello.com/?p=64), basically the basic scaffolding of a cross-platform SDL+OpenGL game. I don't think anyone ever actually used it. But, I'm working on a new game now, and I think I may be building something a little more useful for this one. Basically what I have now is a "Jumpcore 2.0" sort of setup which:

- Compiles out of the box for mac, windows, linux, iPhone, and iPad
- Runs in both OpenGL 1.0 and 2.0 modes with one rendering path, and
- Comes with support set up for text rendering, basic menu GUIs, and some basic utility stuff like loading internal files and loading PNGs into textures.

And I think I'll have it working with Android pretty soon. Basically you write one display function full of OpenGL ES, one audio callback, and some event handlers (which wrap SDL events on the desktop platforms and touch events on the iDevice platforms), and your code will just work on all those platforms. The "both OpenGL 1.0 and 2.0" thing refers to that I've got some wrappers for things like glRotatef() that allow you to write OpenGL 1.0 looking code that actually is being converted to shader-based OpenGL 2.0 under the hood. This allows you to more easily take advantage of shader effects without sacrificing compatibility with old PCs, and more to the point is a really big deal on iPhone/Android-- since ES 1.0 performance can be very poor on ES 2.0 devices, but when you're in ES 2.0 mode ES 1.0 functions are not available (a weird problem that vanilla, non-ES OpenGL does not have), so you're normally expected to write two totally different render paths and it's a big hassle.

What I'm trying to work out is: Is this useful? Is this something if I released it as open source, people would use it? I'm developing this either way-- basically "Jumpcore" is just my personal template for new projects-- but I don't especially want to go to the bother of cleaning this up and documenting it unless someone actually is likely to have a use for it. Alternately, I'd be curious for suggestions along the lines of "this doesn't sound useful, but it would be useful of you changed X, Y", or curious whether it would be any more or less useful if I released what I have now vs waiting a few months to polish some stuff and get the Android support working.

(Logorrhea follows: The big drawback here that I can see is that this is all very minimal-- my goal with Jumpcore has been to try to put something together that sort of bridges the gap between "here's this big pile of libraries like SDL" and a working program, but does no more. I don't want to get in the developer's way or place a bunch of restrictions on how their program should be architected, I just want to allow someone to sit down and start working without writing glue code or makefiles. Of course, this means that the package is primarily useful to someone who's working by writing raw OpenGL, which… I don't think anyone at all does this except me. Now, this isn't a big problem, since you could of course pretty easily bolt something like Cocos2D on top of the Jumpcore distribution. But of course you could also use Unity and get all this out of the box and more. So basically by the time I'm done I'll have "Unity, only X11 licensed instead of non-free, and with a fraction of the features"… which is something I'd like to exist, but without knowing if there's interest in it it's hard to know how much priority to put on it…)

Well I for one would be very interested indeed.

There is no such thing as too many linux compatible cross platform game libraries.

This is cool. I'd love to contribute to a C++ engine that is equivalent to flixel or flashpunk that compiles for desktop + iOS + android.

Well lets see what other framework provide cross-"a lot of platform".




Ok. So yes, I guess it's interesting for a (huge) lot of people.

Yeah, I'm trying to decide now whether we're going to make a custom 2D engine for our next game or use Unity + SpriteManager.

Sorry I kinda disappeared there! I have this project I'm sort of using to drive development in the framework and I got tangled up in the minutae of the project itself. How about this, I'll release a version of what I've got by the end of the week/weekend even if it isn't finished. That way at least you'll be able to see where I was going with this...

OK, as promised, here's what I guess I'm calling

Jumpcore 2, alpha 2 (http://vote.grumpybumpers.com/j/jc2/jumpcore2_a2_r10.zip) (revision 10, updated 11/29/10)

Short version: Here's a simple open source game framework, based on code from an upcoming game project I'm working on, that will allow you write code once and immediately run it on Windows, Mac, Linux (soon), iPhone/iPad, and Android (soon). It abstracts away the differences between OpenGL 1.0, 2.0, ES and Not ES, and bundles in most of the basic libraries you'd need to get a basic game working. (Incidentally, I think this includes the only OpenGL 2.0-compatible version of FTGL ES in the wild presently).

If you'd just like to run a simple, stupid demo app with STRANGE VISUAL EFFECTS I wrote with this in a couple hours, here's a download of that:

ABCD (http://vote.grumpybumpers.com/j/jc2/abcd_mac.zip) (mac)
ABCD (http://vote.grumpybumpers.com/j/jc2/abcd_win.zip) (windows)

(http://vote.grumpybumpers.com/j/jc2/abcd_example.png)

(This is what you get if you compile the Jumpcore2 package above with the HORRIBLE_BROKEN flag. In the demo in the basic package the weird stuff in the background wouldn't be present. Isn't it pretty though?!)

---

Longer explanation: Jumpcore is basically intended to be a bridge between "there exist cross-platform game libraries in the world" and "I can actually sit down and create a game in C++". The idea was to package together a basic selection of game libraries along with the glue code and makefiles you need to actually build them on all the platforms they can theoretically run on-- basically this is the package I had wished existed when I first started writing games and immediately got stuck on "wait, but how do you draw text in OpenGL?". The original Jumpcore was based on the code to Jumpman (http://runhello.com) and supported PC, Mac and Linux; the new version (which incorporates code from Jumpman for iPhone and some other unfinished projects) is a little more interesting, as it adds support for mobile platforms like iPhone without requiring you to change your graphics, sound or input code any. I guess this is gradually developing into something like a ghetto-bootleg, open source Unity, which thinking about it is something that it would be nice if it existed.

What's included. I picked the libraries in the Jumpcore package on a few criteria: They should be X11 or BSD licensed; they should be simple to use and not make demands on program architecture; and they should be simple to compile if you add a build target. All the libraries in Jumpcore, except Freetype and SDL, are statically built into the program. Included in this version are:

- SDL (though you don't really use it directly)
- Chipmunk (http://code.google.com/p/chipmunk-physics/) version 5.3.2 (2D physics engine)
- FTGL ES (text display)
- TinyXML
- LodePNG, and a simple texture loader based on LodePNG
- A loader for texture atlases based on Retro Affect's (http://retroaffect.com/) excellent script
- A simple GUI interface library (based on Chipmunk spatial hashes)
- Pthreads for win32
- A modified version of the http-tiny library

Also included are a set of OpenGL wrappers (partially based on FTGL ES) and basic shaders that add back most of the stuff that's missing from OpenGL ES 2.0, like immediate mode, and let you target ES 1.0 and 2.0 without having to write your code twice. (ES 2.0 normally throws out the standard vertex and color array functions and forces you to use shaders only.) This allows you to take the same code you would run on a desktop and run it on any generation of iPhone just by doing some simple swaps like "jcColor" for "glColor".

How to use this. At present, this will be easiest if you have a mac.

There's a lot of files in this package, but the only ones you want to change off the bat are program.cpp and display.cpp. You want to rewrite the following callbacks: program_init,  program_update, program_metamouse, program_eventkey, program_eventjoy, program_interface, display_init, display, audio_init, audio_callback. There is a simple demo included (it's the thing for download above). If you want to alter the shaders, you probably want to look at glCommon.

The compile directions are unchanged from version 1 of Jumpcore, and you can find those directions here (http://msm.runhello.com/?p=64). You compile the mac/iphone targets with XCode, and the windows targets with mingw (there are instructions on how to install that for both Windows and Mac at the link). If you want to compile for iPhone you'll obviously need Apple's iPhone tools and a development license.

You might not really be able to follow what's happening here unless you're already pretty familiar with OpenGL. I'll have some more in-depth documentation later that should help with that.

Problems. There are rather a lot of these. As mentioned upthread, what I have uploaded here is literally just the state of my svn repository as of this evening. This is not a finished project. The big problems with this particular package are:

- No way to build this with visual studio yet. (Not sure if this would mean just making a solution file, or if there are bigger problems because I rely on mingw to get access to certain parts of POSIX.)
- Android doesn't work. ndk-build will get as far as the link stage, then bomb out saying it can't find symbols for STL or Freetype. I think one can get STL in by compiling with either SDK 2.2 or this particular third party toolchain but I am totally blocked on getting hold of (or creating) a statically built Android freetype. If ANYONE can help with the Android Freetype issue it would be enormously appreciated.
- Linux makefile is out of date and probably won't work. Also, I haven't tested the windows makefile on a windows machine in awhile-- I do all my windows builds on mac with a crosscompiler-- so I'm not sure if that will work on the first try either!

Smaller problems include:

- It's possible that not all libraries are up to date.
- I still don't understand what happens to clientstate enable/disable when you switch shader Programs in OpenGL, and I may be doing some incorrect things in glCommon because of this.
- glCommon could use some cleaning up. There are several possibly redundant enums, which can break if you change one of them without changing all of them. There's an actually kind of nice mechanism for setting up several versions of a shader from a single source file, but it's messy to use.
- The ES1-surrogate shader in glCommon doesn't support a LOT of stuff, for example normals are missing.
- In theory, this works on PPC macs and gen-1 iPhones. I haven't tested on either in awhile.
- One of the more useful things here is some support code allowing you to toggle fullscreen/not-fullscreen as well as alt-tab out of the program while in fullscreen mode. This is broken right now.
- Maybe I should swap out LodePNG for SIL?
- There's a lot of messiness where files shared between desktop and mobile wound up sneaking into Desktop/ or iphone/
- It might make sense for several reasons to give FTGL its own dedicated shader program.
- I should add something to let you access "user prefs" folders, and keep control.obj there (instead of inside the executable, ugh)
- The way I enforce framerate is a little arbitrary here. Vsync is turned off by default.
- http_lib outright crashes on windows (it calls read() on a socket, which is illegal with winsock). Considering just trashing that thing, who needs an http library anyway
- Separation between util_display.cpp and glCommon.cpp is fuzzy, also I think I might have broken DRAW_DEBUG sometime today
- Whitespace in program.cpp is kinda ugly
- BombBox() may be broken on iDevice right now, not sure
- Is a NaCL target worth the bother? As long as all this OpenGL ES is just sitting around here...
- Anybody know how to get mingw to stop whining that hash_map is deprecated?
- Is it worth it to make versions of this that come out of the box with, like, cocos2d, or Ogre or whatever?

Anyway, thoughts? Sorry if this is a little disorganized right now, just if I waited until I had a totally finished product it would have meant nothing released for months. I'm curious if this looks useful to people, and if it's not useful, what I need to change to make it useful (I mean, besides getting it to actually work). Also, is it worth it to do development in the open like this instead of just waiting until I'm done to post? If I put up a public svn server would people use it?

EDIT: Note to self: Remember it's 5.3.4 in trunk

Eee!  Good for you for writing crossplatform software.  You have my approval!

I'm planning on porting my own engine to smartphone platforms in the short term so I don't have much use for this personally.  But when the very restrictive nature of said engine rears its head, perhaps I'll have a look.

(Update, alpha 2, 11/29: Fixed various things about licensing from the first upload. You should now be able to satisfy all license requirements for all included libraries just by including the included Readme.txt along with your program.

Also I removed http_lib because it was awful, and also because it used the Artistic License which is weird. Incidentally if anyone wants a copy of my semi-windows-incompatible C++ http fetcher library, let me know...)


Thanks! Well, the hope with this Jumpcore thing is that it's enough of a "set things up and then get out of the way" thing that you should be able to drop an entire engine, or an entire other program, in there with minimal modifications. Dunno if I actually achieved that, but...

And yeah, this is one thing I worry about. Anyone who's deep enough into C++ to be able to get something useful out of this engine is probably deep enough into C++ to write the whole thing themselves. Oh well, maybe it will still be useful as sample code to raid :)

Just Saying that looks like a BUTTLOAD of fun, now I wish I had an iphone or ipod touch...

This is totally awesome. These are all the libraries I want to use in one working package. But I use a totally different style for my code so I kinda get lost in yours. But it will be of great use because I want to implement FTGL in my "framework", so your code is just what I need. Maybe one day, I will also have time for Chimpmunk, when I will feel smart enough to be able to implement it.

Big thanks for the source, your work will not be forgotten  :coffee: :gentleman:

I noticed you're going to add support for loading texture atlases based on our script.

If you want any help or advice with that, feel free to jump into our IRC channel anytime (its on our website).

-Dave

Hello again:

Jumpcore 2, Alpha 3 (http://vote.grumpybumpers.com/j/jc2/jumpcore2_a2_r30.zip)

This is more noteworthy than the versions posted above in that this is a complete basic C++ game engine which, out of the box, compiles for PC, Mac, Linux, iPhone, and Android. I'm going to do some minor cleanups (okay, basically, I'm going to go find an Android phone to see if this works, because I've only tested in the simulator so far, and then I'm going to take some screenshots) and then I'm going to declare the alpha period over and go post this in Announcements and on my blog. If nothing else maybe people will find my Android code useful as an example of how to use Native-Activity, as it is superior to Google's sample code in several ways (for example: it compiles).

About that Android thing: Because of the way I did this, the code requires Android 2.3. This is a problem (http://upload.wikimedia.org/wikipedia/commons/9/95/Android_os_distribution.png). There are at present only two phones on the market that even support 2.3. It's not a problem for me because the program I'm writing all this code for is designed for tablets (where 2.3 is more prevalent), but it may restrict the usefulness of the package for other people. Probably the problem will become less bad with time, there seems to be a lot of churn in the Android market. I think it might in theory be possible to make a version of this that works back to 2.1 or even earlier, but it could potentially require a lot of time-consuming work and a lot of JNI glue code-- basically Google added a LOT of C++ support stuff to Android 2.3 that wasn't at all present in earlier versions.

I would be curious while I prepare this for any suggestions on how to make all this actually useful to people. For example, would it help if I moved my source code repository to bitbucket (i.e. if there were svn and hg access) or something?

Here's my todo/flaws list for this current package, I don't know:

- The Android version contains sample code from the Android NDK. The sample code for some reason is Apache licensed. I need to update the license disclosures file to reflect this.
- The Android source code is not very useful without some instructions or links on how to install the Android SDK and NDK!
- Android version atm only compiles in Debug mode, you have to edit the makefile to go to release mode
- Android version assumes OpenGL 1.0 mode at present; I'm not sure what will happen when I run it on an actual phone (the actual phones are all OpenGL 2.0)
- Android version has a long pause at startup while it does some file operations, I could easily optimize this out
- Need to add a "user directory" function
- Need to add accelerometer support?
- At the moment the iPhone and Android versions actually quit when you press the "home" button. If you remove the quit the Android version crashes, and I don't know why.
- ...did I copy the updated linux makefile into this zip? I don't remember.
- I still wonder how hard it would be to support the Pre. Easier than Android I bet.

EDIT: Here's the APK built from the most recent version (http://vote.grumpybumpers.com/j/jc2/Jumpcore2.apk) if anyone has an Android 2.3 device and wants to test (though I've found a tester on another site already). It is likely to just crash (because of the OpenGL 1.0/2.0 issue) but, who knows!

EDIT EDIT: To my utter shock I'm getting a report the APK actually works! Except when you go into landscape mode it freaks out. I didn't even know it COULD go into landscape mode.

EDIT EDIT EDIT:

(http://kristianlegault.com/images/dump/mccgam.png)

Very useful.

Great job man.

Ah, if it was 2.2 I could test it as well. Not sure how much work would have to be done differently to get it working in 2.2, but I imagine you already know you have to involve Java and the JNI.

Without reading anything but the title; YES.

This looks wonderful, but unfortunately unless it supports Android 2.2 or earlier it is not very useful to me.

Hope you can figure out how to make it work on earlier versions (if you even plan to :beg:)

So about that.

Basically originally all you could do with the NDK was write a Java program and then call functions out of your C++ shared library file. So things like the display surface get managed in java, and then every so often you call a C function saying something like "now draw a frame". You could do literally nothing from C++ except, like, opengl draw calls, except by calling the java API functions using  JNI. I think it *MIGHT* be possible to get an NDK program written this way working all the way back to 1.6 or so, if you were smart.

In 2.3 they introduced native C++ versions of several of the APIs, and also added something called "Native Activity" which means that program control is handed off to your C++ code from the start and things like event handling are done by registering C callbacks. Normally this means there is no java code component to your application-- it's supposed to be a way of writing totally in C++, however, you still must semifrequently use JNI because the C++ API is incomplete.

I started off using the JNI-calls-C++ method however, I quickly ran into walls where something would be a huge complicated to-do using this method but would be a single function call using native-activity. However it wasn't like the things I wanted appeared to be impossible using java (though I'm not sure about generated audio...). Rather it was more like, this would be an order of magnitude more complex and I want to get something working since I'm not yet sure if I can get this whole thing working at all.

So now that I have some working prototype and have more perspective, I'm pretty sure that this is what you need to do to make a pre-2.3-supporting android/c++ app: You need to write an android app that sets itself up to draw opengl and generate pcm audio data. When it's time to draw an opengl frame, generate a pcm frame, on app-focus gain/loss, or when a touch or tilt event is received, you need to call a callback (incidentally provided by the c++ code). You would also need to reimplement a small thing I do in the C++ code, where at startup I scan over all the assets in the app and save them as standalone files in the user-storage directory so that you can get to them with C file APIs. An app written this way would be superior to one written using native-activity like I did, since it's using the safer Java APIs and therefore you couldn't get into situations like the one I have where the thing crashes when stuff starts happening with the display surface that the program wasn't set up to expect (right now the android app crashes if you repeatedly switch between landscape and portrait mode, or if you close and reopen it!). However, it might be less performant than the native-activity version.

I think if I/we could find someone who actually already knows java android programming, it would be possible to write a wrapper like this very quickly and I could help with that. The problem is if I did it totally myself that means I would need to learn a decent amount about android programming just to write one piece of software which I'd immediately throw away (since, as I said, my own project can require 2.3 without it being a problem). So I think I'd need some help with this.

Setup a repository on github your favorite code site. Then we need to sticky this thread and have the community made aware of it.  You threw this out there like it's no big deal, but this could be potentially HUGE. I know that I and many others have been looking for something like this. I can't commit large swaths of time because of other obligations, but If there was a repository + TODO list + wiki, I would contribute regularly. Multiply that by X for however many indie devs would die for this and we can have a robust, seriously solid framework in a pretty short time.

Maybe move this to TIGProjects or the TIGWiki or something. Lets get this ball rolling people! ROOOOOLLLLEEEEENG!

Thanks for the vote of confidence! And yeah I'm gonna set up some sort of a public source repo and throw this in Announcements... definitely by the end of the weekend. I would at least like to address the "oh hey, there are at least two easy ways to crash the Android version horribly" before I start making too big a deal about it.

Good work man.

Just fyi in case you haven't seen it: www.airplaysdk.com (http://www.airplaysdk.com). Cross platform SDK that allows you to compile for most ARM based mobile devices. And of course my favorite part, all coding is in C++. We used this for our latest project so that we could simultaneously release on android and iOS.

Airplay looks goddamn awesome and when I first saw it I seriously considered just switching to it even though I had Jumpcore mostly working at the time. Their profiling/ARM tools look amazing.

The thing is I feel like there ought to be something out there which is like a free or open source equivalent of an Airplay or a Unity or something.

EDIT: "Shipped". I made an Announcements thread (http://forums.tigsource.com/index.php?topic=18837.0). This thread is probably now obsolete.