Messages

1

Graphics / Re: Own Text Drawing System from sf::Sprites

« on: October 11, 2012, 08:24:38 pm »

Kinda hard to tell, but I'd suggest putting this:

CharPositionXIndex = 1;

Just after and outside your for loop, to reset the x position after the string is rendered.

2

Window / Re: Any analog to SDL's expose event?

« on: October 11, 2012, 06:38:16 pm »

No worries. Thanks for taking as much time as you do to make open source!

3

Window / Re: Any analog to SDL's expose event?

« on: October 11, 2012, 11:42:41 am »

There really is no problem I assure you! Due to certain backends (like SFML) being unable to deal with partial render states, I am accounting for this by periodically flushing the render tree to make sure any stale (that is, clean) areas of the screen get updated no matter what.

I was merely inquiring whether SFML had a mechanism to intercept from the window manager events to notify my application exactly where to redraw. I linked an example of SDL's mechanism, another example is QPaintEvent in Qt.

Since I don't have to worry about the performance hit, I am simply disregarding dirty rectangle information provided to the render() function of the SFML implementation of the Window SPI.

There's no discussion left to be had here, any that existed was merely my inquiry and my subsequent clarification of my intent.

4

Window / Re: Any analog to SDL's expose event?

« on: October 11, 2012, 12:09:46 am »

lol, I'm not trying to drag out the discussion. I was just explaining why I was doing what I was doing and trying to clear up your confusion. I feel like it's a little harsh to ask "what's the point" ...

It's really no problem for me, I've already committed the fixes on my develop branch. Thanks for the input.

5

Window / Re: Any analog to SDL's expose event?

« on: October 10, 2012, 10:45:50 pm »

Sorry if I was confusing! SFML indeed does not run on the browser, Avocado does!

The whole point of me using SFML is as a graphics backend for my game engine. You have a JavaScript codebase that does things like:

image = avo.Image.load("/images/my-image.png")

and on the PC you can select SFML as your graphics SPII, and it will do this:

http://cha0s.github.com/avocado/cpp/classavo_1_1SfmlImage.html#a271112e413d3f9a79c7e4d1c6c91f1ed

You can also select SDL as an implementation, and it will do this:

http://cha0s.github.com/avocado/cpp/classavo_1_1SdlImage.html#ad7b1cad32b8202f001b70f4e504daab6

In the browser, it's more like, you crate an img tag in script, set the src, and then fulfill a promise in an onload callback.

So again, the whole point here is that when I refer to a display list or any other engine logic, I'm talking about JavaScript code, completely platform-agnostic stuff. I'm just using SFML as one backend implementation for stuff... on PC. I'm liking it so far, I think it's a very nice library.

6

Window / Re: Any analog to SDL's expose event?

« on: October 10, 2012, 10:25:25 pm »

Two words: gratis and libre.

7

Window / Re: Any analog to SDL's expose event?

« on: October 10, 2012, 09:37:42 pm »

Well, since this technical question has seemingly become a philosophical debate, I feel like I should justify my position.

The big reason for using this technique is because the (ambitious) game engine Avocado that I'm developing as a hobby project is a JavaScript engine. While it's running on the PC, I am binding to the V8 JavaScript engine. SFML is one avenue I've been experimenting with to provide Graphics, Sound, potentially etc. to the engine using the SPI framework I've developed for Avocado. I also have an SDL backend that works in software, so it should go quite far back in terms of hardware.

That's great! While we're on PC we have access to crazy amounts of power, and it works awesome. The problem is... JavaScript doesn't only run on the PC. The vision for Avocado is that it will run everywhere JS will run (which if you've been paying attention is... everywhere ).

The rub here is that pretty much every JS implementation that isn't V8 SUCKS @$$ compared to V8. That's what I get in other browsers that aren't Google Chrome. So, what seems like "old, useless" techniques actually can make the difference between a smooth experience and a horrible laggy one.

In the browser I'm using HTML5 canvas and it isn't hardware-accelerated yet. This means we're "15 years ago" all over again. I'm not attached to optimization techniques such as display lists out of habit or because "it's all I know". I'm only 28 years old

I was working on a game project when the artist walked away and I had to halt it. It sucked, we were doing well on Kickstarter. I was developing this engine for that project and I've since started basically from scratch, re-architecting it. Avocado isn't currently in the browser again yet (In fact, I've only got it compiling on Linux as yet since I'm now on my own time, and getting the latest V8 compiling in MSYS is a PITA which I will eventually get around to solving), but our demo was a proof-of-concept and it actually worked very well. It just lagged behind in non-Chrome browsers and using these techniques I will solve that problem.

Sorry if it's a long post but I felt like I needed to explain myself.

8

Window / Re: Any analog to SDL's expose event?

« on: October 10, 2012, 08:42:07 pm »

I did some research and I've found that to be correct, with possibly conflicting information.

Here, Laurent says, "And yes, you need to clear/draw/display everything every frame, the back buffer is not a persistent object where you can accumulate rendered objects."

Which leads me to believe that partial "dirty rectangle" rendering isn't supported in SFML. That's a disappointment, but not a show-stopper when implementing a common runtime that can handle dirty rectangle refreshing in a backend-agnostic way (I can just entirely copy my own dirty-rectangle-enabled backbuffer to the window for SFML).

There is a potential conflict in the tutorials. At least, I believe that the clear() requirement was only since 2.0 or the 1.6 tutorial saying, "Note that clearing the window is not actually needed if what you have to draw is going to cover the entire screen; do it only if you have some pixels which would remain undrawn." is wrong or the clear requirement isn't a hard requirement. I'm trying to figure out what the real information is!

9

Window / Re: Any analog to SDL's expose event?

« on: October 10, 2012, 08:20:33 pm »

SFML requires you to call clear(), draw(), display() in every frame iteration.

Actually, SFML requires you to call draw and display when you want to update what's on the window

Unfortunately, there's no way to tell SFML to update the window when the window manager requires I guess, and that's unfortunate.

10

Window / Any analog to SDL's expose event?

« on: October 10, 2012, 07:21:31 pm »

My game library is implementing a display list structure to only refresh the screen (and specifically, the dirty rectangles) when things move.

For instance, in a tile-based 2D engine, if enemies are walking around, one won't have to do the (potentially, based on the speed of the underlying graphics implementation) expensive operation of redrawing the tile matrix every single frame. The display list will keep track of only the rectangles needing updating and rendering what's necessary.

The problem I'm having is that if I let my app do this, and for instance grab the window and move it offscreen and back, or if another window is dragged over my window, there is no event to let me know that due to something outside of the scope of my application, I need to redraw some or all of the window contents.

SDL has SDL_ExposeEvent, is there an analog for SFML?

EDIT: That page really showcases how lame SDL docs are in places The relevant part is:

SDL_ExposeEvent is a member of the SDL_Event union and is used whan an event of type SDL_VIDEOEXPOSE is reported.

A VIDEOEXPOSE event is triggered when the screen has been modified outside of the application, usually by the window manager and needs to be redrawn.

11

Graphics / Re: RenderTexture bug?

« on: October 09, 2012, 06:21:32 pm »

Thanks for the hint, Laurent! It was my fault all along. Somewhere along the line (probably during a kernel update: running Xubuntu 12.04 btw) I missed updating my nvidia drivers. Updating them made everything work lovely!

Thanks and I'll try to limit the noob questions...

12

Graphics / Re: RenderTexture bug?

« on: October 09, 2012, 04:15:38 pm »

I just did some more testing and I found that commenting the first

window.draw(sf::Sprite(buffer.getTexture()));

line causes it to work. I'm very confused! It really feels like a bug. I think I'll go to the stable version and try that.

13

Graphics / Re: RenderTexture bug?

« on: October 09, 2012, 03:40:52 pm »

what happens if you clear the buffer before drawing buffer2 to it?

Please explain how that is not what I'm doing, I genuinely don't understand. I clear buffer both times before I render buffer2 on it.

And does pure white background referre to the whole window or just the rendertexture box?

Pure white refers to what you see if you run the program, it is the end state of 'window' after all operations have been applied.

14

Graphics / Re: RenderTexture bug?

« on: October 09, 2012, 09:55:48 am »

*Sigh*

I did read right, and that's why I posted the second code. Here's new code that does the exact same thing, and exhibits the exact same bug, with a couple of things shuffled around to make you happy:

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

int main()
{
    sf::RenderWindow window(sf::VideoMode(320, 240), "Test");
   
    sf::RenderTexture buffer;
    buffer.create(320, 240);

    sf::RenderTexture buffer2;
    buffer2.create(64, 64);
   
    // Pink box
    buffer.clear(sf::Color(255, 0, 255));
    buffer.display();
   
    // Blue box
    buffer2.clear(sf::Color(0, 255, 255));
    buffer2.display();
   
    // Should draw a light blue box in the upper left corner with a pink
    // background. OK!
    buffer.draw(sf::Sprite(buffer2.getTexture()));
    buffer.display();
    window.clear();
    window.draw(sf::Sprite(buffer.getTexture()));
    window.display();
   
    // White box.
    buffer.clear(sf::Color(255, 255, 255));
    buffer.display();
   
    // Should draw a light blue box in the upper left corner with a white
    // background. NOPE! Pure white background...
    buffer.draw(sf::Sprite(buffer2.getTexture()));
    buffer.display();
    window.clear();
    window.draw(sf::Sprite(buffer.getTexture()));
    window.display();
   
    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
        }
    }
}
 

No offense, but could you help instead of making me do busy work by shuffling my code around into the semantic equivalent over and over?

15

Graphics / Re: RenderTexture bug?

« on: October 09, 2012, 09:27:19 am »

Yep! I know that what I'm doing here is weird looking. The reason is because this is just meant to exhibit the bug, I wouldn't really use SFML like this, I promise!

Here's the code with clear calls before drawing is done on the window, with the same (wrong?) behavior...

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

int main()
{
    sf::RenderWindow window(sf::VideoMode(320, 240), "Test");
    window.clear();
   
    sf::RenderTexture buffer;
    buffer.create(320, 240);

    sf::RenderTexture buffer2;
    buffer2.create(64, 64);
   
    // Pink box
    buffer.clear(sf::Color(255, 0, 255));
    buffer.display();
   
    // Blue box
    buffer2.clear(sf::Color(0, 255, 255));
    buffer2.display();
   
    // Should draw a light blue box in the upper left corner with a pink
    // background. OK!
    buffer.draw(sf::Sprite(buffer2.getTexture()));
    buffer.display();
    window.draw(sf::Sprite(buffer.getTexture()));
    window.display();
    window.clear();
   
    // White box.
    buffer.clear(sf::Color(255, 255, 255));
    buffer.display();
   
    // Should draw a light blue box in the upper left corner with a white
    // background. NOPE! Pure white background...
    buffer.draw(sf::Sprite(buffer2.getTexture()));
    buffer.display();
    window.draw(sf::Sprite(buffer.getTexture()));
    window.display();
   
    while(window.isOpen())
    {
        sf::Event event;
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                window.close();
        }
    }
}
 

For a little background, I'm creating a JavaScript game engine here: https://github.com/cha0s/avocado and I was interested in implementing a graphics backend using SFML. I've been testing it and this behavior is messing up my progress!