Messages

61

General discussions / Re: SFML 2 - Introduction Tutorial & Wallpaper

« on: July 18, 2012, 06:39:24 pm »

But not doing so is still writing bad code and for sure will generate a compiler warning (or error if not supported).

I'm not fond of it (this doesn't provide any feature and may confuse new C++ users...), but this is part of the C++ standard so I wouldn't qualify it as "bad code", using it or not it's more a matter of taste.
And your compiler should not raise any warning. (tested with Visual Studio /W4 and with g++ -pedantic -ansi -Wall -Wextra as well).

62

Feature requests / Re: Missing OpenGL primitive types

« on: July 18, 2012, 05:45:56 pm »

GL_POLYGON is deprecated in OpenGL 3.x (if this article that I didn't read is a reliable source). There's no point supporting it; if it wasn't deprecated, I woudn't even use it anyway.

Nevermind, I've just discoverd that TrianglesFan cover all my needs as well.
Googling "opengl polygon deprecated" give some results indeed, I didn't know about this.

63

General discussions / Re: SFML 2 - Introduction Tutorial & Wallpaper

« on: July 18, 2012, 05:05:52 pm »

Just for the sake of being picky: actually, the return instruction in the main function is not mandatory in C++.

int main()
{
}

This is compliant with the C++ standard, the compiler is required to add "return 0;" at the end of the function if no return instruction is provided.

I'll take a look at your videos when I'm back home

64

Feature requests / Re: Missing OpenGL primitive types

« on: July 10, 2012, 02:35:58 pm »

I'd like the API to remain as simple as possible. Therefore, I have implemented only the most used primitive types, and keep the others for later, when I have more feedback. I don't like to implement things "just because they are available".

I understand your point, but if you provide OpenGL primitive types, then users may expect to be able to use all the 10 of them, as they are all well known and documented.
And the enum PrimitiveType already exists, so the API is barely impacted.

If you don't need them, don't request them

You're right, so here are the use cases that lead me to notice they are missing

- Drawing a hexagonal-tiled map:

// create hexagon (6 vertices) for each tile
sf::Vertex vertices[NB_TILES * 6];
...
// drawing tiles
for (int i = 0; i < NB_TILES; ++i)
    target.draw(vertices + (i * 6), 6, GL_POLYGON, states);

which would be more optimized than using a ConvexShape per tile, especially if you don't need transformations for each tile.
And GL_POLYGON could have many other usages anyway.

- I was also trying to draw the outline of a shape, LINE_LOOP could spare the user from creating an additional Vertex for looping with LINE_STRIP.

65

Feature requests / Missing OpenGL primitive types

« on: July 10, 2012, 12:42:06 pm »

I've noticed that only 7 out 10 OpenGL primitive types are represented in sf::PrimitiveType.
Why are the 3 other ones missing? (GL_LINE_LOOP, GL_QUADS_STRIP, GL_POLYGON)?
Could they be added? They could be useful.

66

Graphics / Re: sf::Sprite/Texture(/Image) and pointers

« on: July 09, 2012, 11:36:55 am »

when you dereference a pointer, is the copy constructor for the object called, and a copy made?

Copying objects and dereferencing pointers are two different and independent operations, the copy constructor is simply called when you proceed to copy an object.

sf::Texture* t1 = new sf::Texture();

sf::Texture& t2 = *t1; // no copy, using a reference
sf::Texture  t3 = *t1; // copy constructor called
 

In your case, sf::Sprite::setTexture takes a reference (const sf::Texture&), so no copy is done here.

67

Graphics / Re: Check to show sprite function

« on: July 08, 2012, 02:06:10 am »

now my game is about 4000 by 2000, all I want to try and do is get the mouse coordinates not from the window itself but from its actually position in the game world, so if i moved right by 1000, the mouses position would be 2024. how can I achieve that?

If you've moved right by 1000px, I'm guessing you're using a view, so you add the view coordinates (+1000px) to the mouse cursor position.

68

Graphics / Re: Check to show sprite function

« on: July 08, 2012, 01:49:11 am »

if i then move the camera 1000px to the right and click again, i get the same X:1476
how can i get my mouse to take in the position of the screen also?

You need to pass the sfml window as a parameter to get the relative mouse position:

sf::Vector2i pos = sf::Mouse::getPosition(render_window);

read the sf::Mouse documentation

69

Graphics / Re: Check to show sprite function

« on: July 08, 2012, 01:39:13 am »

In the example above why isn't it [4][3] instead of [3][4]?

When dealing with 2-dimensions array, I've always stored the rows in the first dimension, and the columns in the second dimension, I think it's a common convention to do the following:

int array[NB_LINES][NB_COLUMNS]

So if you loop over the array and you generate positions (x, y) from array indexes, you will get the y-axis in the first loop, and the x-axis in the second nested loop.

for (int i = 0; i < NB_LINES; ++i)
{
    float y = i * tile_height;
    for (int j = 0; j < NB_COLUMNS; ++j)
    {
        float x = j * tile_width;
    }
}

Maybe some people store the columns in the first dimension, it's up to you really...

70

Graphics / Re: Check to show sprite function

« on: July 07, 2012, 10:41:40 pm »

500*300 Sprites = 150000, that's quite a hugh number for sprites. If you're trying to do something like a tilemap, you should defently rethink your desing and use sf::RenderTexture or better sf::VertexArray.
Also if performance gets a problem with the vertex array than you should use an octtree so you won't have to check every 150000 tiles.

With a VertexArray storing 4 vertices per tile, that would represent 150000 x 4 = 600000 vertices, how come rendering so many vertices could be faster that rendering a single render texture?
I've already wondered this while reading the source code of st::Text (as it also uses a vertex array rather than an intermediate texture), and I don't understand why.

now im trying to code it so if a mouse button is pressed while in contact with a block it will change the sprite of that block. this is the code so far

You don't need to loop over all your tiles to find the one under the mouse cursor.
You can get the tile index by dividing the mouse position by the tile dimensions.
Here's a schema:

71

SFML projects / Re: Sprint

« on: July 06, 2012, 03:41:45 pm »

That's a great little game, good concept with nice retro graphics.
It works fine on Linux using wine.

- The maps are not really challenging, maybe the gameplay could be extended by adding enemies, spikes...?

- Why are you downloading and storing png's for map previews? Couldn't you just build automatically a preview from the .map file, so you could avoid loading from hdd and downloading images in the custom maps menu .

- Same remark as eXpl0it3r regarding the keys bindings, space and/or return should let the player select the focused item.
Moreover, in the custom maps menu, pressing "return" takes you back to the main menu, that's confusing.

- Found a little bug after after playing a downloaded custom map, it seems like the view is not reset and is still centered on the player position.



I'll sure look for updates

72

Graphics / Re: getSize in version 2.0

« on: July 02, 2012, 02:20:30 pm »

If you just want to retrieve the width/height of your sprite, I suggest to use the texture rect instead of the global bounding box (see Laurent's comment about transformations):

float width  = sprite.getTextureRect().width;
float height = sprite.getTextureRect().height;

This code is much faster but it won't work if you have applied transformations on your sprite (such as rotation, scale, etc.).

If you only care about the scale transformation, you can still get the correct size without using the global bounding box:

float width  = sprite.getTextureRect().width  * sprite.getScale().x;
float height = sprite.getTextureRect().height * sprite.getScale().y;

(By the way, this is the exact implementation of sf::Sprite::GetSize in SFML 1.6).

Pick the solution which best fits your needs.

73

SFML wiki / Re: [Wiki] Using sf::View

« on: July 02, 2012, 11:23:59 am »

Ok, thanks to both of you for the tips!

74

SFML wiki / Re: [Wiki] Using sf::View

« on: June 26, 2012, 09:07:03 pm »

That's a really good tutorial, I didn't know views have so many usages, and I've learnt a couple of things about viewports (that's a new feature, right?).

Until now, for split screens, I used a very different approach: a parent container inheriting sf::Transformable & sf::Drawable, and I apply the container's transformations on its children, in the overridden draw method.

class Container: public sf::Transformable, public sf::Drawable
{
    void draw(sf::RenderTarget& target, sf::RenderStates states) const
    {
        states.transform *= getTransform();
        for each child
        {
            target.draw(child, states);
        }
    }
};

Should I use views instead? Is one method faster than the other?

Also, why the viewport rectangle is defined using ratio instead of dimensions in pixels? This puzzles me.
For example, if I want to split my screen between a game zone and an HUD zone like this:

This leads to the following:

float h = (screen_height - 60) / screen_height;

sf::View game_view(sf::FloatRect(0, 0, screen_width, screen_height - 60));
player_view.setViewport(sf::FloatRect(0, 1 - h, 1, h));

sf::View hud_view(sf::FloatRect(0, 0, screen_width, 60));
hud_view.setViewport(sf::FloatRect(0, 0, 1, 1 - h));

So the ratio values are rounded, and I'm afraid this may result in non-pixel perfect positioning.

75

Graphics / Re: rotate a rectangle around its center (SFML 1.6)

« on: June 25, 2012, 10:33:23 pm »

Even if you create a rectangle with the upper-left corner located at (300, 300), the object position is still at (0, 0), because the upper-left corner and the position are two different things.
My advice is to create your rectangle with the upper-left at (0, 0), and then move it.
After that, you just need to set the center at (width / 2, height / 2).

#include <SFML/Graphics.hpp>
int main()
{
    sf::RenderWindow App(sf::VideoMode(800, 600), "SFML rect rotation");
    float angle(0.f);
    while (App.IsOpened())
    {
        sf::Event Event;
        while (App.GetEvent(Event))
            if (Event.Type == sf::Event::Closed)
                App.Close();
        App.Clear();
        sf::Shape thing(sf::Shape::Rectangle(0, 0, 500, 500, sf::Color::Green));
        thing.SetPosition(300, 300);
        thing.SetCenter(250, 250);
        thing.Rotate(angle);
        angle += 0.1f;
        App.Draw(thing);
        App.Display();
    }
}

By the way, this tricky behavior has been fixed in SFML 2.0, you will only pass width and height parameters to the rectangle shape constructor.