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.
You still could trace the calls back with the callstack provided in VS, but you'd eventually end up in some SFML resource/context code and wouldn't be able to figure out what goes wrong either.
You need to provide a bit more information so we can say what porbably happens.
What exacte version of SFML 2 are you using?
Do you link dynamic or static?
Do you compile in debug or release mode?
Do you use the default font?
The problem is although you declare a destructor you don't define it. Your code looks like this:~Randomizer();Now either you just delete it, since it isn't needed anyways and the compiler will generate a default destructor or you change to:~Randomizer() {}
I'm so close to it compiling ( I think).Anyhow, should I redownload SFML, reinstall Visual C++ 2008 or just wreck my computer? ^^Throwing the PC out of the window is always a solution, eventhough not the best one...
So maybe you could provide more details on the actual error messages you get and/or maybe zip everything up (the project file etc) and upload it somewhere so one can take a look at it.
Is there a specific reason why you're still using such an old IDE as 2008? I mean there's VS10 express...
Works perfectly on my end...
As a hint for the sleep function, SFML comes with a sf::sleep(sf::Time) function, which is not implemented as busy-waiting loop, thus it doesn't waste CPU time.
QuoteBut why is there no direct accessor to the m_startTime variable?And what do you want to do with it? It has no special meaning, it's only purpose is to calculate the elapsed time.QuoteIf they are not, that would be another reason as to why sf::time should include a getCurrentTime function, since being able comparing elapsed time to current time is something that I personally would find to be useful in some timing functions.As the doc and tutorials explain it, sf::Time is a time span, not an absolute date-time. So there's no such thing as a "current" sf::Time.QuoteYes, but if I would need to accurately get the "current time" in a form that at least has a resolution of 5 milliseconds?What do you want to do with the "current time" ? Usually it's not a useful information, all you need are time spans. Especially if you need it with such a low resolution. It doesn't make sense.
I have the feeling that, for you, "current time" is what timeGetTime() returns. For me, it's more "monday 20 august, 20:34:56 and 568 milliseconds". The time returned by timeGetTime() is just a time span relative to the last boot of the PC.
So in fact what you need is a function that returns time values all relative to the same time point, right? In this case it's not hard to do.sf::Time now()
{
static sf::Clock clock;
return clock.getElapsedTime();
}
But why is there no direct accessor to the m_startTime variable? Having it available through a interface would make it vastly easier for less experienced and skillful programmers (such as myself) to build upon. Just throwing it out there.Because it would be a bad design decision and just because it could be easier for a few particuallar chases it doesn't justify the spoiling of the variable to derived classes.
It's anyways better as I already said to use a sf::Clock as memeber variable instead of deriving from it.
Also; expl0it3r, are sf::time and time_t (as returned by time function from time.h) comparable or easily converitble? If they are not, that would be another reason as to why sf::time should include a getCurrentTime function, since being able comparing elapsed time to current time is something that I personally would find to be useful in some timing functions.sf::Time and sf::Clock do not have anything to do with date/time.
sf::Time is just a class for representing a time interval and provides an interface to return the time either as seconds, milliseconds or microseconds, whereas sf::Clock is just a class that 'enlarges' the time intervall starting from some given point (= up on creation or when calling restart()).
Although the actual type of time_t isn't specified it's mostly a "integral value holding the number of seconds since 00:00, Jan 1 1970 UTC" (source) thus you can use the function sf::seconds(static_cast<float>(time_t)) to get a sf::Time object with the interval from 00:00, Jan 1 1970 UTC.
).snipQuoteWell yes, but sf::clock is fairly useless on it's own except for very rudimentary timing tasks. That's why I will most likely be constructing my own stopwatch.sf::Clock is not meant to be the final powerful timing class. But it provides a solid base for timing (best resolution and monotonicity), then it's up to you to add whatever high-level feature that you need on top of it.
In 1.6 you could directly check for released keys usingYou still can check for KeyRelease that's the event system we've been refering to all the time (and which is already explained in the official SFML 2 tutorial...):
sf::Event::KeyReleased
atleast, I would assume that was what it did?while(window.isOpen())
{
sf::Event event;
while(window.pollEvent(event))
{
if(event.type == sf::Event::KeyReleased && event.key.code == sf::Keyboard::A)
std::cout << "The key A was released!" << std::endl;
}
}Now that binary so kindly supplied me with the information that sf::Clock should be more accurate than timeGetTime(), I will be building a clock class with an internal sf::Clock.Not only that it's also more crossplatform.
