Messages

9646

Graphics / Re: Shapes problem

« on: September 20, 2012, 01:42:28 pm »

You're talking about shapes and stuff but in the whole code you provide you never make use of it.
Since you don't have a shape as a member variable I guess you try to delete a local obkect in the destructor which obviously doesn't work.

9647

Graphics / Re: Screen Resolution Change - White Textures

« on: September 20, 2012, 01:33:30 pm »

Afaik there's a problem with Virtual Box...

Otherwise make sure you follow the offical tutorial specially about OpenGL.

9648

General discussions / Re: Trying to gauge image drawing limits

« on: September 20, 2012, 01:24:41 pm »

As you've already found out there's a difference between SDL 1.1 and SDL 2, which are you referting to?

Numbers usually don't say much because it all highly depnds on the underlying hardware. For SDL 1.1 you need a good CPU where as for SFML  a good graphics card will boost the numbers.

Pixel manipulation on SFML isn't really that performant, since the textures live directly on the GPU and one would need to copy around.

Transformations will get applied directly (except sf::View stuff). I don't think it's really slow since OpenGL gets used.

9649

General / Re: Version function

« on: September 20, 2012, 12:22:18 pm »

Yes SFML_VERSION_MAJOR and SFML_VERSION_MINOR see here.

9650

Window / Re: pollEvent -> Segmentation Fault

« on: September 20, 2012, 09:02:36 am »

I replaced the classic while (pollEvent) with if (pollEvent). Is this a good/clean way to fix it?

This probably won't fix anything, but just hide it a bit more...
Also now you have the problem that when more events get triggered for one frame, your event queue slowly fills up. One should mostly always handle the events with a while-loop. Besides the only difference between while and if is that the while loop walks through all the events, where as the if just polls one event.
So no it's not a good/clean way, if any.

You should really make a minimal example or at least show the whole source...

9651

Graphics / Re: Converting from world to screen coordinates

« on: September 20, 2012, 01:53:06 am »

The documentation marks the getTransform and getInverseTransform of the sf::View as 'This function is meant for internal use only.'. So I guess it's not advised to use it as a developer.

I think there's a way to do it with existing SFML functions, but I don't remember/can't find it at the moment...
As a alternative you can perform the transformations not only on the view but also on your own sf::Transform object and then use getInverse() to get the inverse...
On the other hand you may find a way to make things work if you get the transformation from the window coordinates to the view coordinates. This is possible through the sf::RenderWindow::convertCoords() function.

9652

General / Re: Punching holes in const corectness (of sf::Drawable)

« on: September 19, 2012, 08:44:56 pm »

When there are more iterations of game logics than graphics, this approach updates the graphics unnecessarily often.

Hmm... I see. I didn't really think enough far.

9653

Window / Re: [Windows] Windows larger than the desktop mode are invisible

« on: September 19, 2012, 08:42:54 pm »

Issue #234

And various posts on the forum...

9654

General / Re: sf::Thread is blocking main thread

« on: September 19, 2012, 06:20:18 pm »

I use scripts to update "player1" and "player2", but i need run it in threads and leave the SFML render in main thread.

I need launch one thread for each player without block main thread that will render everything.

Keep in mind when updating and rendering happen in different threads you might run into the problem, that not every entity is up to date with the same data while you draw it already. E.g. you move 100 players one pixel to the left while on the same time you draw them. The generated image might be that some of the players already moved that one pixel while others are still on the same position...
Apart from that you might run into race conditions and other nasty stuff, if you don't handle mulithreading correctly.

Btw the main thread doesn't get blocked as long as it has to do something, but in the posted example the main function reached it's end, thus it tried to destroy the sf::Thread objects, but since they were still running wait() is called in the destructor.

9655

General / Re: Punching holes in const corectness (of sf::Drawable)

« on: September 19, 2012, 06:14:33 pm »

I still don't get why it shouldn't be a logic update...

You don't update the logic position yourself, but Box2D does and thus after letting Box2D update the (logic) positions you copy them onto your sprites. It then doesn't matter which 'loop' runs at which FPS, because the sprites position get updated as soon as their logic parts could've changed.

Maybe I got you all wrong, but I don't see the need for having updates in the draw call.
If you don't feel comfortable with the update/draw or update/updateGraphics/draw solutions then you're maybe better of with your own draw function...

9656

General / Re: Creating a Hero class

« on: September 19, 2012, 11:58:04 am »

If you sort the spritesheet good enough you can just set the needed offset, the number of sprites and the animation speed and then the animation can work on its own. The properties need to be dedined somewhere, either you hardcode them or load them from an external file at runtime.

9657

Graphics / Re: Drawing things on viewport

« on: September 19, 2012, 08:36:09 am »

This is the same as thePyro_13 suggested, you use a second view that is stationary, in your case the default view.
Keep in mind that if you resize the window the code might 'break', since the dedault view doesn't change with the window size.

9658

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

« on: September 19, 2012, 12:57:30 am »

SFML is under the MIT license so feel free to do whatever you want.

No it's not:

Right, I always confuse them since they are quite similar.

So you think there will be no changes and i shouldn't use SFML for Input?

If you look at the SFML 2 history which is over 2 years long, then you can guess that SFML 3 won't be out next month or so. 10y was obviously just a joke (at least I hope so).

So the Input System can be easily separated-> so  use SFML?

You still didn't get it: It's already seperated!
It's just within the window mosule but nobody forces you to use a window.

Separate it by myself and don't wait for changes ...

Or do you agree with me? -> Use SFML for Keyboard, Mouse, Joystick and others for iOS

Do whatever fits your needs, it really doesn't matter as long as you can work with it.

Maybe you know this guy
http://www.wreckedgames.com/forum/index.php/topic,5598.0.html

Never heard of him or OIS.

9659

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

« on: September 19, 2012, 12:07:31 am »

I know SFML don't support the IOS(iPhone OS). So i thought to use the OIS(Object Oriented Input System) for IOS Touch.

It's iOS and not IOS, that's what got me confused...

But i read in other posts, that laurent is planning for -> "3.0 +" IOS support. It would be nice, but we cannot be sure

Well if you plan on waiting 10 years or so...

What eXpl0it3r probably meant is that these three classes may already know be independent of a window.

Yes!

9660

General / Re: Per-Pixel Collision Detection

« on: September 18, 2012, 11:42:46 pm »

I do realize that I may have sounded rude, and I apologize for that, no hard feelings?

No problem on my side.

Is there a fast way to compare textures to have all the same color pixels?

SFML doesn't provide texture data manipulation, maybe you can find something in OpenGL although I guess Laurent would've worked on such feature if it actually is supported...

If not what would be the best approximation method? Some sort of recursive rectangle or circle collision checking?

I'm not an expert on collision detection but it mostly is just math and can be solved without the need of pixel data (note: it's always good to keep the logic (collision) and rendering (pixel information) separated).
You may find quite a bit of stuff by simply googling, other than that there are dedicated libraries like Box2D which can perform collision detection of rotated objects (rectangle/circle/polygons), if the simple way doesn't work, this way might.