Suitable for game?

I absolutely love the whole idea of JUCE. MY question is whether or not it would be suitable for a 2d video game. The graphics would be a few hundred to a few thousand opengl quads and some text plus the gui.

I’ve thought lots about this, it’s something I’ve been wanting to do for a while. I’m only interested in making simple 2D games, though I’d like them to be pretty!

I’ve done some experiments with it in the past, using Juce ‘as is’ - i.e. everything is rendered using combinations of ‘Component’ and ‘Graphics’ class operations. The two games I made were Tetris [purely using components] and a clone of the flash game ‘Squares’ [which had a proper timing thread and animation]. While it did work reasonably well, the load used by the graphics became noticably worse when I added audio to the mix, and it slowed down quite badly.

So you’re right in thinking about OpenGL, but unfortunately - when i was working on this - I didn’t know a thing about OpenGL. I’ve learned a bit since, but I remember I had a really hard time trying to get anything working properly at all! I made a bit of progress, but never had the chance to apply it to my old game ideas.

On the whole, I don’t see any reason really why Juce can’t be used for making 2D games; for really smooth frame rates the rendering would have to be given to something like OpenGL. Just be aware that getting openGL stuff up and running in Juce isn’t yet quite as easy as it could be. Plus, there isn’t really much precedent for this type of project [juce game] so there’s not a lot of direct guidance available to read online.

All that said, if you give it a shot, someone here will no doubt be able to help out if you get stuck. Best of luck to you!

[incidentally, I’ve been considering trying out SDL for my gaming projects when i pick that back up again… but i just love the Juce classes and I don’t like the idea of having to use equivalent classes in another library!

Well yeah, I would very much like to use JUCE, If its really that hard to get opengl going, it may be better to go with a library like libagar then. This sucks because I was really interested in the other classes JUCE offered besides just a great looking gui + tools.

oh it’s probably not all that hard really, it’s just harder than i expected.

tbh, most of it may have been down to my total lack of any openGL knowledge :slight_smile:

I use OpenGL and JUCE with no problem. Most of what you need to know is in the OpenGLComponent example.

That said, if your game needs to move at a constant and speedy framerate, you’ll find that the regular rendering mechanism provided by JUCE is not satisfactory, or at least it isn’t on OS X. Basically, since the render calls are triggered from the even queue, rendering is jerky and never too speedy, even on a decent machine.

My solution was to decouple GL rendering from the event thread by giving it its own, at a higher priority. Thus you wouldn’t want to call repaint(); your thread would flip the GL buffer instead. Mind you, this creates all sorts of other hassles if you are adding an interface (multithreaded programming is a real pain [hello CriticalSection and MessageManagerLock!!]), but it is the only way to get anything more than 30 FPS from JUCE, at least in my tests.

The nice thing of doing GL with JUCE, other than having a widget kit (as opposed to SDL) is that you can use all of the 2D rendering features of JUCE by rendering them to textures. Thus, you’ll get decent font and text support without having to deal with freetype. i.e. you get easy justification, formatting and font loading. Also, you’ll get more than your basic lines and gl polys for drawing. And, of course, you’ll get super easy image/texture loading for gif’s, png’s and jpg’s. Never mind that you also get filesystem access, XML, etc.

Another thing to keep in mind is that JUCE does not do real full screen. You’ll have to go to native code for that, but it isn’t that complicated (at least in OS X, since it requires about 6 lines of code). If you want full screen, you’ll want to add your OpenGLComponent directly to the Desktop, and then change resolutions and enable full screen mode.

Hope that helps,


Hi everyone:

I just have a couple of questions (and sorry if this thread its so old):

  • You could upload your files or tell us how you achieve this? and:
  • Is there an possibility to change the event dispatching thread priority to achieve more fluid (and less sluggish) animations using Juce (not only to GL components, but all kind of animations)?
  • Its possible to you tell us how you get that behaviour?

I appreciate if someone help me (and help to all the community) to clarify these doubt.


This thread is actually way out-of-date… Juce certainly does do full-screen now! See the Desktop class for that.

Indeed. I’ll see the Desktop class, but: What about the animation FPS in any kind of component (GL or not)? I’ts possible to tweak the render mechanism to improve the animations fluidity?


You can make it repaint as often as you like.

Are you actually having problems with it, or have you just read some FUD about this somewhere?

You can make it repaint as often as you like.

Are you actually having problems with it, or have you just read some FUD about this somewhere?[/quote]

Firt of all, thanks Jules for reply this old thread.

Second: I see the JuceDemo app and all animations are not very fluid. I think Juce have a parameter to regulate the resources needed to render. For example, the OGL demo (the cube that rotate) have 30 FPS max (just a rapid guess). My computer its quite fast and render the new games (with all te details and effects) at 60 FPS (using DirectX9 and OpenGL 2.1), so in contrast whith these games, the fluidity of animation of the GL JuceDemo it very poor. And no just the animation of GL components, the animation of the normal components have the same FPS that the GL ones. So i think that the problem origin its very simple to solve, because it’s just a tweak to make or parameter to modify. I’m are right?

Third: Sorry for my ruggish english. My maternal language its spanish!


Well, don’t use the demo as any kind of benchmark - it was never intended to have smooth animation, and I just chose random values for the repaint intervals, rather than worrying about how fast it goes.