Messages

31

Graphics / Textures not tiling properly

« on: July 29, 2009, 04:53:33 pm »

Anyhow, I'd go with that new interface, just with a note that it has this power-of-two requirement.

From the beginner's point of view:

Yep, it is not beginner friendly. But would be advanced user friendly.
Though advanced user can always change that with a OpenGL call.

Btw, did I mention that when I call Image.SetSmooth(false) it did fix this problem.

No, but I did mention it

Hehe, I meant that did I confirm that it did work  :wink:

32

Graphics / Textures not tiling properly

« on: July 29, 2009, 03:50:17 pm »

Not an option. SFML may create internal textures padded with white pixels when the GPU doesn't support non-power-of-two dimensions.

Ah, true.
Forgot this since I use only power-of-two textures.

Anyhow, I'd go with that new interface, just with a note that it has this power-of-two requirement.
Though, it would be quite dangerous for people who didn't read documentation...

Hmm... You do have a point


Btw, did I mention that when I call Image.SetSmooth(false) it did fix this problem.

33

Graphics / Textures not tiling properly

« on: July 29, 2009, 02:45:30 pm »

GL_CLAMP_TO_EDGE is not a good solution, for two reasons:
- It requires OpenGL 1.2
- You still get one extra pixel, it's just less noticeable because it has the same color as its neighbour

Actually GL_REPEAT fixes this better than that CLAMP_TO_EDGE.
Clamp had extra pixel as you said, but repeat displayed everything perfectly. Tried this with "chessboard" texture.

How about if you give an interface to change between GL_REPEAT / GL_CLAMP, like you already have Image::SetSmooth(bool).
Since sprites are commonly with clamp and level textures with repeat, having one forced to you isn't so nice.
For example Image::SetRepeat(bool) would solve this.


Also a bit offtopic, why OpenGL 1.2 would be a restriction? :wink:

34

Graphics / Textures not tiling properly

« on: July 29, 2009, 04:37:55 am »

I found this with SFML2 branch from SVN

35

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

36

System / Mutex inconsistency

« on: July 27, 2009, 08:55:57 am »

I found this when I was porting my data loader thread from SDL to SFML.

Here's more complete example:

Code: [Select]

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

sf::Mutex WorkMutex;

enum JobEnum
{
LoadJob,
ExitJob
};

sf::Mutex JobMutex;
std::queue<enum JobEnum> LoadQue;

/*--------------------------------------------------------------------------*/

void Worker(void *)
{
bool Done=false;
while (!Done)
{
// Wait for job
WorkMutex.Lock();

// Get a job from queue
enum JobEnum Job;
{
sf::Lock Lock(JobMutex);
std::cout << "Get job from queue" << std::endl;
Job=LoadQue.front();
LoadQue.pop();
}

// Check the type of job
switch (Job)
{
case LoadJob:
std::cout << "Load job" << std::endl;
break;

case ExitJob:
std::cout << "Exit job" << std::endl;
Done=true;
break;

default:
std::cout << "FATAL: Unknown job" << std::endl;
Done=true;
break;
}
}

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

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

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

// Add few load jobs
for (int i=0; i<3; i++)
{
// Add job to queue
{
sf::Lock Lock(JobMutex);
std::cout << "Add job to queue" << std::endl;
LoadQue.push(LoadJob);
}

// Tell thread that there is something to do
WorkMutex.Unlock();

// Simulate data processing
sf::Sleep(0.5);
}

// Tell worker thread to exit
std::cout << "Add exit job" << std::endl;
LoadQue.push(ExitJob);
WorkMutex.Unlock();

return EXIT_SUCCESS;
}

(fyi: this code is not complete, this version here has logical errors)

This prints following:

Code: [Select]

Add job to queue
Get job from queue
Load job
Get job from queue       <---- Bug here, there was only one job in que
FATAL: Unknown job
Thread exit
Add job to queue
Add job to queue
Add exit job


Since SFML is using critical section my worker thread does not work and it gets two jobs from queue, even if only one was created.


My point here is that when someone writes similar code on Linux, it will not work when it is compiled on Windows.
This is not a problem for me, since now I know that SFML doesn't do mutexes as I expect, but it might be problem for someone else at some point.

Also, since my code above should be using Semaphore instead of WorkMutex, this might be much smaller issue than it sounds.

37

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.

38

General / Background image & Loading from resources

« on: July 27, 2009, 07:29:17 am »

I store files in a zip archive, it is quite simple to use.
Hmm, I could create wiki entry about this...

39

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?

40

General / Memory corruption with fs::Sprite

« on: July 26, 2009, 06:14:35 am »

Great, thanks

Btw, I noticed that you applied this into trunk, though this error was present on SFML2 branch :wink:
I should have pointed that out more clearly, but this is nice to have in 1.5+ too.

41

General / Memory corruption with fs::Sprite

« on: July 25, 2009, 09:28:33 am »

Since windows and linux source differ on this case, I made a patch to make windows code similar to linux:

Code: [Select]


Index: branches/sfml2/src/SFML/Window/Win32/Joystick.cpp
===================================================================
--- branches/sfml2/src/SFML/Window/Win32/Joystick.cpp (revision 1194)
+++ branches/sfml2/src/SFML/Window/Win32/Joystick.cpp (working copy)
@@ -42,6 +42,7 @@
 void Joystick::Initialize(unsigned int index)
 {
     // Reset state
+    myPresent   = false;
     myIndex     = JOYSTICKID1;
     myNbAxes    = 0;
     myNbButtons = 0;
@@ -62,6 +63,7 @@
                 // Ok : store its parameters and return
                 JOYCAPS caps;
                 joyGetDevCaps(myIndex, &caps, sizeof(caps));
+                myPresent   = true;
                 myNbAxes    = caps.wNumAxes;
                 myNbButtons = caps.wNumButtons;
                 if (myNbButtons > JoystickState::MaxButtons)
@@ -84,6 +86,10 @@
 {
     JoystickState state = {0};
 
+ // Check if joystick is present
+    if (!myPresent)
+        return state;
+
     // Get the joystick caps (for range conversions)
     JOYCAPS caps;
     if (joyGetDevCaps(myIndex, &caps, sizeof(caps)) == JOYERR_NOERROR)
Index: branches/sfml2/src/SFML/Window/Win32/Joystick.hpp
===================================================================
--- branches/sfml2/src/SFML/Window/Win32/Joystick.hpp (revision 1194)
+++ branches/sfml2/src/SFML/Window/Win32/Joystick.hpp (working copy)
@@ -78,6 +78,7 @@
     ////////////////////////////////////////////////////////////
     // Member data
     ////////////////////////////////////////////////////////////
+    bool myPresent;           ///< Is joystick present
     unsigned int myIndex;     ///< Windows ID of the joystick
     unsigned int myNbAxes;    ///< Number of axis supported by the joystick
     unsigned int myNbButtons; ///< Number of buttons supported by the joystick

Edit: typo

42

General / Memory corruption with fs::Sprite

« on: July 25, 2009, 08:57:50 am »

Debugged this further.
If I comment out ProcessJoystickEvents() from WindowImpl::DoEvents() this bug disappears.

I am using Windows Vista (32bit), so this call goes to SFML\Window\Win32\Joystic.cpp : Joystick::UpdateState()
That function is calling windows joyGetDevCaps(...) which returns value 165

According to specs [ http://msdn.microsoft.com/en-us/library/ms709350(VS.85).aspx ]* it should return one of these values:
JOYERR_NOERROR = 0
MMSYSERR_NODRIVER = 6
MMSYSERR_INVALPARAM = 11

But it did return value 165, there are few discussions about that but nothing clear.
I am wondering if that value is some Vista internal value for undefined joystic, since I haven't ever connected one.

If I comment out that joyGetDevCaps(...) function (and do not enter the if statement) this bug disappears.


Also, since I don't have any joystics connected, why SFML is polling them on every loop?


* Forum software does not accept parenthesis in urls


Edit:
Just found that value 165 is JOYERR_PARMS.
Quite logical, you are polling joystic 1 and 2 when there is 0 joystics present.

43

General / Memory corruption with fs::Sprite

« on: July 25, 2009, 07:49:10 am »

Managed to narrow this thing a bit, here's current version:

Code: [Select]

#include <SFML/Window.hpp>
#include <../extlibs/headers/AL/alc.h>

// Create global alc device
ALCdevice *myDevice=alcOpenDevice(NULL);  // <---- This is the critical line

int main()
{
// <--- Creating alc device here causes same behavior

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

// <--- Creating alc device here causes no problems

// Process "mainloop" ten times
for (int i=0; i<5; i++)
{
// Sleep a bit to get events
sf::Sleep(1);

// Process all events
sf::Event Event;
while (App.GetEvent(Event))
;

// One new thread has now been generated
printf("Debug\n");fflush(stdout);
}

return EXIT_SUCCESS;
}


This error happens when global instance of OpenAL is created. Normally done by SFML/Audio/AudioDevice.cpp.

If I move that alcOpenDevice call inside main function, before sf::Window call, nothing changes. But if it is after Window call, this behavior disappears. (see the highlighted lines on code example)

Could it be so that sf::Window call creates another thread (compared to global context) and that is causing context switching which in turn happens to generate extra threads by some reason.

So, now this seems to be either OpenAL threading or sf::Window bug.

44

General / Memory corruption with fs::Sprite

« on: July 21, 2009, 06:48:29 pm »

This is quite weird...
When tracing it seems that every new thread just exists immediately. After running a while, gdb had only 7 threads running that were generated on startup.

And one even more weird thing.
It does not matter where that sf::Music line is. Even if it is defined in it's own context after the "main loop" those threads will be generated.

This starts to sound like a tool issue. Can you reproduce this error?
I am using gdb 6.8 from here: http://www.equation.com/servlet/equation.cmd?fa=gdb

45

General / Memory corruption with fs::Sprite

« on: July 21, 2009, 03:30:02 pm »

It's in the roadmap, and it's already done in the sfml2 branch.

Yes it is fixed there, just checked

And while doing that I found one weird thing... (in SFML2)
On the moment when I create sf::Music object, gdb tells me that loads of threads are been generated. Seems that every time I poll all events from the queue new thread is generated.

I have this kind of code

Code: [Select]


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

int main()
   {
   // Create the main window
   sf::RenderWindow App(sf::VideoMode(800, 600), "SFML window");
   
   // Create music object
   printf("Create music\n");fflush(stdout);
   sf::Music Music;
   
   // Process "mainloop" ten times
   for (int i=0; i<10; i++)
      {
      // Sleep a bit to get events
      sf::Sleep(1);
     
      // Process all events
      sf::Event Event;
      while (App.GetEvent(Event))
         ;
     
      // One new thread has now been generated
      printf("Debug\n");fflush(stdout);
      }
   
   return EXIT_SUCCESS;
   }


Here's gdb output from this source

Code: [Select]

(gdb) run
Starting program: C:\Code\Code\SFMLTest/test.exe
[New thread 1608.0xde8]
[New thread 1608.0xe8c]
[New thread 1608.0xd70]
[New thread 1608.0x520]
[New thread 1608.0xb7c]
[New thread 1608.0xdd0]
[New thread 1608.0xaf8]
[New thread 1608.0x4f4]
Create music
[New thread 1608.0x620]
Debug
[New thread 1608.0x808]
Debug
[New thread 1608.0x644]
Debug
[New thread 1608.0xaf4]
Debug
[New thread 1608.0xe2c]
Debug
Debug
[New thread 1608.0xe3c]
[New thread 1608.0x42c]
Debug
[New thread 1608.0xadc]
Debug
Debug
[New thread 1608.0x140]
[New thread 1608.0xcb4]
Debug
[New thread 1608.0x624]

Program exited normally.
(gdb)

There is something fishy going on
Haven't checked sfml code yet what it does in this case, but it seems that creating Music class stars music output (even if  I haven't called Music::Play yet) and music output is generating lots of threads by some reason.