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

Pages: [1] 2
1
Graphics / Re: Getting projectiles to move according to time
« on: March 24, 2015, 08:42:32 pm »
its unclear from the code you added - are you calling dt = clock.restart(); every frame? or just once? (you suppose to call it every frame)

Edit: see this page http://www.sfml-dev.org/tutorials/2.0/system-time.php
at the bottom you have an example.

2
Graphics / Re: window.display() getting stuck at some positions
« on: March 22, 2015, 05:53:14 pm »
if you see debugging a function as a personal assault on your code, then yeah, you are kind of defensive mate.
thanks anyway

3
I read some about SwapBuffers() and saw it was GL func.

If you can't reproduce it with pure SFML code then the chance it is a problem with SFML is highly unlikely. Chances are much greater you are doing something in your own code wrong. And you can't 'debug' SwapBuffers because that is an OpenGL function (implemented in the GPU driver). So also check that your drivers are up to date.

dude stop being so defensive. I never once said it was an SFML bug nor have I implied it. I KNOW its my bug but since its effect happens in SFML part I need help solving it. all you did was trying to "prove me wrong" instead of actually helping. next time I will include in the question title "THIS IS MY BUG NOT SFML" to get some help around here.  :-\

...If you had read a bit more about it, you might have probably seen that it is allowed to block if the OpenGL command queue is full, meaning the GPU needs more time to finish off all the operations you told it to perform. What are these operations? Everything you did, up to 3 frames ago. GPUs tend to run 3 frames behind the CPU, and if it starts to lag even further behind, SwapBuffers() will have to block...

thank you this was actually very useful. I did read a little about SwapBuffers but I missed that part.


4
Graphics / Re: window.display() getting stuck at some positions
« on: March 22, 2015, 03:20:55 pm »
The game is written with wrapper layer to SFML, customized sprite entity, and shaders. I can't reproduce it with simple sfml code. I tried.

believe me when I say - I really don't have any minimal example to post. If I had I put it.
but everything works super fast and it get stuck on window.display(), which as far as I know should only flip buffers. and as I said it only happens at certain spots, moving the view as much as 5 pixels from those spots and everything works great.

I disabled everything but the renderings (like physics etc.), but its still a lot of code.
I did notice that it only happens when using my shader.

so maybe let me rephrase the question:
1. what does window.display() actually do besides flipping buffers?  I checked the code and looks like eventually all it does is glCopyTexSubImage2D() so I don't see how it can get stuck? is there some magic inside I'm missing?
2. did you ever encountered a problem similar to this in the past?
3. how can I debug that function?
4. which steps should I do to figure out the problem?

thanks.

EDIT:
I debugged it to this point:
void WglContext::display()
{
    if (m_deviceContext && m_context)
        SwapBuffers(m_deviceContext);
}
 
in WglContext.cpp. SwapBuffers is what taking so long, but the debugger can't find the SwapBuffers() symbol. trying to figure out why..

5
Graphics / Re: window.display() getting stuck at some positions
« on: March 22, 2015, 12:49:17 pm »
I can't post the code, sorry.
I can post only selected parts of it like the init part or the shaders. will that help? what part will help?

6
Graphics / window.display() getting stuck at some positions
« on: March 22, 2015, 12:43:31 pm »
Hi all,

I'm rendering a rather simple scene with some sprites and customized shaders. I'm using a View as a camera to scroll around the level.

For some reason, at some positions of the view, calling window.display() takes up to few seconds! I used counters to check and its not like I render more sprites or anything during those stuck frames. the exact same scene rendered 5 pixels to the left and it gets stuck. I move a few pixels to the right and its back to normal with FPS at 200+.

I tried everything - removing some of the sprites, changing the view, counting times... nothing! at some magic positions window.display just takes seconds to execute with no apparent reason. :(

How do I even tackle this problem? do you think its maybe a problem with my graphic card? (Radeon HD 6500, never had any problems with it before).

Any idea or help will be appreciated!
thanks.  ;)


7
General / [Solved] Keyboard and Mouse with Ogre3d
« on: February 07, 2015, 05:48:57 pm »
hello,

I'm working on an Ogre3d project and I want to use sfml for input only.
I have two questions:

1. can I use functions like sf::Keyboard::isKeyPressed() or sf::Mouse::getPosition() even if I have no SFML window at all and I'm not pulling events via sfml?
2. I'm trying to link statically and I linked to both System and Window libs, but visual studio still don't find sf::Keyboard nor sf::Mouse. (unresolved external symbol...) what do I need to link to in order to make it work?

PS I know the thread that shows how to combine Ogre3d with SFML but there he is creating SFML window and render on it and I rather not do that (since I only use SFML for keyboard & mouse)
thanks!
:)

EDIT: oops it was my mistake. forgot to add some static libs & preprocessor static_lib define.

8
to be honest I didn't fully understand what you are doing in the shader with the fragment_position calculation (maybe its because of the time :)), but if its 2d, why not calculating the distance in screen position? i.e. using the gl_FragCoord varying you already have built-in. or are you doing anything special in the vertex shader?

read more here: https://www.opengl.org/sdk/docs/man/html/gl_FragCoord.xhtml

also two tips about your code:

instead of this:
float vect_lenght = sqrt(vect.x * vect.x + vect.y * vect.y); //get vector's lenght

    vect.x = vect.x / vect_lenght; //normalize vector
    vect.y = vect.y / vect_lenght;
 

you can use normalize() to normal the vector and length() to get vector length (if you need it).

and instead of this:
vec4 light = vec4(pixel.r*light_color.r*intensity, pixel.g*light_color.g*intensity, pixel.b*light_color.b*intensity, pixel.a);
 

you can do something like this:
vec4 light = pixel;
light.rgb *= light_color.rgb * intensity;
 



I don't know if it helps but this is how I wrote my normal maps shader (rgb is normals, a is depth):
(click to show/hide)

9
Graphics / Re: Bomberman's deplacement style
« on: January 28, 2015, 05:07:15 pm »
Quote
The movement is not always the same it's because i replace the player.

I don't mean to disrespect, but can you please stop making up problems???  :P
so what if the movement changes? you still know it! even if you do some crazy random movement every frame, something like this:

player.x += rand();

you can still turn it into this:

float movex = rand();
player.x += movex;

and predict the next step before the actual movement.
there is no reason, and I repeat, NO REASON why you can't predict the next step of the player you move.
and if I didn't understand what you meant I apologize and please explain better :)

10
Graphics / Re: Bomberman's deplacement style
« on: January 28, 2015, 09:45:51 am »
I understand all what you means but for check the collision i need check if the player pos + movement are inside a case and replace him if needed.

So if the player press left and top, the player is always replaced because Movement.x and Movement.y are increased  !  :'(

You talk as if you have no control over the code  :-X. lol just change your logic flow. like Hapax said, first do collision test on the predicted position and only then move the player. you know the current position and the speed, so predicting next step is just position + speed.
and if for some reason its a problem, you can always store the previous position, move, and if collision detected restore to previous pos (on x and y axis separately).

to Arcade - the problems you mentioned are just more reasons to use physics lib (with player having a circular shape and 'sliding' on walls) :)
but if I'm not mistaken in bomberman the movement is aligned, i.e. the player will only stop walking on multiplies of X pixels. for example, if the player walking is aligned to 8 pixels and while walking up the player released the up key at position of 32x13, the player will keep on walking up for 3 more pixels so he will end up standing on 32x16. this requires a little rounding due to framerate independence making the final position inaccurate, but after implementing this you won't have problem with aligning the player on the holes.
I think in bomberman if you collide with a wall it also moves him a bit on the other axis to fit to the opening right?

11
are you talking 2d or 3d?

I implemented a 2d lighting shader with normal maps and I sent the light position to the shader already converted to screen coords. I even asked this somewhat similar question:
http://en.sfml-dev.org/forums/index.php?topic=17352.0

so if you are talking 2d I can give you more info.

12
Graphics / Re: Bomberman's deplacement style
« on: January 27, 2015, 11:04:57 am »
I will first give a solution then explain why its not good :)
you should separate the movement and the animations, meaning do something like this (in pseudo code):

// do movement:
if (key_up_pressed && can_move_up):
    move_up();
else if (key_down_pressed && can_move_down):
    move_down();
if (key_left_pressed && can_move_left):
    move_left();
else if (key_right_pressed && can_move_right):
    move_right();

// do animation
if (key_up_pressed):
    animate_run_up();
else if (key_down_pressed):
    animate_run_down();
else if (key_left_pressed):
    animate_run_left();
else if (key_right_pressed):
    animate_run_right();

 

with this basic logic you have several advantages:
1. the player is not "sticky" to walls, i.e. if you press up and left and he can't move up, he will still move left and won't get stuck
2. player will still animate walking while colliding with walls, which is how bombarman works if I remember correctly. anyway its just my own opinion but I prefer games where your character keeps on the walking animation while stucking at walls rather then games that the character just stop and stand because it collided  with a wall.

now here's why I don't think its an ideal solution:
I believe in always integrating physics into your game rather then implement them yourself. you can never know what kind of physics you gonna need tomorrow. maybe sliding surfaces? bouncy bombs? explosion pushing you back? pushable objects? surfaces with higher friction?.. etc. etc. since implementing your own physics limit your possibilities (every feature suddenly becomes costy), I always recommend to use physics engine (such as box2d) rather then to implement the collision & physics yourself. even for "simple" games (no game is simple! :P)

with that said, if you are still kind of new to this and/or this is just an experimental / hobby / study project, forget about what I said and don't worry about implementing a naive collision detection yourself. its a good practice and anyway messing with physics lib while you are still learning to handle the graphics/game-play can be a bit messy. :)

13
Graphics / Re: transform vector to screen coord, outside the shaders
« on: January 26, 2015, 03:39:06 pm »
this seems to work perfectly on X axis but weird on Y axis.
it looks like the view position on Y axis is not calculated correctly: when view position is 0 the light position is at the bottom of the screen, and as I move the camera around the light move around on Y axis differently then the rest of the sprites.

EDIT:
ok this solves it:
pixel.y = m_window.getSize().y - pos.y;
 

thanks! :)

14
Graphics / [solved] transform vector to screen coord, outside the shaders
« on: January 26, 2015, 02:46:53 pm »
hi all :)

How can get the worldview matrix in sfml?
or more specifically - I have a raw vector which I want to convert to screen position, i.e. the actual 2d pixel it will take on the screen if it was pushed through the rendering pipeline.

I tried the following (light.position is the raw position):
sf::Vector2f pos = m_window.getView().getTransform().transformPoint(light.position.x, light.position.y);
 
but from the shader it doesn't look right. I have a sprite and a light at the same position yet they seem far away. also, when I move the view (and update the shader) it doesn't move the light.

what am I doing wrong here?
thanks!  8)

15
General discussions / Re: bytes vs floats for color components
« on: January 22, 2015, 12:52:42 am »
thanks  ;D

about the byte-to-float conversion I mentioned it as a counter to the fast-copy claim, but both of them are kind of silly points anyway.   8)

Pages: [1] 2