Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Nexus

Pages: 1 ... 391 392 [393] 394
5881
Feature requests / sf::Drawable::GetPosition
« on: July 22, 2008, 12:06:34 am »
Did you watch the intellisense list? Or doesn't the code work if you use a GetPosition() method?

In VC++, the intellisense database is sometimes upset. Rebuilding the project or whole solution and deleting the database file (*.ncb) will help.

5882
Quote from: "Laurent"
Sorry, I totally forgot to add the new files in the VC2008 solution :lol:

No problem, I am currently working with version 1.3 ;)

5883
Hi,
I just downloaded the current SVN version of SFML. But when I try to run my program, I get the following linker errors:
Code: [Select]
1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: class sf::View & __thiscall sf::RenderTarget::GetDefaultView(void)" (?GetDefaultView@RenderTarget@sf@@QAEAAVView@2@XZ)".
1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: void __thiscall sf::RenderTarget::SetView(class sf::View const &)" (?SetView@RenderTarget@sf@@QAEXABVView@2@@Z)".
1>Project.obj : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual void __thiscall sf::RenderTarget::Draw(class sf::Drawable const &)" (?Draw@RenderTarget@sf@@UAEXABVDrawable@2@@Z)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual void __thiscall sf::RenderTarget::Draw(class sf::Drawable const &)" (?Draw@RenderTarget@sf@@UAEXABVDrawable@2@@Z)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: __thiscall sf::RenderTarget::RenderTarget(void)" (??0RenderTarget@sf@@IAE@XZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: virtual __thiscall sf::RenderTarget::~RenderTarget(void)" (??1RenderTarget@sf@@UAE@XZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""protected: void __thiscall sf::RenderTarget::Initialize(void)" (?Initialize@RenderTarget@sf@@IAEXXZ)".
1>sfml-graphics-s.lib(RenderWindow.obj) : error LNK2001: Nicht aufgelöstes externes Symbol ""public: class sf::View const & __thiscall sf::RenderTarget::GetView(void)const " (?GetView@RenderTarget@sf@@QBEABVView@2@XZ)".


I am running in release mode, I also rebuilt the SFML version in static release configuration.

I use the CRT version Multithreaded-DLL (/MD). Additional linker dependencies are:
sfml-graphics-s.lib sfml-window-s.lib sfml-system-s.lib

The path C:\...\SFML\lib\vc2008 is added to library directories, too. I really don't know what is wrong because my previous SVN version (before release of v1.3) worked without problems. And after recompiling the SFML source it should work fine, shouldn't it? Or is the sf::RenderTarget class not ready to use yet or still bugged?

Edit: Seems to be a bug in SVN, the official SFML version 1.3 works fine.

5884
General / New SVN Version
« on: June 08, 2008, 09:35:00 pm »
Quote from: "Laurent"
Quote
Okay, but... what does "origin" in this context mean then?

The center of translation, rotation and scaling.

So by using SetX(), SetY() or SetPosition() I place this center and by GetPosition() I get its coordinates? Sorry, I just want to feel certain ;)

Quote from: "Laurent"
Quote
And about the sf::Font... Could you make one specific constructor taking a std::string parameter for the file name? Or did you design this class to load a font file after construction?

As I don't use exceptions, there's no way to notify an error on loading failure. That's why you have to use the LoadFromFile function, which returns a boolean. And yes, this is all on purpose ;)

Okay, then it's similar to the sf::Image class. I am just not used to classes without specific ctors :D

And, another question: Where is the log file where I can see what changed in SVN since 1.2? Or is there something like a doc for the newest functions?

5885
General / New SVN Version
« on: June 08, 2008, 08:42:43 pm »
Ah ok, from this point of view I didn't see it ;)
I couldn't reproduce some of the changes you've made, so I had doubts. You don't have to be scared, I won't stop using SFML, it's a very good library. :) Just some little thing don't please me too much, but I think I will get used to them...

And until now, I only experienced the (for me) bad part, but I believe that new improvements like vector classes and consistent resource system will help me in future, too ;)

Quote
Quote
And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.

Because the origin of a drawable is no longer at the top-left corner, you can now put it where you want (center, right-bottom corner, ...). It would be a non-sense to keep Left and Top.

Okay, but... what does "origin" in this context mean then? And you said that the function GetX() wouldn't mean anything in the new version, what do you exactly mean? Just to replace it by GetPosition().x? There is also a SetX(), will it soon be useless (only because of the X/Left discussion)?

And about the sf::Font... Could you make one specific constructor taking a std::string parameter for the file name? Or did you design this class to load a font file after construction?

5886
General / New SVN Version
« on: June 08, 2008, 07:30:02 pm »
Hi,
Today I updated from SFML 1.2 to the new SVN version.
I see, there are many changes. Some new features are quite nice, for example the sf::Shape class. But some I can't really understand.

For example:
Code: [Select]
sf::Sprite::GetLeft();        // old
sf::Sprite::GetPosition().x;  // new

sf::View::GetWidth();    // old
sf::View::GetSize().y;   // new


The fact of typing more is not even the worst. The names of the functions seem to be quite random, sometimes there is still GetWidth(), and sometimes that GetSize().x. What's the point of making the names so inconsistent? Do you just want to have an own Getter for specific properties (position, rotation, size, scale)?

And the other thing is, everything has to be an own class now. For me, there's currently too much OOP in SFML. For example, you can't just write a normal sf::String constructor. Instead, the font has to be an own class (a string doesn't seem to be sufficient) which unfortunately doesn't own any specific constructors. The sf::WindowSettings struct is another example.

Up to now, I have been really impressed by SFML, but now I am a little bit deceived. Couldn't there be a possibility to at least add the old GetX() and GetWidth() again? And why did you change "Left" to "X" and "Top" to "Y"? Before it was much clearer.

5887
Graphics / Sprite blurry
« on: June 06, 2008, 09:01:26 pm »
If you move your sprite (btw. isn't there a Move() function?) depending on the frametime, a constant movement is rather not propable.

5888
Graphics / Drawing Everything
« on: May 18, 2008, 05:16:04 pm »
So the argument for iterators is the flexibility and not the performance?
Therefore I can leave my lovely indexes for the next time ;)  - no I think I will change my code.

Quote from: "Laurent"
Quote
Because at the moment I try to avoid them wherever possible

Why ? That's definitively a bad habit.

I don't have a lot of experience with iterators, and I don't need the containers too intensely. I only use std::vector<> and std::string, and until now, everything worked well with indexes, so I didn't see any reason to use iterators.

But I didn't know about the iterator's advantages (and to tell the truth, still don't know everything), I thought it would be just a formal matter. Thank you for the declarations. I guess I will adapt my code. But what is now the point of using iterators? Wouldn't it be okay to use indexes in future? Are there some long-dated consequences I don't recognize yet?

5889
Graphics / Drawing Everything
« on: May 18, 2008, 04:27:14 pm »
Quote from: "Laurent"
You can always construct a vector iterator from an index :
Code: [Select]
vector<xxx>::iterator it = v.begin() + index;

I know, but that's what I hate... I think
Code: [Select]
MyVector.erase(3); would be much easier instead of
Code: [Select]
MyVector.erase(MyVector.begin() + 3);
At least there should be an overloaded function which would accept both iterators and index integers.

But do you think it's better to use iterators all the time (even as loop-counting variables)? Because at the moment I try to avoid them wherever possible ;)
Might it be significant for the performance if I got big sf::Sprite vectors which are drawn every frame?

5890
Graphics / Drawing Everything
« on: May 17, 2008, 08:02:33 pm »
I just asked because I don't like iterators, either. Sometimes I really hate them ;)

Most of the time, you can avoid using iterators, but unfortunately, the erase() function doesn't work with indexes - sometimes, that's really annoying. I really don't understand why there is no overloaded function with an index integer as parameter.

5891
Graphics / Drawing Everything
« on: May 17, 2008, 03:15:12 pm »
Sorry, if it's a little bit off-topic...
Quote from: "Kernelpanic"

It would be good to use iterators for the loop:
[...]
So you can use easily all types of containers.

Is this faster with iterators or is it just more general and easy to port? What is a reason against indexes?

5892
I think sometimes you could leave part of the screen - for example if you are just changing some small sprites, but must redraw the whole scene.
Isn't that a great loss of performance?

5893
Feature requests / sf::Clock Improvement
« on: May 04, 2008, 01:31:33 pm »
Hehe, ok... But SFML is still quite fast ;)
And besides, algorithms like the Clock functions should not be very time-critical... I think, for example graphic rendering requires a lot more performance, doesn't it?

5894
Feature requests / sf::Clock Improvement
« on: May 03, 2008, 11:34:29 pm »
Ok, the problem is, to write an own clock/stopwatch class I can't use the existing sf::Clock since the member myStartTime is private. I should always use GetElapsedTime()... Isn't that a little bit waste of performance?

But in the french forum, I found some propositions...
Thank you!

5895
Feature requests / sf::Clock Improvement
« on: May 03, 2008, 01:03:08 am »
Hi
What do you think about some more features to the sf::Clock class?
For example a function which could pause the timer would be useful. Setting the time to a given float parameter might be of advantage, too.

I think adding a Pause() and SetTime(float Time) function shouldn't be a big problem - or does it upset the whole system because you can't just take the difference between starting and current time anymore?.

Pages: 1 ... 391 392 [393] 394