Messages

1

Graphics / sf::Text problem (bug?)

« on: January 28, 2012, 10:55:53 pm »

Thanks for confirming it is not just me, all I know is sf::Font has reference counting.

2

General / Mouse problem.

« on: January 28, 2012, 10:35:35 pm »

You're getting the mouse coordinates relative to the desktop instead of the RenderWindow.

Code: [Select]

sprite.SetPosition(mouse.GetPosition(Window).x, mouse.GetPosition(Window).y);

3

General / Mouse problem.

« on: January 28, 2012, 09:01:52 pm »

Post your code.

4

Graphics / sf::Text problem (bug?)

« on: January 28, 2012, 08:35:50 pm »

I'm using the latest snapshot of SFML2. After some coding my program started crashing when I would close the rendering window, after much confusion and frustration I've narrowed it down to this.

With the code below my application will run fine until I close the rendering window (then it crashes).

Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");

sf::Font font;
     if (!font.LoadFromFile("res\\font\\white_rabbit.ttf"))
         return EXIT_FAILURE;

sf::Text text;
text.SetString("test");
text.SetFont(font);
text.SetCharacterSize(50);

    //sf::Text text("Hello SFML", font, 50);

while (window.IsOpen())
{
sf::Event event;
while (window.PollEvent(event))
{
if (event.Type == sf::Event::Closed)
window.Close();
}

window.Clear(sf::Color(0, 0, 0));

window.Draw(text);

window.Display();
}

return EXIT_SUCCESS;
}



However if I change the code to use

Code: [Select]

sf::Text text("Hello SFML", font, 50); instead. My application runs fine and doesn't crash upon closing the rendering window.

edit: Seems to work fine on linux...

Windows 7 64b
Visual Studio 2010 Express
Intel® Core™ i5 CPU M 450 @ 2.40GHz × 4
Memory: 3.7 GiB
Some ATI videocard

5

SFML projects / First SFML game (snakes and apples)

« on: January 04, 2012, 03:14:17 am »

I can't play because you used SFML 1.6 but why code empty else statements? you know they aren't compulsory.

6

SFML projects / Pac Cat

« on: December 22, 2011, 11:03:01 pm »

Good job!

Thank you.

at least it looks good (no time to test for now). but did you read the "pacman unveiled" in the pacaman thread ?
Basically, does the ghost have different IA ? or they are all "kill pac man" ?

They have the same AI as the original Pac-Man (minus the overflow programming errors causing a couple of the ghosts to act differently in certain situations).

http://home.comcast.net/~jpittman2/pacman/pacmandossier.html

http://gameinternals.com/post/2072558330/understanding-pac-man-ghost-behavior

I used those sites. The biggest difference between mine and the original is mine doesn't have any cornering because I didn't read about it until I was almost done.  :shock:

7

SFML projects / Pac Cat

« on: December 22, 2011, 03:33:52 am »

Finished my first SFML game, a Nyan Cat Pac-Man. Not very original but oh well

I originally wanted to make some extra maps, enemies and map editor but I would rather move onto something else now.



Game play video:


Download:
http://www.mediafire.com/?dgo3pya12n592bn

You will need Microsoft Visual C++ 2010 Redistributable Package to play Pac-Cat
http://www.microsoft.com/download/en/details.aspx?id=5555

8

General / Vector of class with pointer to sf::Sprite

« on: November 14, 2011, 12:49:32 pm »

Yes.

Now, if you want to improve your code, you can have a look at the following things:
- initializer list (to use in the copy constructor)
- copy & swap implementation of the assignment operator

Thanks! will check them out now.

9

General / Vector of class with pointer to sf::Sprite

« on: November 14, 2011, 12:28:42 pm »

It looks good, but :
1 - why are you using a pointer to a sprite??? this is definitely not necessary, it adds complexity and potential problems for no gain
2 - your assignment operator should be implemented using copy & swap
3 - your assignment operator leaks (you never delete the old m_sprite), but using either 1- or 2- will solve this problem
4 - setting pointers to NULL in a destructor is useless, the object is destroyed and won't be used again

Thanks for the fast reply. Now that you mention it, I don't actually need to use a pointer for this class...  :oops:

This would be correct for non pointer sprite?

Code: [Select]

#include "Pill.h"

sf::Texture Pill::texture;

Pill::Pill()
{
}

Pill::~Pill()
{
}

Pill::Pill(const Pill& other)
{
sprite = other.sprite;
sprite.SetTexture(texture);
}

Pill& Pill::operator=(const Pill& rhs)
{
if (this != &rhs)
{
sprite = rhs.sprite;
sprite.SetTexture(texture);
Entity::operator=(rhs);
}
return *this;
}

10

General / Vector of class with pointer to sf::Sprite

« on: November 14, 2011, 11:48:00 am »

I want to have a vector of a class that has a pointer to sf::Sprite as a class member, can anyone tell me if this would be correct? particularly the copy constructor and assignment operator (ignoring exception safety).

Code: [Select]

#ifndef PACCAT_PILL
#define PACCAT_PILL

#include "Entity.h"

#include <SFML/Graphics.hpp>

#include "Load.h"

class Pill : public Entity {
public:
static bool InitializeTexture(sf::RenderWindow& renderWindow)
{
return Load::LoadTextureFromFile(renderWindow, texture, "resources\\image\\pill.png");
}

Pill();
~Pill();
Pill(const Pill& other);
Pill& operator=(const Pill& rhs);

private:
static sf::Texture texture;

sf::Sprite* sprite;
};

#endif

Code: [Select]

#include "Pill.h"

sf::Texture Pill::texture;

Pill::Pill()
{
sprite = new sf::Sprite(texture);
}

Pill::~Pill()
{
delete sprite;
sprite = NULL;
}

Pill::Pill(const Pill& other)
{
sprite = new sf::Sprite(*other.sprite);
sprite->SetTexture(texture);
}

Pill& Pill::operator=(const Pill& rhs)
{
if (this != &rhs)
{
sprite = new sf::Sprite(*rhs.sprite);
sprite->SetTexture(texture);
Entity::operator=(rhs);
}
return *this;
}

11

SFML projects / Grav, a hard arcade game [WIP]

« on: November 13, 2011, 11:05:27 am »

Did you make that background effect just using SFML graphic commands? or did you use opengl directly?

Very cool.

I used SFML commands, they're not suing very much memory even if they are 1 pixels white sprites xD
Thanks!

Interesting. Your Kill da Ducks game is damn impressive too!

Just played some Grav, here is a couple of things I notiched.

- Why show console window?
- Takes an awful long time to actually launch the main window (I'm not sure why since it doesn't need to load many resources).
- Getting a connection error.

12

SFML projects / Grav, a hard arcade game [WIP]

« on: November 13, 2011, 10:05:54 am »

Did you make that background effect just using SFML graphic commands? or did you use opengl directly?

Very cool.

13

General / Window lag messing with data using timers

« on: November 02, 2011, 11:45:07 am »

There are several solutions to this problem:
- use Thor clocks, they can be paused
- never reset the position of the stars, apply a modulo only when you display them to make them fit in the window
- ignore huge frame times (> 1 sec)

Nice intro screen, by the way

Thanks.  

Going to look into Thor and the second solution is interesting, I did think of the third but it seemed a bit hackish to me.

14

General / Window lag messing with data using timers

« on: November 02, 2011, 10:34:05 am »

When you select the window, hold it and drag it around, the application freezes. This is fine except for data which uses sf::Clock or GetFrameTime().

I have a background which moves stars across the screen using GetFrameTime(). Once they go off screen, The main loop moves them back to the starting side.

Looks like this normally.


However if you freeze the window, the timer still increases which results in them all instantly moving off screen and this ruins the background.

After freezing the window.


Is there anyway I can pause sf::Clock before freezing the application and then unpause upon unfreezing? or any other way around this? do I need to use threads?

SFML-2.0-512a7c6
Windows 7 64b
ATI Radeon HD 4850

15

Graphics / Weird sf::Font scaling artifacts

« on: November 02, 2011, 06:58:29 am »

Do you have to scale them or can you use SetCharacterSize instead?

Unfortunately I have to scale them.