Messages

31

General / Re: Weird horizontal lines

« on: July 14, 2013, 03:53:10 pm »

Could you elaborate on how you mean with depends on decimal? Can't help if I don't understand what you are doing.

also it could be the sampling is a problem that Laurent suggested, but that wasn't what I had trouble with.

32

General / Re: Weird horizontal lines

« on: July 14, 2013, 03:11:43 pm »

I am guessing your friend is sitting on a laptop? This is a rounding error in the position of the vertices. Or well it was when it happened to me. The desktop GPU can calculate it properly while the laptop have lower precision or something like that. It was my experience when i put together a similar demo. Laurent is already in the direction I did to solve it, make sure the numbers you use are integers. Think this also apply to however you offset your view to move around.

33

General discussions / Re: Do you listen to music while you program, if so what do you listen to?

« on: July 14, 2013, 02:36:12 pm »

Nu-jazz, Electroswing Love Goldfish <3

34

General / Re: Handling simultaneous, interdependent, game loop updates

« on: July 14, 2013, 02:55:10 am »

Well it might feel unnatural at first when you haven't done it before.

But logically it makes sense, it makes more things possible. Let's for instance take the example of that you could run the modifying update calls in parallel if you have previously read all the data you need to do the update. Since you know for sure that the data you are reading won't change

Also of course you want the input calculation to be as small as possible and still do as much as possible in the actual update.

About books on the subject, well I don't know any really. There is probably one small chapter in one Game Gem book somewhere. But I hardly think it got any huge article about it or anything like that. Most of the time it's a case-by-case situation when implementing it. You have to look at what you want to do and how you want to solve it.

I know what you are working on, and if this is for that project, I would say this is the way to go because of... reasons   

35

General / Re: Handling simultaneous, interdependent, game loop updates

« on: July 13, 2013, 04:07:04 pm »

When I worked on Project Temporality we actually went with the second approach. We first collected all input that this object would receive, and after that we did a second loop where we actually executed the inputs. This had several practical benefits we gained from it. For one, it allowed us to record an entire game session(thus letting us do the whole time manipulation game mechanics the game is based on)

But it helps a lot with other problems, like this one. As it enforces that everyone is reading the same data, and do the same. So the order in when they are updated doesn't matter anymore. For instance you can get "out-of-synch" errors because you are reading modified data, so an object would behave incorrectly. Which happened to us when somebody messed up 

36

General discussions / Re: SFML Game Development -- A book on SFML

« on: July 09, 2013, 04:35:26 pm »

Awesome! <3
From the whole team, thanks for the support and all the bug reports we have gotten
Will be putting out a public repository for the code pretty soon, we are still trying to choose a fitting license.

37

General discussions / Re: SFML Game Development -- A book on SFML

« on: July 01, 2013, 07:47:39 pm »

Just bought it and I'm reading through it now, it looks very promising, also, thank you for not being a complete bastard and putting DRM all over the .pdf file so I can store it and keep it offline. Too often I buy something digital only to discover if the internet goes down I can't even use it properly.

More developers just need to say no to DRM that doesn't even work.

Edit: The best thing about this book is on one of the very first sections it goes into a lot of detail about a problem I posted on these boards which is really nice

Ah that, we have no control over. That's the publisher that needs cudos for not being dicks then

38

Window / Re: Xbox 360 Controller Triggers Share Axis (Any way to isolate?)

« on: June 30, 2013, 09:22:26 am »

Just curious, how is it with PS3 controller? Anybody tested that?

39

Graphics / Re: Use multiple shaders on same sprite?

« on: June 29, 2013, 09:00:00 pm »

That sounds great but how do you use them in this way? I cannot find much information about blend modes.

It seems like i need sf::Blend::Add yet i have no idea how to use that with Sprite. I always thought a blend mode with add means the graphics get lighter though so i am kind of confused by what you mean.

Does anyone have a simple code example if possible?

You want to look at sf::RenderStates, it is what you pass to the draw function after the sprite. The render state can take various settings for the draw call.

Like I said, blend modes will merge two results together. So Add would add the result of both pixels together thus giving a brighter result, yes. If you do the solution with shader, that will add the last shader on the first one. So if you pixelate first and then blur, you blur the result of the pixelation and not the source image you used.

Like Laurent said, it's hard for us to give you the right solution if we don't know exactly what effect you want to achieve. But if you are just experimenting to see how things work, you should do both

40

General / Re: Can't modify Vertex of a VertexArray

« on: June 29, 2013, 08:55:29 pm »

Aight, I will put a []= operator in the class tomorrow.

I want references to the individual vertices, but that would mean that I have to wrap the sf::Vertex class, they have to be dynamically allocated, and I have to manage the references between them and other classes(like sf::VertexArray). As it is now Ruby does it for me since the object is a light weight ruby object that is just there temporarily. The Ruby GC is quite good at reusing small objects with small life times.

41

Graphics / Re: Use multiple shaders on same sprite?

« on: June 29, 2013, 06:15:10 pm »

The problem you have at the moment is that you are writing over your previous result, thus "only one shader is being shown". All of the shaders are applied, but only the last one is visible because you have written over it. A blend mode will let you choose how you merge these pixels. The default will give you the effect you have at the moment.

So blend mode is the most simple way to solve this. But they are quite limited. That is why I am suggesting what Laurent suggested (but that is from way back in time, it is called RenderTexture now and not RenderImage) that you have an intermediate buffer texture that you first render to, and then read from. That way you will first get the pxelate effect and then a blur effect applied on the pixelated result. While with blend mode you would get one pixelated result and one blurred result that is merged together.

42

Graphics / Re: Use multiple shaders on same sprite?

« on: June 29, 2013, 05:51:09 pm »

What I find it that you are missing is probably a proper blend mode. Though it depends on the effect you want. Do you want to blur only the result from the first draw call with the first shader? Or is the blur shader somehow independent of the result of the first shader?

Edit: Since you have only the default blend mode, the previous data will be overwritten, what you would need to do is either use a blend mode that will preserve the old data and apply the new data. Or you render the sprite to a render texture first, and then use that texture as input for the second texture.

43

Graphics / Re: View only moves once

« on: June 29, 2013, 04:46:21 pm »

I think it would help if you provide some kind of minimal example for us. Also use the [ CODE ] tags to paste in code. Makes it much more readable.

44

General / Re: Can't modify Vertex of a VertexArray

« on: June 29, 2013, 03:24:10 pm »

Ah this is something on my todo list I have to remember to fix.

The VertexArray returns a copy of the Vertex and not a reference. Getting it to return a reference won't be an easy task though.

You can do something like this:

vertex = SFML::Vertex.new
# do changes
array[0] = vertex
# do changes
array[1] = vertex

SFML::Vertex is a pure Ruby object itself, so it's really lightweight so this should not perform any performances issues for you.

Edit: Also #append is super fast actually. The vertex array in SFML is just a wrapper above a std::vector, so the size is cached and even if you clear the array the memory won't be free'd.

45

General discussions / Re: SFML Game Development -- A book on SFML

« on: June 28, 2013, 03:50:00 am »

So just to clarify, if I buy the book from amazon, will I have access to the code from Packt? It looks good, great job  .

Yes you will. You get a download link from their support page.

Also the compile problems with VS11 is bugs that has been introduced in the new compiler, no ETA on when they will fix it. So I have done some fixes in the source code, will get it uploaded as soon as possible.

Bug issue: http://connect.microsoft.com/VisualStudio/feedback/details/773565/cannot-call-const-forwarding-call-wrapper-result-of-std-bind