Messages

1

General / Re: MinGW 4.8 compiled apps crash

« on: May 06, 2012, 05:04:34 pm »

Turns out the lates build of 4.8 is able to compile SFML. Anyway, the linking step takes forever now and I'm getting those 'undefined reference to __unwind_resume' errors that usually occur when mixing SJLJ and DW2, which is definitely not the case here, because I compiled SFML and my app with the same Version of MinGW. I guess I'll just Abandon MinGW, create binaries for Windows with VC++ and use the standard gcc on Linux...

2

General / Re: MinGW 4.8 compiled apps crash

« on: May 06, 2012, 04:44:23 pm »

Concerning the development snapshots: I guess they should work, I've never had any problems with this compiler and the 4.7 version, which is stable, works neither. As 4.8 works on Linux I guess it's not the original code, it's either the bad porting or mixed versions.
I'll edit the other post and list all the missing libraries ASAP (on my mobile right now).

3

General / MinGW 4.8 compiled apps crash

« on: May 06, 2012, 03:40:10 pm »

Hey Laurent,

as you suggested I'm now opening a thread for every compiler that doesn't work. The first one is MinGW32 4.8 from mingw-builds. The apps do in fact compile, but fail to run properly. This minimal example:

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
    bool Running = true;
    sf::RenderWindow Window;
    Window.create(sf::VideoMode(640, 480, 32), "SFML 2 Test");
    while (Running)
    {
        sf::Event tmpEvent;
        while (Window.pollEvent(tmpEvent))
        {
            if (tmpEvent.type == sf::Event::Closed) Running = false;
        }
        Window.clear(sf::Color::Red);
        Window.display();
    }
    Window.close();
    return 0;
}
exits with 0xC0000005.

Call stack:
#0 0046C093   sf::ContextSettings::ContextSettings(this=0x76f52b62, depth=2685440, stencil=0, antialiasing=0, major=0, minor=2) (C:/Users/d10k/Documents/SFML/SFML-2.0rc-sjlj/include/SFML/Window/ContextSettings.hpp:53)
#1 00461D2E   sf::priv::WglContext::WglContext(this=0x7829f0, shared=0x0) (D:\developpement\sfml-master\src\SFML\Window\Win32\WglContext.cpp:58)
#2 0045E4E7   sf::priv::GlContext::globalInit() (D:\developpement\sfml-master\src\SFML\Window\GlContext.cpp:105)
#3 0045D350   sf::GlResource::GlResource(this=0x28fc4c) (D:\developpement\sfml-master\src\SFML\Window\GlResource.cpp:53)
#4 0045C21B   sf::Window::Window(this=0x28fc4c) (D:\developpement\sfml-master\src\SFML\Window\Window.cpp:47)
#5 00401E6F   sf::RenderWindow::RenderWindow(this=0x28fc4c) (D:\developpement\sfml-master\src\SFML\Graphics\RenderWindow.cpp:35)
#6 004015BF   main() (C:\Users\d10k\Documents\CPP-Projects\SFML2 Testing\main.cpp:6)

When I change

Code: [Select]

sf::RenderWindow Window;
Window.create(sf::VideoMode(640, 480, 32), "SFML 2 Test");to

Code: [Select]

sf::RenderWindow Window(sf::VideoMode(640, 480, 32), "SFML 2 Test");
the call stack is:
#0 0045BE91   sf::VideoMode::VideoMode(this=0x280, modeWidth=480, modeHeight=32, modeBitsPerPixel=2) (D:\developpement\sfml-master\src\SFML\Window\VideoMode.cpp:50)
#1 00401636   main() (C:\Users\d10k\Documents\CPP-Projects\SFML2 Testing\main.cpp:6)

I hope this helps to possibly fix the problem.
Note: Compiling SFML 2 fails, too, due to some missing libraries. I'm going to try to get it to compile and see if the apps run fine with that version. Unfortunately I have hardly any time for programming at the moment though, which is why this could take a few days

Regards,
dobbi10k

P.S.:spelling mistakes are most likely caused by Win8's malfunctioning spell-check function.

4

General discussions / Re: C++/Game Programming Tutoring Classes

« on: May 05, 2012, 11:59:27 pm »

Do you have some code samples, tutorials, a demo lesson or something like that? If that makes a good impression, it will become much easier to convince people of paying you.

Second that. Me too, I have written a bunch of small nice games like a year ago. Then my HDD broke... How am I ever going to proof. Never. Too bad the same applies to Paki Programmer. What I think would be a good solution for both you and a possible customer would be some kind money-back guarantee. Of course with some restrictions.

General consideration: Make sure there is a valid contract between you and a customer and mainly get some kind of proof you actually taught the lessons!

5

Graphics / Re: A SJIJ-based compiler makes my app crash

« on: May 03, 2012, 05:09:47 pm »

I didn't literally mean 'like the book says', it was rather considered a pun (a Little Red Riding Hood joke; I don't even have a book about C++).
In my code I have:

Code: [Select]

CStatemanager::Initialize(); //it's a singleton and I made it threadsafe by not using lazy instatioation and placing this code in a part of my grogram that is guaranteed to be st
CStateManager& StateManager = CStateManager::Instance();
StateManager.PushState(Game->States());
StateManager.ChangeState(StartState); //where StartState is #defined

CStateManager::CStateManager()
{
    Running = true;
    FLimiter = true;
    ReturnCode = 0;
    ActiveState = 0;
}

void CStateManager::ChangeState(unsigned short int Identifier)
{
    if (ActiveState) ActiveState->Cleanup();
    ActiveState = States[Identifier];
    ActiveState->PreInit();
}
As you can see the ActiveState pointer would normally inizialized just after object creation, but I wanted to make ChangeState actually reusable, so I included the Cleanup() part. To prevent it being executed before any state was specified I added the if statement. Now it seems the dw2 compiler initializes the pointer to 0, which is why the code worked as intended. The other Compilers initialized it to some other value, which made ((bool)ActiveState) true and hence broke my code. The manual initialization to 0 in the constructor itself fixed the Problems though. I don't think this was so much of an design error, but anyway, it's fixed now

6

Graphics / Re: Extreme Speed loss

« on: May 03, 2012, 04:59:25 pm »

First some general considerations:
You don't really need the strfomint function, IMO it causes unneccessary Overhead every frame. You could use std::string(int) instead, in most cases an int will cast to a string automatically anyway.In your Game::DrawGame function I would rather use an iterator:
for (std::vector<Room*>::iterator i = mRooms.begin(); i != mRooms.end(); i++) i->DrawRoom(nDraw);
Last but not least: don't Forget strings are actually 'big' classes and copying them isn't neccessary. You shouldr ather use (const std::string& str) for Performance reasons. This doesn't have any disadvantage.
Other than that your code is fine IMO.

7

Graphics / Re: A SJIJ-based compiler makes my app crash

« on: May 03, 2012, 07:30:59 am »

The pointer was initialized just in tje next function. For reusability I had to (bool)ptr in an if condition though. I expect unitiqlized pointers to return false as the book sqys. Obviously that's not the case...

8

Graphics / Sorry for the inconvenience

« on: May 02, 2012, 09:39:00 pm »

I think I fixed the problems. It wasn't actually about SFML, but about how the Compilers initialized pointers.
While the dw2 Compiler sot them to 0, the others set them to 1, which broke my code. Manually adding ptr=0 in the constructor solved it.

9

Window / Re: Multi-Threaded Event handling

« on: April 29, 2012, 01:19:58 pm »

Wow, that's a relief... This means I'll only have to cahnge about 5 lines of code
And yeah, in that case my system is likely to work as Nexus'

10

Window / Multi-Threaded Event handling

« on: April 29, 2012, 11:17:27 am »

Hey guys,
I created a MT event handling system for my game engine. Basically in its thread it waits for events and then checks a map whether any part of the game / engine needs to know about the event. If so it pushes the event to the receivers event queu. Sounds great to me, but it doesn't work, unfortunately. It makes the window and hence the app crash, because it 'doesn't respond'... I'm pretty sure this is due to the multi threaded event handling as it works just fine when single threaded (there are other drawbacks, of course). The exact same crash happens when you just leave out the event handling completely. Does anyone have an idea, why Windows doesn't like my way of doing things?

Regards,
dobbi10k

11

Window / Re: Unusual CPU readings relating to Vsync/rateLimit

« on: April 29, 2012, 11:09:36 am »

I'm using an AMD Radeon HD 6970 and I don't have those issues, neither with V-Sync nor a frame rate limit. My CPU (i5 25010K) stays at 0% until I have let's say 100k dots drawn...

I also updated your code to comply with the new SFML2 camelCase:

#include <SFML\Graphics.hpp>

int main()
{
    sf::RenderWindow App(sf::VideoMode(1024, 768, 32), "SFML");

        App.setVerticalSyncEnabled(true);
        //App.setFramerateLimit(60);

        const unsigned int NOOF_DOTS = 100000;

        sf::VertexArray dots(sf::Quads, NOOF_DOTS * 4);

        for (int i=0; i<NOOF_DOTS*4; i+=4)
        {
                float x = rand() % 1024;
                float y = rand() % 768;

                dots[i]  .position = sf::Vector2f( x,   y   );
                dots[i+1].position = sf::Vector2f( x,   y+2 );
                dots[i+2].position = sf::Vector2f( x+2, y+2 );
                dots[i+3].position = sf::Vector2f( x+2, y   );
        }

        while (App.isOpen())
        {
                sf::Event Event;
                while (App.pollEvent(Event))
                {
                        if (Event.type == sf::Event::Closed)
                                App.close();
                }

                App.clear();
                App.draw (dots);
                App.display();
        }

        return EXIT_SUCCESS;
}

12

Graphics / Re: A SJIJ-based compiler makes my app crash

« on: April 28, 2012, 03:19:10 pm »

I tried compiling with all three, unfortunately it didn't help.
I downloaded the builds here. They aren't official, I know, but I've never had any problems with those...

gcc --version outputs what you'd expect it to:
4.6:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
4.7:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.7.1 2012
0425 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
4.8:
gcc.exe (MinGW-builds: https://sourceforge.net/projects/mingwbuilds/) 4.8.0 2012
0425 (experimental)
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I "fixed" the problem, by rewriting my code to use your threading library and constructing a condition_variable class and then compiling with 4.6-DWARF2. Still I feel it's a dirty work-around

13

Graphics / Re: A SJIJ-based compiler makes my app crash

« on: April 28, 2012, 12:35:16 pm »

Oops, actually i intended to include all neccessary information in the thread, but i guess I'm still kinda fuzzy from last night
It's SFML2, as 1.6 doesn't work with my ATi card... I tried both the RC you provide on the download site as well as compiling the latest snapshot.
Yes, I tried the minimal example, crashes, too, unfortunately.
I'm going to try to get a debugger in one of my compilers working, as the 4.6 one refused to help me...

EDIT: a test app works with 4.6 SJLJ, but not with 4.7 nor 4.8, weird... (crashes with 0xC0000005)
I'm now trying to compile a newer MinGW with dwarf2 and trying to get a debugger work

14

Graphics / A SJIJ-based compiler makes my app crash

« on: April 28, 2012, 12:11:27 pm »

Hi,
I'm currently developing a 2D game engine based on SFML. I just rewrite my input code to be multithreaded (e.g. for not having a game stop when moving a window) and hence updated my compiler to GCC 4.7-SJIJ,  because I wanted the "native" C++11 threading code. When I tried to run my app though, it crashed immediately (yes, I used a version of SFML compiled with SJIJ). I got an older revision of the engine, didn't work either. So I tracked down the crash to the point where my "CRender" class is initialized, which has a sf::RenderWindow as a member variable (the actual window isn't created yet). I used my old 4.6-DW2 compiler again and it worked. Out of curiosity I downloaded 4.8-SJIJ and 4.6-SJIJ, too. Both crash the app. I'm positively sure it's the SJIJ error handling, because both 4.4-DW2 and 4.6-DW2 work just fine.

The exact error is 0xC0000005. I did some googling and this error often occurs when using not yet fully initialized variables or something. Anyway from my knowledge this is the access violation error, I'm kinda confued though, because it only occurs with SJIJ.

I hope I made my point and that anyone can possible help me. Of courdse compiling MinGW 4.7 with DW2 would solve the issue for now, I feel that is more of a dirty work-around and not an actual solution.

Regards,
dobbi10k