Hi Nona,
you have articles in these issues about games:
REALbasic Magazine Issue 4.1
September / October 2005
34. Adventure Games: A look at a simple state machine
REALbasic Magazine Issue 8.3
March / April 2010
20. Dropwords, Part 1: Developing a simple game
REALbasic Magazine Issue 8.4
May / June 2010
18. Dropwords, Part 2: Developing a simple game
More data there:
http://www.xdevmag.com
[quote=34507:@Alwyn Bester]I’m getting a file not found error with the link.
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.[/quote]
I had a typo in the link. Try this one instead (for Windows).
I think that the only thing really stopping people from using Xojo to make fun games is the lack of knowledge about using engines and frameworks like OpenGL. Once that door is has crossed, I think you will see a lot more people using Xojo for play as well as “work.” I can’t wait for your tutorial. 
[quote=34516:@David Wylie]High score - 365.
Hit 50, missed 0.
How do you shoot the zepplins?[/quote]
You can’t shoot down the zeppelin, at least not yet. 
I’ll have to think of a reason to shoot it down, maybe once I add in logic to automatically adjust the game’s difficulty level based on how quickly players hit the keys correctly or something.
[quote=34517:@Emile Schwarz]Hi Nona,
you have articles in these issues about games:
REALbasic Magazine Issue 4.1
September / October 2005
34. Adventure Games: A look at a simple state machine
REALbasic Magazine Issue 8.3
March / April 2010
20. Dropwords, Part 1: Developing a simple game
REALbasic Magazine Issue 8.4
May / June 2010
18. Dropwords, Part 2: Developing a simple game
More data there:
http://www.xdevmag.com[/quote]
I have not read them, but I will certainly read them now.
It worked on both my mac and windows 8 machine, but I did notice a slight delay and slow down on the windows when pressing the keys. On the mac, it was instant. Very nice game and concept.
Thank you for testing on the Windows side. Since my wife’s school uses only Macs, I’ll get around to improving the Windows side “when I get around to it” – or when Alwyn finishes the tutorial on 2D sprites with OpenGL. I would love to move this thing to OpenGL to take advantage of the graphics card.
[quote=34497:@stuart s]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[/quote]
Wow, that is interesting. I wonder if that is what is happening on the Windows side. I noticed that when I fire a missile on the Windows version, the frame rates dropped dramatically. It doesn’t seem so bad on the Mac side. I’ll try creating a few more sprites for the missiles and test that out. It should be interesting.
Nice game Nona.
Thanks. I think once I port it over to OpenGL, the entire game play would be much smoother. I just finished the underwater scene. It’s got a shark with a “fricken laser beam” to go pew, pew, pew. It’s compiled only for Mac this time. Select the “Under the Sea” scene/mission.
Sounds great. By looking at your game, I got a good idea of your requirements and are starting to put together some ideas on what the best way would be to proceed forward with a 2D Sprite OpenGL module. Like I mentioned, I first just need to finish the next File IO tutorial, after-which I’ll start working on a 2D Sprites tutorial.
Looking forward to your 2D Sprite OpenGL tutorial Alwyn.
Gaming in Xojo is something I want to learn as well.
Nice game Nona…you have shown it is possible to use sprites. I just need to try harder.
Here’s a tester I’ve been working on to check performance. Drawing 120 sprites the Canvas runs pretty well, only slowing to 30fps at most, but OpenGL stays locked on 60fps easily, even with 1200 sprites.
http://home.comcast.net/~trochoid/code/blueb.zip
To try the demos set the apps default window to one of these and run.
Window3 uses Canvas and sprites drawn from a precomputed array of the rotated image. Command-R toggles between full-frame redrawing and rect-invalidating.
Window3GL uses an OpenGLSurface subclass with event Paint(g As ezgl), supposedly to be more canvas-like. Command-P toggles between canvas style coordinates and a perspective camera (where dragging and wheeling moves the camera).
Stuart, when I run the project I get a “Could not load gluLookAt from OpenGL.framework” error. I’ve never used the OpenGL Utility Library before. Is there a DLL I need to install?
Underwater is great!
I think a nice touch (you may have it planned) is to have word levels. Maybe a preference for 3, 4, 5, 6 , 6+ letter words. I found that letter groupings helped when I learned to type. I’m sure you can come up with some damage over time weaponry to make it interesting
If your approach is more in the style of “write code once and create flash & HTML5 applets” may I also suggest you to take a look at Monkey Language ? It is made by the same guys that wrote Blitz Basic. In addition to desktop and web-based games you can also make iOS and Android games.
The new version of Stencyl that is actually in private beta-testing also allows to write code from scratch in HaXe.
Good job. I’m a little stupid, but I didn’t understand immediatly that the keys to launch missiles were the letters which fall.
Your app seems to be build for Cocoa (not Carbon) but your slider look like those of Carbon (in Cocoa they are circle).
Did you try to build it in Carbon? Application I made which use graphics (game) are faster in Carbon than in Cocoa.
[quote=34799:@stuart s]Here’s a tester I’ve been working on to check performance. Drawing 120 sprites the Canvas runs pretty well, only slowing to 30fps at most, but OpenGL stays locked on 60fps easily, even with 1200 sprites.
http://home.comcast.net/~trochoid/code/blueb.zip
To try the demos set the apps default window to one of these and run.
Window3 uses Canvas and sprites drawn from a precomputed array of the rotated image. Command-R toggles between full-frame redrawing and rect-invalidating.
Window3GL uses an OpenGLSurface subclass with event Paint(g As ezgl), supposedly to be more canvas-like. Command-P toggles between canvas style coordinates and a perspective camera (where dragging and wheeling moves the camera).[/quote]
Very nice tests. It really shows that OpenGL 2D is the way to go. Perhaps once I finished this game in OpenGL, I’ll create some addons/plugins to make creating 2D games easier in Xojo. I’m going to go study your codes on OpenGLSurface now… haha. With iOS coming up soon, this topic (gaming) could become quite popular.
[quote=34832:@Francesco Maida]If your approach is more in the style of “write code once and create flash & HTML5 applets” may I also suggest you to take a look at Monkey Language ? It is made by the same guys that wrote Blitz Basic. In addition to desktop and web-based games you can also make iOS and Android games.
The new version of Stencyl that is actually in private beta-testing also allows to write code from scratch in HaXe.[/quote]
Thanks Francesco, I will look into those this morning before starting my day.
[quote=34865:@Thomas ROBISSON]Good job. I’m a little stupid, but I didn’t understand immediatly that the keys to launch missiles were the letters which fall.
Your app seems to be build for Cocoa (not Carbon) but your slider look like those of Carbon (in Cocoa they are circle).
Did you try to build it in Carbon? Application I made which use graphics (game) are faster in Carbon than in Cocoa.[/quote]
Those sliders and pretty much everything will be rebuilt to look more “game-like”. When I have time to work on unifying the look and feel for the game, I don’t think any controls will look native anymore.
[quote=34816:@Peter Fargo]Underwater is great!
I think a nice touch (you may have it planned) is to have word levels. Maybe a preference for 3, 4, 5, 6 , 6+ letter words. I found that letter groupings helped when I learned to type. I’m sure you can come up with some damage over time weaponry to make it interesting :)[/quote]
I do, actually, have plans for words. The skeleton/framework is already done. As the students become more advanced, they will start getting into words. The end-goal is to teach kids in my wife’s classroom to type and learn words.
[quote=34799:@stuart s]Here’s a tester I’ve been working on to check performance. Drawing 120 sprites the Canvas runs pretty well, only slowing to 30fps at most, but OpenGL stays locked on 60fps easily, even with 1200 sprites.
http://home.comcast.net/~trochoid/code/blueb.zip
To try the demos set the apps default window to one of these and run.
Window3 uses Canvas and sprites drawn from a precomputed array of the rotated image. Command-R toggles between full-frame redrawing and rect-invalidating.
Window3GL uses an OpenGLSurface subclass with event Paint(g As ezgl), supposedly to be more canvas-like. Command-P toggles between canvas style coordinates and a perspective camera (where dragging and wheeling moves the camera).[/quote]
I finally have to get back to looking at your ezGL subclass and I must say that it is very nice. I am having trouble calling the sprites though.
Following your example, in window Open:
dim g As ezgl = gamewindow.getTheGL
g.texture.genTexBank(1)
g.texture.storeImageAlpha(0, seabed, seabed.mask)
g.texture.storeImageAlpha(1, sharkleft, sharkleft.mask)
//tilt cam a bit
gamewindow.getTheCam.angleY = -0.2In gamewindow.Paint, I have:
g.projectAsCanvas(me)
//set alpha blending
OpenGL.glEnable OpenGL.GL_BLEND
OpenGL.glBlendFunc OpenGL.GL_SRC_ALPHA, OpenGL.GL_ONE_MINUS_SRC_ALPHA
// Draw seabed background
g.texture.turnOn
g.texture.bindTo(0)
for i as integer = 0 to me.Width/seabed.Width
g.draw2DRectTex(i*seabed.Width, me.Height - seabed.Height, seabed.Width, seabed.Height)
next
// Draw the shark
g.texture.bindto(1)
g.draw2DRect(me.Width/2, me.Height/2, sharkleft.width, sharkleft.height)The seabed sprites got drawn correctly and shows up, but I can’t seem to get the shark to show up. If I do “g.texture.turnOff” right before drawing the shark, I see that it is drawing boundaries for the shark (white box), just not the shark sprite. How do you add/call sprites? Thanks, very exciting.
Edit: I thought the first sample was OpenGL and when switching to the InvalidateRect sample, it shows regular canvas. I was quit confused, then I went in and commented out everything in “display.Paint” and the animation still ran. So, that means that the tests you provided never used OpenGLSurface, correct? What am I missing?
Your test does show that invalidating the rects will slow down the animation, which was what I thought and why I went with the 1 sprite layer instead of refreshing individual rects. I thank you for confirming this.