Messages

16

SFML projects / SFGUI

« on: October 31, 2011, 02:17:53 pm »

Thanks, binary! I got it working. I'm not very experienced with CMake and that was a good tutorial (the most I've done is compiled SFML 2!).

17

General discussions / Works fine on one machine, crashes on the other?

« on: October 28, 2011, 11:05:14 pm »

So you are using SFML 1.6 correct? If you're using SFML 2.0 you need to define SFML_STATIC.

If above isn't the problem, does the release version work?

18

SFML projects / Pacaman [Demo]

« on: October 26, 2011, 10:25:31 pm »

Tested it on my netbook and it ran good, just a little choppy but I had steam running too so that probably explains it. But when I closed the app it gave me an error.

"pacaman.exe - Application Error

The instruction at "0x100453cc" referenced memory at "0x0120e386". The memory could not be "read".

Click on OK to terminate the program."

19

SFML projects / Pacaman [Demo]

« on: October 26, 2011, 05:15:04 pm »

It runs fantastically on my Windows 7 32 bit, 3 GB RAM, 512 MB GPU, 2 GHZ dual core CPU laptop. I'll have to test it on my 900 mhz 1 GB RAM netbook!

20

General discussions / [SFML] error 0xc015002 help please :S

« on: October 25, 2011, 03:36:50 pm »

You have to recompile SFML for Visual Studio 2010, the Visual Studio 2008 binaries won't work with it. Did you forget to build the dynamic libs? You might want to try following this video to make sure you did it correctly.

21

General discussions / State machines or Screens?

« on: October 25, 2011, 03:27:24 pm »

I should have seen your second design earlier ... Because it's kind of similar to what PeterWelzien suggested. Thank you, this is what I'm going to consider for my next design.

But I have a new question. I saw some designs given in this thread that use a stack of states, with the running one one top of the stack. Is it really useful to store old states ? Do you have an example of situation where this could be necessary ?

It depends on what you need really. For something like a pause menu where you want to render it over the previous game state and/or return to the previous game state, it's probably a good idea, but you could do the latter with the second design but it wouldn't feel as clean and would probably be a bit hacky. (ex, storing a pointer to the previous game state into the pause menu state so you can return to it later). I personally prefer the first design for larger projects where you need flexibility and the second design for smaller projects where you won't need as much flexibility or if you have memory limitations, as the first design allows you to store multiple states which could eat up memory quickly. If you want examples of implementation you could look at http://code.google.com/p/gqe/ for the first design, and I think http://sourceforge.net/projects/gorefactorsfml/ used a system like the second.

22

General discussions / Creating a new sf::Event object in each loop?

« on: October 23, 2011, 04:19:03 am »

Hello, everyone! I have a question about most SFML code I see. Why are they redeclaring an sf::Event object after while(Window.IsOpened()). Wouldn't this cause the sf::Event constructor to be called each time creating a new object and hurting performance slightly? Is there any difference in declaring sf::Event before the main window loop?

23

SFML projects / Airport

« on: October 23, 2011, 04:05:23 am »

Thank you very much!

What are you (all) thinking about the difficulty levels, are they okay? Which one did you choose?

I tried each of the difficulty levels and I think easy is easy as it should be, hard is rather difficult (especially when you get 10 or more planes on the screen at once!), and medium is a nice balance between the two.

24

SFML projects / Pacaman [Demo]

« on: October 23, 2011, 12:34:07 am »

This is a true piece of artwork! The graphics and gameplay are good and everything flows smoothly! Playing the game I observed the small details and the movement of the map and character and everything was very cool. The input was kinda glitchy because sometimes I pressed a button and it didn't respond until I pressed it again or I held it down longer. Are you using sf::Event or sf::Input for key inputs? sf::Event is more reliable and sf::Input is known for missing key events every once in a while.

Edit: The FPS counter flickered so much that I couldn't even tell what the current FPS was, especially without VSync! Maybe update the FPS counter at a slower rate. Also for co-op you might want to make it so that the game only ends once both pacaman characters get to the exit, this adds challenge that you have to get both people to the checkpoint by the end of the time and lets the other person get to finish up what they want so that they can get all of the stars and fruit they wanted to get before it ends. Either that or add a time limit for the second person after the first person gets to the checkpoint they have like 10-15 seconds to get what they want before the level changes (and if they die it either just ends or it restarts the level). And lastly I had a problem with the ghosts spawning in front of the spawn point with no way to escape and me being trapped there so they could make me loose a life. This could annoy some people trying to do a playthrough of the game without loosing a life or something like that. I know it's only alpha version and it's subject to a lot of change but these are just a few suggestions!

25

General discussions / State machines or Screens?

« on: October 21, 2011, 09:42:00 pm »

Hello

This subject highly interests me. I've been confronted to state machine designs issues (I'm still a beginner in game programming). For my last project, I used the implementation given by the LazyFoo tutorial.

My main problem was that retrieving data from a previous state was a real pain in the ***. It seems Vit got a similar problem.
My question is : if you pass the previous state pointer to the constructor of the new one, is there another way than casting the pointer (which is an abstract GameState class pointer) to be able to get some data ?
I never really used casting, and in my mind, if you need to cast, this means the program design is flawed. Is it true ? Or is casting something common ?

Thanks for your advices, I hope what I asked was understandable (I don't speak english very often ...).

That design seems flawed. The states shouldn't know anything about each other. My 2nd design posted above is something you should consider, as it allows you to create a pointer to the next state you want, manipulate the pointer's variables (either via public variables or getters/setters), and then return it back as the next game state. The 1st design I posted above could also do this with a little tweaking.

26

General discussions / State machines or Screens?

« on: October 20, 2011, 04:36:16 pm »

Vit,

Another way I've seen it done is to have a state machine that only stores a pointer to one state, and each state has a virtual function called Run() which returns a pointer to whatever state should come next, so if you clicked the play button it would return a Game state, and that Game state could have functions to choose a certain level, so you could return a Game state object after calling Game->SetLevel() so that object has the current level saved.

Code: [Select]


static void GameState::Start(GameState* state)
{
      while(state)
      {
            GameState* next = state->Run();
            delete state;
            state = next;
      }
}


Code: [Select]


if(myLoadLevelButtonWasPressed)
{
      Game_GameState* gameState = new Game_GameState();
      gameState->SetLevel(myInputBox.GetString());
      return gameState;
}

if(myExitButtonWasPressed)
{
      return 0;
}


You should call GameState::Start(new Intro_GameState(pass render context, or anything you need here) at the beginning of your application, and your game states have full control of the rest of the programs flow.

27

SFML projects / Airport

« on: October 18, 2011, 07:56:06 pm »

The game worked great for me in the new version! It's fun and has great graphics and the GUI is good looking. The only problem I had here was after two planes collided and the screen began getting cluttered with smoke the planes movement got choppy.

28

Graphics / Pointer to RenderWindow object?

« on: October 11, 2011, 06:44:49 am »

In the Run() function, window.Display() should be Window.Display().

29

Graphics / Pointer to RenderWindow object?

« on: October 11, 2011, 05:38:22 am »

Yes, this is possible and quite easy to achieve! Here's some psuedo-code that should explain this. (I'm passing the window by a reference instead, there's no need to use a pointer there.)

Code: [Select]


int main()
{
    sf::RenderWindow window;
    window.Create();

    Game game(window);
    game.Run();
}


Code: [Select]


class Game
{
public:
    Game(sf::RenderWindow& window) : m_window(window)
    {
    }  

    sf::RenderWindow& GetWindow()
    {
        return m_window;
    }

    void Run()
    {
        while(m_window.IsOpened())
        {
            m_window.Display();
        }
    }

private:
    sf::RenderWindow& m_window;
}


Here's an example of usage:

Code: [Select]


void some_func()
{
    int width = game->GetWindow().GetWidth();
}


30

SFML projects / Airport

« on: October 08, 2011, 07:28:05 pm »

They all work on my PC.