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

Pages: [1] 2 3 ... 8
Yes, you can. Usually using a vector is enough for most cases, but you could use lists or maps as well if needed, just make sure that you know the differences between them, as each have both advantages and disadvantages. If you are just starting out, I advice just using vectors, as they are pretty straightforward.

It's true that the elements are destroyed when the container goes out of scope, but that's the case for any variable, so I don't really see the problem. You just need to make sure to declare your vector/list/map in the appropriate scope, like in your main, for example, and the elements shouldn't be destroyed until your game is closed.

The white square problem happens when your sprite is using a texture that no longers exists, so it's not a problem about the STL containers per se, but more about scope/lifetime. Take the following example:

int main() {

    sf::Sprite sprite;

    int number = 1;

    if (number == 1) {
        sf::Texture texture;


The code above will produce the white square problem because the texture is declared inside the "if" statement, so when the code inside the brackets ends, the texture will no longer exists, and you'll get a white square when you draw your sprite.

If you do the following instead:

int main() {

    sf::Texture texture;
    sf::Sprite sprite;

    int number = 1;

    if (number == 1) {


Then it's not a problem, the texture won't get destroyed when the "if" statement ends due to being declared outside of it. The same applies if you are using a vector of textures, or a class, or anything, really.

As to why your particular code doesn't work, I can't really say anything because I'm not familiar with maps, and besides, you only provided us the code of your class, but not the code where you actually use it. However, I can say that you seem to be overcomplicating yourself by using an static instance. I'm no expert at C++, but that looks like bad design, and it seems like it would bring tons of trouble. Maybe your problem is related to that.

Graphics / Re: One sprite for all my objects
« on: June 24, 2017, 06:34:07 am »
Don't do that, just use one sprite per object. There's no problem in having many sprites, that's what they are for.

You should do that with your textures, though, because textures use more resources. Try to use only one texture for all your sprites, and to achieve that don't have a texture inside your class, but rather create your textures outside and just pass them to your "Load_Sprite()" method.

Something like this:

class Object {

        sf::Sprite mySprite;

        void load_sprite( sf::Texture & externalTexture ) {

            // It receives the texture externally as a parameter.
            // Don't forget to use the "&" symbol, meaning that
            // you are passing the texture "by reference".
            // (If you don't know what this is,
            // I strongly recommend reading about it).

            mySprite.setTexture( externalTexture );



int main() {

    // You load your textures externally, NOT inside your class.

    sf::Texture myTexture;

    // You make instances of your class,
    // and you pass your textures as necessary.

    Object myObject;
    myObject.load_sprite( myTexture );

    Object anotherObject;
    anotherObject.load_sprite( myTexture );

    Object thirdObject;
    thirdObject.load_sprite( myTexture );



SFML projects / Re: Cendric: An RPG Platformer
« on: May 30, 2017, 07:53:44 pm »
Congratulations! ;D

Graphics / Re: Tile Map
« on: May 29, 2017, 07:35:11 pm »
Hmm...something is not right the window opens for a second and it closes

You have to put your logic and drawing code inside a loop. Also, you are polling the events incorrectly. It should be like this:

#include <SFML/Graphics.hpp>
using namespace sf;

int main()

    // Your variables, like windows, textures and sprites, go outside the loop.
    RenderWindow window(VideoMode(800,600),"Platformer");

    // Then you start the game loop.
    while( window.isOpen() )

        // First you poll the events inside ANOTHER loop.

        Event event;
        while ( window.pollEvent(event) )

             // The following should be "if", not "while" as you put in your code.
             if( event.type == Event::Closed )  


        // Now you do the rest of your code.

            pos.y -= 5;

        // Finally you draw.

        window.clear( sf::Color::White ) // You have to clear the window first, you forgot about this.

        for(int i = 0;i<4;i++)
            for(int j = 0; j<5;i++)
            if(mapArray[i][j] == 1)
                STileGrass.setPosition(i * 70, j * 70);




I really recommend reading and understanding the tutorials, otherwise you'll run into problems every five minutes, and we won't always be able to help you in time.

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: May 21, 2017, 12:21:05 am »
Your looks cooler and cooler every day. :)
Love how the text looks with that effect, the whole "paper" stylistics is executed very well. :D

I really love this project, and follows it religiously.. reminds me of all the "games" we made back in the school years (age 10+ i guess)

So much imagination and such awesome presentation!

Thanks guys, I'm flattered!

One question, the shadows (in your video above) are all the same offset from the objects that cast them.
Have you considered dynamic distance? so the helicopter will cast a shadow higher up. misiles shadows will change distance as the get near the ground?
(okay, last one will require they know where/what they will hit.... but that could be done with ray casting)

That's a neat idea, I love little details like that, but the thing about projectiles is that they can hit other helicopters too, so it wouldn't make much sense to make them look like they are going to the ground. Besides, even things on the ground, like buildings, cast shadows too, so even if I make dynamic shadows for the projectiles the difference with the offset wouldn't be much, being barely noticeable.

The point of the shadows is primarily to let the player differenciate between the interactive stuff (shadows) and the background (no shadows).

Thanks for the suggestion, though!

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: May 20, 2017, 01:33:10 am »
Hello everyone. Just making a small update.

I've been making a "ransom text" class for the game. So far looks like this:

To make this I needed two classes: one class that creates a single sf::Text with a paper background (which was previously done, I've been using it for most of the HUD already), and another class that holds several instances of the previously mentioned class while also managing the random colors, random fonts, rotations and everything in order to create the whole text and place it on screen.

I had to manually make a list of background/font color pairs to avoid situations where I could randomly get backgrounds and fonts of the same color. The rest of the properties are generated at random, which includes size, rotation and font, with the latter being chosen from a pool of four different public domain fonts that I found.

The whole thing still needs some tweaking, but so far I'm liking the results.

I'm planning on using this for the little cutscene at the beginning of each mission. For reference, check the video a few posts back: at the very beginning there's a little cutscene with the helicopter sideways and the name of the mission pops up at the right side. Imagine that text but with the ransom text style.

Besides the text, I also made a rain effect, which as of now looks like this:

More and more rain drops appear over time. The screen will get slightly darker depending of the amount of drops as well. Keep in mind that I made the transition much faster in the GIF to keep it brief.

Back from the days when I wanted to make an open world game, I made a Map class that loads stuff on screen in an array of 3x3 "chunks" of 2000x2000 pixels each. So, for instance, if the camera moves to the right, the game unloads the column of chunks on the left and loads a new column on the right, and so on. Same applies to rows.

The following old, crappy gif explains the idea. The cross represents the center of the camera, which follows the player:

As the chunks are big enough, the unloading/loading happens off-screen, so you don't notice it while playing.

So, for the rain effect, I simply re-used this Map class, but I made it so the camera always moves up at a constant speed, creating the illusion that the drops are falling, and most importantly, forcing the unloading of the bottom row and the loading of the top row every few seconds. At the same time, using a clock I modify the data that the Map class looks up to when it loads a chunk, so that new loaded chunks contain a different amount of rain drops. At first, a whole chunk only contains one drop, but over time it contains four, then nine, and slowly continues to over a hundred.

It sounds complicated for such a simple effect, but I made it this way to use what I already had, avoiding writing new code. It works so far, but just like the ransom text class, it still needs some tweaking to do.

Besides those two things I haven't made much progress, because lately I've playing GTA Online non-stop. I'm not obsessed at all, I swear...

Help! :'(

Graphics / Re: Get Image of rotated sprite
« on: May 13, 2017, 11:36:04 pm »
Check this line:

Image img = sprite.getTexture()->copyToImage();

You are getting an image of the texture of the sprite, not an image of the rotated sprite itself. That's why it's not working.
What you could try is to render the sprite on a RenderTexture, and get the image from there. Something like the following:

// ...

int width = sprite.getGlobalBounds.width;
int height = sprite.getGlobalBounds.height;

sf::RenderTexture renderTexture;
renderTexture.create( width, height );
renderTexture.clear( sf::Color::White );
renderTexture.draw( sprite );

sf::Image img = renderTexture.getTexture().copyToImage();

// Rest of your code here...

I haven't tested the code, so there may be some errors.

Let me know how it goes.

General / Re: Jump height varies slightly
« on: May 13, 2017, 05:45:27 pm »
I don't know if it's related to the problem or not, but this caught my attention:

        while (window.isOpen()) {
                if (gameIsClosing == false) {
                        if (accumulatedTime >= frameRate) {
                                game.update(&window, accumulatedTime);
                                accumulatedTime -= frameRate;

You are passing "accumulatedTime" to your update function. Shouldn't you pass "frameRate" instead?

General / Re: How can I show a vector of sprites?
« on: May 03, 2017, 07:32:11 am »
In Game.cpp, shouldn't it be "int i = 0" instead of "int i" in the forloop, or was that just a typo?

for (int i; i<5; i++){  

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: April 19, 2017, 06:11:35 pm »
Is it on Steam Greenlight already? Don't remember. But I'd say that "gameplay video" should be enough to get the game greenlit in no time. :)

Wow, that's a huge compliment, thank you.

No, it's not on Greenlight. Honestly I don't feel confident enough to do so, I feel like the game is gonna get destroyed in the comments (I've seen other greenlight projects and the comments can be absolutely vicious :o).

Besides, I barely have "presence" online, and as far I'm aware (reading post-mortems and stuff like that), most of the votes from Greenlight don't come from within the site itself, but from external sources. If I just post the game there, it'll probably just get ignored.

That, and also Greenlight is getting shut down soon, so it complicates things a little bit.

I'm still on the fence about it.

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: April 18, 2017, 05:30:28 pm »
awesome, i really like your work.

Thanks man, glad that you like it :D

I love the dog part  and the self-destruct button :D I hope that you will keep things like these in the release.

First of all, thanks a lot. I was a little nervious about the vid, because it's the first time that I upload a proper gameplay video showing a full level, so I'm glad about the positive comments so far, thanks a lot.

Yeah, I want to make each level to have little fun "moments", so to speak. In the video it's the dog, the volcano, the little guys that are indeed worshipping the ammo box, things like that. Those moments are not necessarily laugh-out-loud funny, and frankly that's not my goal, I just want those moments to make each level somewhat different from each other, to reward exploration and hopefully crack a smile in the process.

(I'd probably work a bit on the dialogues though, they could really make the game more fun. I understand however, that the dialogues featured in the video are just a temporary placeholder until the real ones come)

Oh, man, the dialogue. To me that's the biggest challenge in making the game. I've never written anything in my life, and english is not my native language, so it's pretty hard to me to write decent dialogue.

The game is supposed to have three characters, codenamed Blue, Red and Green, that are playing the paper game, and they have dialogue popups on different parts of the screen with their respective color, so I need to write some good banter (which requires wit, which I lack) while also making each character have their own distinctive personality.

So far, the only things that are well defined is that Blue and Red are kids while Green is an adult that is invited to the game. Green is grumpy and thinks that the game is stupid; Red is a tomboy that enjoys destroying everything, and Blue, the youngest, is the only one who can break the fourth wall. Besides that, I'm still trying to define their personalities, and only after that I can start writing the "real" dialogue, but even right now with blank personalities is extremely difficult for me to write the lines.

Writing code seems trivial in comparison :P, so I'll be grateful for any pointers regarding the writing.

Anyways, thanks for passing by, glad that you guys like it!

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: April 17, 2017, 06:53:24 pm »
Hey, I made a new video if you guys are interested. It shows a full mission, with a set of objectives, dialogue popups, getting items and so on, all the way to the end.


The mission (or level or whatever you want to call it) was specifically made for the video, so it's a little bit rehearsed, but I want the real missions to be similar, although a little longer, with bigger maps and not as linear as in the video, but overall with the same structure: get a set of objectives that you can complete in any order, shoot stuff, get items, and then go home.

It was supposed to be a short video but it ended up being 4 minutes long without realizing it, but hey, at least it represents the overall gameplay well enough, so people can know what to expect, and now I can focus on making shorter, more specific videos in the future, like showing an specific enemy, a new weapon, things like that.

In the last few months I felt that I wasn't making enough progress, but now that I watch this video and the older ones back to back, the game indeed feels different. I still have a lot of stuff to do, though.


General / Re: Stuttering on windowed mode
« on: April 15, 2017, 01:27:21 am »
Wow, I made a build from the master branch and it was fixed, just like that. :o

The stuttering is gone with Vsync, even if windowed. There's some stuttering without Vsync, which I'm sure it's not tearing, but it's much less jumpy than before, it only fluctuates between 62 and 68 frames, so it's ok. The best thing is now that Shadowplay doesn't cause stuttering no more, so now I can record! I could record fine with Fraps and OBS, but my game has a bug that makes most letters in texts missing while recording for some bizarre reason, but that's a topic for another day.

I did read about that joystick issue, but I could've sworn it was already fixed in 2.4.2, how silly of me.

Thanks a lot! ;D

General / [Solved] Stuttering on windowed mode
« on: April 14, 2017, 10:56:04 pm »

I hate to ask, but this has been bothering me for months and I still can't find a solution on my own.

I experience stuttering every second or so on my desktop (Win 7, i5 3.0 ghz, GeForce 780, 8 GB RAM), but only if I run the application on a window that's smaller than the desktop resolution. In other words, it works smoothly either at fullscreen or on a borderless window the same size as the desktop, but smaller windows get stutter, borderless or not. This happens either with Vsync or or off, or with a fixed or variable timestep. 

Weirdly enough, I don't experience this on my much less powerful laptop (Surface Pro 2, with Intel Integrated Graphics).

At first I thought it was a problem with my project, but then I realized that it also happens with the following minimal code. It draws a circle shape on screen and uses the A and D keys to move the view left and right respectively, which makes the stutter noticeable.

int main() {

    // Options.

    int resolutionX = 1920;
    int resolutionY = 1080;

    bool fullscreen = false;
    bool borderless = false;

    bool vsync = true;

    bool unlimitedFrames = false;
    bool variableTimestep = false;

    bool printFPS = true;

    // Create window.

    int style = sf::Style::Default;

    if (fullscreen)
        style = sf::Style::Fullscreen;

    else if (borderless)
        style = sf::Style::None;

    sf::RenderWindow window( sf::VideoMode(resolutionX, resolutionY), "Frame Test", style );

    if (vsync)
    else if (unlimitedFrames)

    // Shape.
    sf::CircleShape shape(100.f);

    // Game loop.
    sf::Clock frameClock;
    float frameTime = 0;

    while ( window.isOpen() ) {

        // Poll events.
        sf::Event event;
        while ( window.pollEvent(event)) {

            if (event.type == sf::Event::Closed)

        // Close window with either ESC or Delete.
        bool esc = sf::Keyboard::isKeyPressed( sf::Keyboard::Escape );
        bool del = sf::Keyboard::isKeyPressed( sf::Keyboard::Delete );

        if (esc || del)

        // Move camera with keyboard.
        bool left = sf::Keyboard::isKeyPressed( sf::Keyboard::A );
        bool right = sf::Keyboard::isKeyPressed( sf::Keyboard::D );

        if ( left || right ) {

            float movement = 1000;
            if (left)
                movement *= -1;

            if (variableTimestep)
                movement *= frameTime;
                movement *= 1 / 60.0;

            sf::View view = window.getView();
            view.move( movement, 0 );

        // Draw.

        // Get frame time, just in case.
        frameTime = frameClock.restart().asSeconds();

        if ( printFPS ) {

            int framesPerSecond = 1 / frameTime;
            std::cout << framesPerSecond << "\n";



    return 1;


Unfortunately I couldn't record the stuttering, because Shadowplay itself also causes stutter, even at fullscreen, and recording with Fraps kind of stops the stuttering a little bit for some reason. However, I found a similar topic (https://en.sfml-dev.org/forums/index.php?topic=16449.0) which has the following video that perfectly describes my problem:

Some considerations:

- As mentioned, it happens either with Vsync on or off. I have Vsync enabled in my Nvidia Control Panel. It also happens if I force Vsync on it.
- I have "Threaded optimization" disabled in the control panel. Doesn't make a difference.
- I don't have F.lux installed. I did have it months ago, but I unistalled it, restoring Windows default color settings.
- I just updated to SFML 2.4.2, but the problem persists. I also updated my Nvidia drivers, but no dice.
- Recording with Shadowplay (or enabling it to always record the last 5 minutes) causes the stutter to happen even at fullscreen, as mentioned. It only happens with SFML; I can record other games smoothly.
- Fully disabling Shadowplay doesn't make a difference.
- It happens both on my 720p monitor or my 1080p TV.
- I don't get stutter on other non-SFML games. I haven't tested other people SFML games, though.

Finally, in the code snippet above you can print the FPS counter in the console, getting interesting numbers. I'm aware that this affects performance, but the stutter happens even without doing it.

With Vsync, it usually prints the following sequence: ..., 59, 60, 59, 60, 59, 31, 190, 59, 60, 59, 60..., every second or so. It usually prints 30 or a very close number first, and then prints a high number like 150, 200, sometimes even 500.

Without Vsync, limiting it to 60 frames per second, it usually prints the folllowing sequence: ..., 62, 62, 62, 62, 62, 30, 62, 62, 62..., every second or so. It usually is 30 or some very close number.

On fullscreen, with or without Vsync, it prints: 59, 59, 59, 60, 59, 59..., as expected. It looks very smooth.

Honestly, I'm baffled, I have no idea what's causing it. Probably it's something on my end, but unfortunately I'm not knowledgeable enough to guess what exactly is happening.

Thanks in advance for any help.

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter
« on: April 04, 2017, 07:34:44 am »
Nice to see this game still going strong!

I've not commented before but I have to say I really really like the paper cut outs art style. It's very stylish, unique and looks SO well in motion on the gifs.

I know I've said this thousands of times, but I'm not good at making assets, I'm not a game artist at all, so I'm really glad that you guys like the art style, as simple as it is. So thanks a lot, guys ;D.

Nowadays I've been working on making a video, and it's taking me more time that I thought it would take (yeah, what a surprise). In the meantime I made a little GIF at 1080p 60 FPS. I don't know if I can embed it here, so I'll just leave the link: https://gfycat.com/HoarseSmoggyDolphin


Pages: [1] 2 3 ... 8