Messages

1

SFML projects / Re: Blind Jump: Space Themed Adventure Game with Roguelike Elements

« on: April 05, 2016, 06:50:41 am »

The game looks great!
I have a tiny suggestion, though. It looks like the main hero moving animation is a bit slow compared to the "speed" of the map scrolling. It seems like it is a fairy flying around 
I'd suggest that you increase the speed of the animation cycle when he runs .

2

Graphics / Re: Motion Blur GLSL

« on: March 23, 2016, 07:54:19 am »

You, possibly, can achieve that using another approach, not dealing with shaders.
Store a stack of a few (1-3, for example) previous rendered scenes and render all of them with an appropriate alpha.
If all you have is several shapes/sprites which move, then you might just store a stack of their previous positions and render them several times, looping through them. (in other words, no need to store *all* data related to the scene in the stack, just a few positions vectors).

Of course, it might be overkill, just a guess.

3

SFML projects / Re:creation - a top down action adventure about undeads

« on: February 11, 2016, 07:17:49 am »

Hi there.
I've been following this topic for a long time. What I can say - you do an amazing job!

One question regarding ECS engine - how  do you process, say 'GraphicsComponents' in the specified order?
For example, let's suppose we have tilemap (i.e. the 'background' layer), then we have HUDS tilemap on top of that, and finally we have our entities like main hero, enemies, whatever. Obviously, during the render we must process them in the specified order: 1) tilemap; 2) HUDS tilemap; 3) enemies and main hero.

Or, suppose, we need to render GUI elements on top of all rendered stuff.

If we just say to our Render system: "hey, take all graphics components and draw them", it will be a mess.

How do you do that? Thank you.

4

SFML projects / Re: First game

« on: January 27, 2016, 10:13:08 am »

I spot tile glitches from time to time. Am I right or it is due to video recording?

5

General discussions / Re: sf::Shader -- API to set uniforms

« on: January 23, 2016, 05:18:55 pm »

thanks for the response.
weird, the previous version works fine in my case even if I pass an integer.

6

General discussions / Re: sf::Shader -- API to set uniforms

« on: January 23, 2016, 04:54:03 pm »

I am sorry for hijacking this thread, had no idea where should I post.
Anyway, I just upgraded to the current SFML version from git (revision 1217699fe0) and noticed that

    fooShader.setUniform("someFloatVal", someIntVal);
 

behaves differently than the previous version:

    fooShader.setParameter("someFloatVal", someIntVal);
 

I mean, if our shader has

uniform float someFloatVal;
//...

the new version stops working.
In order to fix that I had to add an explicit cast from int to float:

    fooShader.setUniform("someFloatVal", (float) someIntVal);
 

Is this a bug?

7

Graphics / Re: Shadermanager [Problem with Noncopyable]

« on: January 07, 2016, 05:17:47 pm »

copy-consructor is forbidden for sf::Shader.
try the following:

  const sf::Shader &ShaderManager::getShader(crString name) const {
    //TODO:
  }
 

oh, wait, also, you cannot add shader in the way you presented because it needs a copy to be created, which is forbidden in the current implementation.

8

General / Re: Project runs extremely glitchy on Linux with the same source code as on windows

« on: December 11, 2015, 07:18:24 am »

as for segmentation faults: debugger is your friend (gdb in Linux), of course, you need to recompile your project in debug without optimizations flags and then investigate your coredump file with it. it should/might shed some light on what's going on.
in the simplest form run

gdb executable corefile
 

and see what happens.

9

Graphics / Re: resource manager

« on: December 08, 2015, 12:30:06 pm »

there's a good explanation what might be improved in the sample presented above (it is about std::map access): http://www.youtube.com/watch?feature=player_detailpage&v=fHNmRkzxHWs#t=1430

I am not going to start holy war, just my two cents:
I wouldn't use map here, because map is bad (speaking about the memory layout), I'd use std::vector and be happy with it. Even if I had used map, I'd prefer std::unordered_map with some integer or, better, enum as a key, instead of a std::string.

10

SFML projects / Re: In Soviet Russia

« on: October 26, 2015, 07:35:51 am »

cool idea!
But, I'd be more happy having bears! Also, as for pickup items you might add balalaikas (musical instrument).
that's my 2 cents :-)

11

General / Re: Weird movement in my program

« on: August 12, 2015, 10:47:00 am »

I have had non smooth movement issues unitl I implemented the idea explained in this brilliant article: http://gafferongames.com/game-physics/fix-your-timestep/

One notable step is explained there in the section "The final touch". Your code snippets above don't apply that technique, so, maybe that's why your movements yet not smooth.

Let me quote an excerpt from the article:

To understand what is going on consider a situation where the display framerate is 60fps and the physics is running at 50fps. There is no nice multiple so the accumulator causes the simulation to alternate between mostly taking one and occasionally two physics steps per-frame when the remainders “accumulate” above dt.

Now consider that in general all render frames will have some small remainder of frame time left in the accumulator that cannot be simulated because it is less than dt. What this means is that we’re displaying the state of the physics simulation at a time value slightly different from the render time. This causes a subtle but visually unpleasant stuttering of the physics simulation on the screen known as temporal aliasing.

One solution is to interpolate between the previous and current physics state based on how much time is left in the accumulator

Hope that helps.

12

Python / Re: Russian problems :)

« on: July 30, 2015, 04:02:25 pm »

he said it didn't work for him/her (the link above).

13

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 27, 2015, 04:31:43 pm »

yes, I do understand what you explained.

if it is a bug, it should be fixed, I hope. in other words, say, I have some OpenGL game which runs fine in fullscreen mode, but I cannot say the same about the SFML example. so, there's something wrong with the SFML example, not my "system".

I just don't know where to move on from here. I'd be glad to help the community in fixing this bug.

14

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 27, 2015, 06:06:30 am »

here's the result: it doesn't hang on another computer (Ubuntu 14.0.2, 32 bit, Nvidia discrete GPU).

15

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 26, 2015, 03:00:28 pm »

I hope I don't bother you. Just tested it in Fluxbox Desktop Environment. It hangs :-/