Messages

166

General / Re: Clock and openGL

« on: April 26, 2012, 05:35:26 am »

You should probably use one timestamp for the entire update cycle. That is, think of it this way: You begin updating your sprites at time t = 0. You call update on the first sprite, and Clock->GetElapsedTime(); returns 0.0001 for that sprite. You call update on the second sprite, and Clock->GetElapsedTime(); returns 0.0002 for that sprite, and so on. In other words, each sprite is using a different update time, even though it's all part of the same update cycle!

This may or may not be causing your problem, but it's probably not helping, at least. What you can do that would help is pass in the current update time so that all sprites use the same update time. That is, in your main loop, you call Clock->GetElapsedTime(); and you store the returned time in a variable, and then you pass that variable to each sprite as the current time stamp. That way, each sprite uses the same update time, and they stay in sync better.

167

General discussions / Re: SFML 2.0 RC

« on: April 23, 2012, 11:01:48 pm »

Hi! I wanted to try SFML but seeing the state of transition from 1.6 to 2.0 - wanted to ask. Are tutorials on site from 1.6 version up to date with current API? Or should i wait for them to be rewritten?

Just a note that in general, it's not too hard to look at a 1.6 tutorial and the 2.0 documentation (the documentation for 2.0 is up to date, as far as I know), and figure out how to do the same thing in 2.0. Version 2.0 introduces a lot of changes/new things, but it's still good old SFML so things are still related.

168

General discussions / Re: Avast alarm

« on: April 20, 2012, 07:53:48 pm »

I have no idea, but from I've googled, you can report false-positives to Avast here.

169

Feature requests / Re: Adding optional background color to sf::Text

« on: April 20, 2012, 07:34:30 pm »

Just out of curiosity, Laurent, what's the best way to do this? I saw this question last night and thought of something like:

Code: [Select]

sf::FloatRect backgroundRect = text.getLocalBounds();
sf::RectangleShape background(sf::Vector2f(backgroundRect.width, backgroundRect.height));
background.setFillColor(sf::Color::Red);

// And draw...
renderWindow.draw(background, text.getTransform());
renderWindow.draw(text);
Is this the best (though of course simplified example) way to do this?

170

Feature requests / Re: Setting Sprite Z (Depth) for Draw Order

« on: April 09, 2012, 04:19:25 pm »

Thank you. I think those are all valid points. After I thought about alpha blending I realized this wasn't really going to work.

171

Feature requests / Re: Setting Sprite Z (Depth) for Draw Order

« on: April 09, 2012, 01:16:11 am »

Sure you could but it's an incorrect way of doing it. First the GPU's optimize to cut away unneeded pixels by testing before reaching the fragment shader. Now comes the funny thing, you can write to the depth buffer in the fragment shader. So if you want to give explicit values to the depth buffer then that is done in the fragment shader and all optimizations the GPU could do would be thrown away. So the better choice would be writing it in the vertex shader. But then you won't have a per-pixel resolution on the depth.

I never suggested using the fragment shader. I've always been talking about doing this in the vertex shader.

Anyway you just disregarded completely the fact that sorting per-entity is much faster than anything the GPU can throw at it. There is a reason why KD-tree's are still in use in commercial games and they do the depth sorting on a per-vertex basis and not only on a per-entity basis. Also a lot of this information is needed on a gameplay basis as well and not only on the GPU so you still need to calculate and store it.

I guess that depends on how busy you're keeping the GPU. I've got spare GPU cycles, whereas I have less CPU cycles to spare.

The values have to be in the range of 0 and 1.f for the z in order to be visible within the native device box. Usually this truncation is done by the projection matrix but I bet you don't have any like that? I might get this wrong but from you it sounds like you think the vertex shader does it for you. No it does not. If you do not explicitly have anything that performs this transformation(unless you already have the values between 0 and 1) the GPU will clip the geometry.

I should've said this explicitly, but I didn't. I figured if I'd be writing a vertex shader to do this, I could easily change the orthographic projection matrix to use different near/far planes instead of using the default [1, -1] (I think that's what the default is...).

Anyway, like I said, I'm pretty sure alpha blending would screw this all up so I don't think a z-buffer would actually be of much help if it were to be used to order sprites.

172

Feature requests / Re: Setting Sprite Z (Depth) for Draw Order

« on: April 08, 2012, 11:58:58 pm »

Well I can say that it is impossible for a vertex shader to do this for you since this is not resolved in the vertex shader. You have no control of the depth-test. You can only modify a pair of states. It's all done in the GPU hardware. And no the depth buffer is not that expensive but it is still a lot more expensive than having none. Remember that the depth test is done on each pixel also for pixels that fails. And then we have the write operations. It does cost a lot compared to having none at all. It is cheaper to do a per-entity compare instead.

Couldn't the vertex shader just set the z value, which would then be used when doing the depth test to determine which fragments to draw? The reason I was thinking of using the vertex shader is exactly because it's done on the GPU, so CPU cycles wouldn't be needed in maintaining a sorted list of sprites. But I guess it would actually take some profiling to see what the speed differences were, if there are any.

The funky bug that can appear with the "I put floating things at z-depth 0.1f" is that if you have a tile-system and calculate the depth based on objects height you can easily get some tiles or objects on the edge that might cut those floating things. But if you then say "I put a limit to 0.5f" then you have more or less created an indirect layer. So why not create a proper system to manage layers and draw entities in separate passes? There is only advantages as you both get a full 32 bit floating point accuracy instead of only half of that and it will become easier to sort things after depth as you have more or less done a form of divide-and-conquer algorithm in a higher level.

Yeah, I guess it'd be like a layer system without actually programming any layer management (the isFlying could be turned into a layer variable instead), which I think could turn out as an elegant alternative (though like I said, I've only just thought about this so there could be issues I haven't thought of yet, so it may not be that elegant... but it could be, I think). But you wouldn't have to restrict z values to the [-1, 1] range, as they get homoginized after the vertex shader, so you could still perform decent depth testing. You could also disable it for certain things, like the background/tilemap and UI.

I'll have to give the vertex shader idea some more thought, but I think it has potential.

Either way, I'd still like to hear Laurent's opinion on this (I'm expecting him to say no, but I'm interested in why as well).

[edit]

I just thought about alpha blending from sprites, as that would probably be needed... I don't think the depth buffer would be much help there (as alpha blending resorts to rendering with the painter's algorithm, right?), so I think you're right in that a sprite's depth with a depth-buffer wouldn't actually help that much. Never mind, I guess.

173

Feature requests / Re: Setting Sprite Z (Depth) for Draw Order

« on: April 08, 2012, 11:18:51 pm »

I can say that Laurent will give you the answer no this will not be implemented and he has already denied this request several times before. Did you even do a quick search on the forum before posting?

I'm pretty sure he'll say no too, but it's worth asking . I did do a search, but google gives dead links to the old forum (I found one google cached page where someone requested it but I'm pretty sure Laurent's answer was on page 2, which I couldn't get to with google's cached version) and this forum's search feature gave nothing relevant (that I could find, at least; maybe there's a fancier search option that does a better job, but I didn't find it).

If you really need to do this you can implement it yourself by just simply drawing the objects back to front and you will get the desired result. Also giving different objects distinct depths is bad. Like you are saying you want to do with the flying units. You should implement a layer system to handle that. Or funky bugs can appear.

Could you elaborate? I'm not saying it's the best solution, but I can't think of a situation in which funky bugs would appear. Layers could help, but drawing sprites in the same layer still requires them to be sorted.

It's possible to sort the sprites in a specific way and then render them in order, to simulate the depth effect, but that's not nearly as efficient as just setting the z value for each sprite.

If you do it right it will be efficient. Certainly more efficient than using the depth buffer when you could do without it.

Really? Unless I have really wrong ideas about how to do the sorting, I didn't think a depth buffer was *that* expensive.

Also, I made an edit after you posted about being able to use a vertex shader for this. So far I haven't thought of a game where a vertex shader couldn't do this for you, and unless I can I guess this request is kind of moot.

174

Feature requests / Setting Sprite Z (Depth) for Draw Order

« on: April 08, 2012, 10:50:32 pm »

I know this wouldn't be a part of SFML 2.0's initial release, but I think it'd be really useful to be able to set a sprite's z-depth so that sprites can be overlapped and rendered correctly.

For example, imagine a 2.5D RTS (like Starcraft). For the most part, units don't overlap too much, but they can a little bit (put two drones by each other). If I could set the sprite's z-depth based on their (x, y) locations, it would be easy to ensure a consistent drawing order. In addition, flying units could be given a distinct depth offset so that they always appear on top of other units, but they overlap other flying units in a consistent way as well.

It's possible to sort the sprites in a specific way and then render them in order, to simulate the depth effect, but that's not nearly as efficient as just setting the z value for each sprite.

Your thoughts?

[edit]

In my example above, I could easily do this with a shader (and using a vertex shader may even be more efficient in this case) with something like z = x + y * mapWidth + isFlying * flyingOffset. I'm not sure if the vertex shader would be the most appropriate place to do this in all situations though; I haven't thought of one where a vertex shader wouldn't work well yet, but I'll give it more thought.

175

Feature requests / Fix links to old forum

« on: March 31, 2012, 11:03:42 pm »

Normally, I've found a lot of stuff on SFML's forums through google. However, since the forum moved, all the links from Google are invalid and result in this page.

Is there any way to make these links to old threads redirect to their current location?

176

General discussions / New naming convention

« on: March 17, 2012, 10:41:50 pm »

I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic. I see Config.hpp still has long long so I'm assuming C++11...

Code: [Select]

-Wno-long-long


SFML is currently C++03, and will have conditional support for C++11.

*facepalm*  Thanks, overlooked that one.  And thanks for the info.  And SFML.

177

General discussions / New naming convention

« on: March 17, 2012, 09:11:03 pm »

I compiled with

Code: [Select]

-Wall -Wextra -Wshadow -pendantic -Wno-long-long
with

Code: [Select]

clang
gcc
mingw32-gcc
 and fixed all that was found.

Just out of curiosity, which versions did you use?  Specifically, will SFML 2 be targeting C++03 or C++11?  I see issue 129 is about adding conditional C++11 support, but I can't tell if that means adding support conditionally (i.e. it doesn't exist yet) or removing it (i.e. it does exist now).  I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic.  I see Config.hpp still has long long so I'm assuming C++11...

178

Network / UdpSocket visibility issues with destructor & vtable

« on: March 16, 2012, 05:37:50 pm »

If it were a real world application, yes, I most certainly would do that.  But for this assignment they don't want a bundle, they just want an executable.

Anyway, this should be ok for now.  I'll test it with g++4.6 someday (probably during the summer, when I have time to work on my personal projects that'll use SFML), and if there are issues with g++4.6 I'll look into it more and see if I can help provide a patch (or at least a detailed bug report).

179

Network / UdpSocket visibility issues with destructor & vtable

« on: March 15, 2012, 06:57:36 am »

Hi Laurent, thanks for the reply.  Normally, I would use dynamic libraries (on Windows too), but I'm currently working on a game project for school and it needed to be a static build.  I just wanted to see if anyone's had these warnings before and how to resolve them.  I can ignore them if necessary.

180

Network / UdpSocket visibility issues with destructor & vtable

« on: March 14, 2012, 04:24:24 am »

So I've been excited to use the latest SFML, but I'm getting some weird warnings.  Things still work and my program runs, but I'm not sure if this is just my build system or if it's an issue with SFML.  I'm using the System and Network modules of SFML, and I've build and configured them with no warnings or errors.  However, my program is trying to use the libraries and I'm getting the following warnings at link time:

Code: [Select]

g++ -g -L../sfml/lib -lsfml-system-s -lsfml-network-s -L../protobuf/lib -lprotobuf -I../sfml/include -I../protobuf/include -o client main.cpp Message.pb.cc
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: vtable for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo name for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o

It's complaining about the visilbility of the UdpSocket destructor, as well as the vtable and typeinfo for UdpSocket.  I'm positive the headers and source files are all the same version, as I just did a clean checkout.  I can't see anything wrong with UdpSocket either.

Does anyone thing this is an issue with SFML or is it probably an issue with my computer?  What more can I do to narrow down the problem?

If needed, my setup is:
OS X 10.6
g++ 4.2.1
SFML revision d592b2a