Messages

16

Graphics / Re: Efficiency question

« on: April 26, 2015, 10:22:47 am »

don't draw the sprites which are not visible. the current version draws them all, no matter, whether or not they fall into the game view.

17

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 25, 2015, 08:56:44 pm »

thank you.
I tried your approach. in this case when it freezes and I come back to the tty where the GDB is running, it immediately quits and says something like ".[Inferior 1 (process xxxx) exited normally]".
Also, nothing happens when I set a breakpoint at the line having "window.close();". it ignores it somehow.

18

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 25, 2015, 07:49:46 pm »

I cannot break in the debugger when the fullscreen applications hangs at exit, unfortunately. All desktop environment freezes and I cannot get to the gdb session.

19

General / Re: "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 23, 2015, 11:12:51 am »

okay, I manager Pong to hang on quit:

 sf::RenderWindow window(sf::VideoMode::getFullscreenModes().front(), "SFML Pong",
                            sf::Style::Fullscreen);
 

this is my change in the Pong source code. It hangs, yes, but, it does not output any error messages on the console. Sorry, I have forgotten to mention that my application produces those errors in the console randomly. I.e. I might or might not see them at a particular run. So, the behavior is 100% the same, I'd say.

Out of curiosity I printed out all the available fullscreen modes:

1366x768 BPP 32
1360x768 BPP 32
1280x720 BPP 32
1024x768 BPP 32
1024x576 BPP 32
960x540 BPP 32
864x486 BPP 32
800x600 BPP 32
720x405 BPP 32
680x384 BPP 32
640x480 BPP 32
640x360 BPP 32
1366x768 BPP 24
1360x768 BPP 24
1280x720 BPP 24
1024x768 BPP 24
1024x576 BPP 24
960x540 BPP 24
864x486 BPP 24
800x600 BPP 24
720x405 BPP 24
680x384 BPP 24
640x480 BPP 24
640x360 BPP 24
1366x768 BPP 16
1360x768 BPP 16
1280x720 BPP 16
1024x768 BPP 16
1024x576 BPP 16
960x540 BPP 16
864x486 BPP 16
800x600 BPP 16
720x405 BPP 16
680x384 BPP 16
640x480 BPP 16
640x360 BPP 16
1366x768 BPP 15
1360x768 BPP 15
1280x720 BPP 15
1024x768 BPP 15
1024x576 BPP 15
960x540 BPP 15
864x486 BPP 15
800x600 BPP 15
720x405 BPP 15
680x384 BPP 15
640x480 BPP 15
640x360 BPP 15
1366x768 BPP 8
1360x768 BPP 8
1280x720 BPP 8
1024x768 BPP 8
1024x576 BPP 8
960x540 BPP 8
864x486 BPP 8
800x600 BPP 8
720x405 BPP 8
680x384 BPP 8
640x480 BPP 8
640x360 BPP 8
1366x768 BPP 4
1360x768 BPP 4
1280x720 BPP 4
1024x768 BPP 4
1024x576 BPP 4
960x540 BPP 4
864x486 BPP 4
800x600 BPP 4
720x405 BPP 4
680x384 BPP 4
640x480 BPP 4
640x360 BPP 4
1366x768 BPP 1
1360x768 BPP 1
1280x720 BPP 1
1024x768 BPP 1
1024x576 BPP 1
960x540 BPP 1
864x486 BPP 1
800x600 BPP 1
720x405 BPP 1
680x384 BPP 1
640x480 BPP 1
640x360 BPP 1

But anyway the first mode is correct (my desktop environment uses 1366x768 resolution).

20

General / "Unhandled event type: 85. Report this to the SFML maintainers if possible"

« on: April 23, 2015, 09:05:10 am »

Good day.

I am using the latest SFML from git (commit e0d27358fb9d62fcba96e1d14fa3185ce63668e9) and just caught this error message when the application quits:

X Extensions:
   Generic Event Extension - First event: 0
   SHAPE - First event: 64
   MIT-SHM - First event: 65
   XInputExtension - First event: 66
   XTEST - First event: 0
   BIG-REQUESTS - First event: 0
   SYNC - First event: 83
   XKEYBOARD - First event: 85
   XC-MISC - First event: 0
   SECURITY - First event: 86
   XFIXES - First event: 87
   RENDER - First event: 0
   RANDR - First event: 89
   XINERAMA - First event: 0
   Composite - First event: 0
   DAMAGE - First event: 91
   MIT-SCREEN-SAVER - First event: 92
   DOUBLE-BUFFER - First event: 0
   RECORD - First event: 0
   DPMS - First event: 0
   Present - First event: 0
   DRI3 - First event: 0
   X-Resource - First event: 0
   XVideo - First event: 93
   XFree86-VidModeExtension - First event: 0
   XFree86-DGA - First event: 95
   DRI2 - First event: 102
   GLX - First event: 104
   SGI-GLX - First event: 104
Unhandled event type: 85
Report this to the SFML maintainers if possible

It occurs only when I create render window with

sf::Style::Fullscreen

. When I press an ESC it hangs and doesn't close. In order to close it I had to switch to another virtual console (pressing CTRL+ALT+F2) and come back, then it closes and shows that message in the console.
 
It does not occur when I use one of the examples coming with SFML 2.2 though (I changed the Pong program source code to run the fullscreen mode).

I use Ubuntu 14.04.2 LTS 64bit on my notebook, Intel drivers are up-to-date.

According to the message I report it to you I'll be glad to give you more information regarding my system setup if you need. Thank you.

ps: some time ago I couldn't run my application in the fullscreen mode on the notebook. I mean, it ran okay, but it produced weird visual glitches, althought I hadn't experienced this problem when quitting. Now the visual glitches are gone (I made no changes in my program's source code since that time), but I have this error message on quit. Maybe it is relevant.

21

Graphics / Re: 4th Shooting statement not working in SFML game.

« on: March 14, 2015, 07:36:59 pm »

else if (dir = 2)

change it to

else if (dir == 2)

same goes for

else if (dir = 3)

22

Graphics / Re: Subtract Polygons From Polygons(Create Concave Shape)

« on: March 10, 2015, 02:50:15 pm »

Hi there.

I think I have a solution for your problem, at least I hope so. Okay, here we go.

Suppose we have:
convex shapes/polygons which represent the light areas (which we have calculated using the rays intersection algorithm or alike).
Let's call them *the visible areas*.

Now, the problem we are facing is that we want to draw all the scene's objects to the screen so that they became fully/partly invisible if they do not fall into the visible areas (see above).

Of course, having visible areas related to the screen, we might calculate the remaining polygons (i.e. an invisible ones), so that invisible areas + visible areas = the whole screen's rectangle.
They, presumably, will be represented as the concave shape(s). Then, having these invisible area(s) we can utilize the some of the approaches described here: http://en.sfml-dev.org/forums/index.php?topic=7427.0 There are at least 3 solutions  (with the 1st one being kind of slow). But computing the invisible areas polygons is not an easy task, which involves a lot of math, though of course it is possible.

I have an alternative solution which involves SFML's blend modes and RenderTexture.
Here it is:
1) instantiate a RenderTexture object filled with the transparent color.
2) draw the visible areas (i.e. your lights convex shapes, for example) onto it.
3) perform RenderTexture display method
4) instantiate a blend mode with alphaSrcFactor equal to zero, and alphaDstFactor equal to one.
5) draw all your scene's objects (which, possibly, should be only partly visible or not visible at all) onto the RenderTexture using the blend mode from the 4th step.
6) clear your renderWindow (i.e. the target surface) with the desired color, whatever the scene's background color you want.
7) draw your RenderTexture on top of the renderWindow

Here is a code snippet which demonstrates the problem (there're the two shapes: the red and the green rectangles. the scene's background color is blue):

#include <SFML/Graphics.hpp>
#include <SFML/Graphics/RectangleShape.hpp>
#include <SFML/Graphics/BlendMode.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Visible vs Invisible areas render");
    window.setVerticalSyncEnabled(true);
   
    sf::RenderTexture targetVisible;
    if (!targetVisible.create(window.getSize().x, window.getSize().y))
        return -1;
    //targetVisible.clear(sf::Color::Transparent); //!
           
    //visible shape
    sf::RectangleShape rectangle1;
        rectangle1.setSize(sf::Vector2f(100, 200));
        rectangle1.setFillColor(sf::Color::Green);
        rectangle1.setPosition(100, 200);    
       
        targetVisible.draw(rectangle1);
    targetVisible.display();
   
    /*
     * uncomment, if you want to have a look at the intermediate image
     * (it is the transparent rectangle with the small green rectangle drawn on it)
     * */
        targetVisible.getTexture().copyToImage().saveToFile("intermediate_result.png");
       
    //partly visible shape
    //sf::BlendMode bm; //!
    //bm.alphaSrcFactor = sf::BlendMode::Zero; //!
    //bm.alphaDstFactor = sf::BlendMode::One;  //!
   
        sf::RectangleShape rectangle2;
        rectangle2.setSize(sf::Vector2f(200, 400));
        rectangle2.setFillColor(sf::Color::Red);
        rectangle2.setPosition(150, 300);
       
        targetVisible.draw(rectangle2/*, bm*/); //!
        targetVisible.display();
           
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear(sf::Color::Blue);
        window.draw(sf::Sprite(targetVisible.getTexture()));

        window.display();
    }

    return 0;
}
 

Here is my solution:

#include <SFML/Graphics.hpp>
#include <SFML/Graphics/RectangleShape.hpp>
#include <SFML/Graphics/BlendMode.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Visible vs Invisible areas render");
    window.setVerticalSyncEnabled(true);
   
    sf::RenderTexture targetVisible;
    if (!targetVisible.create(window.getSize().x, window.getSize().y))
        return -1;
    targetVisible.clear(sf::Color::Transparent); //!
           
    //visible shape
    sf::RectangleShape rectangle1;
        rectangle1.setSize(sf::Vector2f(100, 200));
        rectangle1.setFillColor(sf::Color::Green);
        rectangle1.setPosition(100, 200);    
       
        targetVisible.draw(rectangle1);
    targetVisible.display();
   
    /*
     * uncomment, if you want to have a look at the intermediate image
     * (it is the transparent rectangle with the small green rectangle drawn on it)
     * */
        targetVisible.getTexture().copyToImage().saveToFile("intermediate_result.png");
       
    //partly visible shape
    sf::BlendMode bm; //!
    bm.alphaSrcFactor = sf::BlendMode::Zero; //!
    bm.alphaDstFactor = sf::BlendMode::One;  //!
   
        sf::RectangleShape rectangle2;
        rectangle2.setSize(sf::Vector2f(200, 400));
        rectangle2.setFillColor(sf::Color::Red);
        rectangle2.setPosition(150, 300);
       
        targetVisible.draw(rectangle2, bm); //!
        targetVisible.display();
           
    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear(sf::Color::Blue);
        window.draw(sf::Sprite(targetVisible.getTexture()));

        window.display();
    }

    return 0;
}
 

Compile with:

g++ ./test.cpp -lsfml-window -lsfml-system -lsfml-graphics

The 1st code snippet generates the image 1, the 2nd one gives us the image 2 from the attachment.

Now imagine that the green rectangle is your visible area, calculated from the lights and the red one is some scene's object which visibility is in question, depending on its location on the scene related to the visible lights area ;-)

Hope that helps.

23

SFML projects / Re: Witch Blast (dungeon crawl shooter)

« on: February 24, 2015, 10:13:01 am »

I like your last video. looks promising and amazing!
I am sorry if I bother you, but isn't there a memory leak:

void BubbleEntity::dying() {
     ...
    BubbleEntity* b1 = new BubbleEntity(x - 5 + rand() % 10, y - 5 + rand() % 10, bubbleSize + 1);
    BubbleEntity* b2 = new BubbleEntity(x - 5 + rand() % 10, y - 5 + rand() % 10, bubbleSize + 1);
   ...
}
 

or here:

 SpriteEntity* star = new SpriteEntity(ImageManager::getInstance().getImage(IMAGE_HURT_IMPACT), xs, ys);
 

and so on.

24

Graphics / Re: Sprite Transformation Batching

« on: February 02, 2015, 03:43:42 pm »

if you have such bug, then something is wrong with your "draw tiles" algorithm.
suppose you have two layers: background and foreground.
do I need to convince you that if you draw the background and only after that you draw the foreground, the foreground will be completely visible? it even doesn't matter whether you work with the isometric scene or whatever. the foreground will be visible *always* if you don't draw something *after* you drawn the foreground.

you draw tile,then you draw the object(s), then you draw the next tile, then the object(s) on it, etc.
no wonder that you have such issue.
instead do the following:
draw all the tiles which are visible at the current moment, and only after that you draw all the visible objects,
then it will be correct.

25

Graphics / Re: Sprite Transformation Batching

« on: February 02, 2015, 03:01:03 pm »

So you might argue: Render entire lines instead single cells. But an object might also overlap a tile from the next line.
So, culling first, drawing then seems more suitable

it is not a problem if you separate tiles draws and objects draws: draw all the visible tiles, then draw all the visible objects (as a result they will be drawn "upon" the tiles; achievement unlocked .

as for "heavy data dependencies". I am sorry, but you do have the heavy data dependencies already.

I still don't get:
1) why do you need to reposition/update all your game objects on each iteration. suppose there're tons of them.
2) why do you need to draw tiles and objects in one go.
3) why do you need to separate sprites data into sprite's data and its position/whatever, being pushed into the global vertex array
4) as for animations: why don't you update the sprites' texture regions during the update phase just in place (i.e. someEntity->updateTextureRegion()); in OOP approach I would put that in the "AnimatedEntity::update(float timeDelta)" method and Bob's your uncle)
5) why doesn't the classic render approach (has been mentioned a few times above) work for you.
6) did you perform any benchmarks which led you to the conclusion that the classic approach doesn't work for your requirements

26

Graphics / Re: Sprite Transformation Batching

« on: February 02, 2015, 02:21:41 pm »

...
for each object at this tile:
        add pointer to the object's sprite to the array
...
for each sprite pointer in array:
    draw sprite

how is it different from the classic way:

for each visible tile:
    draw tile
    for each object in tile:
        draw object
    end
end

?

Isn't it better to simply draw them "in the first place"?

and, as it has been already mentioned above, there's no need to rebuild the vertex array. if you know the index of the tile in the "global" vertex array, you can simply render just these 4 (speaking of tile) vertices directly as Ztormi explained.

moreover, if you know that "okay, I am iterating over the 4th row of tiles and there's a chunk of 10 tiles holding the same texture region" then you might even simplify the render: you might render all these 10 tiles in one go (again, utilizing the vertex array, and using the range [index_of_the_1st_tile's_vertex_in_array, index_of_the_10th_tiles_4th_vertex_in_array])!
for this example it might be, for instance, [5, 5+10*4], keeping in mind the tile consists of 4 vertices.

I'll try to clarify my approach in the pseudocode:

Code: [Select]

//1 = grass; 2 = dirt; 3 = water
tileMapVertexArray = [
1,2,1,1,1,1,1,2,2,2, //10 items
3,3,3,3,3,1,2,2,2,2  //10 items
...
]
here, if the first and second rows fall into the view area/screen region, you can draw them (if you still want to draw the tiles one by one)  using 7 draw operations only, not 20.

nevertheless I prefer just to draw the whole vertex array (where vertex array = your tile map's data).
if it is not tremendously big it is okay. otherwise I would partition it into the smaller chunks (also the vertex arrays) and draw some of them according to the visible region/screen.

hope that helps.

ps: why do you speak about objects as if they were tied to the tiles? what about this: draw the objects which are visible only.
you can get the visible ones using some math and their positions and it is not necessary needed to refer to the tiles to achieve that information.

27

Graphics / Re: Sprite Transformation Batching

« on: February 02, 2015, 09:45:05 am »

@Laurent , yes, I do agree.
I was discussing the scenario where one doesn't perform ".clean()' and just pushes the data over and over into a vector.
eventually it  will reach its maximum capacity and will need to perform reallocations.
if we do ".clean()", we might end up with having a large vector in memory with a few items for example, yet occupying a lot of memory. (now there's ".shrink_to_fit()" which might help).

28

Graphics / Re: Sprite Transformation Batching

« on: February 02, 2015, 07:55:24 am »

you store all object's vertices in a big vertex array on each iteration, wouldn't it be expensive?
i.e. I mean there's no need to draw all objects if there're only a few of them in the current view region/visible part of the game.
or am I missing something?
how many objects do you draw in average, 10, 100, 1000? if you draw them as a single vertex array, they must be the same, i.e. they hold same texture, is it so? otherwise there will be many "renderStates.texture = ..."  operations which has a big impact on the performance (swapping textures is not "free").

anyway, I believe that

pushing all object's vertices (as mentioned: only colored, not textured) to a huge vertex array while drawing.

is not a good idea. it is unrelated to the draw purpose IMHO. now you have a lot of problems coming from performing operations on a vector (vector grows -> it has a dramatic impact on performance, i.e. it needs to reallocate a new chunk  of memory big enough to hold the new data, then it must shift all the present items around, append the newly created ones in the end, etc).
hmm, do you recreate the vector on each draw iteration or reuse the present one?

have you tried to do "vector.reserve(...)"?
you might benchmark/measure/output that vector memory-related characteristics during the game and see what is going on with it internally. you might be interested in checking its  ".size()" and ".capacity()".

29

Graphics / Re: Sprite Transformation Batching

« on: February 01, 2015, 10:28:13 am »

To make the object move into camera view, it's position needs to be upated. Hence the transformation needs to be applied.

yes, but it is not necessary to actually move all your objects? say, there's a big dungeon with hundreds of enemies moving, is it crucial for you to move all of them always? if you consider chunking the dungeon into the smaller parts and update the enemies in the current chunk only (where the player is located for example), will it hurt your gameplay?  of course if you want all the enemies track the player (i.e. each second they're approaching towards the player location), then this approach might not work.
It is all about considerations, after all.

30

General / Re: Problem with smooth movement in 2d game (scrolling view, render interpolation)

« on: January 29, 2015, 09:27:29 pm »

I tried really hard to disable IGP, but it led to Nvidia driver (!) refused to load. Weird.
What I did: put i915 (Intel driver) into /etc/modprobe.d/blacklist, rebooted, checked that Intel IGP is not "detected" by the system. So far so good. Funny moment is that now I cannot enable my Nvidia card. nvidia-settings doesn't recognize it, reinstalling Nvidia drivers didn't help.

Then I removed my i915 entriy from the blacklist, installed i915 driver, removed nvidia one, rebooted and voilà, - I have stable 59-60 FPS running any SFML apps with/or without vsync enabled in the code. What matters is that there's no more tearing.

Looks like having hybrid graphics has its drawbacks, or maybe it is an Nvidia fault. I still don't get why I couldn't force Nvidia to work with vsync.