Topics

1

Graphics / Textures missing in Ubuntu

« on: October 15, 2009, 08:21:28 am »

Hi
I tried latest SVN version of SFML2 in Ubuntu(9.4) and I can't get textures working.
Textures work fine if I use SFML 1.6 from SVN, so there seems to be something in SFML2 branch.

Here's working example:

Code: [Select]

#include <SFML/Graphics.hpp>
#include <SFML/OpenGL.hpp>
 
int main()
{
// Create the main window
sf::RenderWindow App(sf::VideoMode(500, 200), "SFML window");
//sf::RenderWindow App(sf::VideoMode::GetDesktopMode(), "SFML window", sf::Style::Fullscreen);

// Load a sprite to display
sf::Image Image;
if (!Image.LoadFromFile("Logo.png"))
return EXIT_FAILURE;
sf::Sprite Sprite(Image);

// Main loop
while (App.IsOpened())
{
// Process events
sf::Event Event;
while (App.GetEvent(Event))
{
// Close window : exit
if (Event.Type == sf::Event::Closed)
App.Close();
if (Event.Type == sf::Event::KeyPressed)
App.Close();
}

// Clear screen
App.Clear();

// Draw white box
App.SetActive();
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0, 1.0, 0.0, 1.0, -1.0, 1.0);
glBegin(GL_QUADS);
{
glColor3f(1.0,1.0,1.0);
glVertex3f(0.25, 0.25, 0.0);
glVertex3f(0.75, 0.25, 0.0);
glVertex3f(0.75, 0.75, 0.0);
glVertex3f(0.25, 0.75, 0.0);
}
glEnd();

// Draw the sprite
App.Draw(Sprite);

// Update the window
App.Display();
}

return EXIT_SUCCESS;
}

Only white box that I draw manually gets displayed. It is not even overlapped that 400x200 image, so it seems that image drawing is just totally skipped. Adding App.Flush() calls didn't change anything.

Title bar was also missing, but this was fixed by disabling Compiz, which didn't affect anything else.

Any idea what is happening?

2

Graphics / Can't change sprite image

« on: August 11, 2009, 03:02:35 pm »

Hi

Found that I can't change sprite source image in SFML2

Here's simple example:

Code: [Select]

// Load first image and create sprite
sf::Image Image;
Image.LoadFromFile("Logo.png"); // Size of 400x100
sf::Sprite Sprite(Image);

...time passes...

// Load second image and set it to sprite
sf::Image Img2;
Img2.LoadFromFile("Checkers.png"); // Size of 256x256
Sprite.SetImage(Img2);
After that last line the Sprite size is still 400x100 instead of 256x256 what I would expect.

This behavior comes from SFML/Graphics/Sprite.cpp:

Code: [Select]

void Sprite::SetImage(const Image& image)
{
    // If there was no source image before and the new image is valid, adjust the source rectangle
    if (!myImage && (image.GetWidth() > 0) && (image.GetHeight() > 0))
    {
        SetSubRect(IntRect(0, 0, image.GetWidth(), image.GetHeight()));

So, if image did already exist, then sprite size will not get changed.

This gets fixed by making this change to SFML:

Code: [Select]

   // If new image is valid, adjust the source rectangle
    if (image.GetWidth() > 0) && (image.GetHeight() > 0)

Or calling Sprite.SetSubRect( sf::IntRect(0,0, Img2.GetWidth(), Img2.GetHeight()) ) after I change the image.

Is there some reason for this behavior or is it just a small bug?

3

General / Keylogger warning from Comodo

« on: August 10, 2009, 05:48:24 am »

Hi

I lately installed Comodo firewall/virus scanner and noticed that I'll get following alert when running something that uses SFML:


It seems to think that my app could be a keylogger since it is using dinput.dll.
Wonder would there be any way around this, this kind of windows will scare people

4

Graphics / Textures not tiling properly

« on: July 28, 2009, 08:25:24 am »

I have tiling texture (get it here if interested) but it will not tile properly.
Image size is 256*256.

Here's relevant parts of code

Code: [Select]

// Load image
sf::Image Image;
if (!Image.LoadFromFile("Test.png"))
return EXIT_FAILURE;
int Width=Image.GetWidth();
int Height=Image.GetHeight();
sf::Sprite Sprite(Image);

...

// Draw the sprite
for (int y=0; y<3; y++)
for (int x=0; x<3; x++)
{
Sprite.SetPosition(x*Width,y*Height);
App.Draw(Sprite);
}

The result is this:


As you can see, there are seams on the texture

The reason for this can be found from SFML, at src\SFML\Graphics\Image.cpp, line 658 (in SFML2 branch)

Code: [Select]


        GLCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP));
        GLCheck(glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP));


When I replace that GL_CLAMP with GL_CLAMP_TO_EDGE, I'll get this image instead:


This could be graphics card dependent, I have ATI Radeon 4890, but I think that is not the reason.
Here's more about the subject

Anyhow, that GL_CLAMP should be replaced with GL_CLAMP_TO_EDGE

5

SFML wiki / [Sources] ZipLoader

« on: July 27, 2009, 08:19:37 am »

I added a ZipLoader to wiki.
It is small class that can load data from zip file archive.

6

System / Mutex inconsistency

« on: July 27, 2009, 05:08:04 am »

There seems to be inconsistency in mutex implementation between Windows and Linux in SFML 1.5.

I have following code:

Code: [Select]

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

sf::Mutex WorkMutex;

void Worker(void *)
{
int Count=0;
while (Count<5)
{
// Wait for job
WorkMutex.Lock();

// Doing the job now
std::cout << "Work: " << Count << std::endl;
Count++;
}

std::cout << "Thread exit" << std::endl;
}

int main()
{
// Lock mutex to prevent worker doing anything
WorkMutex.Lock();

// Create and launch worker thread
sf::Thread Thread(Worker);
Thread.Launch();

// Start five jobs
for (int i=0; i<5; i++)
{
std::cout << "Start: " << i << std::endl;
WorkMutex.Unlock();

// Sleep a bit
sf::Sleep(0.5);
}

return EXIT_SUCCESS;
}


In Windows this prints:

Code: [Select]

Start: 0
Work: 0
Work: 1
Work: 2
Work: 3
Work: 4
Thread exit
Start: 1
Start: 2
Start: 3
Start: 4

When I unlocked the WorkMutex from main, Worker thread entered to critical section (as it is implemented in SFML/Win32). And if thread is on critical section, locking it doesn't do anything. Therefore Worker thread processed all jobs immediately.

But, here comes the interesting part.
I replaced mutex with boost::mutex which is using POSIX pthread_mutex_t or similar (as is SFML/Linux code) and here's the output:

Code: [Select]

Start: 0
Work: 0
Start: 1
Work: 1
Start: 2
Work: 2
Start: 3
Work: 3
Start: 4
Work: 4
Thread exit


So, I dare to claim that my code example works differently between Windows and Linux, even if both are using same SFML source.
Could someone try this code on linux and tell what it outputs?

7

General / Memory corruption with fs::Sprite

« on: July 20, 2009, 07:18:41 pm »

I am using nvwa to track memory leaks and Sprite class (or Resource) seems delete a pointer twice when it goes out of scope.

I have following program

Code: [Select]


#include <SFML/Graphics.hpp>

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

// Load image
sf::Image Image;
if (!Image.LoadFromFile("Image.png"))
return EXIT_FAILURE;

// Own context to isolate the error
{
// Create sprite
sf::Sprite Sprite(Image);
}  // Double deletion here

return EXIT_SUCCESS;
}


On the marked line nvwa will kill the application because deletion of unknown memory address.

I compiled this in MinGw 4.3.3 with SFML_DYNAMIC flag and I am using dynamic libraries (will get thousands of errors with static libs)
SFML version is 1.5, using debug versions (no change if I use non-debug)

Here's backtrace from gdb

Code: [Select]


...std stuff removed...
#9  0x004be99c in std::set<sf::ResourcePtr<sf::Image>*, std::less<sf::ResourcePtr<sf::Image>*>, std::allocator<sf::ResourcePtr<sf::Image>*> >::erase (this=0x22feac, __x=@0x22fae4)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/c++/4.3.3-dw2-tdm-1/bits/stl_set.h:448
#10 0x00470a3e in sf::Resource<sf::Image>::Disconnect (this=0x22feac,Observer=@0x22fe94)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/System/Resource.inl:87
#11 0x0046cc09 in ~ResourcePtr (this=0x22fe94)
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/System/ResourcePtr.inl:68
#12 0x0046cd95 in _fu0___ZTVN2sf6SpriteE ()
    at c:/code/mingw/bin/../lib/gcc/i686-pc-mingw32/4.3.3-dw2-tdm-1/../../../../include/SFML/Graphics/Sprite.hpp:45
#13 0x004017d0 in main () at Src/main.cpp:17


So in short ~ResourcePtr() calls myResource->Disconnect(*this);
which then calls myObservers.erase(&Observer); (where observer is ResourcePtr) and this ends up to deletion of unknown memory addess.
Quite weird...