Messages

1

General discussions / Android and iOS ports Status

« on: July 27, 2015, 04:30:50 am »

I want to ask about the progress of these two ports. I can see Mario is working hard on them. Are either of them far enough along to start a project and put it in a store? Would you currently recommend one over the other Thanks!

2

General / Re: Several strange errors while compiling with MSVC 2015

« on: July 23, 2015, 06:08:05 pm »

I googled "universal crt" and read the msdn article (thanks for this). I now see Microsoft redesigned the cruntime for Visual Studio 2015. This can be necessary because the cruntime is both compiler and platform specific.

Now to try and answer my own question. I downloaded the SFML source and I see there is a directory named extlibs with a subdirectory name libs-msvc. Now there are libs for both 32 and 64 bit Windows. These libraries were compiled with an older version of the cruntime library, so their in-place generation of some functions will be outdated. Hence the errors. You'd need to track down the flac, freetype, jpeg, ogg, openal32, vorbis, vorbisenc, and vorbisfile source and recompile it with VS2015. Then you can build SFML with VS2015.

I am fine using VS2013 for now. I just wanted to understand what was happening. That being VS2015 has been released (it's no longer a release candidate).

3

General / Re: Several strange errors while compiling with MSVC 2015

« on: July 23, 2015, 01:06:41 am »

Its because VC14 broke the C runtime, so the C extlibs need to be recompiled.

Is anyone able to explain this with a small example? I am a bit confused as to what exactly it means.

4

Graphics / Re: Initial draws take much longer then the following

« on: May 13, 2015, 07:37:51 am »

I appreciate the responses. I now understand the issue and its insignificance. I was reading the "first draw" as the first draw of a unique object and not the first draw of the program.

To summarize the first draw of the program will do some initialization which will make this single draw slow. Each subsequent draw will not need to to the initialization and will run fast. The first draw is normally a splash screen or some other screen that is not time sensitive, so this is insignificant.

5

Graphics / Re: Initial draws take much longer then the following

« on: May 12, 2015, 09:43:54 pm »

But I doubt that was only due to the 400ms delay.

I am fairly certain this is the issue. The tutorial passes a constant time step to the update methods. Multiple time steps will be processed during the current frame if the previous frame was slow. Therefore, the ball's current position will move forward proportional to the previous frame's duration and then be drawn.

Considering the ball can move across the screen in about half a second it then follows that if the initial draws take half a second the ball will move across half the screen on the next frame before it is drawn.

Now I do understand what you are saying in regards to starting a game without user input, but I believe it is irrelevant. There are many instances were an object could be drawn for the first time and the game has not just started.

I have shown a very minimal example where a first clear followed by two draws and then a display takes nearly half a second on my computer. That seems like a fairly large chunk of time. I imagine if someone else runs the minimal code example I gave they'll report a much faster time. I think that explains the difference in behavior, but I am still surprised.

6

Graphics / Re: Initial draws take much longer then the following

« on: May 12, 2015, 05:01:24 pm »

Thanks for posting your short example. When I run your example I get the following results.

157085
1578
111925
768
91841
1373
195144
641
193948
1401
197849
679
 

I am asking this question purely from an educational point of view. The tutorial is just that, but if it was an actual game the ball would have traveled a quarter of the screen, knocked out two bricks, and ricocheted off the wall before the player could react (if they were playing on my computer).

I can work around this by doing the initial draws as part of the "initialization." That seemed weird, so I created this post.

7

Graphics / Re: Initial draws take much longer then the following

« on: May 12, 2015, 03:37:10 pm »

Thanks for the response. I have started by creating a minimal example. If I set a breakpoint on the last line of the loop the 'duration' is always 400+ milliseconds on the first iteration then the following iterations are much lower around 4-20 milliseconds.

#include <SFML/Graphics/CircleShape.hpp>
#include <SFML/Graphics/Color.hpp>
#include <SFML/Graphics/RectangleShape.hpp>
#include <SFML/Graphics/RenderWindow.hpp>
#include <SFML/System/Clock.hpp>
#include <SFML/System/Vector2.hpp>

int main()
{
        sf::CircleShape circle{10.f};
        sf::RectangleShape rectangle{{60.f, 20.f }};
        sf::RenderWindow window({800, 600}, "Minimal Example");

        while (true)
        {
                sf::Clock clock;

                // Start timing
                sf::Time startTime = clock.restart();

                // "Clear" the window from previouly drawn graphics
                window.clear(sf::Color::Black);
                window.draw(circle);
                window.draw(rectangle);
                window.display();

                // End timing
                sf::Time endTime = clock.restart();
                int duration = endTime.asMilliseconds();
                int x = 0; // Set breakpoint here
        }

        return 0;
}
 

8

Graphics / Initial draws take much longer then the following

« on: May 11, 2015, 11:23:32 am »

I have been walking through the Arkanoid in 160 lines tutorial (I don't believe knowledge of the tutorial is necessary to answer the question). I just finished the second one and started to notice my version is exhibiting some undesirable behavior. This occurs when I pass the ball and paddle function time deltas.

What happens is the first visual the player sees is further along then I would like to be. I have attached two screenshots. In the first one the ball is near the center of the screen and this is the appropriate behavior. However, in the second one the ball has already knocked out two bricks and traveled quite a bit of distance before it was ever drawn.

What I have noticed is my initial draws take a very long time compared to the following ones on the next iteration of the loop. Here is a code snippet to show what I am doing. The points of interest are where I begin timing (comment 'Start time') and finish timing ('End time').

        while (window.isOpen())
        {
                auto startFrame(std::chrono::high_resolution_clock::now()); // Start time

                sf::Event event;
                while (window.pollEvent(event))
                {
                        switch (event.type)
                        {
                                case sf::Event::Closed:
                                        window.close();
                                        break;
                        }
                }

                ball.update();
                paddle.update();

                testCollision(paddle, ball);
                for (auto &brick : bricks)
                {
                        testCollision(brick, ball);
                }

                bricks.erase(std::remove_if(begin(bricks), end(bricks),
                        [](const Brick &brick){ return brick.mDestroyed; }),
                        end(bricks));

                window.clear(sf::Color::Black);
                window.draw(ball.mShape);
                window.draw(paddle.mShape);
                for (const auto &brick : bricks)
                {
                        window.draw(brick.mShape);
                }

                window.display();

                auto endFrame(std::chrono::high_resolution_clock::now()); // End time

                // Frame duration
                auto frameTime(std::chrono::duration_cast<std::chrono::duration<FrameTime, std::milli>>
                     (endFrame - startFrame).count());
        }
 

The value of 'frametime' on the initial time through the loop takes around 400-700 milliseconds. This value will be passed to the update functions and on the next draw the ball will make a huge jump and that's the undesirable behavior I am seeing. However, after this initial frame each frame then takes around 15 milliseconds and this is very expected (as it matches the tutorial).

Also, to be clear I moved around the time points and it was clear that it was the draws were taking up the bulk of the time. I believe I understand what is going on, but I am surprised. I want to ask the following questions. Should the initial draw be significantly slower than the following ones? Also, what explains the difference in Romeo's (author of tutorial) game behavior and mine? I don't think such a simple example would exasperate the fact I may be using slower computer.

9

General discussions / Re: SFML Game Development -- A book on SFML

« on: February 10, 2015, 08:22:42 pm »

Thanks Jesper. I am using Visual Studio. I am looking into disabling debug support for iterators, but I will need to recompile all the libraries I use.

Makes me wonder what all they have to do to get a triple A title to run in debug mode.

10

General discussions / Re: SFML Game Development -- A book on SFML

« on: February 09, 2015, 06:30:53 pm »

I have been using the following methods from the book to check for collisions in my personal project.

void   checkSceneCollision(SceneNode &sceneGraph, std::set<Pair> &collisionPairs);
void   checkNodeCollision(SceneNode &node, std::set<Pair> &collisionPairs);
 

My scene graph is quite a bit larger than the scene graph used in the the book's game. However, in release my game still runs fine (200 fps), but in debug it has become nearly unresponsive ( < 1 fps). I can't use the debug mode currently. 

I could toggle the size of the scene graph for the debug and release versions, but before I do that I want to understand why this has become necessary in my simple game.

I was curious if you had any insight into this? Thanks!

11

General discussions / Re: Where can i get sprites/tiles?

« on: October 29, 2014, 03:17:11 pm »

http://opengameart.org/

12

Graphics / Re: sf::Text and Character Size

« on: October 26, 2014, 01:33:01 pm »

Alright, thanks.

13

Graphics / sf::Text and Character Size

« on: October 26, 2014, 11:54:49 am »

I am drawing the '-' character. At character size 20 it looks thicker than it does at character size 22. I have attached screenshots. I wanted to know why this happens (ex. anti-aliasing)?

14

Graphics / Re: sf::Transformable

« on: October 25, 2014, 02:47:29 pm »

I  updated Button::handler's signature from

void handler(const sf::RenderWindow& window, const sf::View& view);

to

void handler(const sf::RenderWindow& window, const sf::View& view, sf::Transformable* transformable = nullptr);

and then I am able to apply the transform to my rect

sf::FloatRect buttonRect(getPosition().x, getPosition().y, mSize.x, mSize.y);
if (transformable)
   buttonRect = transformable->getTransform().transformRect(buttonRect);

This works. Now I am wondering if my motivation to use sf::Transformable is intended. The ToggleButton class inherits sf::Transformable, because I like how it "creates" a coordinate system for that object. For instance, within the ToggleButton object I can place a Button button0 at (0,0) and then I can place Button button1 at (button0.width + buffer, 0). Then I can set the position of the entire instance of the ToggleButton object in the game world. Granted, I only care about  the position (and not rotation, scaling, etc), but is this the intended usage?

By the way, are you only using the transforms for position? Do you test something like sf::FloatRect::contains()?

Yes and yes.

15

Graphics / sf::Transformable

« on: October 25, 2014, 11:52:57 am »

I am having confusion when using sf::Transformable.

I have a class called Button that inherits sf::Transformable. My motivation to do this is I want to be able to set the position of the entire class with a single sf::Transformable::setPosition. This works.

Next, I create another class called ToggleButton that inherits from sf::Transformable and is composed of two Buttons. My motivation is the same. I want to be able to set the position of the entire class with a single single sf::Transformable::setPosition. This works.

However, I run into a problem with Button::handler(). The handler is comparing the position of the button with the position of the mouse. The problem is Button::handler() does not take into account the transform (setPosition) that occurs to ToggleButton.

When drawing the elements this is not an issue, because by inheriting from sf::Drawable I can easily apply the transform within sf::Drawable::draw with

states.transform *= getTransform();

One solution I see is for ToggleButton not to inherit from sf::Transformable. Then simply call sf::Transformable::setPosition on each Button member variable. However, I am curious to understand how I should be properly using sf::Tranformable in such situations. How do I "string" multiple transforms like this together?