I am creating a little typing game for my wife’s elementary school classroom. I have so far created a simple proof-of-concept (4 scenes, with 1 not fully completed). As I will be spending more time on this project, I am starting to worry that Xojo (native) might not be the best tool for creating games. I have looked into some simple alternatives like GameMaker or GameSalad, but they feel a little “rigid” to me. I like 100% complete control over every aspect of the game and the alternatives don’t seem to allow that.
You can download my proof-of-concept game here. If you download the game, please let me know what your thoughts are on the game so far. You can go into the config panel (3rd icon from top right corner) and select the scenes, or just let the scenes change automatically based on time of day).
My question is:
Should I move the game off of Canvas to OpenGL (since I read that OpenGL will move graphics processing into the graphics card)?
Has anyone done any 2D gaming using OpenGL, and is it working good for you?
Since I have never touched OpenGL, does anyone have a sample “2D” type gaming sample i can learn from?
By the way, this only works in Mac OS X at the moment. It runs on Windows too, but the Windows version seem to not accept key strokes. It just beeps every time I press a key. I’ll get to fixing the key issue someday.
I haven’t implemented “advance” levels (auto-adjusting speeds/number of bombs) yet. It does seem to run okay, but I had to limit the resolution to 1400x900 max. Anything above that, the game will just run in a window at 1400x900. This should control the framerate down to acceptable levels.
I tested fullscreen on my 27 inch Thunderbolt display and it seems okay, but the framerate drops down to something like 15-20/sec - which is noticeable. This was the major reason I was thinking about using OpenGL instead. I also built a sample using GameSalad and the framerate remained steady and smooth no matter which resolution I tested on.
I just wish the documentation for OpenGL in Xojo is better.
I have had no problems with “animation” type apps on OSX (and some work well under windows as well)… and for the most part I am able to maintain FPS > 20… which is fine as long as you are not showing constant motion.
One trick (and I have not yet looked at your app)… is to create a PICTURE object with those items that DO NOT MOVE (or at least don’t move on each frame)… and this way you do not redraw 100% of your scene each time… just the part the “changed”.
My Snapddragon Diagramming application uses this technique and provides smooth drag and drop of multiple complex shapes
[quote=34340:@Dave S]I have had no problems with “animation” type apps on OSX (and some work well under windows as well)… and for the most part I am able to maintain FPS > 20… which is fine as long as you are not showing constant motion.
One trick (and I have not yet looked at your app)… is to create a PICTURE object with those items that DO NOT MOVE (or at least don’t move on each frame)… and this way you do not redraw 100% of your scene each time… just the part the “changed”.
My Snapddragon Diagramming application uses this technique and provides smooth drag and drop of multiple complex shapes[/quote]
I actually have two images. The first image is to create the background (non moving parts). This becomes the backdrop and does not get repainted throughout the level. The second image is a buffer which captures all the moving sprites and is drawn on the top layer. Without the buffer, the animations would be unusable.
This should be able to be done in PURE XOJO without OpenGL at FPS >20 no problem… it is just a matter of what you draw, when you draw it, etc.
You don’t ever seem to have more that 20 or so items moving at once… that should be easy to manage.[/quote]
Well, for other scenes, there could be more moving sprites. The underwater scene has a method to paint any number of fishes. I’m just limiting the numbers to a few until I make a final decision to move to OpenGL or not.
[quote=34341:@Alwyn Bester]There is a couple of tutorials on how to use OpenGL with Xojo at www.xojo3d.com. These tutorials should give you a good start at setting up OpenGL.
IMO doing 2D graphics with OpenGL is a great idea, because you can then take full advantage of the GPU in your computer.
Would love to see a Windows version of your game…[/quote]
I’ll fix the keystrokes and have a working Windows version ready later today or tomorrow. I have gone through the website you noted above, but it just seems to focus on drawing shapes from scratch. I would love to see a tutorial on just “plopping” 2D images (sprites) onto a surface and move them around. That’s all I really needed, really.
I’ve already started work on such a tutorial, since there are a few people that requested this (2D graphics with OpenGL). Will post it here as soon as it is available.
Here’s the Windows version. I have to say that on my little Windows laptop, the game is horrible and disappointing. Each time I fire a missile, the game would stutter and the sound should become choppy. I’m sure I can probably optimize it more for Windows. All I have is a very old Lenovo laptop, so that probably did not help much.
But its issues like this that would make OpenGL extremely beneficial for projects like this since graphics would be moved onto the graphics card for better drawings/animation. I can’t wait for your tutorial on “2D graphics with OpenGL”.
Are you using InvalidateRect and the areas parameter? For a similar setup of a constant background with several small moving sprites the fastest technique was only calling InvalidateRect on those regions that need redrawing. I’d keep a list of what sprite was associated with each rect and in Paint it drawPictures the background image then draws the sprite. Runs faster because it’s only drawing 40 small regions instead of a full sized image then 20 small ones.
That only works if most of the scene is static. If you want a fullscreen constantly shifting background or sprites of any size then OpenGL is the way to go. Compared to Picture and Graphics though it’s basically declares; and the drawing of basic shapes in Alwyn’s tutorials is the place to start. It builds up to Tutorial 11 about texture mapping and how you’d finally get to ‘DrawPicture’ in OpenGL.
[quote=34394:@stuart s]Are you using InvalidateRect and the areas parameter? For a similar setup of a constant background with several small moving sprites the fastest technique was only calling InvalidateRect on those regions that need redrawing. I’d keep a list of what sprite was associated with each rect and in Paint it drawPictures the background image then draws the sprite. Runs faster because it’s only drawing 40 small regions instead of a full sized image then 20 small ones.
That only works if most of the scene is static. If you want a fullscreen constantly shifting background or sprites of any size then OpenGL is the way to go. Compared to Picture and Graphics though it’s basically declares; and the drawing of basic shapes in Alwyn’s tutorials is the place to start. It builds up to Tutorial 11 about texture mapping and how you’d finally get to ‘DrawPicture’ in OpenGL.
ps your app is fun : )[/quote]
Excellent suggestion. I actually started off refreshing only the areas right around the moving sprites, but I thought that might be too many “calculations” and could slow down the game vs just refreshing the entire sprites layer. Now that I’m a little further along, I’ll have to try your suggestion and compare the results. By the way, thanks again for your help in calculating the missile projections. It has been a great and fun learning experience so far.
On second thought… I retested “InvalidateRect”(sic) and things are so efficient now it didn’t make that much difference, and sometimes on the worse side. It seems when the dirty regions are spread wide across the canvas it takes a little more work to handle all the clipping. So drawing the full background image then the sprites each time is pretty efficient (on all platforms?).
Where I think you will see a difference is if you’re using PixmapShape to draw the rotated sprites every frame. When rotated it’s much much slower than DrawPicture. Instead use a pre-built array of Pictures of the sprite rotated say every 4 degrees. In one test 120 sprites drew at 60-50fps with 35% cpu when only DrawPicturing. The same with DrawObject managed 5fps at 90% cpu. *not a compiled test
You actually got me very excited to dig into 2D sprites with OpenGL. It is something that I’ll use myself, so definitely worth the effort to build a decent tutorial around the idea.
I’m just wrapping up Tutorial 14 (File IO), then Tutorial 15 (2D Sprites) has my full attention. I’m planning to keep the 2D code compatible with the existing 3D code, so even if you do only use it for 2D sprites, you will still have full access to all the 3D routines, should you want to create 3D effects in your game.
