Topics

1

Python / Can't copy VertexArrays with slice notation?

« on: July 25, 2017, 11:11:07 pm »

I tried making a copy of a vertex array using the slice notation...

textLayer = extraTextBuffer[:]

... and this is what happens:

#  File "graphics.pyx", line 1587, in sfml.graphics.VertexArray.__getitem__ (src/sfml\graphics.cpp:26182)
#  TypeError: an integer is required

I'm confused as to why this happens. (EDIT: Probably because VertexArrays are not python Lists! I realized later.)

I want to copy the array by value, and I can copy it by iterating through it, but that's quite a slow process (because the array is BIG). My goal was to check if using slice notation was significantly faster or not.

Basically my idea here is to have a vertex array with default values (colors and tex_coords), and simply use it to "clear" the one I'm using every frame. I'm doing this to test how it might affect performance. Iterating through a vertexarray and reseting all the vertices is also a rather slow process. Perhaps even slower than copying vertices from another array.

Simply copying like

array1 = array2

seems to copy them by reference, as it would a python list.

2

Python / pySFML documentation seems to be gone

« on: July 07, 2017, 12:17:18 am »

Does anyone have an offline version of it?

And by the way, what happened? The certificate for the site is expired too.

3

Python / [SOLVED] Converting the c++ VertexArray example (TileMap) to pySFML

« on: December 08, 2016, 05:40:46 pm »

I was creating a small test script to convert the example tile map to python, but I came across a problem. This is my code so far (it can contain other errors, I haven't made it work yet):

01      vertices = sf.VertexArray(sf.PrimitiveType.QUADS)
02
03      def createVertices(tiles, w, h):
04              global vertices
05              vertices.resize(w * h * 4)
06
07              for i in xrange(w):
08                      for j in xrange(h):
09                              tile = tiles[i + j*w];
10
11                              tu = tile % (tileset.width / TS)        # TS is tilesize
12                              tv = tile / (tileset.width / TS)
13
14                              quad = vertices[ (i+j*w) * 4 ]
15                              print quad                                                     
16                      #       ^ <sfml.graphics.Vertex object at 0x0225A1F0>
17                             
18                              # positioning
19                              quad[0].position = sf.Vector2( i*TS, j*TS )
20                      #       ^ TypeError: 'sfml.graphics.Vertex' object does not support indexing
21
22                              quad[1].position = sf.Vector2( (i+1)*TS, j*TS )
23                              quad[2].position = sf.Vector2( (i+1)*TS, (j+1)*TS )
24                              quad[3].position = sf.Vector2( i*TS, (j+1)*TS )
25
26                              # tex coords
27                              quad[0].tex_coords = sf.Vector2( tu*TS, tv*TS )
28                              quad[1].tex_coords = sf.Vector2( (tu+1)*TS, tv*TS )
29                              quad[2].tex_coords = sf.Vector2( (tu+1)*TS, (tv+1)*TS )
30                              quad[3].tex_coords = sf.Vector2( tu*TS, (tv+1)*TS )

On line 14 I get a vertex back from that assignment while in the example they get an array of vertices. I'm a bit confused. How do I get the quads then?

4

Graphics / Is there any advantage in having one Sprite to rule them all?

« on: September 25, 2016, 01:33:03 am »

If you take a Sprite and draw it, then change its position and draw it again (in the same loop), you can draw it as many times as you want on the screen. Obviously you can change the position of its texture rectangle as well, if you need it to draw different tiles from a tileset.

I'm curious as to whether this could have any kind of benefit/advantage over having multiple Sprites, or if there's any real practical application for it (I used it in a few prototypes, like Conway's Game of Life and some sort of roguelike-like-ish thing I did).

5

General / Inconsistent time acceleration problem

« on: June 07, 2016, 09:57:25 am »

Is there an inconsistency I'm not aware of when dealing with very low amounts of time?

I'm trying to increment minutes in my game by 240/s (4h/s)...

elapsed += timer.restart();
(...)
switch(timeSpeed)
{
    case 1:     // 1 s/2s - real game time
        if (elapsed.asMicroseconds() >= 2000000)    countMinutes();
        break;
    case 2:     // 5 m/s
        if (elapsed.asMicroseconds() >= 200000)     countMinutes();
        break;
    (...)
    case 5:     // 4 h/s
        if (elapsed.asMicroseconds() >= 4166)       countMinutes();
        break;
}
 

...but it only passes 3h/s if I unlock the frame rate, and 1h/s if I lock it at 60. It seems there is a bottom limit to how many microseconds I can manage too, since lowering the value does nothing to increase the speed.

This is my countMinutes() function.

++db.minutes;

if(db.minutes >= 60)
{
    db.minutes = 0;
    countHours();
}

elapsed = reset;
 

Also, reset is another sf::Time, that is used for nothing else than to reset elapsed. I'm doing this because elapsed = 0 doesn't seem to be possible and using % doesn't seem to work well with timers.

Is this a valid approach?

If I let it go beyond two millions I won't be able to call countMinutes() anymore. I don't know another way of doing it, but this one also creates a bit of a delay (-1s per every ~10s or something like that).

6

Graphics / problem with coloring tiles as separate sprites

« on: April 26, 2016, 03:54:15 pm »

I'm using a bitmap font and a tileset to display everything, from text to the ui, etc, and I have the rendering assigned to a separate class called Terminal.

The way I figured out to place all the text and graphics on the screen was to use an sf::Image as a buffer, where everything gets printed and drawn into, and then at the time to render I pass into a Texture, into a Sprite, and into the RenderWindow.

But now I want to apply different colors to certain tiles, so I can have a menu option selected and colored, or anything else I can think of.

Since there doesn't seem to be a way to color an sf::Image in the same way you can color an sf::Sprite with setColor(), the only way I figured to do this was by, instead of printing directly to the buffer Image, I created a stack of Sprites and their respective Textures (std::pairs) that are colored as they are created and kept there until it's time to render each of them and empty the stack.

It does work, but the problem is now I'm noticing a slow down... While cycling through the menu options, in game, the interaction doesn't seem fully responsive, sometimes I press a key and nothing happens (it's worth noting that the stack, currently, only applies to text, not the rest of the graphics, so I imagine it could get even worse).

I'd like to know if anyone would have a better (and faster) idea on how to achieve this. I'd rather deal with a single buffer than a stack of separate sprites, but I can't think of any other way to do it. I never tried using sf::RenderTexture as buffer, as the process for using it seems even more convoluted, but I also don't know if it could help...

EDIT: note - I'm doing the rendering separately so the rest of the code can deal only with grid coords, in small numbers of rows and columns. It's less confusing to me.

Don't know how relevant it is to show the code, but this is my Terminal::print() function:

void Terminal::print(int16_t row, int16_t col, string str)
{
        if (str.size() == 0) return;

        sf::Image img;
        img.create(str.size()*TS, TS, BLACK);   // TS = tile size (16) | BLACK = sf::Color::Black

        for (uint8_t i = 0; i < str.size(); i++)
                img.copy( *fStrip, i*TS, 0, sf::IntRect(str[i]*TS, 0, TS, TS) );
                // fStrip is where the font is stored (sf::Image)

        sf::Texture tex;
        tex.loadFromImage(img);

        sf::Sprite spr;
        spr.setColor(color); // Terminal::setColor(sf::Color) is used before Terminal::print()
        spr.setPosition(col*TS, row*TS); // convert from grid coords to pixel coords

        bufstack.push( make_pair(tex, spr) ); // stack<pair<sf::Texture, sf::Sprite> > bufstack;
        bufstack.top().second.setTexture(bufstack.top().first);
}
 

And my Terminal::render() function

void Terminal::render(sf::RenderWindow* window)
{
        sf::Texture tex;
        sf::Sprite spr;

        tex.loadFromImage(buffer);      // still using the buffer sf::Image for the rest
        spr.setTexture(tex);
        window->draw(spr);

        while (!bufstack.empty()) // maybe while loop slows it down?
        {
                window->draw(bufstack.top().second);
                bufstack.pop();
        }

        clearBuffer();
}
 

7

Graphics / Need some help on sf::Views and building UI stuff

« on: March 27, 2016, 09:50:52 pm »

I just recently started dealing with SFML. and I'm getting a bit confused as I'm building some UI elements. I'm making this post to help myself think, as well as to ask a thing or two about this, and to see if anyone has any helpful suggestions.

I need lots of parts, some fixed and some scrollable. I decided to call them panels. As far as I can think, all the contents of each panels will only ever scroll up/down (except the world map, but that will probably have it's own screen for itself).

So I had to find a way to hide stuff outside each panel, and sf::View seems the way to go. But I wonder, is there's such a thing as too many sf::Views?

In the quick mockup below, the parts that are framed in red (1 and 2) are the main UI stuff, and are fixed and persistent. No sf::View needed there. They'll contain buttons with which I'll be able to navigate through several screens, each with different info about the game (panel 2 is just placeholder, and I probably won't need it).



This is essentially a resource management game, where you run an Inn, so I need various screens to show all the relevant data. This mockup shows just one of those screens, and I have at least six more of them planned.

This one lists all the NPCs that are currently in the house (3) and available for interaction through dialogue (6/7) and inspection (4 - info / 5 - portrait). I'll need lots of sf::Views on the whole, to make the rest of the screens for stock items, hired staff, sales, all the money stuff, perhaps even cooking recipes... Perhaps I should mimic a state-machine for that?