Messages

46

Graphics / [Solved] Loading Images Inside a Thread

« on: July 15, 2008, 03:21:40 am »

Okay, I put it on the wiki.

Here's the source:
http://www.sfml-dev.org/wiki/en/sources/loadimagesinthread.cpp

Here's a little tutorial (sort of):
http://www.sfml-dev.org/wiki/en/tutorials/loadimagesinthread

47

Graphics / [Solved] Loading Images Inside a Thread

« on: July 15, 2008, 01:18:16 am »

Okay, I answered my own question.
I'll post the code in a sec in case it helps someone else.

48

Graphics / [Solved] Loading Images Inside a Thread

« on: July 15, 2008, 12:39:39 am »

This is a little old but..

I've read all of this but I'm still wondering if it's possible to load images in a thread and draw something indicating progress (like an sf::String with percent).
I think laurent said it isn't really possible.
But is it not possible even with a mutex?

Sorry, I'm new to multi-threading for the most part.
And could anyone provide a tiny bit of sample code for loading images in a thread?

49

General / Something strange... (Mouse click)

« on: July 10, 2008, 11:08:33 pm »

I confirmed it doesn't happen with style set to None or Fullscreen.
I have also confirmed it never happens when a debugger is attached.
You can attach a debugger while the app is running (even after the problem occurs) and it will not occur.
It's very odd.
I feel like this is maybe a windows quirk. Maybe windows is doing something different behind the scenes when a debugger is present.
I just don't know!

50

General / Something strange... (Mouse click)

« on: July 09, 2008, 09:33:05 pm »

Mindiell: So it has something to do with sfml?

I mean there's no way my code to spin and draw the wheels can mess up the event's right? how could it? Have you also noticed how the cursor switches to the hour-glass quickly sometimes only when pressing the left mouse button? never with any other button.

I builded the game with Code::Blocks and got the same behaviour.

Thanks everyone for trying.

It seems like it has something to do with SFML to me.

I don't know how your code could screw with events.
And yes, I noticed the cursor changes to an hourglass for some reason.

I do wonder if this problem exists under linux as well.

51

General / Something strange... (Mouse click)

« on: July 09, 2008, 03:31:50 pm »

Yeah this really is weird.
I nearly rewrote the whole thing in a little framework.
If run under the debugger, it's all fine.
But when you run it alone, that weird thing happens.

I suggest you try to rewrite it in a different way.
This must be some weird bug in MSVC/CRT or SFML. Who knows.

52

Feature requests / wstring in Window title, unicode strings, String baseline

« on: July 09, 2008, 10:42:24 am »

Lastly, I believe sf::String should draw on/above the baseline, not below it.

In my opinion, it would confuse a lot of users (including me), because sf::String is like sf::Sprite and GetPosition should give the upper left corner.

It may confuse users at first, but it really should be done.
Users coming from other libraries may find it confusing that it doesn't stick to this standard.
See http://freetype.sourceforge.net/freetype2/docs/glyphs/glyphs-3.html

53

Feature requests / wstring in Window title, unicode strings, String baseline

« on: July 09, 2008, 06:25:48 am »

I think sf::Window::Create should be able to take a std::wstring for the Title.

Yep.

Great!

Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.

Improving all the unicode stuff is in the roadmap.

Ah. I feel a little stupid as I forgot about the roadmap.

Lastly, I believe sf::String should draw on/above the baseline, not below it.

That wuold probably need some thinking

hah. I just thought it seems weird the way it draws now.
I don't use sf::String but I was using it as a reference when working on my sfmlTTF library and noticed this oddity.
Changing that would mean users will have to change all of their positions.
But I think it would be more intuitive and standard.

54

Feature requests / wstring in Window title, unicode strings, String baseline

« on: July 09, 2008, 05:21:23 am »

I think sf::Window::Create should be able to take a std::wstring for the Title.
I understand it's easy to convert the title and then call Create.
But I'm binding some of SFML to a scripting language which requires wchar_t*/wstrings.

Also, since SFML is cross-platform, I think it should use a cross-platform unicode string type.
The size of wchar_t varies.
I personally use ICUs UChar*/UnicodeString but ICU is rather large.
I'm not sure how this could be easily solved.

Lastly, I believe sf::String should draw on/above the baseline, not below it.
In other words I think this:

Should be like this:

Where the yellow line is the Position specified.

55

Feature requests / Enhanced sf::View

« on: July 08, 2008, 09:31:26 am »

I understand that you have many things to do.
There's no rush.
We all appreciate SFML, it's great!

56

Feature requests / Enhanced sf::View

« on: July 08, 2008, 05:37:03 am »

Well this post is a few months old.
But I wanted to say I would also like the view rotation feature.
I came to SFML from HGE as you know, and miss this feature.
I've stayed away from direct OpenGL calls for now and I'm trying to keep it that way.

57

Graphics / [Solved] SetCenter

« on: July 06, 2008, 08:29:25 pm »

Yeah, fixed it.

I can't even remember what I changed.
The final code is like this:

Code: [Select]


mSprite.SetImage(theGlyph->Texture);
mSprite.SetSubRect(sf::IntRect(0, 0, theGlyph->Texture.GetWidth(), theGlyph->Texture.GetHeight()));
mSprite.SetPosition(static_cast<float>(x), static_cast<float>(y));

mSprite.SetCenter(mRotationCenterX * mSprite.GetSize().x, mRotationCenterY * mSprite.GetSize().y);
mSprite.SetRotation(mRotation);
mSprite.SetScaleX(mHScale);
mSprite.SetScaleY(mVScale);

mWindow->Draw(mSprite);

I'm so pissed I wasted my time and your time on this.
I've been programming for way to long to make these type of mistakes.
Oh well, I guess I'm just tired.

Somewhere along the line this caused glyphs to not be drawn on the baseline.
I'll have to figure that out now.

58

Graphics / [Solved] SetCenter

« on: July 06, 2008, 08:21:51 pm »

EDIT: Son of a B.

I knew one day I would make one of these moronic mistakes.
I've been recompiling but using my old executable because I had copied it from "Debug/" to "/".
This is why I always change my projects to output to $(SolutionDir).
So I don't need to load resources with "../" or copy the exe to "../".

OKAY, i'm going to try to confirm I can fix this now.

59

Graphics / [Solved] SetCenter

« on: July 06, 2008, 08:17:02 pm »

I looked through older version of my code and tried using some of the older code.
It's still not working.
I have test programs for sfmlTTF that were linked with SFML 1.2 and things rotate as expected.
I think something changed or broke from SFML 1.2/1.3.

I'm still testing things.

60

Graphics / [Solved] SetCenter

« on: July 06, 2008, 07:58:24 pm »

So this was intentional?

Code: [Select]

mSprite.SetCenter(0.5f * theGlyph->Texture.GetWidth(), 0.5f * theGlyph->Texture.GetHeight());


I would think you would want to do this:

Code: [Select]

mSprite.SetCenter(0.5f * mSprite.GetSize().x, 0.5f * mSprite.GetSize().y);


That does seem to be correct.
I'm guessing sf::Sprite::GetSize returns the transformed size?

EDIT: I see you edited your post and I get it now.
So is SetSubRect() even needed?

Yes, I edit quick and often.
I believe SetSubRect is needed because I'm re-using the sprite with different sf::Images all the time.
I seem to recall it crashed if I didn't use SetSubRect().

I still haven't figured this out, I'm trying though.