Messages

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 / Re: pySFML documentation seems to be gone

« on: July 08, 2017, 01:07:44 am »

Why didn't I think of that... It's been a while.
Thanks!

3

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.

4

Python / Re: Converting the c++ VertexArray example (TileMap) to pySFML

« on: December 08, 2016, 09:53:01 pm »

Well... it goes through the roof only while I'm not doing anything in the test script. As soon as I tested with my actual program the frame rates are actually worse with 1 draw call (~20fps) than they were before with 3600 draw calls (~50fps).

I was using an 80x45 image (size of my tile grid) to store the background colors in pixels (the associated sprite with ratio raised to the tile size, so it fills the screen), and one sprite to draw each of the foregrounds (glyphs - as in a roguelike).

Now, at every frame I'm changing the vertex colors and their texture coords. I raised the frame rate to ~60 by testing if the color and tex-coords are different, and change only if they are. I don't know if there's a better way to do that...

I was hoping to be able to get the frame rate at least over 100. By the nature of a traditional roguelike, I'll have to draw all those tiles every frame.

5

Python / Re: Converting the c++ VertexArray example (TileMap) to pySFML

« on: December 08, 2016, 08:12:22 pm »

Thanks for clarifying. I wasn't expecting subtle differences from under the hood like that one.

By the way, the frame rates just go through the roof with this! Way to see how the weight of each draw call adds up.

6

Python / Re: Converting the c++ VertexArray example (TileMap) to pySFML

« on: December 08, 2016, 07:44:36 pm »

Ah, that does work. Thanks a lot.

Just out of curiosity...

... thus getting a pointer to the portion of the vertex array that defines the quad (because vertices are stored contiguously in memory).

... is this a difference in how python handles memory, or how pySFML handles VertexArrays or memory?

7

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?

8

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

« on: September 26, 2016, 10:20:40 am »

I meant if you have x sprites that never change, it would be redundant to keep setting the properties ever frame.

Ah yes. Wasn't thinking of that.

Now that I think about it, having to be changing the properties during the drawing seems like mixing logic with rendering...

9

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

« on: September 25, 2016, 10:08:39 am »

Wouldn't the number of calls be the same? As they'll have to make a draw call each anyway. Unless what you're thinking is about gathering them in some way and thus making less calls?

I'm probably missing something. There are still many things I don't know about or have only barely heard of (such as sprite batching).

10

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

« on: September 25, 2016, 08:09:45 am »

I think I can see what you mean.

The thing with both of those games in which I used this was that they used a sort of a rendering delegate, that stored everything in a tilemap, and then made all of the game's draw() calls in one single loop. I did this "trick" more out of convenience and lazyness than anything else. Didn't even think to ask around first.

In these cases I wouldn't think I was running a great risk of anything, but then I'm no expert. I didn't make any tests for performance or anything else (I don't really know how to test that stuff anyway, besides observing frame rates...), and I wouldn't be able to tell if the problems I had could've been caused by this.

11

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).

12

General / Re: Inconsistent time acceleration problem

« on: June 09, 2016, 09:56:06 am »

So I tried Gaffer On Games' way:

sf::Clock timer;
sf::Time elapsed;

(...)

float t = 0.0f;
float dt = 0.016f;
float currentTime = 0.0f;
float accumulator = 0.0f;

while(window.isOpen())
{
    // (...) // events

    elapsed = timer.getElapsedTime();

    const float newTime = elapsed.asSeconds();
    float deltaTime = newTime - currentTime;
    currentTime = newTime;

    if (deltaTime>0.016f) deltaTime = 0.016f;
    accumulator += deltaTime;

    while (accumulator >= dt)
    {
        accumulator -= dt;
       
        window.clear(sf::Color::Black);

        coreState.update();
        db.update();
        debuger.update();

        coreState.draw(terminal);
        terminal->render(&window);
        debuger.draw(&window);
       
        t += dt;
    }
    window.display();
    if (!running) window.close();
}
 

I didn't separate the drawing functions like he advises because I don't see a way to apply the same integration tricks he did, so if separate them I will get the visual stuttering he mentions.

I suppose I could pass the time into the update functions, but if that's is so, which one? t? dt? currentTime? I'm not resetting the clock now, though, so both the clock and t will go on forever. I have no clue whether that's a bad thing...

This does seem to solve my counter problems, even if I'm still doing the same thing I was doing in the World class with the timers, except I'm now counting more minutes at a time in the fastest time speeds.

I am, however, essentially doing two variations of the same thing in two different places, this one in the main() and the other in the World class. I wonder if that's a good idea, or if that's the way it should be.

There is an improvement in the frame rates. I now have ~1500 fps when unlocked, and I haven't even implemented Vertex Arrays instead of Sprites, yet.

13

General / Re: Inconsistent time acceleration problem

« on: June 08, 2016, 09:28:58 am »

Gonna try to fix the timestep to see how it goes. I'm currently just using the simplest:

// main.cpp

elapsed = timer.getElapsedTime();    // could've been restarting the clock here anyway
if (elapsed.asMicroseconds() >= 16666)
{
    window.clear(sf::Color::Black);

    coreState.update();
    debuger.update();

    coreState.draw(terminal);
    terminal->render(&window);
    debuger.draw(&window);

    window.display();

    if (!running) window.close();
    timer.restart();
}

I didn't think it was relevant before, to show much of the code, as I didn't think the problem might be rooted somewhere else (and I wanted to receive answers solely focused on this, not other possible unrelated mistakes), but since now I think it is, this is what I was doing:

I was creating the clock in the World class, as a quick and dirty experimental thing, since it makes sense to me that the World class gets to manage the world's time (either that or a specific time manager class, is what I figured). I'm keeping some global variables in a separate database while I don't know enough to organize things better, and that includes the world's time and date variables (so that the UI can also access them and show the clock).

This is all stuff that may change in the future anyway. I may want to display a visual rotating sun and moon or something else entirely, and end up not needing global variables or even an actual clock display, but meanwhile I'm going with this, since the numbers help me see if it actually works as intended.

So I had two clocks. One in the main loop, that I copied from a youtube video some months ago, and the other in the World class. I suppose the clocks wouldn't interfere with each other, but now I think there's no point in having two. I can use the main one to pass the time to the database, or pass the time down the update() functions.

Although, I wonder if sf::Clocks aren't something like sf::Fonts, that we shouldn't go wild with. I had never tried to actually understand timers and clocks until now.

14

General / Re: Inconsistent time acceleration problem

« on: June 07, 2016, 05:39:15 pm »

You didn't show where in your game loop you are resetting your clock, but I'm guessing this will be problematic because you are relying on your game being very fast for it to work.

I tried resetting the clock in several places. Was all the same, as far as I could tell.

But you just got me thinking about something I read on some other old thread, that maybe my actual problem is with me being drawing way too many Sprites, keeping the game busy drawing for too much time (at least that's the idea I got from there). I'm building graphics by tiles, to mimic consoles/terminals (much like roguelikes do), and using two vectors<Sprite> as buffers, one for graphics, the other one for text. Even if the text buffer is only initialized with null pointers to Sprites, I still have a minimum of 4000 Sprites (80x50) in the other buffer at all times (only two Textures (tilesets), though).

I was thinking of converting it all to vertex arrays. My game runs exactly 10x faster if I turn off the drawing functions. Goes from 150fps (unlocked) to 1500fps.

Maybe I should do that first, and then see if the problem persists?

(EDIT:forgot to mention, yes, I'm trying to fast forward. If you've played Jagged Alliance 2 or X-Com Apocalypse, I'm trying to do something very similar)

You may want to consider using my small timing library, Kairos, which includes a clock (called Continuum) that can be paused and have its speed adjusted; it can even go backwards!

Thanks. That might actually be useful.
I want to see if I can understand my mistakes first, though...

const float clockDivision = 10.f;
const sf::Time elapsedTime = clock.getElapsedTime();
const sf::Time processedTime = elapsedTime / clockDivision;

processedTime would be ten times slower.

Then, I guess that by multiplying it I could make it faster, too.

15

General / Re: Inconsistent time acceleration problem

« on: June 07, 2016, 04:33:33 pm »

Indeed the name elapsed is a placeholder. Got it from tutorials.

But maybe I'm missing something in what you told me, it doesn't seem to work. I got rid of += in passing the clock's value to elapsed. But now, how exactly would you get the difference into frameTime? I'm supposing you'd use even more sf::Times?

(by the way, can we use many sf::Times, and with the same clock?)

Some problems I noticed: if I reset the clock, it works, but delays a lot, being slower than I want it to be (never getting 4h/s), so it's part of the problem I was having before; if I don't reset the clock but reset elapsed, the latter will reach 2 million, be reset to zero, and from then on will always receive a value that is over 2 million from the clock, since the clock never stopped adding up.

That will make any if statement in the switch always be true on every frame (minutes will go wild and hours will go 1h/s - regardless of time speed, which confuses me), forever, or until I finally reset the clock.

If I had a way to divide the clock's value to reach something lower that could be relatively accurate...
My math is quite rusty though.

The thing is, I could be doing all this really easily by just calling countHours()directly at every quarter of a second, but then I wouldn't be counting the minutes - they would halt on the counter. It was my intention to have them rolling fast, for a nice visual effect and for a better sense of the speed at which the time is passing. EDIT: or maybe I could count minutes, a few at a time.