Messages

1

Feature requests / Batching and other graphical improvements

« on: March 08, 2009, 11:55:30 am »

I still haven't found the perfect solution

I don't think there is one.  =/  Batching inherently means state changes spanning across drawable boundaries, which breaks the current model.

2

Feature requests / Batching and other graphical improvements

« on: March 08, 2009, 03:28:42 am »

Ok, the task of batch rendering can roughly be broken up into two parts, the sorting and the actual rendering.  Because we have to sort, I don't think there's any way around having some kind of container that you queue drawables into each frame.  I think you'd almost certainly want to add some kind of layer variable to drawables.  Then sorting would be something like layer/[view]/topology/image/blend mode (topology might be better last, it depends).

From there I see two possibilities.  The first is to have the drawables give the data necessary to the renderer.

Code: [Select]


void BatchRenderer::render()
{
    sort queue
    for each drawable in queue
        get drawable render information
        draw the stuff
    empty the queue
}

I could see this being made potentially fairly fast, but it's probably harder to extend.  If you needed some new topology or something, you'd have to add it to the render function.

The second strategy (which I think probably fits SFML best) would be to add a new virtual member function on drawables (private and friends with the batchrenderer).  Then create a class BatchRenderState (my nomenclature shouldn't be taken as recommended, just using whatever comes to mind) that holds the current state and the batched data.
That would look something like this:

Code: [Select]


void BatchRenderer::render
{
    sort queue
    for each renderable in queue
        drawable->batchrender ( batchrenderstate );
    batchrenderstate.finished
    empty the queue
}

A drawable batchrender function would then look something like this:

Code: [Select]


void SomeDrawable::batchrender ( batchrenderstate )
{
    batchrenderstate.setstate ( drawable's topology, image, etc. );
    batchrenderstate.setdata ( drawable's vertices, texture coords, etc. )
}

The batchrenderstate object would watch for state changes, thus ending the current batch and would actually call opengl with whatever it had stored up so far.  If things were written well, you could even call opengl inside the drawable::batchrender without passing the data to the state object, as long as you informed the state object accordingly (a flush type command, or set state without data).

I think a few things could be problematic, namely child drawables (since you can't push/pop and have a good batch renderer), the current color, the view (you have to queue everything, so if you have different views that has to go in there as well).  For views, one solution is to have per layer views, so the renderer can change the view when the layer changes.  That might work for colors as well (colorable layers vs normal layers).  Heh, you could even do blend modes that way to avoid having to check lots of state with each drawable.

There are some potential speed optimizations as well, for example, maybe instead of setdata, it's getdataptr and then the drawable stuffs the data in itself.  *shrug*

Anyway, a proposal at least. =)  Now that I've thought it out, it's less complicated than I expected.

3

Feature requests / Window rendering and event processing in Windows

« on: March 08, 2009, 02:35:42 am »

I think that's just windows being stupid.  There are lots of cases of that.  For example your app will basically pause while the user is resizing the window.  The default window proc is dumb.  =/

4

Feature requests / Batching and other graphical improvements

« on: March 07, 2009, 01:27:46 pm »

Heh.  I somehow never looked at PostFX.  I guess the name threw me.  I didn't realize it was shader support.

I'll see if I can't take some time this weekend to doodle out a few batch rendering schemes.  Unfortunately, I suspect part of the problem is simply implementing and profiling different techniques to see what kind of speed-up you get.

5

Feature requests / Batching and other graphical improvements

« on: March 07, 2009, 02:18:05 am »

I started my current project using SFML, but relatively early on I shifted to raw OpenGL in place of SFML sprites; keeping SFML for window creation and image loading.  I quite like the clean code style of SFML, in stark contrast to the make-shift disaster that I slowly hacked together over the course of my project.

However, SFML doesn't really do what I want.  I'd like state sorting/sprite batching, and looking forward I'd really like to be able to play with render to texture and perhaps even shaders.  I can imagine things like texture compression and built in sprite animation eventually being convenient as well.

Most of the recent changes I've seen to SFML have been in non-graphical areas, which is fine.  I'm curious what the level of interest is for graphical additions like I've suggested.  From my brief poking around in the sprite and renderwindow internals, I don't see how batching could be added without significantly changing things.  I could be wrong.  I see some of what I've listed on the roadmap.  Does that mean Laurent has design ideas, or just a general interest in the feature?

I have a pretty clear idea of what I want to be able to do.  I'm even willing to help SFML get there since I'll being doing some of this stuff anyways.  I'm just not clear on what direction SFML is heading in or whether the help is wanted.  =)  I can honestly see a fancy batching rendering system being confusing and 'ugly' in comparison to what SFML already has.

6

Graphics / Optimizing tile-grid drawing

« on: December 26, 2008, 03:57:38 pm »

Hrmm.  Do you have a really bad graphics card on your laptop?

Also, I'm not sure you can really use cpu use as a metric for optimizing.  If you aren't doing any other background tasks, your game should be using all of the CPU.  A better measure would be framerate.

7

Graphics / Optimizing tile-grid drawing

« on: December 24, 2008, 06:23:47 am »

Your code looks fine.  I'd check other parts of your program.  A few hundred tiles should get drawn quickly.

8

Graphics / Hatching and masking

« on: December 09, 2008, 01:38:21 am »

It really depends what exactly you want to do.  With shaders anything like what you described is easy.

If all you want to do is 'floodfill' a polygon with a hatching pattern, then generate a hatching texture, set texture repeat (as far as I know, not available in SFML), and draw your polygon with the texture coordinates proportional to screen space (uh, also not available in SFML).  Easy to do with OpenGL though.

9

Graphics / Best way to "SCROLL" an overworld map?

« on: December 02, 2008, 12:35:21 pm »

Can someone explain to me what exactly you would use XML or protocol buffers for?  I don't really understand the problem it's trying to solve.

10

Graphics / Not all tiles from TileMap are shown

« on: November 30, 2008, 08:49:20 pm »

But, there is something in your code thant won´t work.

Code: [Select]


Sprite TileSprite[2];

TileSprite[0].LoadFromFile ( "grass.png" );
TileSprite[1].LoadFromFile ( "dirt.png" );


Oh, right.  That's what I get for just going from memory.  Second attempt from memory:

Code: [Select]


sf::Sprite TileSprite[2];
sf::Image TileImage[2];

TileImage[0].LoadFromFile("grass.png");
TileImage[1].LoadFromFile("dirt.png");
TileSprite[0].SetImage ( &(TileImage[0]) );
TileSprite[1].SetImage ( &(TileImage[1]) );


The reason I suggest using an array instead of what you're doing is that eventually you wind up with code that looks like this:

Code: [Select]


If (Tile[X][Y] == 1 )
  ...
else if (Tile[X][Y] == 2 )
  ...
else if (Tile[X][Y] == 3 )
 ...
else if (Tile[X][Y] == 4 )
 ...
etc.


Eventually it's just not very easy to add tiles.  Much easier to have an array or a vector container of some sort.

11

General / framerate drops when drawing 100+ shape::lines

« on: November 30, 2008, 12:54:39 pm »

I'm not completely sure what you're doing, but it doesn't look fast.  =/

I think you're generating a shape per edge of your asteroid, and then drawing each edge separately.  Ouch.

A few possible solutions.  

* Make a few different images of asteroids and then use one sprite per asteroid.
* Make your own asteroid drawable and use OpenGL to draw the lines that make up the asteroid.  This is easier than it seems.  It's quite literally glBegin(GL_LINES); glVertex2f (); ... glEnd(); You might need to glDisable(GL_TEXTURE_2D); and then glEnable(GL_TEXTURE_2D) when you finish.
* Cut your asteroid into convex polygons and use the polygon drawable.

12

Graphics / Not all tiles from TileMap are shown

« on: November 30, 2008, 01:40:26 am »

You're only drawing 1-2 sprites.  The draw call has to be in the loop.

Try something more like

Code: [Select]



const int TILE_SIZE = 128;

int TileMap[mapHoehe][mapBreite] =
{
   {1,1,1},
   {1,2,1},
   {1,1,1},
};

Sprite TileSprite[2];

TileSprite[0].LoadFromFile ( "grass.png" );
TileSprite[1].LoadFromFile ( "dirt.png" );

// later to render the tiles
for(int y = 0; y < mapHoehe; y++)
{
   for(int x = 0; x < mapBreite; x++)
   {
      int i;
      i = TileMap[y][x];
      TileSprite[i].SetPosition ( x*TILE_SIZE, y*TILE_SIZE );
      Window.Draw ( TileSprite[i] );
   }
}



13

Graphics / Why does each sprite set the projection matrix?

« on: November 29, 2008, 05:58:08 am »

I've recently started using SFML in a platform game.  Because I had polygonal textured tiles, I had to do a bit of source browsing to make sure my OpenGL calls wouldn't cause trouble with the generic SFML sprites I was using.

I discovered that the SFML RenderWindow Draw call was setting the projection matrix and then calling the drawable's render function.  This seems a bit strange to me.  I'd expect SetView to change the matrix and then everything else to assume it had been set properly.