Messages

1

General / New to SFML, game design questions

« on: September 06, 2011, 11:06:13 am »

Yes which  is what it appeard from the docs I read on SFML. And as such I'm still not surehow Laurent intends the Sprite object to be used exactly.

Previously in other stuff Ive just had a Sprite as a collection of graphical data (1 or more texture subrects, multiple being used in the case of animations, and the origin point), then there were methods like DrawSprite(spr, frame, x, y, angle), so it was clear that I had one Sprite object per different "visuals". SFML seems to have put that positional data into the Sprite objects itself, but one still doesnt use that data for logic, some I'm not entirly sure where that leaves sf::Sprite?

Well I guess batching isnt needed in the same form as D3D requires it since you havnt got this massive per call overhead that (the older versions at least) D3D has due to Kernel mode transitions. The graphics card still likes to render lots of vertices without constantly being asked to change state, but I'm not sure if in OpenGL/SFML you might actually get that by just drawing the same sf::Texture (with same blend etc) in a row (not sure, but whatever SFML is doing it passed my previous 200line d3d quad renderer I made at uni last year for a particle engine expierment in performance by a huge margin, and I know OpenGL and D3D should be near equals when you do things the right way ).

2

General / New to SFML, game design questions

« on: September 06, 2011, 01:49:58 am »

Of course it could be said reusing the Sprite like that defeats the 'purpose' of the Sprite class, which I believe is for defining separate "entities" in the worldspace ^^

Well how is it "designed" to be used, given it has already been established that using its position/rotation for logic purposes isnt a great idea, and is not possible with interpolation anyway, leaving position/rotation to be set at render time (and therefore as far as I can tell, loosing pretty much any benefit I can see of a per world object instance sf::Sprite except possible matrix benefits which I guess is possibly useful for static objects, but is still a fairly cheap part of rendering)? Even with some depth sorting scheme (which I still havnt really solved and tested) I'm not sure how a per-instance sf::Sprite helps? Unless perhaps position setting (on a per frame bases to interpolate) and rendering are performed as two seperate steps, but again I see no benefit to do this, just extra loop overhead?

If SFML was providing some kind of scene structure that it then rendered in the most optimal way (i.e. avoiding uneeded state changes, batching alike objects where the Z order allows) via some kind of RenderWindow::RenderEverything or somthing I could understand, but SFML doesnt seem to provide that functionalty?

3

General / New to SFML, game design questions

« on: September 05, 2011, 11:23:54 pm »

Well I think since there only there in the structs/classes for "storage", but created and used by rendering components, even somthing dramatic like going to straight OpenGL wouldnt be to much of a nightmare, apart from the doing the rendering with OpenGL part Definatly seemign better right now than trying to make some kind of seperate storage space with some kind of uid lookup (be it string, int, enum, etc).

The graphics code can then also take care of texture caching and lifespan (refcounting I guess, and am I also right in thinking sfml doesnt auto cache images and textures internally?).

I'm still not sure on the details of sf::Sprite. Can I just use a single sprite object to render the entire game, changing it's texture as required, or does that incur some large performance penalty I might not be noticing in small tests? I put some small pieces of code below on the ideas I was thinking.


So the only other major issue I have right now is the renderer getting the positional information for an instance and carrying out the interpolation. A common base class seems the most straight forward since I can have a "sf::Vector2f GetCurrentPosition(const Object &obj, float dt);float GetCurrentAngle(const Object &obj, float dt); " type methods, but I'm not sure I really want a common base class for every single visibile object in the game... The template solution doesnt really seem a whole lot better, although I guess it reduces source code duplication in some cases... I certainly don't want to type out the same interpolation code (likly with the same bugs ) for every single moving object,

Code: [Select]


//Idea A
void Renderer::Draw(const Ship *ship)
{
    sf::Vector2f pos = CalcCurrentPos(ship);
    float angle = CalcCurrentAngle(ship);
   
    spr.SetPosition(pos);
    spr.SetRotation(angle);
    spr.SetTexture(ship->GetType()->tex);
    spr.SetOrigin(ship->GetType()->texOrigin);
    //...anything else I decide to add...
    DrawSpr();
}
//Idea B
void Renderer::Draw(Ship &ship)
{
    sf::Vector2f pos = CalcCurrentPos(ship);
    float angle = CalcCurrentAngle(ship);
    //Ship and GetType cant be const for this, unless I use a const casting hack...
    sf::Sprite *spr = ship->GetType()->spr;
    spr->SetPosition(pos);
    spr->SetRotation(angle);
    DrawSpr(spr);
}


4

General / New to SFML, game design questions

« on: September 05, 2011, 09:19:34 pm »

Well perhaps, but it also creates a hardcoded data component. Say I want to create a fighter variation and made a fighterb.xml, fighterb.png, etc. But wait I cant, because ShipImage enum has no value for a fighterb.png, I need to change the program... I guess I could store the "fighterb.png" string in my object, but thats a string search on every single ship instance every single frame...

I could also use an id/handle system, but that seems no better than an sf::Texture* or whatever... (or sf::Sprite*, if there is some significant performance hit from constantly "reusing" a single sf::Sprite for each item rendered?)

Code: [Select]


struct ShipType
{
    float turnRate;
    float maxSpeed;
    WeaponMounts weapons;
    ...everything else describing a given ship...
    sf::Sprite spr;///?
    sf::Texture *tex;///better and reuse an internal sf::Sprite for each draw.
    std::string imageFile;//and some string lookup on each render? Performance?
    int imageId;//allocated in some way with some kind of lookup? How is that better than a spr/*tex ?
};
class Ship
{
...
    const ShipType *GetType(){return type;}
private:
    ShipType *type;//Each ship instance uses one of the described ship types to define its mount points, accelleration, turn rate, etc
};

For both *img and spr it would be obtained at load time from the render system with some kind of LoadGraphicsInfo function (I'm also assuming SFML doesnt do automatic texture caching if I was to load the foo.png 10 times), and only really used by the graphical components. I guess I could put it in a "RenderInfo" child struct as well? Perhaps even private fields where the rendering class is a friend?

5

General / New to SFML, game design questions

« on: September 05, 2011, 12:46:05 pm »

I spent soem time looking at creating this "Renderer" class, however Ive run into some issue that I'm  not sure on how to solve, and I couldnt find any existing code that uses such a Renderer class to see exactly what people are suggesting

My assumption was the the intention is for Paddle, Ball, etc, to not contain an sf::Sprite or similar graphics member objects. This works fine for Pong, although I had to add in some "magic" number for width,height,etc of some objects, but in a real game I suspect Id put more detailed collision info in some kind of data file anyway.

The issue I ran into here is when one object may have one of many different images. E.g. a "Ship" class may use one of fighter.png, frigate.png, bomber.png, heavy_fighter.png, etc, etc, but each of these different ships is still only a Ship class (the difference coming from the data itself thats externally defined). I considered creating some kind of "enum ShipImage", but that idea seems even worse than the Ship having an sf::Sprite in the first place....

Also I was thinking of how to remove code duplication on the interpolation front by perhaps having a common base class to hold the pos, lastPos, angle, lastAngle, etc. members (as protected, with public getters) so the renderer could have for example "sf::Vectro2f Renderer::interpolatePosition(const Object &obj)". I guess I could also make interpolatePosition a template method where each object using interpolation just has to provide a suitable getPos and getLastPos, but I'm not sure thats any cleaner than a common base class and it still creates duplication in the generated code due to the nature of templates?


The other issue I ran into was how best to handle HUD rendering. Would the best way simply be to have some HUD class that renders itself (since HUD isnt really doing any logic in the first place, I guess this is ok?)?

6

General / New to SFML, game design questions

« on: September 02, 2011, 06:06:19 pm »

The abstract IRenderer is just something you'd need with multiple possible renderers, so you could have IRenderer that then becomes a CSFMLRenderer, a CDX9Renderer, a CDX11Renderer, a CSoftwareRenderer etc.

As ok, that makes more sense, and is along the lines of what I considered on a direct d3d/opengl solution, but there doesnt seem much advantage to doing that when using SFML except a lot of extra work

The concept of a service as used in XNA seems to be essentially only giving the information other components actually need to those components and hiding the rest of it.

You got some code example to show of this (Ive never used XNA)? Sounding somwhat what like public/protected/private/friend does?


Any suggestions on my tree idea? The only other solution ive personally seen in 2D was to give each object a "depth", sort the objects by depth and then render in that order. But I found such a system difficult when I wanted to insert objects immediatly before/after other objects.

7

General / New to SFML, game design questions

« on: September 02, 2011, 04:20:54 pm »

Ive looked a bit at this services thing, but I'm not entirly sure what problem it solves?

It seems to just add an interface for each "component" and then provide a "IRenderer *Game::getRenderer()" instead of a "Renderer *Game::getRenderer()"? What good is this doing except making function calls more expensive, preventing inlining, etc?

If I do the rendering as describe here with a bunch of draw overloads neither IRenderer or Renderer are useable between games anyway, and even in general I don't think an interface makes a class more or less useable between projects?



Also I thought some more about Z-ordering, but am still not sure on what the "standard" solution is. Currently I'm thinking of some kind of renderer tree structure that is ordered back to front, and then can be transversed. e.g. the tree might look like this in a space invaders syle game with nodes containing other items, and the leafs being the visible objects.

Code: [Select]


Game Root Node
    Ship Node(Player)
        Ship
        Bullet
        Bullet
        Bullet
        Missile Node
            Missile
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
    Ship Node
        Ship
        Turret
        Turret
        Bullet
        Bullet
        Bullet
        Bullet
        Missile Impact Effect Node
            Explosion
            Shockwave
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
    Ship Node
        Ship
        Missile Node
            Missile
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
        Missile Node
            Missile
            Smoke Particle
            Smoke Particle
            Smoke Particle
            Smoke Particle
        Damage Effect Node
            Explosion
            Smoke Particle
            Smoke Particle
            Smoke Particle

As far as keeping this completly seperate from the simulation logic goes I have no idea, since an object needs to know which "render node" it is working with in order for new objects to know where to insert themselves into this tree?

8

General / New to SFML, game design questions

« on: August 25, 2011, 02:27:57 pm »

Well regardless if its singleton itself, or accssed via a Game::GetRenderer method is littel difference? Unless your suggesting I pass the Renderer* around the majority of objects in my game?

Also how would I extend this to add say a particle effect trail to the ball? Have seperate Renderer::Draw(ball) and Renderer::Draw(ParticleTrail)? Or would the Renderer::Draw(ball) somehow "know" to render the particle effect, perhaps even update the particles simulation itself (since they dont effect logic of other objects, and so dont really gain anything froma  fixed timestep anyway?)?


EDIT:

Also I was kind of thinking, in the interest of allowing certain optimisations should they be required without much effort, take care of Z ordering automatically (e.g. if I say hae some space ships shooting bullets, and 1 space ship is above the other, I need to make sure the bullet fired by the one "below" doesnt get rendered ontop of the other), and also perhaps (allthough I have even less of an idea on this one) provide some sort of capability to perform logic and rendering on seperate threads.

I seem to recall 3D games use somthing called a scene graph for somthing along those lines, but I could be way off on that since Ive never programed any 3D stuff.

9

General / New to SFML, game design questions

« on: August 25, 2011, 01:35:34 pm »

So you saying I should have a singleton class like:

Code: [Select]


class Renderer
{
public:
    void drawBall(sf::Vector2f);
    void drawPaddle(sf::Vector2f);
    void drawScoreText(int player, int score);
    void drawWinText(int frame, int player);
    void drawMenuButton(sf::Vector2f, string text, bool hover, int alignment);
    ...
};


and paddles/balls/buttons/etc get there "size" from "some other source"?

10

General / New to SFML, game design questions

« on: August 23, 2011, 02:25:01 pm »

I set up SFML 2.0 and made pong to learn the classes and test design. I plan to make a much larger game using more or less this design, so it would be useful to get some feed back on it (e.g. I'm really not sure I like the "((LevelState*)getGame()->getState())->getBall()->getPos()" I have somewhere, but also I don't really want to make singletons left right and centre...).

http://www.mediafire.com/?pc05ooqa8eatxlk

Its only a very small amount of code. Ive got some extracts to show what I was doing for the most part:


I often see it said that its better for a number of reasons to keep the logic simulation at a fixed rate and use interpolation to keep rendering smooth. However I found finding actual implementation examples hard to come across So this is pretty much my own solution to the problem, and probably flawed in some way...

Code: [Select]


void Game::run()
{
    running = true;
    sf::Event evt;
   
    sf::Clock clk;
    unsigned stepSize = 1000/30;
    unsigned nextStep = clk.GetElapsedTime();
    unsigned time;//current time
    while(running)
    {
        //handle events
        while(window.PollEvent(evt))
            handleEvent(evt);
       
        time = clk.GetElapsedTime();
        //update simulation
        while(clk.GetElapsedTime() >= nextStep)
        {
            nextStep += stepSize;
            //will be called 30 times a second
            update();
           
            time = clk.GetElapsedTime();
        }
        //render game

        //calc time position between nextStep-stepSize and nextStep
        unsigned untilNext = nextStep - time;
        //fraction
        float dt = untilNext / (float)stepSize;
        assert(dt >= 0 && dt <= 1);
        render(dt);
    }
}


The various parts of the game (main menu, the level, etc) all implement this interface. The Game object then maintains the current state, and handles switching to a new state.

Code: [Select]


class State
{
public:
    State(){};
    virtual ~State(){};
   
    virtual void update()=0;
    virtual void render(float dt)=0;
    virtual void onEvent(sf::Event &evt)=0;
};


The moving objects have a pos and lastPos variables. In the objects update code lastPos is set to the position at the start of the update (except for teleports, that ensure pos == lastPos at the end). The render code then interpolates between pos and lastPos. In the game I plan to work on, similar things will be done for rotation etc.

Code: [Select]



void Paddle::update()
{
    ...ai/player input stuff, sets move var (within range -moveSpeed to moveSpeed)...
    //move
    lastPos = pos;
    pos.y += move;
    //limit to window edges
    if(pos.y < 0)pos.y = 0;
    else if(pos.y + spr.GetSize().y > getGame()->getSize().y)
        pos.y = getGame()->getSize().y - spr.GetSize().y;
}
void Paddle::render(float dt)
{
    //draw
    sf::Vector2f renderPos = pos + dt*(lastPos - pos);
    spr.SetPosition(renderPos);
    getGame()->getWindow()->Draw(spr);


11

General / Re: New to SFML, game design questions

« on: August 14, 2011, 05:53:59 pm »

Obviously these classes don't have all the logic required for a game object, and so I need to make my own class that adds this logic.

Yes. Don't inherit from sf::Sprite for logic objects, since sf::Sprite is a pure graphics-related class. You could take a sprite as member, or go even further and separate graphics and logics. That is, the object doesn't know how to draw itself, it just contains data required for the game logics. You could write a Renderer class that has overloaded Draw() functions for different logic objects, and create sprites on the fly (this should usually be very fast). Or you leave sprites as a member, but don't let the logic object draw them itself. Or create a map that associates logic objects with sprites. Or...

There are many possibilities. Generally, it is a good idea if graphics and logics are not too tightly coupled.

So along the lines of the method C I showed, where the actual logic stuff works with a seperate data set, and its only when I want to render stuff I deal with the sf::Sprite?

12

General / New to SFML, game design questions

« on: August 14, 2011, 01:10:36 pm »

Hi,

Ive looked through the published tutorials and some of the samples, but am still unclear on some of the best practices for designing a non-trival game.

e.g. the Drawable classes store position, rotation, etc with getters and setters. Obviously these classes don't have all the logic required for a game object, and so I need to make my own class that adds this logic. However I'm not clear on what the intended way to do this is, since there seems to be a few posibilites.

Code: [Select]


//A, inherit sf::Sprite and use its getters and setters directly for positional stuff
class Bullet : public sf::Sprite
{...};

//B, have sf::Sprite as a member, and use its getters and setters for positional stuff
class Bullet
{
private:
    sf::Sprite spr;
public:
    const sf::Vector2f& getPos()const{return spr.GetPosition();}
    ...
};

//C, have sf::Sprite as a member, have my own positional stuff, and set it in a render function
class Bullet
{
private:
    sf::Sprite spr;
    sf::Vector2f pos;
    float direction;
public:
    void render()
    {
        spr.SetPosition(pos);
        ...
    }
   ...
};



Also does SFML do any rendering optimisation itself (i.e. look at what it was told to draw on the frame, and draw it such to avoid constant texture and state switches between every object), or have I got to do such batching myself? If so what are the recommended ways to do this where the Z order of the sprites is important and alpha blending is used (I had some previous success just putting all my games sprites in one big texture, so it could all be drawn in one big D3D batch)?


And one last thing. It looks like a major update to SFML is coming soon. Is it worth goign straight there rather than learning 1.6, and is there some resources around for doing so?

It would also be useful to see the code for somthing more complete that follows fairly good code practices. The best ive found so far is like that pong sample that stuck everything in the main function...