1
Graphics / Re: Gradually changing hue
« on: October 14, 2014, 12:30:53 am »
Perfect! Thank you.
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.
Pages: [1] 2
2
Graphics / Re: Gradually changing hue
« on: October 13, 2014, 07:19:32 am »
I grabbed the newest github SFML source (https://github.com/SFML/SFML/archive/master.zip) and built it and replaced my old one. There's no error anymore, but, strangely, the minus operation now turns the rectangle invisible. However, it appears to be changing the rectangle black despite this, as when I start holding the key to turn it white (which functions perfectly fine), it becomes visible again and is at a darker shade from before it turned invisible. 
(I've made sure it wasn't just blending in with my black background. Even on blue, it still completely disappears when I press the key that should darken the shape.)
Is this yet another issue with SFML as it is now at its current version, or have I made a mistake?
Does this code behave properly on your end?
(I've made sure it wasn't just blending in with my black background. Even on blue, it still completely disappears when I press the key that should darken the shape.)
Is this yet another issue with SFML as it is now at its current version, or have I made a mistake?
Does this code behave properly on your end?
//Outside game loop
sf::RectangleShape rect;
rect.setSize(sf::Vector2f(100,100));
rect.setFillColor(sf::Color(100,100,100));
...
//Inside game loop
if(sf::Keyboard::isKeyPressed(sf::Keyboard::O))
{
sf::Color rectColor = rect.getFillColor();
if(rectColor != sf::Color::White)
rect.setFillColor(rectColor + sf::Color(1, 1, 1));
}
if(sf::Keyboard::isKeyPressed(sf::Keyboard::P))
{
sf::Color rectColor = rect.getFillColor();
if(rectColor != sf::Color::Black)
rect.setFillColor(rectColor - sf::Color(1, 1, 1));
}
sf::RectangleShape rect;
rect.setSize(sf::Vector2f(100,100));
rect.setFillColor(sf::Color(100,100,100));
...
//Inside game loop
if(sf::Keyboard::isKeyPressed(sf::Keyboard::O))
{
sf::Color rectColor = rect.getFillColor();
if(rectColor != sf::Color::White)
rect.setFillColor(rectColor + sf::Color(1, 1, 1));
}
if(sf::Keyboard::isKeyPressed(sf::Keyboard::P))
{
sf::Color rectColor = rect.getFillColor();
if(rectColor != sf::Color::Black)
rect.setFillColor(rectColor - sf::Color(1, 1, 1));
}
3
Graphics / Re: Gradually changing hue
« on: October 13, 2014, 12:12:54 am »
I was hoping it wasn't a matter of being outdated 
Swapping out versions and fiddling with compiler and project settings confuse me to no end, but I'm absolutely not smart enough to implement it myself.
Guess I'll just have to take the time to rectify that. Thanks for the help.
Swapping out versions and fiddling with compiler and project settings confuse me to no end, but I'm absolutely not smart enough to implement it myself.Guess I'll just have to take the time to rectify that. Thanks for the help.
4
Graphics / Re: Gradually changing hue
« on: October 12, 2014, 11:23:16 pm »
tbh part of the reason I didn't post the compiler errors anyway is because I wasn't sure how to copy them to the clipboard haha
..turns out Code::Blocks has a right click option just especially for that, so here you go.
I'm baffled by why it is mentioning sf::Vector2 or sf::Time at all.
To be clear, the code that produces that error is exactly like the working "+" code aside from the fact that it uses a "-" instead (and a different key and sf::Color::Black, but I've already changed these to the same and can confirm the only issue is the "-" symbol).
It's really weird that it works for you, so maybe I should try it in a fresher project and see what happens.
edit: Just tried a fresh project, but I get the same errors when trying to minus.
..turns out Code::Blocks has a right click option just especially for that, so here you go.
(click to show/hide)
I'm baffled by why it is mentioning sf::Vector2 or sf::Time at all.
To be clear, the code that produces that error is exactly like the working "+" code aside from the fact that it uses a "-" instead (and a different key and sf::Color::Black, but I've already changed these to the same and can confirm the only issue is the "-" symbol).
It's really weird that it works for you, so maybe I should try it in a fresher project and see what happens.
edit: Just tried a fresh project, but I get the same errors when trying to minus.
(click to show/hide)
5
Graphics / [SOLVED] Gradually changing hue
« on: October 12, 2014, 10:12:02 am »
Hi. I have a RectangleShape that I'm trying to make gradually change to white as I hold a key. Actually, I've succeeded in this, but now I'd like a different key to gradually turn it black. It seems, however, that the minus operator will not work with sf:Color like the plus operator does.
To change my shape to white, I've used this code in the game loop.
I could only imagine this very same code with a "-" in place of the "+" (and sf::Color::Black instead of White, and a different Key) should do the opposite.
However, that only gives me compiler errors that I don't entirely understand (I will post them if needed). Could somebody tell me why this won't work?
To change my shape to white, I've used this code in the game loop.
if(sf::Keyboard::isKeyPressed(sf::Keyboard::Up))
{
sf::Color shapeColor = shape.getFillColor();
if(shapeColor != sf::Color::White)
shape.setFillColor(shapeColor + sf::Color(1, 1, 1));
}
{
sf::Color shapeColor = shape.getFillColor();
if(shapeColor != sf::Color::White)
shape.setFillColor(shapeColor + sf::Color(1, 1, 1));
}
I could only imagine this very same code with a "-" in place of the "+" (and sf::Color::Black instead of White, and a different Key) should do the opposite.
if(sf::Keyboard::isKeyPressed(sf::Keyboard::Down))
{
sf::Color shapeColor = shape.getFillColor();
if(shapeColor != sf::Color::Black)
shape.setFillColor(shapeColor - sf::Color(1, 1, 1));
}
{
sf::Color shapeColor = shape.getFillColor();
if(shapeColor != sf::Color::Black)
shape.setFillColor(shapeColor - sf::Color(1, 1, 1));
}
However, that only gives me compiler errors that I don't entirely understand (I will post them if needed). Could somebody tell me why this won't work?
6
General / Re: Problem with using Velocity to Stop a Sprite
« on: July 05, 2013, 01:46:50 am »
Thank you so much, that did the trick. If anybody still wants to offer an alternative solution, you can ask for some more code or just go ahead and let me know. I'm not an incredibly good problem-solver on my own so seeing how other people do things helps me out a bunch.
7
General / Problem with using Velocity to Stop a Sprite
« on: July 05, 2013, 12:06:05 am »
Hello, I wanted to add a bit of a gradual X-axis acceleration and deceleration to my player sprite, and I am having a slight issue with deceleration. When I release the movement keys, the character almost stops, but inches ever so slightly to the right (A few pixels per second probably). This is how I'm doing it:
I thought that these two statements would eventually neutralize each other and make the velocity zero, but I guess not.
That's all the code I think is necessary to post, because changing the lines inside the block to just
solves the problem but gets rid of the deceleration. How can I do this differently and fix the bug?
if(!isRightPressed && !isLeftPressed)
{
if(playerXVel > 0)
playerXVel -= 8;
if(playerXVel < 0)
playerXVel += 8;
}
{
if(playerXVel > 0)
playerXVel -= 8;
if(playerXVel < 0)
playerXVel += 8;
}
I thought that these two statements would eventually neutralize each other and make the velocity zero, but I guess not.
That's all the code I think is necessary to post, because changing the lines inside the block to just
if(!isRightPressed && !isLeftPressed)
{
playerXVel = 0;
}
{
playerXVel = 0;
}
solves the problem but gets rid of the deceleration. How can I do this differently and fix the bug?
8
General / Re: Animated States with Thor
« on: April 15, 2013, 03:14:44 am »
Oh! He was totally animating correctly, I was just playing it too fast. It works!
Thank you so much for all of your help, it's really satisfying to have a character move around animated on the screen after so much time.
Thank you so much for all of your help, it's really satisfying to have a character move around animated on the screen after so much time.
9
General / Re: Animated States with Thor
« on: April 15, 2013, 01:02:59 am »
Thank you so much for doing that for me! <3
My animation looks messed up, but I did some tests where I made it play when I just pressed "P" and it's no better, so I think I'm looping through the frames wrong or something. It's strange because I could've swore that when I made my original post and did the same test, it looped correctly. However, I also remember from the time of my original post doing that test would have the frames reset like what I've been trying to fix when I held down "P", and now if I include a check with getPlayingAnimation it doesn't appear to reset. The problem looks unrelated.
(If any of that even made sense)
I'll post again if I can't fix it.
My animation looks messed up, but I did some tests where I made it play when I just pressed "P" and it's no better, so I think I'm looping through the frames wrong or something. It's strange because I could've swore that when I made my original post and did the same test, it looped correctly. However, I also remember from the time of my original post doing that test would have the frames reset like what I've been trying to fix when I held down "P", and now if I include a check with getPlayingAnimation it doesn't appear to reset. The problem looks unrelated.
(If any of that even made sense)
I'll post again if I can't fix it.
10
General / Re: Animated States with Thor
« on: April 12, 2013, 09:40:12 pm »
Events are what I attempted to use in the original post, no?
I tried using real-time input as a solution to that, but it ended up becoming sort of the opposite problem by making the animation play too much. I thought there was a way to use a bool to correct the problem I am having with the real-time input without using event polling. Is there?
Also that comparison tip is handy, thanks.
Howdy, I'm trying to make a sprite animate with the Thor library when I press a key and stop animating when I release it.
This is pretty easy with event polling. I just did this:while(mainWindow.PollEvent(Event))
{
...
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Right))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Right))
animator.StopAnimation();
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Left))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Left))
animator.StopAnimation();
}
//and a thing down here that stops the animation if both keys are pressed at the same time
Unfortunately, this gets totally messed up if you happen to press both left and right at the same time, and then release one of those while still holding the other. Since no new key pressed event was fired there, the sprite will be unanimated even though a key is down (therefore my sprite is sliding along without being animated).
I tried using real-time input as a solution to that, but it ended up becoming sort of the opposite problem by making the animation play too much. I thought there was a way to use a bool to correct the problem I am having with the real-time input without using event polling. Is there?
Also that comparison tip is handy, thanks.
11
General / Re: Animated States with Thor
« on: April 11, 2013, 06:17:57 am »
Big bump, I haven't been messing in SFML since I originally posted this thread but came back and tried the booleans just today. No reason to make a new thread.
I happen to be very bad at logicking out where to put booleans, so can somebody help me out?
I made a bool called "isIdle" that is initiated at the start of the program as true. I just need to know what exactly I do with it where I'm handling the animation.
I need it to be arranged so that playAnimation only gets called a single time for either of these (it calls every frame like this, resetting the animation to frame 1 as soon as the game loop cycles again), but I cannot for the life of me figure out what to do with the bool. I'm really sorry if it seems like I'm asking for you guys to write my program for me or something, but I've been sitting here trying to figure it out for a good while now and know it won't hit me anytime soon.
I happen to be very bad at logicking out where to put booleans, so can somebody help me out?
I made a bool called "isIdle" that is initiated at the start of the program as true. I just need to know what exactly I do with it where I'm handling the animation.
if(isRightPressed == true || isLeftPressed == true)
{
animator.playAnimation("walk", true);
}
if(isRightPressed == false && isLeftPressed == false)
{
animator.playAnimation("idle", true);
}
{
animator.playAnimation("walk", true);
}
if(isRightPressed == false && isLeftPressed == false)
{
animator.playAnimation("idle", true);
}
I need it to be arranged so that playAnimation only gets called a single time for either of these (it calls every frame like this, resetting the animation to frame 1 as soon as the game loop cycles again), but I cannot for the life of me figure out what to do with the bool. I'm really sorry if it seems like I'm asking for you guys to write my program for me or something, but I've been sitting here trying to figure it out for a good while now and know it won't hit me anytime soon.
12
General / Re: Animated States with Thor
« on: February 14, 2013, 03:32:23 am »
I updated MinGW, and now I finally have the newest Thor and SFML working in my project. 
It should not be too hard to do what I wanted to do with the animations now, but I will post in this thread again if I really can't figure it out.
By the way, is there no longer a specific default animation for Thor's animator class that plays when stopAnimation is called?
edit: Oh, that last thing I wrote is actually breaking the idea I had on how to make this work...
I replaced the default animation with just another animation called "idle", but since idle is playing when the walk animation is not, there is technically always an animation playing and isPlayingAnimation() isn't helpful to me anymore. D:
It should not be too hard to do what I wanted to do with the animations now, but I will post in this thread again if I really can't figure it out.
By the way, is there no longer a specific default animation for Thor's animator class that plays when stopAnimation is called?
edit: Oh, that last thing I wrote is actually breaking the idea I had on how to make this work...
I replaced the default animation with just another animation called "idle", but since idle is playing when the walk animation is not, there is technically always an animation playing and isPlayingAnimation() isn't helpful to me anymore. D:
13
General / Re: Animated States with Thor
« on: February 13, 2013, 02:21:40 am »
I've never actually used CMake before but I've just learned how to make and compile the newest revisions of SFML and Thor. I got SFML alright, but when I try to compile Thor's makefile I am getting some errors. I'm not really sure if it's my fault or perhaps a bug somewhere, but I am stuck now nonetheless. Here's a screenshot:
(Sorry for kind of off-topic double post)
(Sorry for kind of off-topic double post)
14
General / Re: Animated States with Thor
« on: February 13, 2013, 12:39:14 am »
Oh, that sounds handy. Thank you!
It may still be good if somebody were to explain the original way I asked for as well, though.
It may still be good if somebody were to explain the original way I asked for as well, though.
15
General / [SOLVED] Animated States with Thor
« on: February 13, 2013, 12:06:58 am »
Howdy, I'm trying to make a sprite animate with the Thor library when I press a key and stop animating when I release it.
This is pretty easy with event polling. I just did this:
Unfortunately, this gets totally messed up if you happen to press both left and right at the same time, and then release one of those while still holding the other. Since no new key pressed event was fired there, the sprite will be unanimated even though a key is down (therefore my sprite is sliding along without being animated).
The alternative to polling is the real-time input or w/e, but since that calls every frame, it'll screw up animator.PlayAnimation by calling it over and over while the key is pressed and restarting the animation before it even has time to reach its second frame.
I know I can do some fancy boolean state stuff to fix this (e.g. have some bool called isWalking or something, and do some things with it to circumvent a continuously restarting PlayAnimation call), but I can't logic it out myself.
Can you help a brother out?
This is pretty easy with event polling. I just did this:
while(mainWindow.PollEvent(Event))
{
...
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Right))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Right))
animator.StopAnimation();
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Left))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Left))
animator.StopAnimation();
}
//and a thing down here that stops the animation if both keys are pressed at the same time
{
...
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Right))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Right))
animator.StopAnimation();
if((Event.Type == sf::Event::KeyPressed) && (Event.Key.Code == sf::Keyboard::Left))
animator.PlayAnimation("walk", true);
if((Event.Type == sf::Event::KeyReleased) && (Event.Key.Code == sf::Keyboard::Left))
animator.StopAnimation();
}
//and a thing down here that stops the animation if both keys are pressed at the same time
Unfortunately, this gets totally messed up if you happen to press both left and right at the same time, and then release one of those while still holding the other. Since no new key pressed event was fired there, the sprite will be unanimated even though a key is down (therefore my sprite is sliding along without being animated).
The alternative to polling is the real-time input or w/e, but since that calls every frame, it'll screw up animator.PlayAnimation by calling it over and over while the key is pressed and restarting the animation before it even has time to reach its second frame.
I know I can do some fancy boolean state stuff to fix this (e.g. have some bool called isWalking or something, and do some things with it to circumvent a continuously restarting PlayAnimation call), but I can't logic it out myself.
Can you help a brother out?
Pages: [1] 2