Messages

1

SFML projects / Re: Thor 2.0

« on: May 08, 2012, 06:17:41 pm »

As an extension of the event system and custom actions, what about creating a simple console? I envision something that you can bring up on screen and type commands. The console class would parse the input, then go to a data structure that contains all the commands. Commands would basically be a function pointer with a string for the command name.

You implement your own custom commands, then push command objects onto the console. I think it would be really useful for people to be able to quickly add a command console to their game, rather than using key code combinations or other stuff when testing. It would also promote better software design, since people wont be tempted to "hack" something into their code to test some aspect of their game, since they can write a console command class instead.

2

General discussions / Re: 1 Month Project- Need suggestions of a good game that can be made with sfml

« on: May 08, 2012, 05:30:59 pm »

I recommend you pick something with really simple gameplay mechanics that you can evolve and add features to, so that you can finish the game in the time allotted, but if all goes well you have time to add additional stuff.

A simple beat em up is a great idea, since you can add weapons, new characters, enemies, bosses, etc...

For me, when making a game, art is always may greatest limitation. If you can do your own art, that certainly helps, but if you can't I recommend letting existing art assets be a contributing factor in your decision. If you are looking for awesome 2D art that is community license, I recommend you try http://www.reinerstilesets.de/ or http://www.lostgarden.com/search/label/free%20game%20graphics since they have a great stuff that has a common art style so your game looks great. Lost Garden has a lot of cool RTS and Shooter art, while Reiner's has a huge variety of sprites (most are isometric) that you can probably fit into any kind of game.

3

System / Rect with negative width

« on: May 04, 2012, 02:33:33 am »

I did some searching on the forum, but "Rect" "Intersect" "Negative" and the like are not the best search terms, so I apologise if this has been noted.

I held off posting on the tracker because I wanted to check if this is by design or a bug. If this is a bug I will happily toodle off to the Github and submit a patch.

Rectangles with a negative width/height do not seem to intersect properly with rectangles with positive width/height. For example, a rectangle at 0,0 with width and height of 10 should intersect with a rectangle at 15, 15 with a width and height of -10. In SFML they do not.

Here is the obligatory code snippet:

Code: [Select]

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

int main(int argc, char *argv[]) {

// intersect test
sf::IntRect rect1(0,0,10,10); //Rectangle at 0,0 with width of 10 and height of 10
sf::IntRect rect2(15,15,-10,-10); //Rectangle at 15,15 with width of -10 and height of -10
bool test1 = rect1.intersects(rect2);
std::cout << "Test 1 " << test1 << std::endl;
std::getchar();
return 0;
}
The output is:

Code: [Select]

Test 1 0

So clearly, the rectangles are considered to not intersect. Is this the intent?

For anyone interested in a more involved test, I've attached a .cpp that checks a couple different combinations.


[attachment deleted by admin]

4

Graphics / Thanks

« on: February 22, 2012, 05:12:42 pm »

I've spent the night looking through the source and I see exactly what you mentioned.  I forgot to mention that I have tried with repeating textures on and off.

Is sf::Sprite likely to change between now and the SFML 2 release?  The only reason I ask is that I am taking advantage of the current behaviour for an inverted texture rect, combined with negative scaling, to "flip" my textures and I'd hate for all that code to break in the next update when I could exercise a little patience instead.

5

Graphics / Inverted Texture Rect explanation

« on: February 22, 2012, 12:04:22 am »

From what I've read, inverted texture rects should be working, but I can't seem to get the behaviour I want.

For example, assuming a texture is 64x64, w and h are the width and height values, sprite is an initialised sf::sprite, the origin is in the top left default position, and the texture has been properly set (all tested)

Based on what I know about how this all works this code

Code: [Select]

sprite.SetTextureRect(sf::InteRect(w, 0, -w, h) );
should generate a flipped sprite, since I am setting the origin of the sub-rect for the texture to 0, 64 and creating a rectangle that goes backward 64 pixels and down 64 pixels, which should generate a texture that is mirrored on the Y axis.  

What I actually get when I draw the sprite, it that it is translated -w pixels on the x axis from the position.  i.e., if the aforementioned sprite is located at (128,128) the sprite will render as if it was located at (64,128).  The rendered sprite is also not mirrored.

(I have a solution that works, using:

Code: [Select]

sprite.SetTextureRect(sf::InteRect(w, 0, -w, h) );
sprite.SetScale(-1,1);

I like this solution better than setting the origin to (w/2, h/2) since I am a top-left kinda guy.  In this case I understand how the SetScale() function works.  I am looking for an explanation as to why the inverted texture rect behaves the way it does).