Messages

9586

General / Re: Weird sf::Font problem

« on: September 22, 2012, 06:31:54 pm »

If you have use Visual Studio, then use the Visual Studio compiler, you attach it to the application and when the application crashes the debugger will tell exactly which functions call where made till the crash occurred (= call stack).
Are you using the SFML 2rc binaries?
If so try to initialize the sf::Text objects directly (i.e. in the initialization list of the constructor) with your own font, so that no default font can get loaded.

9587

General / Re: Weird sf::Font problem

« on: September 22, 2012, 06:17:59 pm »

It depends on what causes the error which one could find out with a debugger...

I guess it's something with cleaning up the context etc. Are you using global objects at some point?

Also do you both have either an ATI or a Nvidia graphics card?

9588

General / Re: Weird sf::Font problem

« on: September 22, 2012, 06:05:53 pm »

sf::Font is a resource and thus should not be copied around, when you pass with not as reference nor as pointer (nor with move sematics) you pass it by value, i.e. you get a copy of the original. This doesn't work with OpenGL, so you create one and pass references to that one object around.
Now why exactly it crashes, I can't really say...

now i understand that a const will not be deleted...

This is wrong, const only means that 'it' can not change. The 'it' can either relate to pointers, values or functions. You may want to google a bit for const correctness.

9589

Graphics / Re: is it possible to subtract a texture from an other

« on: September 22, 2012, 05:58:40 pm »

Please make use of the code=cpp tag!!

You still don't understand how it works, don't you? Please at least try to understand it!
You only have to clear and display the render texture once and not with every single light...

9590

General / Re: Weird sf::Font problem

« on: September 22, 2012, 05:46:03 pm »

Is there a way i can pass a sf::Font via parameters?

Yes as (const) reference or (smart) pointer.

void foo(const sf::Font& font)

9591

SFML projects / Re: Crazy Painter

« on: September 22, 2012, 05:31:35 pm »

Yes it works without crash.

9592

General / Re: Weird sf::Font problem

« on: September 22, 2012, 05:20:53 pm »

I bet it's some problem in your state machine/manager, which we can't find out with the given code, also we don't really want to dig through your code, thus it's probably the easiest if you'd just go on it on your own, with a debugger and by minimizing the codebase.
The debugger/call stack will tell you exactly where the problem originated from and by taking away all the parts that don't have anything to do with the error, you end up with a small/minimal example that reproduces the error.
If it's a problem with SFML itself then it's mostly possible to reproduce the problem with a simple main function.

Are you making sure that the state doesn't get freed/deleted before the member variable aren't used anymore? Otherwise you'd end up with an invalid object, which can blow things up quite easily.

9593

SFML projects / Re: Crazy Painter

« on: September 22, 2012, 04:45:16 pm »

Well mine was also a real crash (same as his) and I've also installed the standard runtime lib, but I guess the versions do not match.

9594

SFML projects / Re: Crazy Painter

« on: September 22, 2012, 04:17:53 pm »

So from my message you could've guess that the runtime library was missing (libstdc++-6.dll) and since you now included it with the other zip it now works (although you forgot to include the shader in the debug zip).

Looks good!

9595

General discussions / Re: Comparison SFML vs SDL -> GUI and OGRE3D

« on: September 22, 2012, 03:50:51 pm »

Events are something totally different than just plain input stuff and we've many times stated that events can only be used with a window.

If you're requesting to split the sf::Keyboard, sf::Mouse and sf::Joystick into their own small 'input' library or similar, than this is 'okay', although I don't think this should be done to SFML...
If you want a separated library that can handle events, then this is simply not possible, since as Nexus already stated just now and earlier, events are connected to a window.

9596

SFML projects / Re: Crazy Painter

« on: September 22, 2012, 03:07:54 pm »

Well I get the following information:

Problem signatur:
  Problem event name: APPCRASH
  Application name:   Crazy Painter.exe
  Error module:       libstdc++-6.dll
  Exception code:     c0000005
  Exception offset:   00049542

Not sure if that will help you in anyway though.

9597

General discussions / Re: Comparison SFML vs SDL -> GUI and OGRE3D

« on: September 22, 2012, 03:03:06 pm »

I still don't get it! Where is the Input System separated from the Window?

Yeah we still don't get what you don't get either...
sf::Keyboard, sf::Mouse and sf::Joystick are classes that are not directly connected to sf::Window or sf::RenderWindow, but of course they get compiled into the same library as sf::Window and sf::Event etc.
The functions themself though aren't connected to the window class, you can just take the functions (SFML/src/Window/<OS>/InputImpl.cpp & SFML/src/Window/<OS>/InputImpl.hpp) and plug them into your own stuff without having to write-out hundreds of SMFL code parts you don't need.
Thus the input system (sf::Keyboard, sf::Mouse and sf::Joystick) is separated from the window itself (sf::Window).

9598

SFML projects / Re: Crazy Painter

« on: September 22, 2012, 02:15:54 pm »

I would've liked to test it, but unfortunately it just crashes when starting it...

9599

Window / Re: pollEvent -> Segmentation Fault

« on: September 22, 2012, 02:11:13 pm »

My "engine" is not using parts of your code, so I must implement my own fix hahah 
I took a look at your code just to see how are you handling the events

I see

I also did merge the HandleEvent and Update functions

In a real game, particularly in the Play state, this can be a hell of a mess in one function :S

That always depends on how you do things. But it makes more sense to tide them together since both are logical steps and one might depend on the other. I mean at one point one might want to handle user input over the event system but for another task one wants to use the directly sf::Mouse/sf::Keyboard classes, so where would one draw the line between event handling and updating?
If the one function gets too big one can always create new functions to wrap specific tasks.

Now I think you should add an initialization function to your states, instead of loading files in the state constructor

Well such a design pattern is actually against the whole purpose of a constructor and RAII. The only time I'd use a init function in C++03 would be when having multiple constructors which initialize the member variables equally, so one could prevent code repetition. With C++11 this problem doesn't exist anymore and one can just call the other constructor.
I'm not sure if we had this discussion already, but I'd still like to hear why you suggest to use a separate init function.

No, but I get the idea, thank you for sharing the fix.

Glad we could help each other.

The guy that wrote the SDL tutorial doesn´t have this problem because he is using evil singletons   

Yep.

9600

Graphics / Re: SFML and Box2D.. Shaping polygons?

« on: September 22, 2012, 11:35:57 am »

I guess it's possible and as a preloading generator function it could also workout quite well.
SFML also supports the direct use of polygons though so you might want to let the users define their own polygon.
It's hard to say how hard such a generator function is to implement, but you could try it. IIRC someone once wrote a tool that lets user construct their own polygons. Maybe you can find it by searching through the project forum.