JUICE as a 2D game engine

I'd like to make a 2D game engine & editor/IDE with JUCE.

It's going to be tough for me to gather all my thoughts and arrange good questions here, but I'll try. Bare with me!

I will add that this is a new project. And like all new projects you have to do a lot of shopping and experimenting to find what you need. I've already looked at many others. The problem at this stage is that I don't want to sink a whole lot of time into each. I usually evaluate the website, documentation, tutorials, community, and the examples. Give it a quick mental score and off to the next.

That being said, I'm asking this is a favour so that can skip ahead on my evaluation of JUCE. Also note that I have yet to learn OpenGL

So, I'm in love with JUCE as a gui for the engine IDE. Like this one http://www.google.ca/imgres?safe=off&sa=X&rlz=1C1CHFX_enCA545CA545&espv=210&es_sm=93&biw=1280&bih=937&tbm=isch&tbnid=V7J8DkN4qC_B6M:&imgrefurl=http://gamejolt.com/community/forums/topics/game-develop/629/&docid=NtVFRq5ScZGtUM&imgurl=http://www.compilgames.net/images/GameDevelop/ScreenPhysics.png&w=1332&h=798&ei=TkhZUubbA8aJrQG9o4HwCw&zoom=1&ved=1t:3588,r:0,s:0,i:79&iact=rc&page=1&tbnh=174&tbnw=290&start=0&ndsp=19&tx=173&ty=91

I'm expecting to be able to create a OpenGL display in the middle of the editors controls to show the game view. I don't mind writting pure OGL from scratch. One thing I can't get past is building the users window of the game. I can build the code, I've seen that far in the future, but I kinda can't see using a full screen OGL window for running the users game from JUCE. I'm assuming here that you have seen these sort of game editors before. You design your game in the editor. Then the editor would build the game. And to further complicate things I would like to be able to expose JUCE gui controls to the users game - so that they can re-use it.

So, ah. Can we do this sort of thing with JUCE alone. I really like GLFW. Could we use GLFW for the rendering and JUCE for GUI, etc?

To be clear, I've seen the OGL example. It's great. So I feel like I can do the editor. It's just making the users end game with fast 2d graphics and JUCE gui overlay that I can't envision yet. So, maybe I should be asking if I can use JUCE's OpenGL facilities to make a game - because that's what I want my editor to do - make a game.

 

Forgive my scrambled thoughts. It's been a rough week for me!! 

I'll take any answer at this point.

Thanks!

 

Haven't much time to help talk you through things, but I'm keen to see more game-dev happening with juce, so if you get your project underway and have any game-oriented feature requests, I'd be eager to do what I can to help make it happen!

 

Fair enough!

JUCE has made it into the finals! I'm going to spend some more time on it.

But, haha, geesh. There isn't much in the way of documentation, is there?!

I'm currently stuck on simple hello world. I wanted to add "Are you sure (Yes/no)" window to the provided example. I made the window, but, I can't seem to figure out how to make it come up when the quit button is pressed. 

Guess I'll have to figure it out by reading the JUCE Demo code, but, it's ALOT to take in! Seems to me that a mid level example would be in order. Because going all the way from super simple hello world to JUCE demo is a huge jump for me! And not much documentation to help.

There's always the forthcoming book to look forward to, but that doesn't help me now. (http://www.packtpub.com/getting-started-with-juce/book)

If anyone has a stripped down example of something like hello world calling a "Are you sure (Yes/no)" dialog, Perferably with a .jucer included it would prove very useful to me, and perhaps many other newbies.

 

Anyway, I ramble!

Sorry!

Awesome work here! I love it! Thanks!

Ohh, while I'm at it, I may as well try my luck. Does anyone have some kind of simple OpenGL based graphics example to share? Something - anything to learn something from? (Again a .jucer included would be good - I'm madly in love with Introjucer...)

 

Going for simple here. It's a long shot, but what the heck?!!

I'll take anything. It's better than nothing! XD

 

Thanks!

You've seen this one I take it? 

http://lubyk.org/en/software/mimas/document171.pdf

I started on that, and 9000 lines of code later I've got something quite groovy going on...

Yeah thanks. It seems quite out of date. But it is helping some.

Haha. Until that book, that pdf seems to be about it.

How is there not more about JUCE? This is weird to me..! 

Probably the simplest way to show an ok/cancel box at quit is to override JUCEApplication::systemRequestedQuit(), show a message box and respond to the choice.

    void systemRequestedQuit() override
    {
        const bool res = AlertWindow::showOkCancelBox (AlertWindow::WarningIcon, "Are You Sure you Want to Quit?",
                                                       "Press OK to quit the application or Cancel to return.");

        if (res)
            JUCEApplication::systemRequestedQuit();
    }

 

To get this to work in the hello world example you'll also have to make sure the quit and window close buttons call this method instead of hard quitting as they currently do:

    //==============================================================================
    void closeButtonPressed()
    {
        // When the user presses the close button, we'll tell the app to quit. This
        // HelloWorldWindow object will be deleted by the JUCEHelloWorldApplication class.
        if (JUCEApplication* app = JUCEApplication::getInstance())
            app->systemRequestedQuit();
    }

and

 

void MainComponent::buttonClicked (Button* buttonThatWasClicked)
{
    if (buttonThatWasClicked == quitButton)
    {
        if (JUCEApplication* app = JUCEApplication::getInstance())
            app->systemRequestedQuit();
    }
}

But, the proper way to deal with windows is to never run modal loops and invoke callbacks asyncronously (I added the flag to avoid showing multiple quit windows):

   void systemRequestedQuit() override
    {
        if (isShowingQuit)
        {
            ModalComponentManager::getInstance()->bringModalComponentsToFront();
            return;
        }


        AlertWindow::showOkCancelBox (AlertWindow::WarningIcon, "Are You Sure you Want to Quit?",
                                      "Press OK to quit the application or Cancel to return.",
                                      "OK", "Cancel",
                                      nullptr, ModalCallbackFunction::create (&quitCallbackHandler, this));
        isShowingQuit = true;
    }
    
    static void quitCallbackHandler (int modalResult, JUCEHelloWorldApplication* app)
    {
        app->isShowingQuit = false;

        if (modalResult != 0)
            JUCEApplication::quit();
    }    

I'll admit this is longer but necessary for certain platforms (iOS and Android at least, probably more in the future) and is much better to start an app modeless than to try and convert it later and work around all the blocking code you'll have. It's also just much better design in general.

 

 

I do admit, the lack of examples is something that gets brought up but the reason behind it is probably something simple like it just takes a long time to write good quality, well explained examples, and most people seem to be busy with exciting projects of their own. The other problem with examples is that they can drift out of sync with the current codebase and inevitably aren't well maintained. The JUCE demo is always built with the tip though so is is guaranteed to be accurate. The JUCE demo is a great resource, it is big but then there's simply a lot of the library to demonstrate!

 

It might be simpler if you don't treat the JUCE demo as a single app, rather each demo Component as a stand alone app that demonstrates one particular set of features. Each demo is fairly self contained.

 

The Doxygen documentation is extremely well written and exhastive, it does however require a basic knowledge of the library to find what class you're looking for. One of the things I've always liked about JUCE is the class and method naming scheme so you can usually just start typing what you want and let auto-complete fill in the name, jump to declaration and read the docs in-place. A lot of the docs also have basic code examples which are really helpful.

 

Hope that helps you on your way and have fun getting to know JUCE!

Sadly true, aside from the example application and the somewhat outdated document referenced, there is a lack of kickstarting documentation in JUCE. However, the learning curve is not that steep, and once you’ve managed to wrap your head around the basics, things start getting easier, and then the existing doxygen documentation actually does a real good job. Still, we need to provide some kickstarter for new developers; and since jules is always busy implementing new stuff, fixing old stuff and handling complaining users, not forgetting running Tracktion and whatnot, I believe this is a community job.

FYI I'm currently working with Dave96 on a new demo app... The old one's looking extremely tired now, and the new version will hopefully show-off quite a lot of cool features.