Messages

1

Feature requests / A little more exposure... and smart pointers too.

« on: May 20, 2010, 02:36:07 pm »

There's no need to store pointers to rows and provide an operator[]. An operator() taking directly x and y is cleaner and more efficient.

Your comment kicked off a discussion here at work regarding the relative merits of double indirection using row pointers vs. simply doing the pointer arithmetic. The final consensus was: it depends. It depends upon what you are doing algorithmically as well as the performance aspects of the compute environment in which you are executing. So I retract my request:

In addition, if an image container also contained pointers to the start of every line, and appropriate operator[] functions were provided, then pixels could be accessed using doubly indexed notation such as: myImage[row][column].

2

Feature requests / A little more exposure... and smart pointers too.

« on: May 19, 2010, 10:47:33 pm »

I am using SFML for a rather non-traditional application. I am using it to animate a slide show. In doing so I have had to expose a few protected class members.

Reading large images fails because of texture size limitations. In order to load a large image, I have had to expose the ImageLoader. By doing so, I am able to read a large JPEG image and decimate it before creating a sf::Image using the LoadFromPixels function.

In animating the slide show, I often interpolate between transformation states. It would be easier to work directly with the transformation matrix. I see no reason not to expose GetMatrix as well as create a SetMatrix function.

I would also recommend some changes regarding images. Since images rarely change size, the overhead of STL vectors is not really justified. However, moving images around would be much easier if smart pointers were used to handle the allocation/deallocation of memory. In addition, if an image container also contained pointers to the start of every line, and appropriate operator[] functions were provided, then pixels could be accessed using doubly indexed notation such as: myImage[row][column].

Thanks for your consideration.

3

Graphics / Point inside polygon shape?

« on: April 30, 2010, 04:52:00 am »

Thanks from me as well.

4

Graphics / SFML2 bugs

« on: March 31, 2010, 01:51:19 am »

Its been about 15 minutes since my last try and it still hasn't bounced yet. Its about as small as I could make it, but its still a solution with three projects (GUI, Wrapper DLL, and static library).  As such it adds up to about 430K. Sorry. At least I tried to document it as fully as possible.  :wink:

5

Graphics / SFML2 bugs

« on: March 30, 2010, 10:04:49 pm »

I have a minimum build in a zip file that I can send to you. However, I have encountered problems trying to sent them to the email address listed: laurent@sfml-dev.org (and the gmail account to which it appears to forward).

Is there another address you would like me to send it to?

6

Graphics / SFML2 bugs

« on: March 29, 2010, 08:44:50 pm »

I will try to do so as soon as I can.

7

Graphics / SFML2 bugs

« on: March 29, 2010, 05:39:54 pm »

I have been using SFML2 to implement an interactive slide show as part of an image management prototype. I have encountered a few difficulties. I plan back down to SFML 1.5 and defer some of my planned visual effects in hopes of gaining stability and portability across Windows versions. However, as I do so, I would like to document my problems.

My environment:
OS: XP SP2
IDE: Visual Studio 2005 SP2
The main application GUI is C#. My image analysis and management library is in unmanaged C++. The managed<->unmanaged transition is made via a thin wrapper that creates a DLL used by the C# GUI. SFML is used within the unmanaged C++ domain, contained by the wrapper. To avoid naming collisions (my project is pretty big and has a lot of stuff in it), I link with the DLL versions of SFML. Because the slide show is just a feature, it may not be called and SFML functions may not be executed every time the program runs.

The Issues:
(1) I found that I had to put the following line in my main constructor within the C++, otherwise the SFML destructors would crash on exit if I did not call any other SFML functions.

Code: [Select]


  // HACK - This following line is to avoid a crash when the SFML dll exits
  sf::Context context;


(2) When using a RenderImage, sometimes the images are drawn vertically inverted. This is particularly odd because I cannot seem to anticipate whether it will be flipped. However, the behavior is repeatable to the extent that I can set the "FlipY" parameter to compensate once I have seen it flip in a given usage.

(3) In some cases, the first time I use a RenderImage, it is drawn onto my RenderWindow as all black. I am using the RenderImage to accomplish a clipping path on a rotated sprite. I clear() the RenderImage with a transparent color, draw the rotated sprite into the RenderImage, Display() the RenderImage, create a Sprite using the RenderImage, draw the RenderImage Sprite into the RenderWindow. After the first such use, it appears to behave normally.

(4) RenderImages appear to behave differently on different versions of Windows (or at least on different machines I have at my disposal). When it fails, most commonly it displays as black, however I have seen it display as the Sprite color.

(5) I played around with sounds and music and encountered a crash when I tried to LoadFromFile. However, I have not spent any time determining the details of this failure.

I suspect that many of these problems originate from my use of SFML within a DLL, combined with the fact that SFML is not always called upon.

I like SFML and find it pretty easy to use. I hope that these comments are not taken as overt criticism of the library, rather I am just trying to document behaviors that appear to be bugs.

Thanks

8

SFML projects / More Info

« on: March 15, 2010, 09:11:34 pm »

I just did a few more tests, in an attempt to isolate my problems.

In my first test, all I displayed was my "spinner" and only read and immediately deleted new images. My window updated smoothly.

In my second test, I preloaded my background loader and modified it to recycle images by pushing them back onto the end of the deque. Then, I commented out the part of my code that deleted images. Thus, my slide show would loop through several images without disk activity. During this test, I noticed mild hiccups as images appeared. Each of these appearances coincides with the creation of a RenderImage (and thus a drawing context).

It appears that the significant hiccups occur with the near simultaneous creation of a RenderImage and reading of a large image from disk.

9

SFML projects / SFML-based slide show

« on: March 15, 2010, 07:32:42 pm »

I am working on a "slide show" project. The goal is to display multiple images simultaneously in different parts of the screen and to provide some sophisticated transitions as images enter and leave. It appears that SFML may have most of the features I need. I have hit several rough patches of road along the way and have been able to work through them with help from the SFML community (Many thanks!).

My current confusion centers around loading images via a background thread. I have written an image loader that employs a background worker thread in order to avoid pauses in the animation of the slide show. I have included the loader and some simple test code below. I encounter several problems with this code:
1) I still experience pauses in the execution
2) Some of the images are only rendered as white rectangles.
3) I am apparently leaking large amounts of memory (even though I delete the images).

Any insight to my problems would be greatly appreciated.

Note: I am using SFML 2.0 build 1444 because I need to use RenderImage until clipping paths are available.

Another Note: Upon re-examination, my "real" slide show routine does not appear to leak as much memory. the only real differences appear to be that the sprite that uses the image goes out of context and is destructed, and the RenderImage pointer that uses the sprite which uses the image is deleted immediately after the image is deleted. (Clear as mud?)

This is my test routine. The image file spinner.png is just a small image that I rotate to visualize hiccups in execution. The other images are from digital still cameras.

Code: [Select]


//-----------------------------------------------------------------------------
void LoaderTest()
{
  // Create a clock for measuring the time elapsed
  sf::Clock clock;

  // Create main window
  sf::RenderWindow canvas(sf::VideoMode(800, 600), "loaderTest");

  sf::Image spin_image;
  spin_image.LoadFromFile("C:/images/spinner.png");
  sf::Sprite spin_sprite(spin_image);
  spin_sprite.SetOrigin(spin_image.GetWidth()/2.0F, spin_image.GetHeight()/2.0F);
  spin_sprite.SetPosition(canvas.GetWidth()/2.0F, canvas.GetHeight()/2.0F);

  vector<string> fnames;
  fnames.push_back("C:/images/smallA.jpg");
  fnames.push_back("C:/images/largeA.jpg");
  fnames.push_back("C:/images/smallB.jpg");
  fnames.push_back("C:/images/largeB.jpg");

  SlideShowImageLoader loader;
  int idx = 0;
  sf::Image *pImage = 0;
  sf::Sprite image_sprite;
  std::string filename;

  // Start game loop
  float switchDelay = 2.0F;
  float switchTime = clock.GetElapsedTime();
  float currentTime = clock.GetElapsedTime();
  while (canvas.IsOpened())
  {
    // Process events
    sf::Event Event;
    while (canvas.GetEvent(Event))
    {
      // Close window : exit
      if (Event.Type == sf::Event::Closed)
        canvas.Close();

      // Escape key : exit
      else if (Event.Type == sf::Event::KeyPressed)
      {
        if (Event.Key.Code == sf::Key::Escape)
          canvas.Close();
      }
    }

    // queue up images
    while (loader.imagesTotal() < fnames.size())
      loader.RequestImageFile(fnames[idx++ % (int)fnames.size()]);

    // switch images periodically
    currentTime = clock.GetElapsedTime();
    if (currentTime >= switchTime)
    {
      if (pImage)
      {
        delete pImage;
        pImage = 0;
      }
      if (loader.DequeImage(filename, pImage))
      {
        image_sprite.SetImage(*pImage, true);
        image_sprite.SetOrigin(pImage->GetWidth()/2.0F, pImage->GetHeight()/2.0F);
        image_sprite.SetPosition(canvas.GetWidth()/2.0F, canvas.GetHeight()/2.0F);
        float scale = std::min((float)canvas.GetWidth()/pImage->GetWidth(), (float)canvas.GetHeight()/pImage->GetHeight());
        image_sprite.SetScale(scale, scale);
        switchTime = currentTime + switchDelay;
      }
    }

    // Display
    canvas.Clear();
    canvas.Draw(image_sprite);
    spin_sprite.SetRotation(currentTime * 180);
    canvas.Draw(spin_sprite);

    // Finally, display the rendered frame on screen
    canvas.Display();
  }
}


The SlideShowImageLoader.h looks like this:

Code: [Select]


#pragma once

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


typedef std::pair<std::string, sf::Image *> NamedImagePtr;

//-----------------------------------------------------------------------------
class SlideShowImageLoader
{
public:
  SlideShowImageLoader();
  virtual ~SlideShowImageLoader();

  static void LoaderLoop(void *pData);

  void RequestImageFile(std::string &filename);
  bool DequeImage(std::string &filename, sf::Image *&pImage);

  inline unsigned imagesAvailable() const { return (unsigned)responses.size(); }
  inline unsigned imagesPending() const { return (unsigned)requests.size(); }
  inline unsigned imagesTotal() const { return (unsigned)responses.size() + (unsigned)requests.size(); }


protected:
  bool                                exitSignal;
  sf::Thread                          loaderThread;
  sf::Mutex                           responseMutex;
  sf::Mutex                           requestMutex;
  std::deque<NamedImagePtr>           responses;
  std::deque<std::string>             requests;
};


SlideShowImageLoader.cpp

Code: [Select]


#include "SlideShowImageLoader.h"

//-----------------------------------------------------------------------------
SlideShowImageLoader::SlideShowImageLoader() : exitSignal(false), loaderThread(LoaderLoop, this)
{
  loaderThread.Launch();
}

//-----------------------------------------------------------------------------
SlideShowImageLoader::~SlideShowImageLoader()
{
  exitSignal = true;
  loaderThread.Wait();
  while (responses.size())
  {
    delete responses.front().second;
    responses.pop_front();
  }
}

//-----------------------------------------------------------------------------
void SlideShowImageLoader::LoaderLoop(void *pData)
{
  sf::Context context; // this line is needed for images to be loaded properly
  SlideShowImageLoader &loader = *(SlideShowImageLoader *)pData;
  while(!loader.exitSignal)
  {
    if (loader.requests.size())
    {
      loader.requestMutex.Lock();
      std::string filename = loader.requests.front();
      loader.requests.pop_front();
      loader.requestMutex.Unlock();

      sf::Image *pImage = new sf::Image();
      if (pImage->LoadFromFile(filename))
      {
        loader.responseMutex.Lock();
        loader.responses.push_back(NamedImagePtr(filename, pImage));
        loader.responseMutex.Unlock();
      }
    }
    sf::Sleep(0.01f);
  }
}

//-----------------------------------------------------------------------------
void SlideShowImageLoader::RequestImageFile(std::string &filename)
{
  requestMutex.Lock();
  requests.push_back(filename);
  requestMutex.Unlock();
}

//-----------------------------------------------------------------------------
bool SlideShowImageLoader::DequeImage(std::string &filename, sf::Image *&pImage)
{
  bool rval = false;
  if (responses.size())
  {
    responseMutex.Lock();
    filename = responses.front().first;
    pImage = responses.front().second;
    responses.pop_front();
    responseMutex.Unlock();
    rval = true;
  }
  return rval;
}
:lol:

10

Graphics / SFML2: Strange behavior (threading GL)

« on: March 15, 2010, 12:15:33 pm »

Sorry,
From the sixth post in this discussion thread, I assumed that this requirement ( sf::Context context; ) was required for multithreaded application using SFML 1.5 as well.

11

Graphics / Add this to threading tutorial

« on: March 15, 2010, 03:38:01 am »

I spent about two days chasing down an error with this solution. This should be added to the tutorial on threading.

I was trying to create a multitheaded project in which the primary thread animated images as a slide show while a background thread queued up images. I was using a development version of SFML 2.0 and assumed my problem was with RenderImage. It took a while but I stripped the problem back to a minimal implementation and eventually found this post. It should be made more conspicuous.

12

Graphics / One more thing... Documentation for SFML 2.0

« on: March 09, 2010, 04:13:32 pm »

Laurent,
Thanks for your help and all your work on SFML. Do you have any documentation on SFML 2 under development? I was able to access the SVN repository last night, however the doc directories are mostly empty. The "next version" of the online documentation appears to be for version 1.6.
Thanks again for all your help.
---Pete

13

Graphics / Help for rotation?

« on: March 08, 2010, 04:21:13 pm »

Thanks model76, This great.

Unfortunately, I still need to be able to rotate the image within the clipping rectangle (leaving the rect in its original location in the window). Any other ideas.

14

Graphics / Should really try it.

« on: March 05, 2010, 01:35:35 am »

I have not tried it (I am home right now). However, I would expect the subrect to transform (scale and rotate) with the rest of the sprite. I will give it a go tomorrow morning, however.

UPDATE: I coded up an example and verified my expectation. The subrect does transform with the image. Thus, my question remains. How do I implement clipping paths or masks.

15

Graphics / Clipping paths or masks

« on: March 04, 2010, 11:44:37 pm »

I am very new to SFML and greatly appreciate the help I have received so far. My latest question concerns clipping paths or masks. I would like to create pan, zoom, rotate, and alpha blend effects within a defined region of the window. Referring to the picture below, consider that I have a full screen in which the background is a sprite  I would like to define regions of the screen in which I can use pan and zoom effects. For instance, I would like to be able to zoom into one of the faces in one of the foreground images while clipping the image to the white rectangle surrounding the foreground image, and leaving the background image completely intact.

Currently, I am only interested in rectangular clipping windows, however I could definitely imagine using arbitrary clipping paths if available.

Thanks for any advice you can share.
---Pete