46
General / Re: Collision causes problem with movement
« on: January 05, 2015, 10:34:05 pm »
This is the sort of problem that can probably be solved easily with a debugger. Have you tried using one?
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.
47
General / Re: Problem with TMX Parser
« on: January 05, 2015, 10:00:39 pm »
You need to learn how to use your toolchain. If you're building from the commandline, typically you specify the "include directories" (the folders where it'll look for header files) with a flag like -I, unless they're already in the PATH. It's often easier to simply add folders to the PATH so you don't have to remember this. If you're building from an IDE, then the project configuration menus should have an equivalent setting where you list directories for it to look in. The official SFML tutorials specify how to do this for the SFML headers with a variety of popular toolchains, and whatever it is you're using there should be guides on the internet for it somewhere.
48
General / Re: Proposal
« on: January 05, 2015, 08:31:16 pm »
I see quite a few questions on the first page of General that aren't specific to a single module or a build process, so it's not like it'll suddenly be empty...unless we start purging all the newbie questions about code structure and C++ idioms.
49
Graphics / Re: Mouse Drag Box
« on: January 05, 2015, 08:28:09 pm »
The bug is that your MouseEvents object is being created inside the game loop, so every frame you have a brand new one that doesn't "remember" anything about its previous lives, much less previous mouse events. That's why you only see the box getting drawn on the exact frames when events happen.
And exploiter is right, the code would be more readable if you went with his suggestions.
And exploiter is right, the code would be more readable if you went with his suggestions.
50
Feature requests / Re: Pixelated text
« on: January 05, 2015, 12:58:32 am »
It could also be an optional constructor argument.
51
General discussions / Re: Multi Monitor Setup
« on: January 04, 2015, 11:48:00 pm »I believe it is support create windows in more than one motinor, and have control over what is drawn on each of them.
...
Yes believe this and a feature that extends to all operating table systems.
I think we can be more precise than that. Off the top of my head, we might want to support:
- Getting the current number of monitors
- Getting the valid fullscreen resolutions of all monitors
- Getting the current desktop resolutions of all monitors
- Creating a window on any monitor (as you said)
- Moving a window to any monitor, in addition to setting its position
- Getting/setting the monitor the mouse is currently on, in addition to its position
All of which are potentially complicated by the facts that:
- There is usually a "primary" monitor, which should probably be the "default" for most purposes
- A single window can occupy space on more than one monitor at a time.
I don't have a use case for multi-monitor support personally, and I suspect a lot of the scary corner cases are handled by OS magic, so I don't know how many of those things we actually care about.
My very brief googling on the mobile question implies that the only instances of mobile "multi-display environments" would be handheld gaming devices with two screens and projector phones. I believe projector phones are dead, and we aren't planning on 3DS support anytime soon, so mobile might not be a problem.
52
Audio / Re: sf::Music play() and pause() bug?
« on: January 04, 2015, 10:25:15 pm »
That looks like a good candidate for a regression test, though I'm not sure if the unittest branch is meant to include slightly "fuzzy" tests like this or not.
53
General / Re: Diagonal movement with fixed speed
« on: January 04, 2015, 09:54:55 pm »
- A lot of initial event handling code is in your Ship class, whereas all of it should be in the pollEvent() loop. It's common for that event handling to involve calling methods on Ship, or set variables that are later result in calls to Ship methods, but Ship itself should not be the one checking which mouse buttons or keys are being pressed. That's coupling your Ship entity far too tightly to your game loop/input logic. Specifically, your Ship really doesn't need direct access to your Window and Event objects (except in the draw() method where it needs a window to draw itself on).
- You were mixing event-based input and real-time input, which is never good because those represent two fundamentally different ways of handling input that don't make sense together. You'll see a lot of other threads on this forum where we tell newbies not to do that. If you don't know what that means, I'm specifically referring to one of the Ship methods doing this:
- You were using real-time input (isButtonPressed) to determine if the player's Ship was selected or not. You almost certainly want to use event-based input if the goal is to select something in reaction to a click. With real-time input you may miss clicks (if one frame takes too long), react to a single click multiple times (if it takes multiple frames), or any number of other strange issues.
- Arguably the most serious: Your movement logic doesn't appear to contain any attempt at calculating how much the Ship should move during this one frame (it just calls setPosition() on the final destination) and yet you were expressing surprise at the fact that "it just teleports there instantly", which indicates a serious conceptual issue of some kind. I figured showing you an update() method that handled this properly would be the fastest way to clear up the confusion.
Those are the really big ones anyway.
- You were mixing event-based input and real-time input, which is never good because those represent two fundamentally different ways of handling input that don't make sense together. You'll see a lot of other threads on this forum where we tell newbies not to do that. If you don't know what that means, I'm specifically referring to one of the Ship methods doing this:
if( (event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::M) ) { // event-based input
}
if( sf::Mouse::isButtonPressed(sf::Mouse::Left) ) { // real-time input
}
What you want to do is have a pollEvent() loop that deals with all of the pending events (remember there may be several), and then move on to any real-time tests you need afterward.}
if( sf::Mouse::isButtonPressed(sf::Mouse::Left) ) { // real-time input
}
// event-based input
while (window.pollEvent(event)) {
if( (event.type == sf::Event::KeyPressed) {
} else // other types of events
}
// then real-time input, if needed
if( sf::Mouse::isButtonPressed(sf::Mouse::Left) ) { ... }
while (window.pollEvent(event)) {
if( (event.type == sf::Event::KeyPressed) {
} else // other types of events
}
// then real-time input, if needed
if( sf::Mouse::isButtonPressed(sf::Mouse::Left) ) { ... }
- You were using real-time input (isButtonPressed) to determine if the player's Ship was selected or not. You almost certainly want to use event-based input if the goal is to select something in reaction to a click. With real-time input you may miss clicks (if one frame takes too long), react to a single click multiple times (if it takes multiple frames), or any number of other strange issues.
- Arguably the most serious: Your movement logic doesn't appear to contain any attempt at calculating how much the Ship should move during this one frame (it just calls setPosition() on the final destination) and yet you were expressing surprise at the fact that "it just teleports there instantly", which indicates a serious conceptual issue of some kind. I figured showing you an update() method that handled this properly would be the fastest way to clear up the confusion.
Those are the really big ones anyway.
54
General / Re: Diagonal movement with fixed speed
« on: January 04, 2015, 08:34:47 pm »
What I see in that code has a lot of conceptual errors and architectural problems that will prevent your program from ever working properly (mixing events and real-time input, doing top-level event processing outside of the main pollEvent loop, trying to implement a fixed speed using a fixed duration, etc), so rather than trying to tweak what's there I'll start over and give you a skeleton of how this code should be organized because I think that would be a lot faster for everyone.
I'll be basing this on descriptions you've given in the previous threads about wanting Dota-style movement where pressing the movement key makes the player start moving towards the current mouse position, which they continue moving to at a fixed speed until they either reach it or are given a new destination.
Your main() should have a loop that looks something like this:
The actual movement should be done entirely in the update method, and nowhere else. It should look something like this:
There are loads of corner cases and eventualities I'm not even trying to deal with here, and obviously it won't quite compile as-is since I'm writing this off the top of my head, but this is how your movement code should be structured in relation to the rest of the program.
I'll be basing this on descriptions you've given in the previous threads about wanting Dota-style movement where pressing the movement key makes the player start moving towards the current mouse position, which they continue moving to at a fixed speed until they either reach it or are given a new destination.
Your main() should have a loop that looks something like this:
while(window.isOpen()) {
sf::Event event;
while(window.pollEvent(event)) {
if(event.type == sf::Event::MouseButtonPressed) {
if(event.mouseButton.button == sf::Mouse::Left) {
sf::Vector2i mousePos(event.mouseButton.x, event.mouseButton.y);
if(playerShip.contains(mousePos)) {
playerShip.isSelected(true); // I'll let you decide when it should be unselected
}
}
} else if(event.type == sf::Event::KeyPressed) {
if(event.key.code == sf::Keyboard::M) {
playerShip.setMovementTarget(sf::Mouse::getPosition(window)); // if a target already exists, it gets overridden
}
} else // handle other events
}
sf::Time deltaTime = clock.restart();
playerShip.update(deltaTime); // we'll worry about fixed timesteps later
window.clear();
playerShip.draw(window);
window.display();
}
contains(), isSelected() and setMovementTarget() should be trivial to implement. I'll assume the Ship class gets its draw method for free since it inherits from sf::Sprite.sf::Event event;
while(window.pollEvent(event)) {
if(event.type == sf::Event::MouseButtonPressed) {
if(event.mouseButton.button == sf::Mouse::Left) {
sf::Vector2i mousePos(event.mouseButton.x, event.mouseButton.y);
if(playerShip.contains(mousePos)) {
playerShip.isSelected(true); // I'll let you decide when it should be unselected
}
}
} else if(event.type == sf::Event::KeyPressed) {
if(event.key.code == sf::Keyboard::M) {
playerShip.setMovementTarget(sf::Mouse::getPosition(window)); // if a target already exists, it gets overridden
}
} else // handle other events
}
sf::Time deltaTime = clock.restart();
playerShip.update(deltaTime); // we'll worry about fixed timesteps later
window.clear();
playerShip.draw(window);
window.display();
}
The actual movement should be done entirely in the update method, and nowhere else. It should look something like this:
void Ship::update(sf::Time deltaTime) {
if(m_isSelected && m_movementTargetSet) {
sf::FloatRect spriteBounds = getGlobalBounds();
if(spriteBounds.contains(m_movementTarget)) {
m_movementTargetSet = false; // we've arrived, so we can stop moving now
} else {
// the remaining movement the Ship has to do before stopping
sf::Vector2f movement = getPosition() - m_movementTarget;
// normalize that movement so we get a unit vector representing our current direction (we could use thor::unitVector() here)
double length = sqrt(movement.x * movement.x + movement.y * movement.y);
sf::Vector2f direction(movement.x / length, movement.y / length);
// given our current direction and a fixed speed, we now move the appropriate distance for this frame
sf::Vector2f movementStep = direction * deltaTime.asSeconds() * PLAYER_SPEED;
setPosition(getPosition() + movementStep);
}
}
}
if(m_isSelected && m_movementTargetSet) {
sf::FloatRect spriteBounds = getGlobalBounds();
if(spriteBounds.contains(m_movementTarget)) {
m_movementTargetSet = false; // we've arrived, so we can stop moving now
} else {
// the remaining movement the Ship has to do before stopping
sf::Vector2f movement = getPosition() - m_movementTarget;
// normalize that movement so we get a unit vector representing our current direction (we could use thor::unitVector() here)
double length = sqrt(movement.x * movement.x + movement.y * movement.y);
sf::Vector2f direction(movement.x / length, movement.y / length);
// given our current direction and a fixed speed, we now move the appropriate distance for this frame
sf::Vector2f movementStep = direction * deltaTime.asSeconds() * PLAYER_SPEED;
setPosition(getPosition() + movementStep);
}
}
}
There are loads of corner cases and eventualities I'm not even trying to deal with here, and obviously it won't quite compile as-is since I'm writing this off the top of my head, but this is how your movement code should be structured in relation to the rest of the program.
55
Audio / Re: Failed to open sound file "music.ogg" (Error : flac decoder lost sync.)
« on: January 04, 2015, 07:11:53 pm »I have some compatibilities problems xP
Could you elaborate? The minor versions of SFML definitely aren't ABI compatible, but that shouldn't affect anyone developing new code.
56
Graphics / Re: Font Aliasing
« on: January 04, 2015, 06:05:21 pm »The compile part looks a bit complicated
In my personal experience as a newbie, it's actually slightly easier to build SFML myself than trying to use the pre-built libraries, especially on Mac/Linux where the dev environment is much harder to misconfigure. Your mileage may vary.
57
General discussions / Re: Multi Monitor Setup
« on: January 04, 2015, 11:25:59 am »
I believe http://www.sfml-dev.org/development.php has all the information you need to get started with contributing, including a code style guide and contribution guidelines and whatnot.
58
Audio / Re: Failed to open sound file "music.ogg" (Error : flac decoder lost sync.)
« on: January 04, 2015, 03:59:05 am »
The sf::Music object called "music" never has loadFromFile called on it, so I wouldn't be surprised if you aren't hearing that one.
The one called "lalala" has play() called on it in the render() method every frame, which is very strange and definitely unnecessary, though it doesn't seem like that should cause any problems.
Also, it has been waaaaay too long since I studied Spanish. Seeing "ventana" refer to a GUI window instead of a physical window on the side of a house just looks weird to me.
The one called "lalala" has play() called on it in the render() method every frame, which is very strange and definitely unnecessary, though it doesn't seem like that should cause any problems.
Also, it has been waaaaay too long since I studied Spanish. Seeing "ventana" refer to a GUI window instead of a physical window on the side of a house just looks weird to me.
59
General / Re: Simultaneous Drawing/Rendering
« on: January 04, 2015, 03:35:28 am »
If it's unrelated best to put it somewhere else. PM if you think 1-on-1 would be more constructive, thread if you think multiple pairs of eyeballs would help.
60
Audio / Re: Failed to open sound file "music.ogg" (Error : flac decoder lost sync.)
« on: January 04, 2015, 12:41:05 am »
This could be as simple as a corrupt music file. Could you upload your music.ogg?