Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Silderan

Pages: [1] 2
1
Graphics / Re: Sprite Transformation Batching
« on: February 02, 2015, 02:55:36 pm »
IMHO....

update time
move_player();
move_camera();
clear_viewable_list();
for each animated_object // Not just viewable or you'll loose IA on non-seen NPCs
{
    apply_position_up_to_physics();
    if( is_object_viewable )
    {
        add_to_viewable_list();
        update_textures_source_rect();
    }
}
if( camera_points_to_new_tile_position )
    update_tile_vertex_array_positions_and_textures_source_rect();
 

drawing time
draw_vertex_array(); // The tilemap.
for each object in viewable_list
  draw(object);
 

I don't see the needs for "dirty" flag thanks to viewable_list that avoids the re-loop entire animated objects again in drawing time.

Well, it's so simplified. For example, not sure how handle when player is behind a tile xD

2
Graphics / Re: Sprite Transformation Batching
« on: February 01, 2015, 11:33:53 am »
Well, without transformation everything runs smooth - also over those 1k objects. Each one is picked, each one's dirty flag is checked and then nothing is done (if transformations are disabled in code). And because no optimization is applied, the compiler won't optimize that in any way.
I see... then, too hard to understand where is the bottleneck indeed. Seems that the problem is at transformation.
Just an idea, if it makes any sence for you, of course... you talk about rotation, position and scale. Did you tried to use sprite->setPosition and change animation textures instead of rotating objects? setPosition instead transformation may (shall) not make any change, but rotation... :P

3
Graphics / Re: Sprite Transformation Batching
« on: January 31, 2015, 11:01:28 pm »
But, a orthogonal to isometric view conversion is not a "transformation" that must be applied to all objects.

Up to view size and position, you must be able to know the tiles and objectes that must be shown in screen using orto to iso conversion. As I understand from your posts, you apply orto to iso conversion on all tiles and objects. That's a wrong aproach, IMHO.
Anyway, not sure if this is the problem. The main problem is the objects iteration, not the maths involved per object transformation apply... if 1K objects move... doesn't mathers if you just make two or four math operation... the problem is the 1000 object batch... and you cannot avoid it :P Well, yes, you can. I have some years of experience with a text MUD games where is quite normal having many objects. The solution is to keep living objects at minimum. I can tell you some tips if you want.

Silderán.

4
Graphics / Re: How to improve rendering with big vertex size?
« on: January 31, 2015, 08:29:47 pm »
For sure, it's my fault as is hard to me to write in english. :P

- I don't know how SDL works. I tested a game engine based on SDL.
- I'm not trying to display 1Milion tiles!!! Maybe some day with 100" screen with ultra-hyper-high-definition xDD
- It's not a render problem. It's how to handle big tile maps. After reading some posts arround here I see that I must reduce the vertex array size used for draw() (culling). I start from tutorial and tile map and vertex array has the same size (well, vertex is 4x because of Quad) I didn't thought about culling. Furthermore, as vertex array is one dimension and view is two dimension (at least) there is no direct way for culling... or I don't know!!!

Right now, I think the best way to do that is:
- Allocate a vertex array just for the view needs.
- Every time the view moves, recalculate the vertes array view positions and texture source squares.

Reading your answers I can realize that you take for granted some things that I don't. That means that I must read much more.

Thank you all for your infinite patience xD

Silderán.

5
Graphics / Re: Sprite Transformation Batching
« on: January 31, 2015, 07:55:35 pm »
As the other post.. maybe I will say another stupid thing... more seeing your amazing "Rage". But, objects positions, scaling and rotation is up to logic/physics, because graphics "just" interprets this. I think that's what Hapax post is saying, and I agree. Of  course, this is a point of sight and doesn't changes your needs for improving transformations to increase FPS.

This is what comes to my mind. But, for sure, you'd considered and/or you won't gain many speed with it:
1. Refactor game logic to reduce the object transformation update needs (As you said, not possible)
2. Improve maths/code (practically useless because of modern compilers optimizations).
3. Reduce at all recursivity.
4. Reduce allocations (global or local -stack-)
5. Memory array (data[ i ]) much faster than linked lists. If you have some linked list (or tree) and you MUST have it, consider to create an array with the list/tree nodes for quicker iterations.
6. Multithread. With...
6.1 Lock entire objects transformations, so game logic must wait for it and code complexity is so low. Maybe, you won't gain many speed.
6.2 Make some kind of "transformations queue" without locks. More speedy but some frames may show objects deformed.
6.3 Locks at object transformation. You'll ensure to don't see any object deformed, but some object can be transformed and other one doesn't.

Sorry if it doesn't helps you or if my english is cryptic :P

BTW: Is this "problem" for Rage? Are you trying to animate all game NPCs?

Silderán.

6
Graphics / Re: How to improve rendering with big vertex size?
« on: January 30, 2015, 10:36:29 pm »
As I said, it's just for learning how to do that because someone talks about 1 milion tile map as if it was quite ussual. Furthermore, I tested a graphic game engine, based on SDL, with spacific APIs for tile maps and FPS doesn't change regardless of map size.

Silderán.

7
Graphics / Re: Sprite Transformation Batching
« on: January 30, 2015, 10:23:52 pm »
For sure, it's an stupid question but... Do you need to perform transforms to such amount of objectes? Can't you appy the "dirty" flag to the non-seen objects and apply transform when needed... or the transform itselfs may move the object to/from camera view and you cannot avoid from applying transform to all?

8
Graphics / Re: How to improve rendering with big vertex size?
« on: January 30, 2015, 09:07:11 pm »
It's release mode. But on debug gives me 36 FPS :)

Do you think that 39 FPS is too low with a 1M map?
It's 39 milions of square comparations per second plus rendering tiles + text.
For that reason, I thought that must be something to improve this. But don't know if SFML has something or I must code it by my own.

Another way I thought is to create a vertex array just for screen view and update their values accordingly to camera position.

Silderán.

9
Graphics / Re: How to improve rendering with big vertex size?
« on: January 30, 2015, 12:07:56 am »
Yes, you're right... it's simpler :) Maybe you had bad luck. I got 39 FPS in this computer with mine and your code version.

Not sure if 1M tiles is big, huge or insane XD
But, for sure, 30 FPS is not good because there is nothing more than rendering: No IA, no player interaction, no music, no collision, no effects...

Thanks for your attention, Hapax! :)

Silderán.

10
Graphics / How to improve rendering with big vertex size?
« on: January 29, 2015, 02:51:46 pm »
Hello.

I've tested vertex array as explained in this article and works fine. But, when the array size is so big, FPS drops.

I'm not going to use such size of array, but I'm curious of how to do it correctly.

That's the code:
#include <SFML/Graphics.hpp>
#include <time.h>
#include <cstdio>

const int tilesX = 1000;
const int tilesY = 1000;

class TileMap : public sf::Drawable, public sf::Transformable
{
public:

    bool load(const std::string& tileset, sf::Vector2u tileSize, const int* tiles, unsigned int width, unsigned int height)
    {
        // load the tileset texture
        if (!m_tileset.loadFromFile(tileset))
            return false;

        // resize the vertex array to fit the level size
        m_vertices = new sf::Vertex [width * height * 4];

        // populate the vertex array, with one quad per tile
        for (unsigned int i = 0; i < width; ++i)
            for (unsigned int j = 0; j < height; ++j)
            {
                // get the current tile number
                int tileNumber = tiles[i + j * width];

                // find its position in the tileset texture
                int tu = tileNumber % (m_tileset.getSize().x / tileSize.x);
                int tv = tileNumber / (m_tileset.getSize().x / tileSize.x);

                // get a pointer to the current tile's quad
                sf::Vertex* quad = &m_vertices[(i + j * width) * 4];

                // define its 4 corners
                quad[0].position = sf::Vector2f(i * tileSize.x, j * tileSize.y);
                quad[1].position = sf::Vector2f((i + 1) * tileSize.x, j * tileSize.y);
                quad[2].position = sf::Vector2f((i + 1) * tileSize.x, (j + 1) * tileSize.y);
                quad[3].position = sf::Vector2f(i * tileSize.x, (j + 1) * tileSize.y);

                // define its 4 texture coordinates
                quad[0].texCoords = sf::Vector2f(tu * tileSize.x, tv * tileSize.y);
                quad[1].texCoords = sf::Vector2f((tu + 1) * tileSize.x, tv * tileSize.y);
                quad[2].texCoords = sf::Vector2f((tu + 1) * tileSize.x, (tv + 1) * tileSize.y);
                quad[3].texCoords = sf::Vector2f(tu * tileSize.x, (tv + 1) * tileSize.y);
            }

        return true;
    }

private:

    virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const
    {
        // apply the transform
        states.transform *= getTransform();

        // apply the tileset texture
        states.texture = &m_tileset;

        // draw the vertex array
        target.draw(m_vertices, tilesX * tilesY * 4, sf::Quads, states);
    }

    sf::Vertex *m_vertices;
    sf::Texture m_tileset;
};

int main()
{
    // create the window
    sf::RenderWindow window(sf::VideoMode(800, 600), "Tilemap");

    // define the level with an array of tile indices
    int *level = new int[tilesX*tilesY];

    for( int i = tilesX*tilesY-1; i>=0; i--)
    {
        level[i] = rand()%12;
    }
    // create the tilemap from the level definition
    TileMap map;
    if (!map.load("tileset.png", sf::Vector2u(32, 32), level, tilesX, tilesY))
        return -1;

    sf::Text text;
    sf::Font font;
    font.loadFromFile("consola.ttf");
    text.setFont(font); // font is a sf::Font
    text.setString("FPS: wait...");
    text.setCharacterSize(24); // in pixels, not points!
    text.setColor(sf::Color::Red);
    text.setStyle(sf::Text::Bold | sf::Text::Underlined);

    sf::View vistaPj = window.getView();
    sf::Vector2f centerPj = vistaPj.getCenter();
    int frames = 0;
    int frameTime = time(0);
    // run the main loop
    while (window.isOpen())
    {
        // handle events
        sf::Event event;
        while (window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
       }

        // draw the map
        window.clear();
        window.draw(map);
        if( frameTime != time(0))
        {
            static char tmp[256];
            snprintf(tmp, 256, "FPS: %d", frames);
            text.setString(tmp);
            frames = 0;
            frameTime = time(0);
        }
        window.draw(text);
        window.display();
        frames++;
    }

    return 0;
}
 
For it to work, you'll need a Tileset, for example: https://vxresource.files.wordpress.com/2011/05/tileeyl5.png (don't forget to rename it "tileset.png" and place it at correct folder) And "console.tff" font to see FPS count.
As you can see, I've changed VertexArray to a simple Vertex[]. I did it just for testing another draw() function that gives to me more control about the chunk of vertex to draw.

Low FPS are quite normal as draw() must iterate through all vertex, searching for the vertex ones to be drawn.

I think that the solution is to call one draw() per tile line, with the vertex pointer and size up to view possition.
What do you think?

11
Graphics / Re: Bomberman's deplacement style
« on: January 27, 2015, 02:32:57 pm »
I think TheNess gives you the correct answer.
Maybe you coded like this:

if( up_pressed() )
{
    if( can_move_up() )
        move_up();
}
else
if( down_pressed() )
{
....
}
else
...
 
So, player won't chose the avaiable direction.

By the way, I prefer modify TheNess code in that way:

// do movement:
if (key_up_pressed && can_move_up):
{
    move_up();
    animate_run_up();
}
else if (key_down_pressed && can_move_down):
{
    move_down();
    animate_run_down();
}
if (key_left_pressed && can_move_left):
{
    move_left();
    animate_run_left();
}
else if (key_right_pressed && can_move_right):
{
    move_right();
    animate_run_right();
}
else
{
    // do animation
    if (key_up_pressed):
        animate_run_up();
    else if (key_down_pressed):
        animate_run_down();
    else if (key_left_pressed):
        animate_run_left();
    else if (key_right_pressed):
        animate_run_right();
}
 
If I'm not wrong, this way the player won't do the "moonwalk" 8) facing up and moving left (for example)

12
Graphics / Re: Zoom a sf::View to Mouse-Point Center?
« on: January 27, 2015, 02:04:15 pm »
I agree with Laurent.

I have some code to do that but is not correctly done due to pixel maths and don't zoom out well. But, no jumps. As I don't need this feature right now and code is just to test Scale feature, I will repair code later.

I don't have the code right now but I can give it to you this night (Spain night time) if you like.

Silderán.

13
Graphics / Re: tile glich.
« on: January 26, 2015, 09:06:51 pm »
Maybe I'm saying some stupid thing but... what about tile *tileArray = new tile[1000x1000];?
Sometimes we understimate c++ basis or overstimate stl, if you prefer xD

By the way, out of topic but... I've tried a million tile map (1000x1000) using vertex tutorial and FPS drops to less than 40. Must I perform some kind of map render clip? I though that was the SFML rendering engine (through it's View coords) who does that. Maybe I've coded something wrong.
I've tested another game engine based on SDL (not OpenGL directly like SFML) and doesn't care map size at all.

Silderán.

14
Graphics / Re: tile glich.
« on: January 20, 2015, 10:37:56 pm »
Thank you very much to both...

I didn't read all SFML docs. I saw other forum thread about tile map and get that code. But, vertex is much more impressive approach :)

eXpl0it3r, you're right. I didn't modify code for your use out of the box. I appology.
This code is not for "real" use. Tile map matrix, of course, must not be into stack. But, for testing, it works.
I agree. Must be the graphic driver as there is no "other code". TileMap class has only the renderMap() function  called from main(). I will test this program on other computer.

Hapax, thanks again for your tip. For sure, I will use vertex :)
Can you please tell me why do you prefer 1D vector instead 2D matrix?
Maybe because I won't need double "for" anymore?

Thanks again!

Silderán.

EDIT: I've compiled with DLL, and statically with the same tile flashing. As I don't have another computer in home to test it, i've uploaded on my GDrive. Here it is if you like to test: https://drive.google.com/file/d/0BzTQYbPFSWp2dEZJd1hBa3g3dDA/view?usp=sharing

EDIT2: XDDD I run it ussing my NVIDIA graphic card instead intel embedded and tile doesn't flash. So, here is the problem :P

15
Graphics / tile glich.
« on: January 20, 2015, 12:18:21 am »
I've write down this code and when tiles are 23x23 or more, one of them begins to flash:
const int tileW = 10;
const int tileH = 10;
const int tilesX = 23;
const int tilesY = 23;
void TileMap::renderMap()
{
        window = new sf::RenderWindow(sf::VideoMode(800, 600, 32), "Tile Map");
        int x, y;
        sf::RectangleShape tiles[tilesX][tilesY];
        for (x = 0; x < tilesX; x++)
        {
                for (y = 0; y < tilesY; y++)
                {
                        tiles[x][y].setSize(sf::Vector2f(tileH, tileW));
                        tiles[x][y].setFillColor(sf::Color(x * (255/tilesX), y * (255/tilesY), 0));
                        tiles[x][y].setPosition(sf::Vector2f(x * tileW, y * tileH));
                }
        }
        while (window->isOpen())
        {
                sf::Event event;
                while (window->pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window->close();
                }

                window->clear();
                for (x = 0; x < tilesX; x++)
                        for (y = 0; y < tilesY; y++)
                                window->draw(tiles[x][y]);
                window->display();
        }
}


What is wrong with my code?

EDIT: I think the error is in color as when I use a fixed color for entire tiles, works fine.
But, just fixing color of flashing tile, don't solve:
                        if (x == 22 && y == 19)
                                tiles[x][y].setFillColor(sf::Color::White);
                        else
                                tiles[x][y].setFillColor(sf::Color(((x * (255/tilesX)) % 254), ((y * (255/tilesY)) % 254), 0));
 

Pages: [1] 2
anything