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

Pages: [1]
1
SFML game jam / Re: Open GL - Yes/No
« on: January 12, 2014, 06:43:29 am »
Since the rules have been opened to include everyone the last thing would be to require the person to simply state, "I/We have used pure SFML rendering" OR "I/We have used SFML and some/all raw OpenGL for rendering" on the game entry. (or maybe have a small flag in that fancy new site  ;))

Another option would be to simply require at least two components of SFML to be used. Such as window management and audio, window management and networking, and so on. This would allow any combination of SFML and/or OpenGL while making sure it is still in the spirit of using SFML.  ;D

I am for either or both suggested rules. This would keep the game jam loosely structured and fun (participants won't have so much concern with breaking the rules) and it would continue to showcase SFML great features of SFML. I might change the wording of the second suggestion in some way to reflect that participants must use two APIs from SFML, and not just two classes from the same header.

2
Ahhh, I was tired today. I forgot that's why one would implement sf::Drawable in the first place.
This bit of code in main:
state->draw(window, sf::RenderStates::Default);
was an artifact of my previous drawing system.

Appreciate the efforts, Omega/Nexus.

3
Nevermind, all. Found the problem shortly after. If I declare draw(...) public in State, I can call it from main.
class State : public EventHandler, public sf::Drawable {
public:
        virtual void update(const sf::Time &delta) = 0;
        virtual void draw(sf::RenderTarget &target, sf::RenderStates states) const = 0;
};
I am under the assumption that this is because my State pointer in main.cpp is of type State and not of type StateMenu.

Still curious why the protected access control modifier was chosen, if anyone might indulge me.  :)

4
Graphics / Calling draw(...) on instance of class implementing Drawable
« on: January 04, 2014, 02:00:32 am »
I noticed sf::Drawable's draw(...) method is protected. Why is that? (I'm not the best C++ programmer, so pardon me if the answer's rather obvious.)


As a followup question, what is the best way to call this method from outside my implementing class, StateMenu?

Here's my parent interface:
// a state the game can be in (menu, playing, credits).
class State : public EventHandler, public sf::Drawable {
public:
        virtual void update(const sf::Time &delta) = 0;
};

Here's an implementer of that interface:
// the title menu of the game.
class StateMenu : public State {
public:
        bool handleEvent(sf::Event &event);
        void update(const sf::Time &delta);
        void draw(sf::RenderTarget &target, sf::RenderStates states) const;
       
private:
        sf::Time mTimeElapsed;
};

And here's some snippets from main.cpp:
sf::RenderWindow window(sf::VideoMode(WINDOW_WIDTH, WINDOW_HEIGHT), TITLE,
                                                sf::Style::Titlebar | sf::Style::Close);
State *state;

void render() {
        window.clear(sf::Color::Black);
        state->draw(window, sf::RenderStates::Default);
        window.display();
}

int main() {
        ...
        state = new StateMenu;
        ...
        while (window.isOpen()) {
                ...
                render();
        }
        return 0;
}

Sorry if I posted too much code, and thanks in advance for any and all help!

Pages: [1]