Topics

1

SFML projects / GameStateMayhem

« on: September 15, 2016, 05:27:27 pm »

Hi all!

In February this year I have finished my first ‘big’ project  -  the program that has 3 games in it. The goal of the progam at that time is that I wanted to get aquainted with the program and game states, hence the name. But then it evolved into a full project, and I was using it to implement the ideas for every game on the list. I have already put the screenshots of the prototype last year.

The program was an interesting learning experience for me, in it I kinda learned the basics of game (and generaly the program) flow, resources loading and unloading, draw priorities, rudementary user interface etc…

Unfortunetaly, as the program grew larger, so did the code. Since the code was written in veeery amateurish way, it quickly became unwieldy to add new things or to fix things without breaking the code. So in the end, I decided to call it a day and put the final punctuation.

I originaly wanted to share the code and program in order to get feedback on which part of the code I should work on to improve, but I decided not to because I realised that would most probably mean everything. After that, I have decided to hit the books, internet articles and other people’s open-source code to continue educating myself in neat code design, which is the hallmark of my next big project.

After months of completion of my first project, I have decided to share it, because ultimately, the program does work well... mostly well. And I am interested what you guys think. Personaly, for a novice programer with no formal education in progaming, I do believe that finishing this is quite an important milestone.

Here is the dropbox link to the game: https://www.dropbox.com/s/rslmqq2pj9xx574/GameStateMayhem.rar?dl=0
Still I am hesistant to share the code, but I might do so in next few days (just to get familiar with github). 

Also, here are some screenshots:

Edit: Here is link to the source code, in case you want to take a look on it. (It's awful, you have been warned   )
PS: It uses SFML 2.3.2 version.
https://github.com/Braximus/GameStateMayhem

2

General / My petty dillema: Separation of graphical drawing of UI objects

« on: June 03, 2016, 09:12:29 pm »

In my new project, I have started to seperate the graphic drawing from the ingame objects ( i.e. an object contains the position, size, velocity ect... and a Graphic class contains sf::sprite)

My dillema is, does the same code design should also apply to the UI objects, like mostly stationary buttons and labels?

I can understand such logic for game objects, where they would get constantly updated and changed and should not be burdened by all the drawing components, but for UI objects, I do not view them as complex enteties, and I wonder should they contain the drawing components and draw themselves?

Sorry if the question is kinda noobish to you guys.

3

General / [SOLVED]"Pure Virtual Function Called" - problem while drawing

« on: November 01, 2015, 11:04:16 pm »

Hi!

First of all, I am sorry for posting a general C++ question, but the origin of the problem made me believe that this would be the best place. I also searched the forum and web, but didn’t found satisfying solution or guideline (or I just suck at searching ).
Also bear in mind that I am inexperienced in C++, (but learning new things steadily  )

Basically, I am making use of polymorphism during drawing.
I made a abstract base class (derived from sf::Drawable and sf::Transformable) and several derived classes. The objects from derived classes are updated, but not drawn.
Then I made a special deque in which are stored raw pointers of base class. These pointers point to the objects of derived classes and are used for drawing.

So instead of writing something like this:

window.draw(object_1);  //  object of derived class 1;
window.draw(object_2);  //  object of derived class 2;
window.draw(object_3);  //  object of derived class 3;
window.draw(object_4);  //  object of derived class 4;
for (const auto& it: cont_1)  // container of X objects of derived class 5;
   window.draw(it);
for (const auto& it: cont_2)  // container of Y objects of derived class 6;
   window.draw(it);
// Now imagine that there are additional 50 more derived classes with at least one object below.
 

I can write it like this:

for (const auto& it: cont_of_pointers)  // container of X pointers of the base class that point to objects derived classes;
   window.draw(*it);
 

Neat! 

When object is no longer useful and won’t be used any time soon. I need to delete it. Therefore, I need to delete both the pointer pointing to that object from the array and the object itself during runtime.

The deletion goes smoothly, but the program crashes when it starts drawing objects, with the message “R6025 – Pure Virtual function called”. The error seems to refer to a draw function inside sf::Drawable, which is the main reason why I posted topic on this forum.

The problem now is, what I managed to figure out, is that when I delete the object itself, the problem occurs. If I delete only the pointer, it works, but the object itself is still inside the memory and program takes him into account when dealing with logic, it is simply invisible because it is no longer being drawn.

(Maybe the lambda expression is the problem… I started using them just recently, thought I should point that out.  )

So my questions are:
1. What should I do in order to prevent the pure virtual function call in this method for drawing?
2. Should I even draw like this in the first place?
3. How is this error even possible? There are no dangling pointers nor calls to a pure virtual functions inside my base class constructor/destructor and the compiler won’t even run the program if there is a call to a pure virtual function somewhere else in the code, as far as I know.

Here is complete and minimal example that reproduces the problem:

(click to show/hide)

#include "SFML\Window.hpp"
#include "SFML\System.hpp"
#include "SFML\Graphics.hpp"

#include <algorithm>
#include <deque>


//      Base object
class Object : public sf::Drawable
{      
public:
        virtual void draw(sf::RenderTarget&, sf::RenderStates) const = 0;
        bool is_deleted;
};

//      Derived object
class Square : public Object
{
        sf::RectangleShape square;
public:
        Square(sf::Vector2f position)
        {
                square.setFillColor(sf::Color::Green);
                square.setSize(sf::Vector2f(20, 20));
                square.setPosition(position);
                is_deleted = false;
        }

        void draw(sf::RenderTarget& target, sf::RenderStates state) const
        {
                target.draw(square, state);
        }
};

int main()
{
        sf::RenderWindow window(sf::VideoMode(800, 600), "Test", sf::Style::Default);
        sf::Event eve;

        //      Initialising objects and putting them into containters
        std::deque<Square>      square_deque;
        Square square_1(sf::Vector2f(100, 25));
        square_deque.push_back(square_1);
        Square square_2(sf::Vector2f(100, 50));
        square_deque.push_back(square_2);
        Square square_3(sf::Vector2f(100, 75));
        square_deque.push_back(square_3);

        //      Seperate deque that contains pointers of base class - pointers take adresses of derived objects and are stored for later drawing.
        //      Doing so, I can store different types of objects into the deque who share the same parent class.
        Object* ptr;
        std::deque<Object*>  objects_for_draw;
    for (unsigned int i = 0; i < square_deque.size(); ++i)
        {
                ptr = &square_deque.at(i);
                objects_for_draw.push_back(std::move(ptr));
        }

        while (window.isOpen())
        {
                while (window.pollEvent(eve))
                {
                        if (eve.type == sf::Event::Closed)
                                window.close();
                        if (eve.type == sf::Event::KeyPressed)
                        {
                                if (eve.key.code == sf::Keyboard::Space)
                                {
                                        //      When space is pressed, the second square is marked for deletion.
                                        //      Then the object is being  evaluated in lambda expression whether the 'is_deleted' bool true.
                                        //      If it is, then it's removed from both deque containters.
                                        square_deque.at(1).is_deleted = true;
                                        objects_for_draw.erase(std::remove_if(objects_for_draw.begin(), objects_for_draw.end(), [&](Object* param) { return param->is_deleted; }), objects_for_draw.end());
                                       
                                        //      Here is a second deque container from which the object should be removed.
                                        //      Unfortunetaly, when it is removed, the " Pure virtual function call" error occurs later.
                                        //      When this is commented out, the program runs fine - but object still exists and can interact. It is simply not drawn anymore
                                        square_deque.erase(std::remove_if(square_deque.begin(), square_deque.end(), [&](Square param) { return param.is_deleted; }), square_deque.end());
                                }
                        }
        }
                window.clear(sf::Color(63,63,63,255));
                for (const auto& it : objects_for_draw)
                        window.draw(*it);               //      The program breaks here (or at least the breakpoint points here), with error message "R6025 - Pure virtual function called"
                window.display();
        }      
        return 0;
}
 

4

General / Printscreen key and SFML

« on: July 26, 2015, 11:20:27 am »

Hi!
I have a few questions about the key in the title.

First of all, I know how to capture current frame from the fullscreen window and save it to file:

if (mEvent.key.code == sf::Keyboard::F12)
{
    sf::Image screenshot = mWindow.capture();
    screenshot.saveToFile("screenshot.png");
}
 

But I got soo used to in using the Printscreen key for making screenshots, since majority of games I played would support it, either by making the image file or by capturing the frame and then pasting it in a image editor program. It is kinda intuitive. 

So, what is the reason that SFML doesn't support the printscreen key?
Also, is there a way to force a program into using the printscreen key the way I want (as code above)?

I was searching a bit and found this topic, but since I extremely lack the OS* inner workings knowledge, I have no idea how implement the code from that topic into my code. 
Which means that the second question basically boils down to "can you write the code for me, pleasee?"
Or just point me at right direction on how to implement it. 

PS: I am a c++ and a programer noob, just so you know...

* OS is Windows 7.