Topics

1

Graphics / Shaders: General questions

« on: January 11, 2013, 06:17:14 am »

Alright so I've spent the past few days reading up on shaders. I know I'm probably going to get scolded and/or flamed for some/all of these but I figured I'd ask here. I'm trying to grasp a few things about shaders before I go about doing anything serious with them.

Here is a list of questions that have been on my mind for a while now and that pertain almost specifically to SFML (for the most part). I realize there are a lot, but hopefully a few of them can be answered at the least.

- To clip drawing textures, would I use a fragment shader as opposed to a vertex shader (and update the bounds using parameters?) then setting the alpha to 0 if the pixel lies outside of the bounds? My current understanding of shaders says yes but more or less I'd like some confirmation that I'm not too entirely crazy.

- Are shaders faster/more ideal than using sf::Sprite and an sf::Texture to draw images each frame?

- What's the difference (internally) between drawing an sf::Sprite with a texture and just a set of polygons with a shader that draws a texture specified? Is there any advantage? If SFML isn't using a built-in shader to do this, how is SFML drawing a texture to the screen?

- If shaders -are- faster, to draw an image with a shader (assuming the shader has been passed the appropriate texture as a parameter) would I just draw four points do the draw() method and then pass the shader as part of the render state?

- Are `uniform` constants (variables) in shaders just the parameters set by SFML's setParameter() method, verbatim?

- If so, what happens when I want to use a uniform constant that hasn't been set by the application? Is it undefined behavior?

- Are parameters sticky - meaning, if I set a parameter one frame, and not the next, does the value from the first time I set the parameter "stick" (persist) throughout the rest of the frames until it is explicitely set again?

- Can/will shaders lock up the computer if something unexpected happens (like drivers do)?

- For maximum compatibility (the application in question is not a game) should I target the lowest possible shader version?


Keep in mind I've been reading tons of articles on the structure of a shader, the pipeline flow, etc. However, I'm still trying to map out how exactly to incorporate shaders into my program. I've already decided to use them because I know there will be a direct advantage over my previous methods.

2

Graphics / Debugging a text problem - 'invisible' text

« on: November 13, 2012, 05:17:29 am »

Alright, I'm stumped. It's been three days and I'm running out of options - I'm to the point of just trying random, seemingly pointless stuff just to get something to work.

I'm writing a program that binds to Lua and allows scripts to draw things to the canvas. The code is completely custom and is too large to simplify down (sorry Laurent, this one won't be easy).

I have tried running a bare-bones text drawing program, which, of course, works.

I have a font preloader (which does exactly what it sounds like - creates a font and loads from a file, stores it in an array, and then returns a raw pointer [Lua uses raw pointers]), as well as an image loader that works pretty much in the same way.

Images have a wrapper class, whereas the sf::Font class is bound directly to lua (no wrapper).

There is also a text class that lightly wraps the sf::Text class.

Text was working intermittently (certain, seemingly similar builds would show/hide text at random) until it just stopped working altogether. The text just seems to be completely invisible.

I have stepped through the program to the point my F10/11 keys are screaming for mercy, and all pointers/references/arguments/etc. seem fine. I have compared runtime break data for Fonts between the working sample program and the actual app - everything looks fine. There are absolutely no errors or exceptions, the text simply does not display.

The other weird thing is that images draw just fine. They also follow the same code-path as text does. It  seems to be an internal thing.

Here is a few code snippets to help visualize the code-path:

Button (which is what holds the text) instantiates the label (wrapper Text class):

Text                            _label;

which instantiates itself using the sf::Text default constructor. The button class then sets the label's string and calls the lua script to set itself up.

_label.setString(std::string("Test"));

-- Get Label
local label = self:GetLabel()
       
-- Set up font/color
label:SetColor(R.Color(255, 0, 0, 255))

-- _buttonFont is a font that was pre-loaded earlier in the script
self:GetLabel():SetFont(_buttonFont)

The above lua code works as far as I can tell; Even deeper into the draw functions, the color values are correct (255,0,0,255) and the font seems to be normal (the pointers are valid, the page count is 1 or so, and the pixel data is reasonable).

The code then continues on to draw, calling the lua callback with a reference to the target (which wraps a pointer to a rendertarget):

-- Draw image then text on top of it
--      Commented out image drawing; It works fine
--target:Draw(_buttonIdle)
target:Draw(self:GetLabel())

The target draw method is as follows:

ITarget&                                draw(Drawable& drawable)
{
        // Is it visible?
        if(!drawable.isVisible())
                return *this;

        // Init
        initStack();

        // Combine transform
        _transformStack->push(_transformStack->top());
        _transformStack->top().combine(drawable.getTransform());

        // Draw
        drawable.drawThis(*this);

        // Pop Transform
        _transformStack->pop();

        // Return
        return *this;
}

It is confirmed the drawable is visible (which is a method that belongs to a wrapper) and the transform stack (used to combine transforms for 'component'-ized drawables) is initialized and working fine.

The code goes on to draw the drawable's wrapper function, which calls the pure virtual method "onDraw" that actually does the drawing.

// Draw
target.drawRaw(*this);

drawRaw() simply calls another target wrapper draw method to call the SFML draw method itself:

// Copy + Combine states with transform
sf::RenderStates s = states;
s.transform.combine(_transformStack->top());

// Lock and load
lock();
_ref->draw(drawable, s);
unlock();
 

Again it pushes the transforms, etc. and locks (thread and GL states, including setting the target to be active) and draws.

This triggers the SFML sf::Text draw method. The m_font information at that point looks like this:


Beyond that, everything seems fine. Like I said, the color is there, the font information looks fine, and with the help of notepad+watch lists, I've confirmed all pointers are as they should be.

I seriously don't know why text is just invisible.

---

My question isn't 'how do I fix this' or 'what's wrong with my code' (since condensing this to something simpler would be pointless) - but more of how can I begin to debug text drawing? I have already updated GLEW and Freetype, building from source, and I'm using the latest (as of a few hours ago) dev snapshot of SFML 2.0.

3

General / Strange bottleneck

« on: October 24, 2012, 05:10:21 am »

Running my program is fine for a while; however, over a period of about 4-5 minutes it slows down almost to a halt and maxes out the CPU.

Did a little profiling and found this particular callstack to be the culprit:


I'm not using the joystick at all. Why is this slowing down the program? It'd be easy if it was showing where my code was involved in this particular stack but it doesn't.

Any help?

4

General / SFML 2.0 from apt-get

« on: October 17, 2012, 07:30:00 am »

Why isn't libsfml-dev 2.0 available from the debian repositories?

I have searched and can't really find a reason, though it's probably because it's still a RC.

5

Graphics / Possible bug with loadFromFile

« on: October 02, 2012, 05:15:46 am »

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
        EnableConsole();

// ...

// ...

        // Get command line
        int argc = 0;
        char** argv = CommandLineToArgvA(GetCommandLineA(), &argc);

        // If there were no images dropped...
        if(argc == 0)
        {
                // ...
                return 0;
        }

        sf::RenderWindow win; // Thought maybe it was because a window wasn't open (I read somewhere that
        win.create(sf::VideoMode(10, 10), "..."); // OpenGL may not init until a window is opened)

        // Init images
        deque<sf::Texture*> textures;
               
        // Load images
        for(int i = 0; i < argc; i++)
        {
                sf::Texture* img = new sf::Texture();
                if(!img->loadFromFile("test/test_1.png")) // RUNTIME ERROR
                {
                        // ...
                }
                textures.push_back(img);
        }
}
 

In the above code, upon the loadFromFile call (where it is marked), the program crashes and dumps running memory to the console.

Stack trace:

Code: [Select]

> msvcr110.dll!memcpy(unsigned char * dst=0x00676e70, unsigned char * src=0x00000000, unsigned long count=5044544) Line 367 Unknown
  msvcp110.dll!std::basic_streambuf<char,std::char_traits<char> >::sputn(const char * _Ptr=0x004d0ffb, __int64 _Count=6778480) Line 203 C++
  sfmlg.dll!std::operator<<<char,std::char_traits<char>,std::allocator<char> >(std::basic_ostream<char,std::char_traits<char> > & _Ostr={...}, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Str={...}) Line 521 C++
  sfmlg.dll!sf::priv::ImageLoader::loadImageFromFile(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & filename={...}, std::vector<unsigned char,std::allocator<unsigned char> > & pixels={...}, sf::Vector2<unsigned int> & size={...}) Line 126 C++
  sfmlg.dll!sf::Texture::loadFromFile(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & filename={...}, const sf::Rect<int> & area={...}) Line 160 C++
  ImageSequencer.exe!WinMain(HINSTANCE__ * hInstance=0x00150000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00542a83, int nShowCmd=1) Line 79 C++
  ImageSequencer.exe!__tmainCRTStartup() Line 528 C
  ImageSequencer.exe!WinMainCRTStartup() Line 377 C

In the file SFML\Graphics\ImageLoader.cpp,  line 126 says:

err() << "Failed to load image \"" << filename << "\". Reason : " << stbi_failure_reason() << std::endl;

At runtime, err() is showing that it has an address of 123 (which is not a valid pointer address at all, unless I'm missing something).

6

Graphics / Drawing/Display operations on worker thread

« on: September 30, 2012, 12:33:55 pm »

Stemming from this thread, my question is whether or not drawing functionality can take place in a separate thread (so long as the window events are handled in the main thread) on Mac OSX?

And yes, I know about setActive()

EDIT: This ticket seems to say that OpenGL contexts are thread safe for Mac, but I'd like to confirm.

7

Graphics / RenderTexture resize

« on: September 30, 2012, 11:10:44 am »

Is the easiest way of resizing a RenderTexture to simply delete/recreate it with the new size?

Also, can you call create() twice?

8

Graphics / [Solved] PNG refuses to draw

« on: September 28, 2012, 03:17:52 am »

Having a hell of a time getting this PNG to draw. Certain code blips have gotten it to draw in the past, but I've since re-written a large portion of the code and it's refusing to work. I've followed all the tutorials and looked at a ton of issues posted on the forum. The code just seems right, but it won't work.

Png class that extends `sf::Sprite`

RGPng::RGPng(string path)
{
        // Store
        _path = path;
        //setPosition(0, 0);

        // Create image
        if(!_image.loadFromFile(path))
        {
                // Throw
                throw new RException("Could not load PNG image '%s'", path.c_str());
        }

        // Create texture
        _tex.loadFromImage(_image);

        // Load into sprite
        setTexture(_tex, true);

        sf::IntRect r = getTextureRect(); // Confirmed; 0,0, correct w, correct h
}
 

Code that extends another drawable (debugging confirms this is being called)

RGPng* png; // = new RGPng("test.png");

// The SFML 'draw(target,states)' method calls this.
void OnDraw(sf::RenderTarget& target, sf::RenderStates states) const
{
        target.draw(*png);
}
 

And then the window's draw code (which eventually draws the above object)

void Draw()
{
        // Are we open?
        if(!isOpen() || !this) return;
       
        // Draw
        setActive(true);
        pushGLStates();
        clear(_(RIT_THEME, R_THEME)->Window.BaseColor);
        draw(*_manager);
        display();
        popGLStates();
        setActive(false);
}
 

Fraps is confirming I have ~30 FPS, so it's definitely being updated. I've also successfully drawn a simple triangle to the window using the same architecture in my program. Everything works fine up until I try to get this PNG to display.

Again, This PNG has worked just fine with SFML in past versions of the code before the engine was re-written.

Am I missing a fundamental idea behind the texture/sprite system? Am I missing a step?

9

Feature requests / sf::Window::getTitle()

« on: September 27, 2012, 01:05:14 pm »

std::string sf::Window::getTitle() would be nice.

I would fork it but I'm knee deep in a project right now.

More or less this is a reminder for myself to do it later.

10

Window / OpenGL on layered window

« on: September 25, 2012, 04:22:29 am »

Is it possible to set the native windows window to WM_LAYERED and draw on the window transparently? As in, clearing the window with a transparent color.

11

Window / TextEntered vs. KeyPressed

« on: September 25, 2012, 03:23:30 am »

When is TextEntered fired as opposed to KeyPressed? What's the difference? Are they both fired? When would TextEntered be used rather than KeyPressed?

12

Window / Wide strings in window titles

« on: September 20, 2012, 06:32:13 pm »

Is there any chance of getting wide strings to work in window titles? This was also a limitation in SDL that I was kind of hoping would be available in SFML.

13

SFML website / Page content at *beginning* of title

« on: September 20, 2012, 06:12:28 pm »

Is it possible for the page's content (i.e. "Forum Home" or "sf::RenderWindow - Wiki" or something) to be at the beginning of the title instead of "SFML - Simple ..."? I am the type of guy who has a million tabs open, and the titles just make it harder to work with.

14

Graphics / RenderTexture -> RenderWindow

« on: September 20, 2012, 04:10:18 pm »

What is the best way to blit/copy/draw a RenderTexture to/on a RenderWindow?

The only way I can see is to convert the RenderTexture to an Image and then draw the Image onto the RenderWindow.

15

Graphics / View optimizations?

« on: September 20, 2012, 04:07:28 pm »

Is the View system optimized in such a way that items drawn off-screen are ignored?

For instance, if I have a RenderWindow or Texture with a view with a top-left position of {5,5} (theoretically), and the right-most point of a line only reaches, say, {3,x}, is the line ignored for that frame?