Messages

9181

General / Re: Rendering large number of sprites with similar characteristics

« on: November 20, 2012, 01:33:06 am »

My question is, what do you make of this approach? Is it worth it, and if not, why, and do you think it may affect my performance?

There's never the best way, it always depends on what you really want to do. If you're really concernded about the performance you should test the different versions and use the one that performed best, but keep in mind that it might run differently on other machines (due to different graphics cards/drivers/CPU/etc.).

I don't know how big your textures are, but in most of the cases it would be probably better to save them all into one image and load this once, instead of having x different textures lying around. You then can simply move the texture rect instead of changing the texture. Performance wise the two operation are quite equal, but if I'm not mistaken the switching between different textures (on the GPU) isn't the cheapest operation.
You can use one sprite, which will use a bit less memory. For the performance, if you use the sprites a lot then you might want to have them all in memory, this way you'd only have to set the position ones and not every iteration for every image, but it also won't have a hug influence.
You could also think about using a VertexArray for this kind of task. Not sure how the performance will be though.

9182

Graphics / Re: White sprite

« on: November 20, 2012, 12:58:28 am »

I hope to be able to release SFML 2 and the new website soon enough. The current website is like SFML 1.6: still the latest official "release", but totally unmaintained

I'll believe it only when it actually has happened and even then I'll verify it at least one hundred times.

9183

Graphics / Re: how to draw like this?

« on: November 19, 2012, 08:37:37 pm »

You can use a sf::Image and call setPixel to set a specific color to that pixel and then call loadFromImage on a texture, reference the texture in a sprite and draw it to the screen.
Repeat the first two steps every frame iteration.

But keep in mind that loadFromImage is a heavy operation, thus you'd be probably better off with some shader, but this needs some more knowledge and I think you're not ready for it atm.

9184

General / Re: Using GLEW with SFML

« on: November 19, 2012, 06:05:57 pm »

SFML comes with it's own GLEW version and already initializes it, so afaik you don't/shouldn't try to init it again.
Then there's the problem when you want to use your own GLEW version described here...

9185

Graphics / AW: Re: Help in sf::text

« on: November 19, 2012, 12:49:07 pm »

Thank you so much, I didnt know that I have to link sfml-system because sf::Text is part of sfml graphics module.

But sf::String (as complained about by the linker) is in the system module and also alot of other badic ghongs like sf::Vector2. The graphics module depends on the window module and both depend on the system module.

9186

SFML projects / AW: Re: Open Hexagon - challenging fast paced game

« on: November 19, 2012, 09:01:03 am »

Thanks for the report. Does this happen with the latest version (1.11)? I made some changes in the polygon spawning from 1.0.

Yes it's with the latest one.

9187

Graphics / Re: Explanation of interactions between Image, Texture, and Sprite?

« on: November 19, 2012, 02:01:35 am »

Well good luck with your attitude then, I don't like it, but who am I and why would you care?

Does all of this mean I'm responsible for the lifetime of the texture?  I can't assume that it's going to be cleaned up after there are no more references to it?  I don't mean the representation on the video card, I mean the object itself.

What?
sf::Texture is not a smart pointer or anything. It's a normal object and one always have to take care of the lifetime of the object one is using...

For example:

// tex doesn't exist
void foo()
{
    sf::Texture tex;
    // tex exists
} // tex gets released/deleted
// tex doesn't exist

So, even though the constructor for sprite takes a *reference*, it's assumed that reference is to heap memory, or the sprite is not going to last past the current scope?

No it can be on the stack, but it (the texture) has to exist when you call window.draw(sprite).

For example this would work

void foo(sf::RenderWindow& rw)
{
    sf::Texture tex;
    tex.loadFromFile("img.png");
    sf::Sprite spr(tex, true);
    rw.clear();
    rw.draw(spr);
    rw.display();
} // tex & spr get released/deleted

9188

SFML projects / Re: Open Hexagon - challenging fast paced game

« on: November 19, 2012, 12:39:34 am »

Btw. why didn't you make them pentagons/octogons/etc to differentiate yourself?

There are some, you just need to keep going, I unfortunately die most of the time too early.
Additionally I guess you could change the level the way you want it to be.

There seems to be a bug where sometimes the big black trapeze shape doesn't match the other smaller ones. Unfortunately screen-print just returns a white image, so I'll have to use some other trick to get you an image (if you need it). But what the trigger is for that behavior is not clear to me.


And here's a short clip that shows when it happens, maybe it gives you some clue:

9189

Graphics / Re: Font .loadFromFile throwing a access violation.

« on: November 19, 2012, 12:35:56 am »

Okay, you should never draw/display anything inside the event loop. It not only will lead to strange behavior (an event gets only triggered occasionally if you do something) but it's also very bad practice.
You should also never call window.display() twice in one iteration, because the second one will overwrite the first one.
And as already said, you should always clear (window.clear()) the render window before drawing anything on it.

As I already said, I can't help you further, because I'm not gonna guess what could maybe be to cause that comes from code XYZ I don't have access to. If you can confirm that this minimal and complete example does also crash, then it's something with SFML/your setup. If not, then it's something in your code.

#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
    sf::RenderWindow window(sf::VideoMode(1024, 765), "Mandelbrot");
    window.setFramerateLimit(60);

    sf::Font font;
    if(!font.loadFromFile("PATH-TO/arial.ttf"))
        std::cout << "OMG OMG OMG!" << std::endl;

    sf::Text text("Test Text 123", font, 20);
    text.setPosition(20.f, 20.f);

    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(text);
        window.display();
    }
}
 

9190

Graphics / Re: Explanation of interactions between Image, Texture, and Sprite?

« on: November 19, 2012, 12:21:04 am »

Hey I can also make nice listings

• All the answers in here are free and all the time spent to answer in here is taken their responses free time. If you expect a high-quality, book-perfect answer you're way off here. As a tip, appreciate every answer you get, because it's not very common, that people spend evenings just answering questions, which the asking person could find the answer to it on their own, if he just spent some more time researching the tutorials, the documentation, the source and the concepts of C++.
• I was typing on my phone and didn't want to write an complete essay on my touch keyboard. So I apologize that I didn't add tons of examples.
• Although I didn't answer your questions directly, I did tell you the solution to the actual problem, so my answer wasn't just useless or anything. It just wasn't complete.
• I'm aware that ranks and all don't really matter, but it's just very sad to see people join a new forum, totally unaware of their surroundings, what the rules are, how people talk to each other, etc. and the within in the first few posts just show their hate/annoyance towards members that have been around for quite a bit and help quite a few people. I personally try always to be most respectful to anyone when I join a new community. It preserves the atmosphere and you as newbie gain some respect in return.

I gave you enough of an example to see exactly what was needed.  It was enough or you wouldn't have been able to point out the issue.  I made a subjective decision on that, and it was the right decision.  Don't ask for a complete code listing when I gave you enough.  Ask for a complete code listing when I don't.

I never requested a full listing for your current code, I simply said "Also for further post", which obviously doesn't include this one. I gave you this advice since I saw that you're new to this forum and most of the new comers don't even think about providing complete examples and me having to answer in every other post "please provide a complete and minimal example that reproduces the error" gets quite annoying too. Prevention is better than reaction.
Besides that, I can request whatever I want, like: "I want a chocolate cake from you."
But you're not forced to follow my requests. (It's called freedom of speech and freedom of decisions.)

1.  Tell me my code is using bad practices for SFML, but choose not to link me to anything I can actually learn from, and

• Don't pass the window as pointer, pass it as reference. Also instead of passing by value (e.g. std::string), pass them as const reference.
• Don't use arrays, specially if you have to pass it around. If you (for some reason) don't want to use std::vector then at least use std::array (TR1/C++11). The problem with a pure array is, that you never really know it's size and thus you'll have to use many hard coded numbers or other not so nice hacks.
• Don't create a additional sprite object just to initialize it, if you're only purpose is to copy that object to another place later on. E.g. just use setTexture() to set the texture instead of sp(bt).

But then again this is all some mock-up code, so maybe you usually do follow all of these things.

2.  Failed to answer the question I specifically asked for.  Which is, what is the interaction between images, textures, and sprites.

sf::Image is a representation of an image and lives on the RAM.
sf::Texture is a representation of an image and lives on the memory of the GPU.
To get a sf::Texture things get internally loaded as a sf::Image and then copied to the GPU's memory. This operation is slow, thus one shouldn't have to copy stuff from the RAM to the GPU memory too much.
sf::Sprite holds a reference to a sf::Texture. If the reference is dead, i.e. the sf::Texture went out of scope or no texture has been set, then you'll get a rectangle filled with the color defined for the sprite.

To get picture on the screen, these rules need to be followed:

• The image file must exist and be conform to the types SFML supports.
• The texture has to in a scope where it exists as long as the image is needed.
• The sprite has to reference the texture.

Am I expected to keep the images around as well, or do the underlying textures share the images?

sf::Image and sf::Texture are both representation of images (i.e. pure memory), thus you actually only need sf::Texture to display something on the screen.

How and when are they released?

The SFML objects use all RAII (google it), thus they get released as soon as they leave the scope.

and the documentation for SFML is hard for me to find.

You mean what you're looking for is hard to find in the doc right?
The doc is easy to find, here.

If your critique was of the general quality of the C++ code, I would ask you to be quiet.  It's tetris.

Don't post stuff nobody should ever see or comment upon.

I really want your input, but you didn't really give it.  It certainly wasn't enough to help the next person who finds this thread, or to keep me from running into other problems because I don't have the proper mental model for how these things interact with each other in SFML (and I mostly mean from a memory standpoint).

Read, learn, experiment.

Do I now get paid for my 30+min essay just for you?

9191

Graphics / Re: Font .loadFromFile throwing a access violation.

« on: November 18, 2012, 11:36:40 pm »

Well the issue there is, that wouldn't show how I'm referencing anything, and would likely cause me to never be able to re produce the issue, thus finding no fix for it since it cannot be re produced.

Well then you'd do it wrong. If you know that the problem doesn't exist for a minimal example, then you should write this, so we can indefinitely exclude SFML as the source of the problem. And since the minimal example doesn't show the problem you'd have to go the other way, the harder way. Strip down everything unrelated of your code until you end up with very few lines that reproduce the problem. Going this way will often solve the problem on its own, since the mistake gets clear to you at some point.

void DevHud::printToWindow(EngineWindow& glWindow)
{
        glWindow.draw(CurserPosText);
        glWindow.display();
}
 

You should always clear the window before drawing anything (except if that happens outside of this class, but then you shouldn't call display within this class).

class DevHud{
        Font font;

        sf::Font DevHudFont;
};
 

Having a class with the name Font next to sf::Font doesn't seem that nice. What does your Font class do, because it probably should have a different name...

But overall I don't see why your application should go nuts at the font loading operation. With a complete example one might find out where you screw up earlier.

9192

Graphics / Re: Explanation of interactions between Image, Texture, and Sprite?

« on: November 18, 2012, 10:44:46 pm »

Tetrimino buildTetrimino(...) {
    sf::Texture bt;
    // ...
    return tet;
  }
 

You create a texture within your function, thus as soon as the function is left the texture will get destroyed = white rectangle.
The texture has to be kept alive as long as it's in use.

Also for further post, please make use of the code=cpp tag to highlight your code examples and provide complete and minimal examples, rather than providing some pieces of your live code.
Additionally this post gives some guidance towards nice posts, which is directly connected to fast and precise answers.

PS: There are quite a few bad practices in your code. Maybe you could take a look at some more example code in the forum.

9193

General / Re: Stack corruption bug with sf::Shape

« on: November 18, 2012, 10:39:42 pm »

This is with Visual Studio 2012, standard compiler, SFML2 RC (downloaded like a week ago).

Does that mean you downloaded it from the official download page or from GitHub and built it yourself?
Because for VS 2012 you have to build SFML newly (or use my nightly builds).

9194

Graphics / Re: Font .loadFromFile throwing a access violation.

« on: November 18, 2012, 10:22:19 pm »

You still didn't get what a complete and minimal example is though.
Complete means, there's not a single left which needs to be added to compile and run it.
Minimal means that it exist only out of the most basic set of commands/function calls/variables which are needed to reproduce the error. At best just a few lines within the main function.

If you'd provide such an example, we could most likely tell you with a simple look whar's wrong, if you wouldn't have found it on your own by then.

9195

SFML projects / Re: Open Hexagon - challenging fast paced game

« on: November 18, 2012, 07:18:48 pm »

I encourage you also to try the original game, Super Hexagon.

I would but it seems as of right now it's only available for iOS and since I don't like Apple, I don't own any iOS devices.

Btw if I'm/Google is not mistaken it's Terry Cavanagh and not Terry Canavagh as you've written in the first post.