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 - eXpl0it3r

Pages: 1 ... 611 612 [613] 614 615 ... 623
9181
##### General / Re: Correct way to do player movement
« on: April 19, 2012, 10:26:35 am »
In this case, deltatime should be the time of one frame. So you have to calculate it correctly.

But keep in mind, the time of one frame doesn't include just the events or just the drawing.
So restarting the clock while acquire the deltaTime is the right right way, otherwise you ignore the fact, that the time between two frames is the sum of passed time of the update/event handling and the drawing.

Now the question remains where to put the restart statement.
If you set it at the end or the beginning of the game loop you'll get the deltaTime of the last frame. If you put it between the update and the draw blocks you'll get the sum of the elasped time for the update block of the last frame and the draw block of the frame before the last one.

For fixed times steps there's also another article I can point to: http://gafferongames.com/game-physics/fix-your-timestep/

Restarting your clock doesn't take away any performance, so don't worry.

9182
##### General / Re: Correct way to do player movement
« on: April 19, 2012, 12:25:43 am »
On a large scale you'd have some hooking somewhere inbetween to make everything as independed as possible, but in the end it often isn't very diffrent from what you have now.

What can easily change, is the way you calculate the position. For instance you may want to have some gravity, so you'll have to subtract some amount from the position, or you want the player to move equally fast in the diagonal and calculate the squareroot of the x and y position, etc.

But for simple eight direction movement this is 'the' solution.

9183
##### Window / Re: How do I maximize my window without changing how big sprites look?
« on: April 19, 2012, 12:14:20 am »
As Lo-X said you'll have to update the size of the sf::View or your sf::RenderWindow.

That's what I've implemented in my code:
sf::Vector2f size = static_cast<sf::Vector2f>(mWindow.getSize());

// Minimum size
if(size.x < 800)
size.x = 800;
if(size.y < 600)
size.y = 600;

mWindow.setSize(static_cast<sf::Vector2u>(size));
mWindow.setView(sf::View(sf::FloatRect(0.f, 0.f, size.x, size.y)));
It gets called whenever the resize event (event.type == sf::Event::Resized) is fired.

But keep in mind, if you want to change to fullscreen mode, you'll have to 'create a new videomode' with window.create(...)

9184
##### DotNet / Re: Sprite draw crash.
« on: April 19, 2012, 12:02:44 am »
No, in my own program, with no OpenGL at all.

Laurent meant the example that comes with the library.

A 'wild' guess do you define that sprite as global or before the window gets created?

9185
##### General discussions / Re: sf::Thread and know if it's running?
« on: April 17, 2012, 05:23:27 pm »
Volatile for multi-threading is useless.
So the problem is that diffrent compilers don't follow excatly the standard?
I mean from the theoretical point of view, as it's taught at universities, it should have a usefull effect, shouldn't it.

Thanks for pointing that out. Just wanted to write here again and explain what volatile is for, since I've learned it in a lecture today.

Personally, I'm a fan of only having a thread as long as you need it, and do not like  the open a thread now and keep brute forcing it 'alive'.
This may work for some tasks but it won't help if you're trying to write a multithread application.
Also what would be the sense of using threads if you only run one at a time? In my opinion this would be equal to a sequential program...

First is the "isActive()" is a bit ambiguous. Often the better question is, "is this a deadlock, or race condition?"
Most will say best way to handle race conditions and deadlocks is to avoid them. This is definitely something to strive for but anyone working on a project with many people can tell you, you don't always have control on all of the factors involved. If you do however, make sure you think of all the ways out of your loops ( have sentinels for any condition if it's important, it's worth the extra checks ).
Checking if a taks is still being worked on and writing lock and race condition free applications are two completly diffrent topics.
If you can't coordinate lock and race condition freedom within your team, either your team structur or your application design is wrong.
In my opinion it's just wrong to write code that determinse if an application is in a deadlock situation or has trouble with race conditions, it seems like a very ugly hack. (Then again I haven't worked on a big project with a team)

If I was way off the mark and all you wanted to know was if the function ran through to completion and the thread object is just sitting idle, ( then like you said initially ) just set a Boolean that the function was finished. Boolean values are expected atomic in nature.

It seems someone didn't read what Tank wrote and linked to...

9186
##### General / Re: Trouble linking with SFML 2 release candidate
« on: April 17, 2012, 12:40:18 am »
Dude at least close your freaking code block, if you HAVE to past it all in here!

9187
##### General / Re: Determing top/bottom and side collision
« on: April 16, 2012, 12:01:17 pm »
We can't really tell where what the problem is, since we have no idea what BoxCollision does.

Additionally I'd advice you to use references instead of pointers and since you're not gonna change anything about the sprites, use const references.
Also bool can work with 0 and 1 but it's actually meant to work with false and true.
And as a side note SFML provides typedef Rect<float> FloatRect;, so you don't need to write sf::Rect<float>.
So the code should more look like this:
bool ADVBoxCollision(const sf::gEntity& sprite1, const sf::gEntity& sprite2, bool& pTop, bool& pSide)
{
sf::FloatRect FirstRect(sprite1.GetPosition().x - sprite1.GetCenter().x ,sprite1.GetPosition().y - sprite1.GetCenter().y,sprite1.GetPosition().x+sprite1.GetSize().x - sprite1.GetCenter().x,sprite1.GetPosition().y+sprite1.GetSize().y - sprite1.GetCenter().y);
sf::FloatRect SecondRect(sprite2.GetPosition().x - sprite2.GetCenter().x ,sprite2.GetPosition().y - sprite2.GetCenter().y,sprite2.GetPosition().x+sprite2.GetSize().x - sprite2.GetCenter().x,sprite2.GetPosition().y+sprite2.GetSize().y - sprite2.GetCenter().y);
//ToS stands for Top or side. It tells whether the sprite collided with the top/bottom part or the side part. 0 = top/bottom, 1 = sides
if(BoxCollision(FirstRect, SecondRect))
{
if((FirstRect.Left <= SecondRect.Right) && (FirstRect.Right >= SecondRect.Left))
{
if(!pSide) pSide = true;
else pSide = false;                        //If RECT1 is to the left of RECT2
}
if((FirstRect.Top <= SecondRect.Bottom) && (FirstRect.Bottom >= SecondRect.Top))
{
if(pTop) pTop = false;                   //If RECT1 is over RECT2
else pTop = true;
}
return BoxCollision(FirstRect, SecondRect);
}
else
return false;
}

Regarding your problem, it's quite hard for us to spot the problem, since we'd need to go though everything by hand and asume stuuff, since we don't really see with what data you're working.
It's way easier on your side to check. Just start up the debugger, set breakpoints at the if-statements, check why the one if-statement never evaluates to true and trace back from there what happens before.

And since SFML 2 RC got (finally) released yesterday, you may consider switching over to SFML 2.

9188
##### Graphics / Re: Deleting Images
« on: April 14, 2012, 12:58:43 pm »
I wouldn't generalize that. Usually, the preferred option should consist of directly using RAII objects, such as sf::Image. Especially std::shared_ptr has some overhead that is only worth the cost if ownership is actually shared.
Sure one can not generalize this, I just wanted to point him into a modern direction.

That's only true for the local object in the loop, but you can copy or move it into the vector or even directly construct it there (emplace it).
And day after day I notice, I know nothing about C++(11).

By the way, thanks for recommending Thor all the time
Hehe no problem! Great stuff should be shared!

Btw congrats to your 2000th post! xD

9189
##### Graphics / Re: Deleting Images
« on: April 13, 2012, 02:34:42 pm »
Oh right, didn't like the temp variable too but didn't take my time to think about it longer.

9190
##### Graphics / Re: Deleting Images
« on: April 13, 2012, 11:39:53 am »
Then you would hopefully learn that one should not use 'raw' pointers but smart pointers, like std::shared_ptr or std::unique_ptr

For you problem, you have to allocate the resource with the new keyword otherwise the memory will get allocated on the stack and would be released as soon as you go into the next for loop iteration.

std::vector<sf::Image*> images;
for(unsigned int i=0; i < 10; ++i)
{
sf::Image* temp = new sf::Image();
images.push_back(temp);
}

for(unsigned int i=0; i < images.size(); ++i)
delete image.at(i);

I'd also suggest not to use SFML 1.6 anymore, mainly because it won't run on most of the computers with ATI graphic cards.
And if you switch to SFML 2 you could then also use the Thor library for resource management, although the API will change in the near future.

9191
##### Window / Re: Not displaying anything at all
« on: April 11, 2012, 06:56:51 pm »
can I set it up the same way as I did with SFML1.6?
Yes, except you'll have to build SFML 2 first but it's very easy, just run CMake, then open the generated project files and build the library.
Are things a lot different in 2 in comparison with 1.6?
Yes there are quite a few changes, specially for the graphic part but it's fairly easy to switch, just change a few class names, change all Get and Set to get and set functions and use sf::Texture instead of sf::Image (except for pixel manipulation).
Also, final question, what part is exactly bugged with ATI graphic cards?
I think it's because of some OpenGL state stuff (or is that just what's bugging in SFML 2), but I don't really remember.

9192
##### Window / Re: Not displaying anything at all
« on: April 11, 2012, 05:31:45 pm »
Let me guess: ATI graphic card?

SFML 1.6 has it's bugs with ATI graphic cards.
You can try to link staticly but I'd rather suggest to use SFML 2.

9193
##### SFML website / Re: Spam user?
« on: April 11, 2012, 05:29:13 pm »
Haha

As long as it doesn't put much load on the database it gives the bot the 'feeling' everything is working fine and he does not need to adjust anything.
Aka slient ban.

9194
##### Graphics / Re: Drawing lines in sfml.
« on: April 10, 2012, 02:48:38 pm »
You know there's a search function for this forum (and every other forum you'll ever visit).

Since you're talking about rectangleshape I suppose you're using SFML 2, which is already a good thing.
A line can be done simply with to vertices (sf::Vertex) and a vertex array (sf::VertexArray).
As primitve type you can choose sf::Lines.

9195
##### General discussions / Re: sf::Thread and know if it's running?
« on: April 10, 2012, 02:01:57 am »
Yes.

SFML just provides the basic abstraction, so one can use threads cross platform. Anything more than starting, waiting or terminating has to be implemented on your own. And never forget about all the race conditions etc. that can occure when programming parallel stuff.

AFAIK setting a boolean variable is an atomic operation so it would be quite possible to check the operation status with such a variable. But you can't check the variable if you put it in the thread you want to check since it isn't valid anymore as soon as the thread finishes, but putting it outside would work.

Pages: 1 ... 611 612 [613] 614 615 ... 623