Messages

1

Graphics / Re: No display in renderTarget?

« on: July 04, 2014, 03:26:57 am »

A renderer would merely draw to its target and no more. Leaving the display() call to the code that actually instantiates and thus owns the RenderWindow or RenderTexture is the better way of doing things. After all, drawing might not be limited to your renderer. There might be others who want to draw as well, and prematurely calling display() before the complete frame is rendered is not recommended.

This is probably a better way of doing it, I suppose.  I'm still a little bleary on my implementation details so I can't say for sure.

Let me think out loud for a moment:
A likely reason to use a renderTexture is to create something like a light map which is drawn "off screen".  Is this correct?
So then you can take this off-screen texture, bind it to a sprite, and draw it (with blending) over/with the actual renderWindow contents.  Still on track?

My concern is passing around "unfinished" renderTextures to the final blending/mixing operation.  Whoever calls that operation needs to know to "finish/display" the renderTexture before it does the final display.

Another thing, why would you try to design your own interface when SFML already provides sf::Drawable?

I'm doing the bit that takes a sorted list of sf::Drawables and actually does the state setting and calling of draw() to a given target.

This is the first time I'm trying to do something that isn't just a hard coded blob of draw calls.

2

Graphics / No display in renderTarget?

« on: July 04, 2014, 02:00:54 am »

I'm trying to implement a more "general" renderer that can draw to either a renderWindow OR a renderTexture.

So I inherit from something like:

class IRenderer
{
public:
    virtual void Render(sf::RenderTarget &rt) = 0;
};

I'm lead to believe I must call "display()" after drawing...

This function updates the target texture with what has been drawn so far. Like for windows, calling this function is mandatory at the end of rendering. Not calling it may leave the texture in an undefined state.

This leads to a problem, because my inherited renderer cannot call "display()" because it is not a virtual method in RenderTarget (it is contained in both RenderTexture & RenderWindow separately).

Is my entire architecture kind of wonky?  I sorta thought having a generic renderer that can just "RenderThisListOfThings" on "ThisRenderTarget" would be pretty versatile.

3

Graphics / Re: No way to transform VertexArray?

« on: September 03, 2012, 08:11:40 pm »

ooh, excellent.  Didn't realize that was hidden in the render states bit.  Thanks.

4

Graphics / No way to transform VertexArray?

« on: September 03, 2012, 08:04:00 pm »

Maybe I'm missing something obvious here, but is there no way to translate and/or rotate a vertexArray?

Regenerating the entire geometry each frame is too slow already.  Essentially I need something like:

glTranslatef(x,y);
glRotatef(angle);
window.draw(vertexArray);

Would mixing opengl and sfml in that way cause unexpected effects with regards to their transforms fighting?

5

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: September 01, 2012, 02:35:47 am »

So,

Any specific strategies for using this on a "larger" scale.  I only have a few buttons, and already I can see that hard coding each panel and having a giant "switch" block in the callback loop is pretty much unwieldy and error prone. 

Should I wrap panel in my own class and load things like position, size, text, etc from XML or similar files?
Do you just make one generic "OK/Cancel" confirmation dialogue box and show() it when needed.  If so, how to hook his outputs to different targets?

6

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: August 30, 2012, 11:51:48 pm »

Loading font...

sf::Font defaultFont;
defaultFont.loadFromFile("Fonts/DejaVuSans.ttf");
...
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;
 

Code for panel checkbox is inside:

    tgui::Panel* menuPanel = window.add<tgui::Panel>("menuPanel");
    menuPanel->load(500,300, sf::Color(50,50,50,175));
    menuPanel->setPosition(0,35);

Code for checkbox...

    tgui::Checkbox* checkbox = menuPanel->add<tgui::Checkbox>("Fullscreen");
    checkbox->load("Gui/Checkbox/Black");
    checkbox->setText("Fullscreen");
    checkbox->setSize(25,25);
    checkbox->setPosition(15, 15);
    checkbox->callbackID = 2;

Drawing code:

        window.clear();
        window.setView( window.getDefaultView() );
        window.draw(bg0);

        window.setView(mainView);  // Set view for drawing game objects

        vertexArray.s = texPage.GetTexPage();       // Select texturePage for vertexArray
        window.draw(vertexArray, vertexArray.s);    // Draw vertexArray

        window.setView( window.getDefaultView() );
        window.drawGUI();

        window.display();

I don't rescale the text anywhere and am using the default "Black" theme.

7

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: August 30, 2012, 11:16:11 pm »

setText() seems to lose leading spaces in the string.

If I would allow spaces in front of the text, do you expect the area of the spaces to be clickable or not?

By all means, do not show leading spaces.  But I can't figure out how to make my text not overlap the button.
It's entirely possible I just don't know what I'm doing.  In fact, that's very likely.

8

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: August 30, 2012, 01:30:31 am »

Minor thing...

setText() seems to lose leading spaces in the string.  I am having some trouble with text overlapping on my checkboxes, and I cannot space it out this way. 

9

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: August 29, 2012, 11:45:33 pm »

Ah, yep.  Missed that one in your setup tutorial.  Works now, thanks for the speedy reply.

I think the name "handleEvent(event)" kind of blends into the woodwork of the SFML event system that is already there.  It isn't very clear that it is related to the GUI working.

Maybe something like
"HookEventsToTGUI" or something similar that makes it clear what its really doing.

10

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: August 29, 2012, 11:32:25 pm »

I cannot get buttons to throw any callbacks.  I have commented my program back down to effectively nothing, even setting default views and such.  But I never get any "mouseover" highlight, and it never enters the callback block.  The button otherwise displays correctly.  I just rebuilt SMFL2 (latest snapshot) and TGUI (0.5 from "download latest revision" on homepage) again to make sure I was up to date, but that did not change anything.

    ////////////////// Setup Window //////////////////////
sf::VideoMode mode = sf::VideoMode(1024,768,32);
tgui::Window window(mode, "Terran Command 0.0001 Alpha");
window.globalFont = defaultFont;

tgui::Button* button = window.add<tgui::Button>();
button->load("Gui/Button/Black Square");
button->setText("BUTTON");
button->callbackID = 1;

//////// Main Loop //////////////////
    while(window.isOpen())
    {
        HandleEvents(window);
        tgui::Callback callback;
        while(window.getCallback(callback))
        {
            std::cout << "Anybody?" << std::endl;
        }

        window.clear();
        //window.draw(bg0);
        window.drawGUI();

        //window.setView( sf::View( sf::Vector2f(750, 500), sf::Vector2f(mode.width*4, mode.height*4)));  // Set view for drawing game objects
        window.setView(window.getDefaultView());
        //vertexArray.s = texPage.GetTexPage();       // Select texturePage for vertexArray
        //window.draw(vertexArray, vertexArray.s);    // Draw vertexArray

        window.display();
    }

What am I missing?

11

Graphics / Getting crisp texture display

« on: August 25, 2012, 04:22:59 pm »

Are there specific recommendations to get the sharpest detail on sprites/textures? 

Specifically I am rendering tiles using a vertex array and one large texture (just shifting tex coords).  I am getting some problems with "space" between tiles at certain zoom and pan settings.  I suspect this is related to how opengl scales texture coordinates, so what can I do to minimize these artifacts?

Note the horizontal black lines that sometimes appear


I have isSmooth set to false everywhere that it seems applicable. 
I have my View.size set equal to the videoMode width&height.
The "zoom" factor is powers of 2. 
The View.position is in integers.

Anything else?  Should I have pre-made textures for each zoom level?  Course this means I have to rewrite the entire vertex array everytime the zoom changes.

Thanks.

12

Graphics / Re: Vertex Array: Store or calculate?

« on: August 24, 2012, 12:14:31 am »

You usually have one sf::VertexArray that holds all the tiles, then you se sf::Sprite or your own entity class for players/enemies/moving things and if you want to scroll the screen you change the sf::View of the render target.

Problem is that "all the tiles" could be hundreds of megabytes just in *verticies*, let alone actual object data.  Scrolling around with View is no problem, but that doesn't avoid the fact that either I have to save all of the geometry, or procedurally generate it as needed depending on what is inside the scene.

This is the usual "memory vs performances" battle.

At least it sounds like the methods I have presented are reasonable, and not completely out of left field.  I'm kinda new at this, so I was trying to make sure I was not missing some obvious solution.

Onward with the "procedural" vertex array, I think.

13

Graphics / Vertex Array: Store or calculate?

« on: August 23, 2012, 11:11:23 pm »

I'm partially just thinking out loud here, but definitely interested in suggestions...

Background
I have a game which is roughly tile-based.  More specifically, the *objects* of my game are made up of tiles, and can do the usual moving around the world that is expected of objects. 

So, I have defined my maximum object size to be 512x512 tiles.  In the future I would like to expand this to include some depth, but I'm keeping it simple for now.  Then I store tiles in "chunks" which are effectively just arrays of 16x16 tiles.  The chunks are then stored in a tree structure.  I currently have been able to render a single fixed chunk using vertex arrays, and it works good and fast, but I think my implementation will not work when expanded to full game size.

Question
How can I best handle my vertex arrays to render this type of "world". 

Option A:
Each chunk stores his own vertex array to describe his own geometry. 
Advantages:
The vertex array(s) need only be updated when something occurs which changes the chunk (tiles are added or removed).  Otherwise they carry over to the next frame.
Disadvantages
Enormous memory footprint.  Each tile needs (4)sf::Vertex, which works out to be 80 bytes(?)  When a tile's own footprint is only 2 bytes, and a world can have thousands or hundreds of thousands of tiles, this does not seem workable.  A 512x512 tree that is fully filled with tiles will be 20+MB or verticies, and only 524kB of tile data.  Seems redundant anyways, since every tile has the same geometry, just in a different position.

Option B:
Vertex array to describe all of the geometry is recreated each frame.
Advantages
Memory footprint problem is alleviated, since only geometry that is needed for drawing a given frame is created.
Disadvantages
The geometry needs to be recreated every frame.  Is this a heavyweight operation, or negligible? 

Option C:
As in Option B, except geometry from previous frame is cached for use next frame.
Advantages
Memory footprint as above.
Most frames, the geometry probably wouldn't change much, so this cuts down on recreating verticies that exist already.
Disadvantages
Detecting when recreation or editing of the vertex data is required sounds complicated and error prone. 
As the frustrum clips different geometry, the vertex data may change more often than anticipated.

Thoughts?  Am I reinventing square wheels again?