Messages

1

SFML projects / sigui = Simple Includable GUI

« on: March 04, 2011, 07:23:28 am »

well, since you're feeling adventurous... :twisted: ... lets jump right to using function calls.

place this before the main statement

Code: [Select]

// GUI invoked functions
void CloseGUIform(GUIwidget *pWidget)  // close the form
{
    // find parent form
    while (pWidget->parent != NULL) pWidget = pWidget->parent;  // find uber parent
    if (pWidget->thisType == tguiForm) static_cast<GUIform*>(pWidget)->close(); // if uber parent was a form (it should be!), close it
}

void getoutahere(GUIwidget *pWidget)  // close the program
{
         // find parent form
    while (pWidget->parent != NULL) pWidget = pWidget->parent;  // find uber parent
    if (pWidget->thisType == tguiForm) static_cast<GUIform*>(pWidget)->parentApp->Close(); // close the application.
}

put this after GUIinitialize

Code: [Select]

   GUIform ExitDialog(App.GetWidth()/2-210, App.GetHeight()/2-100, 440, 200); // create 420x200 dialog in middle of screen
    ExitDialog.showTitleBar = false; // no need for resizing, moving or closing this dialog
    ExitDialog.bevelInner = bsDown;   // makes it a little more decorative
    GUIlabel exitText(&ExitDialog, 20, 30, "Changes unsaved, please confirm Exit (without saving).");
    GUIbutton exitCancelBtn(&ExitDialog, 100, 100, "Cancel");
    GUIbutton exitConfirmBtn(&ExitDialog, 240, 100, "Exit");
    exitConfirmBtn.OnClick = &getoutahere;
    exitCancelBtn.OnClick = &CloseGUIform;
    exitCancelBtn.toggle = false;
    exitConfirmBtn.toggle = false;

and put this in the event handler

Code: [Select]

           if (Event.Type == sf::Event::KeyPressed)
            {
                if (Event.Key.Code == sf::Key::Escape) // Escape key : exit
                {
                        ExitDialog.show();
                }
            }

Now when you press the escape key, the "confirm exit without saving dialog" will pop up.

:? I see that I need to change buttons so that "toggle" is false by default, since that is the typical behavior desired.

While this is bit complicated for a first taste, it does show how little you need to have in the game loop if you use function calls.

Still adventurous? Add the lines

Code: [Select]

   exitConfirmBtn.faceColor = sf::Color(sf::Color::Red);
    exitCancelBtn.faceColor = sf::Color(sf::Color::Green);
    exitConfirmBtn.useParentColors = false;
    exitCancelBtn.useParentColors = false;

to add color clues to the user!

2

SFML projects / sigui = Simple Includable GUI

« on: March 03, 2011, 08:44:11 am »

Its available at http://sourceforge.net/projects/sigui/
But there is no documentation yet. I consider it not quite ready for beta testing. Though I am settling on the current component set for the initial version. I need to finish up some details on the menu items and the tree-view component. Then a little more basic testing and it will be "beta-time" (serious testing and revision of the interface for ease of use).

If you are adventurous enough to try it out already, I can certainly give you some guidance on usage.

Just promise not to freak out when you see my sloppy code  :oops:

3

SFML projects / sigui = Simple Includable GUI

« on: March 01, 2011, 04:34:32 am »

Its all SFML - no OS specific code. Originally, the drawing was all done as opengl code, but most of it is now done with SFML graphic calls, and should be completely converted before release. The naming conventions and exact function naming, etc is still subject to change. The idea, of course, is to make things easy to use. Currently, in addition to including the files in your project's development environment (I use Code::Blocks most of the time), 4 lines of code are needed to enable it.

// 1) access the header file:
#include "sigui.hpp"

...

sf::RenderWindow App(sf::VideoMode(800, 600, 32), "Test"); // eg.

// 2) after creating the renderwindow and before declaring any gui components, initialize the gui system:
   GUIinitialize(&App);

...

 while (App.GetEvent(Event))
{
// 3) at the beginning of the event handler:
   if (GUIprocessEvent(Event)) continue;

...

// 4) after drawing your scene and before issuing the App.Display():
GUIdraw();


---------------------------------------------------

After step 2, you will need to declare all of the gui components. These are placed on "Forms" with the SFML renderwindow being a default form named "GUImain". A Form can be created with:

GUIform Form1(100, 50, 500, 300, "First Form"); // left, top, width, height

// a menu added with:
GUImenuBar Menu1(&Form1, "Files, Edit, View, Options, Help, Exit");

// callback function specified:
Menu1.MenuItemOnClick(5, &getoutahere); // respond to "Exit"

There are different ways to create the components, just some quick examples are shown. Form and component colors can be changed and images can be applied. Overall, it is still an "old-school" rectangle based GUI.

4

SFML projects / sigui = Simple Includable GUI

« on: February 28, 2011, 09:09:53 pm »

sigui is a GUI for SFML 1.6 currently in alpha development. It consists of a c++ source file and header file which are simply included in your project. Interaction is via callback functions (or simple polling.)

5

General discussions / .h Files and forward Declarations

« on: February 24, 2011, 06:53:36 pm »

This may sound silly, but double check that the current GQE_Types.h file is actually the one being used by CB for the project. CB will happily keep files in the editor without them being part of the project. I've been caught by that before - it may reference a file in a different directory with the same name but obviously, it doesn't get updated as you edit the file with the same name in another directory.

6

General discussions / .h Files and forward Declarations

« on: February 24, 2011, 12:38:31 am »

try moving your "MakeEvent" enum to preceed the "StatusType" enum. (Just in case there is some mismatch of braces that errantly signal the end of the namespace.)

7

Window / Glu issues.

« on: February 22, 2011, 06:39:34 am »

You probably just need to add a linker setting: eg. glu32 for windows or GLU for linux.

8

General discussions / .h Files and forward Declarations

« on: February 22, 2011, 06:34:14 am »

For the sake of testing, can you move or copy that "enum MakeEvent ..." into EventManager.h and confirm that everything would work if it could find it? Perhaps add a fake enum into GQE_Types.h and see if it that can be referenced somewhere else within EventManager.h?

9

General discussions / .h Files and forward Declarations

« on: February 20, 2011, 09:29:08 pm »

Sabo, I tried out those code snippets as files (had to add #endif to the end of the GQe_Types.h code above.) I don't know what you are using for App.h so I made a test file:

Code: [Select]

#ifndef APP_H_INCLUDED
#define APP_H_INCLUDED

class App
{
    public:
    sf::RenderWindow thisApp;
};


#endif // APP_H_INCLUDED

and within my main program (which #include's these three headers) I have the lines:

Code: [Select]

  App myApp;
   myApp.thisApp.Create(sf::VideoMode(400, 200, 32), "Test Program");

It compiles and runs without a hiccup. I'm guessing that your problem is more subtle than header guards.

10

Graphics / Restricting zoom level

« on: February 20, 2011, 05:09:33 pm »

Tori, when I try your code (with "background" being an sf::View which contains an image), it allows the user to zoom in (a smaller portion of the image fills the window) and zoom back out to the original size. Is that not what you were aiming to do?

A problem for you to tackle later is the inherent round off errors that creep in with zooming in and out: 1.1 is not the exact inverse of 0.9; and even if it were, round off errors will still creep in and eventually corrupt the view. Another way to handle the zooming is to use SetHalfSize and perform your own calculations based on zoomlevel.

11

General discussions / .h Files and forward Declarations

« on: February 20, 2011, 03:29:57 pm »

Sorry, I did find "pragma once" in the gcc documentation; along with a warning that it is not always implemented.

Another way to prevent a header file from being included more than once is with the `#pragma once' directive. If `#pragma once' is seen when scanning a header file, that file will never be read again, no matter what.

`#pragma once' does not have the problems that `#import' does, but it is not recognized by all preprocessors, so you cannot rely on it in a portable program.

12

General discussions / .h Files and forward Declarations

« on: February 20, 2011, 04:18:19 am »

I tried this:
for file: "header1.h"

Code: [Select]

#ifndef HEADER1_H_INCLUDED
#define HEADER1_H_INCLUDED

namespace GQE
{
class A
{
public: int z;
};
};

#endif // HEADER1_HPP_INCLUDED

and for file "header2.h"

Code: [Select]

#ifndef HEADER2_H_INCLUDED
#define HEADER2_H_INCLUDED

#include "header1.h"

namespace GQE
{
class B
{
void Foo(A* theA);
};
};

#endif // HEADER2_HPP_INCLUDED

and I included (but do not use) these files within a simple main program. It compiles ok.

A couple of caveats... include files for cpp are often named with the "hpp" extension instead of "h" - buts thats no biggie.

Per the GCC documentation - avoid pragma commands I don't see "pragma once" in the documentation and it hasn't worked when I've tried it in the past.

13

General / please help!!! SFML Crash on App.Clear() and App.Display()

« on: February 19, 2011, 01:06:27 am »

You might try reinstalling the driver from the manufacturer. FWIW, older versions of catalyst are available at: http://downloads.guru3d.com/Videocards---ATI-Catalyst-Vista---Win-7_c31.html

14

General / please help!!! SFML Crash on App.Clear() and App.Display()

« on: February 19, 2011, 12:17:38 am »

Well, it appears that SFML is not acquiring a valid handle to an openGL rendering context. Any drawing to the screen will then cause an error/crash. The most likely culprit is the video driver.
One last thing you can try is to replace the RenderWindow line with the following:

Code: [Select]

  sf::RenderWindow App(sf::VideoMode::GetDesktopMode(), "Test Program", sf::Style::Resize|sf::Style::Close);
   App.SetSize(400, 200) ;

This should give you the best chance of acquiring a valid render context by using the current pixel format descriptor. (things you don't really care about - thats why you want to use SFML The SetSize is just there to make the window easier to move around.

15

General / please help!!! SFML Crash on App.Clear() and App.Display()

« on: February 18, 2011, 07:56:47 pm »

What happens if you leave App.Clear commented but uncomment App.Display ? It should present the window with a black background.