Author Topic: Strange math needed (Read 6389 times)

computerquip · « **on:** February 05, 2010, 12:54:45 am »

I'm making a small Pong game and I'm not having really any problems. I did find some strange behavior and it may perhaps be because of some of my amateur coding although I don't see how:

Code: [Select]

      
        if (Input.IsKeyDown( sf::Key::S ))
        {
            float distance = (Speed * Window->GetFrameTime());
            if (Paddle.GetPosition().y + distance > Window->GetHeight() - (Paddle.GetSize().y / 2) )
                Paddle.SetY(Window->GetHeight() - (Paddle.GetSize().y / 2)); //I don't know why I have to divide it by 2.
            else
                Paddle.Move(0,distance);
        }

I found that I needed to divide the size of the sprites height by two for it to calculate correctly and to prevent the paddle from moving off the screen at all otherwise, perfectly half of the paddle would move off of the screen. I couldn't figure out why so anyone have ideas?

EDIT: Thought I'd add that I enjoy the simplicity of the library and the C++ interface.

Boogiwoogie · « **Reply #1 on:** February 05, 2010, 02:25:55 am »

Quote from: "computerquip"

I found that I needed to divide the size of the sprites height by two for it to calculate correctly and to prevent the paddle from moving off the screen at all otherwise, perfectly half of the paddle would move off of the screen. I couldn't figure out why so anyone have ideas?

i think its just where the origin of your sprite is. obviously its in the centre of the sprite. so if you have 640x480 resolution, your paddle ist 100 pixel in height, and it moved down to y = 430: how much space is left on the bottom to move your paddle further down?

computerquip · « **Reply #2 on:** February 05, 2010, 06:09:06 am »

I actually just thought a little more about it and figured something a bit dumb. I haven't really tested the size of the object or figured what size the library will return or where the origin truly is but lets say I were to set Y of Paddle to 0. This works perfectly fine without the extra math needed otherwise. What's up with that?

EDIT: A little bit more testing in, I find that if I hardcode the size of the sprite (100), It has the same reaction as if I didn't divide by two. I also noticed that if I change the window resolutions, the solution to divide the size by two no longer works and requires other fittings. To be honest, this is starting to make my head hurt. Is there a more orthodox method that I'm missing to accomplish this?

OniLinkPlus · « **Reply #3 on:** February 06, 2010, 12:46:26 am »

Quote from: "computerquip"

I actually just thought a little more about it and figured something a bit dumb. I haven't really tested the size of the object or figured what size the library will return or where the origin truly is but lets say I were to set Y of Paddle to 0. This works perfectly fine without the extra math needed otherwise. What's up with that?

EDIT: A little bit more testing in, I find that if I hardcode the size of the sprite (100), It has the same reaction as if I didn't divide by two. I also noticed that if I change the window resolutions, the solution to divide the size by two no longer works and requires other fittings. To be honest, this is starting to make my head hurt. Is there a more orthodox method that I'm missing to accomplish this?

The problem is simple:
There is no problem. You are setting the origin of the sprite to the center of the sprite. Because it is the center of the sprite, you need to divide the height by 2 to get correct values. You're overthinking way too much.

computerquip · « **Reply #4 on:** February 06, 2010, 04:32:02 am »

What function sets the origin to it's center? I haven't called anything explicitly. Also, setting Paddle's Y to 0 would no longer work if the origin was not where it is by default. I am not changing the origin.

I'd like to add a little bit more to the topic. When I record the window height at the beginning of the program, it indeed gives 800 or whatever I have it set as. But whenever the main loop begins, the window decreases its size. For instance, it will reduce to 725 however the the physical window doesn't change.

Here's my code. It's all in a single file and it is a bit sloppy and the so called "debugging" output is very crude. However, it should be very easy to read and understand: http://pastebin.com/f5adcc5d2

If you can pinpoint the location in which I'm changing the origin of the sprite, I would be much obliged. I run Linux if this were to have any relevance (since the implementation is different for X11). I also have a statement that moves the paddle to the very bottom before the main loop begins. This works successfully but when you move down (or press S), it moves up which doesn't make sense at all. There might be some useless code that doesn't almost nothing in there. This was just me testing a few things out to see if somethings were faulting. They can be ignored or removed. It does compile as is with a few warnings concerning the event enumerations.

computerquip · « **Reply #5 on:** February 07, 2010, 06:44:44 am »

Further testing has helped narrow it down but I still fail to see the problem here:

I find that the paddle actually goes all the way to the bottom if I predefine a resolution but will not work if I use GetMode(0);. I also find that if I resize the window, the paddle will no longer match up to the bottom of the window which doesn't make sense since the bounds are equal to the size of the window minus the size of the paddle. Would anyone care to tell me what is happening? This is the third day I've been diagnosing this problem.

DdR_Dan · « **Reply #6 on:** February 07, 2010, 08:47:37 am »

It seemed as if the bottom of the game window went off the screen, at least for me. Instead of using "sf::VideoMode::GetMode(0)", maybe use "sf::VideoMode(800,600)" or something like that (it worked for me). I think using "Window->GetView().GetRect().GetHeight()" instead of "Window->GetHeight()" will fix the errors when the window is resized. I hope that helps.

I didn't need a divide by 2 or anything by the way.

computerquip · « **Reply #7 on:** February 07, 2010, 08:53:51 am »

I noticed that using GetMode(0) caused this as well. I confirmed it on multiple platforms as well and it seems like a bug :/. Your solution works. Thank you "HOLY CRAP" much. Although this works, would you happen to be able to explain why this works for future reference? If not, that's fine.

DdR_Dan · « **Reply #8 on:** February 07, 2010, 09:14:09 am »

Well, I don't really know it that well, but the problem with the paddle going half way off the screen seemed to just be the screen being to large. As for GetHeight and GetWidth, I think they don't give the value you want when the size of the window changes, so you have to get the height or width of the new view of the window to make up for the change in the view.

computerquip · « **Reply #9 on:** February 07, 2010, 09:22:36 am »

I always figured that the view by default was equal to the size of the window unless changed explicitly Perhaps I was wrong in thinking this or is this a bug?

Seeing my little test game run perfectly how I want it to puts a smile on my face. I also noticed that once I placed your little fix in there, GetMode(0) works fine as well. Now I can continue making the game and progress a bit further into a much more complex design and style. This also taught me that I need to learn a bit more about Windows themselves to help my understanding a little bit. Thanks a lot.

Laurent · « **Reply #10 on:** February 07, 2010, 10:37:42 am »

Depending on the OS, a window that has the same size as the current resolution may be forced to be smaller so that the borders and title bar can fit. I think I implemented a workaround for this on Windows, I have no idea about Linux. Maybe it explains your problems.

computerquip · « **Reply #11 on:** February 07, 2010, 04:45:00 pm »

Then it's a serious bug. Although, I've confirmed this happens on Windows and Mac, not just Windows. GetMode(0) does work now when I fetch the view of the window.

Also, from what I know, I was brought to believe the view was a section of the current graphed window, not the other way around. That makes no sense unless the function itself is returning an incorrect value. I'm sure I'm confusing this somewhere since I can't seem to get a clean explanation of the concept.

Laurent · « **Reply #12 on:** February 07, 2010, 05:59:49 pm »

Quote

Then it's a serious bug

Well, I can't do anything if the OS forces the size of the window to be smaller than the current resolution so that the title bar an borders fit. Use either fullscreen or a smaller resolution. The idea of using the desktop resolution to create a window is a bad one anyway.

Quote

Also, from what I know, I was brought to believe the view was a section of the current graphed window, not the other way around. That makes no sense unless the function itself is returning an incorrect value. I'm sure I'm confusing this somewhere since I can't seem to get a clean explanation of the concept.

Sorry I don't get what you mean, can you explain more please?