Messages

1

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 11, 2012, 12:38:47 am »

I tested it, and as you said, with BlendNone the text drawn on a transparent renderTexture now looks as if it was drawn to the window directly.

This completely solves all my concerns written in this thread, thank you very much!

2

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 10, 2012, 11:47:34 pm »

EDIT: Deleted, I was wrong

3

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 10, 2012, 09:06:41 am »

Thanks for the reply,
It would be great if the blend modes would work for drawing text.

Also thanks for the heads up on having to clear the renderTexture initially.

4

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 10, 2012, 08:01:02 am »

My solution

So I kept trying to fix this somehow, and even though this is probably not the cleanest way to do it, I managed to fix the problem I was dealing with, which is the very low quality of text drawn to a transparent background renderTexture if a small character size font is used.

This problem is (most likely) due to the font smoothing SFML uses, and is most visible when the text is so small, that the "lines" the characters are made of are less than a pixel "thick". In that case, the smoothing fades away even that single pixel "thickness" at some places, resulting in the low visual quality.

I was able to fix this, by drawing the text to the renderTexture multiple times (2 is enough), which might significantly decrease performance if the text is redrawn every frame, but in my case I only render the text once, after that I am just dealing with the renderTexture. By drawing the text at least twice, the areas that got lowered alpha values due to the smoothing get to be completely solid this way.

I have modified the previous example code, to show the results:

http://postimage.org/image/e4cympxfr/

#include <SFML/Graphics.hpp>

int main()
{       sf::RenderWindow App;
        sf::VideoMode VM;
        VM.width = 800; VM.height = 400;
        sf::RenderTexture rTexture; sf::Sprite rSprite;
        rTexture.create(800,400);
        rSprite.setTexture(rTexture.getTexture());
        sf::Font ProFont;
        ProFont.loadFromFile("profontwindows.ttf");
        sf::Text Text;
        Text.setFont(ProFont);
        Text.setCharacterSize(9);
        Text.setString("Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud \n exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in eprehenderit in voluptate velit esse cillum dolore eu fugiat \n nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.");
        App.create(VM, "sfml");
        App.clear(sf::Color(128,128,128));
        App.draw(Text);
        Text.move(0,100);
        //xrTexture.clear(sf::Color(0,0,0,255));
        rTexture.draw(Text);
        Text.move(0,75); rTexture.draw(Text); rTexture.draw(Text);
        Text.move(0,75); rTexture.draw(Text); rTexture.draw(Text); rTexture.draw(Text); rTexture.draw(Text);
        rTexture.display();
        App.draw(rSprite);
        App.display();
        while (App.isOpen())       {}
        return 0;

}

I hope this helps someone, but still, I think giving an option to disable font smoothing would be a better solution.

5

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 07, 2012, 11:41:04 pm »

I see, that's what I was afraid of. This is a pixelated bitmap font, that otherwise would look great without smoothing, but if there is no solid background behind the text, whatever the smoothing does breaks it. I think if there would be a way to turn off smoothing, it would resolve this.

I see others on the forum have requested this option, I hope an sf::Font::setSmooth(bool) kind of option would be added in the near future.

Thank you for your help!

6

General / Re: Text drawn to renderTexture looks broken (see example)

« on: August 07, 2012, 07:51:51 pm »

Thank you for your answer!

I didn't clear the rendertexture on purpose, since I wanted to have the text on a transparent background, and I  only need to clear it when one page gets filled (in my engine), and even then with a transparent color.

So now it appears, that this is caused by drawing text on transparent background, and not from it being a renderTexture.

Do you think there's any way to improve the quality of the text when drawn to a transparent, or semi-transparent renderTexture, so I could have some scrolling text/console overlay above my game?

7

General / Text drawn to renderTexture looks broken (see example)

« on: August 07, 2012, 03:39:50 am »

Hi,

I am working on making an in-game terminal/debug console for my engine, and I wanted to draw all the text once to a renderTexture, then I'll just scroll the sprite it is linked to up, so I don't actually need to render the text every frame.

I have noticed however, that when I directly draw text on my main renderWindow, it looks perfect, but if I draw the text on a renderTexture, and then draw the sprite linked to the renderTexture to the renderWindow, it looks ...broken. I can't really find a better word to describe it, but I have attached a screenshot of what I am talking about.

The top 3 lines are drawn to the renderWindow, and look good, the bottom ones are on the renderTexture and look the way it shows.


EDIT: I uploaded a bigger pic without compression, that better shows this:

In case the direct image link changes, and the image doesn't show, try this:
http://postimage.org/image/7ss9oaj7j/

Here is a minimal and complete (and super sloppy) example that reproduces the output in the screenshot:
(I have attached the font I used)

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow App;
        sf::VideoMode VM;
        VM.width = 800; VM.height = 400;
        sf::RenderTexture rTexture; sf::Sprite rSprite;
        rTexture.create(800,400);
        rSprite.setTexture(rTexture.getTexture());
        sf::Font ProFont;
        ProFont.loadFromFile("profontwindows.ttf");
        sf::Text Text;
        Text.setFont(ProFont);
        Text.setCharacterSize(9);
        Text.setString("Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud \n exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat \n nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.");
        App.create(VM, "sfml");
        App.clear(sf::Color(128,128,128));
        App.draw(Text);
        Text.move(0,50);
        rTexture.draw(Text);
        rTexture.display();
        App.draw(rSprite);
        App.display();
        while (1)       {}
        return 0;
}
 

Laurent, if you are reading this, what do you think is causing this? Is there some setting I would need to apply to the renderTexture? I have tried with smooth on and off, and saw no difference.
This "graininess" becomes less visible the bigger the characterSize is, but I would need this font as small as it is now, I want the most possible text displayed on the screen (this is the font and size I use in my IDE as well).

Thank You in advance!
(I am using SFML 2.0, the snapshot I downloaded on 08-03-12 (3 days ago), in Win7)

[attachment deleted by admin]

8

System / Re: How can I properly remove/fix handling joystick events?

« on: August 04, 2012, 06:47:29 pm »

Thanks for the reply, but I still have the same issue in both the release candidate and the snapshot I compiled yesterday.

I have tried this on 2 computers (but with the same 360 wireless receiver).

Am I the only one encountering this?

9

System / How can I properly remove/fix handling joystick events?

« on: August 04, 2012, 02:56:43 am »

Hi,

A while ago I have noticed that while I have my 360 Wireless receiver installed (whether it is in use, or plugged in at all does not matter) SFML produces extremely low performance, and it completely hangs while the mouse is being moved, or keyboard input is being received.

Laurent helped me out with:

Can you try to comment line 121 of src/SFML/Window/WindowImpl.cpp (ProcessJoystickEvents() and recompile SFML?

This completely fixed the issue, I can live with the gamepad not being usable with SFML for the time being.

Recently however, I have started using MS AppVerifier, mostly to help debug issues with multiple threads, but   it also stops my program when the above line is commented out in the source, producing this log:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<avrf:logfile xmlns:avrf="Application Verifier">
   <avrf:logSession TimeStarted="2012-08-03 : 17:33:15" PID="8424" Version="2">
      <avrf:logEntry Time="2012-08-03 : 17:33:17" LayerName="Handles" StopCode="0x303" Severity="Error">
         <avrf:message>NULL handle passed as parameter. A valid handle must be used.</avrf:message>
         <avrf:parameter1>0 - Not used.</avrf:parameter1>
         <avrf:parameter2>0 - Not used.</avrf:parameter2>
         <avrf:parameter3>0 - Not used.</avrf:parameter3>
         <avrf:parameter4>0 - Not used.</avrf:parameter4>
         <avrf:stackTrace>
            <avrf:trace>vfbasics!AVrfpHandleSanityChecks+29 (d:\avrf\source\base\avrf\vrfcommon\handle.c @ 178)</avrf:trace>
            <avrf:trace>vfbasics!AVrfpNtClearEvent+1f (d:\avrf\source\base\avrf\vrfcommon\handle.c @ 418)</avrf:trace>
            <avrf:trace>KERNELBASE!ResetEvent+e ( @ 0)</avrf:trace>
            <avrf:trace>DINPUT!+40f095a3 ( @ 0)</avrf:trace>
            <avrf:trace>DINPUT!+40f07c37 ( @ 0)</avrf:trace>
            <avrf:trace>DINPUT!+40f0b23b ( @ 0)</avrf:trace>
            <avrf:trace>DINPUT!+40f05ab7 ( @ 0)</avrf:trace>
            <avrf:trace>WINMM!joyConfigChanged+638 ( @ 0)</avrf:trace>
            <avrf:trace>WINMM!joyGetPosEx+50 ( @ 0)</avrf:trace>
            <avrf:trace>sfml-window-d-2!sf::priv::JoystickImpl::isConnected+ad (e:\myfiles\downloads\laurentgomila-sfml-2.0-rc-68-ga0c1f5f\laurentgomila-sfml-a0c1f5f\src\sfml\window\win32\joystickimpl.cpp @ 66)</avrf:trace>
            <avrf:trace>sfml-window-d-2!sf::priv::JoystickManager::update+e2 (e:\myfiles\downloads\laurentgomila-sfml-2.0-rc-68-ga0c1f5f\laurentgomila-sfml-a0c1f5f\src\sfml\window\joystickmanager.cpp @ 80)</avrf:trace>
            <avrf:trace>sfml-window-d-2!sf::priv::WindowImpl::processJoystickEvents+38 (e:\myfiles\downloads\laurentgomila-sfml-2.0-rc-68-ga0c1f5f\laurentgomila-sfml-a0c1f5f\src\sfml\window\windowimpl.cpp @ 150)</avrf:trace>
            <avrf:trace>sfml-window-d-2!sf::priv::WindowImpl::popEvent+45 (e:\myfiles\downloads\laurentgomila-sfml-2.0-rc-68-ga0c1f5f\laurentgomila-sfml-a0c1f5f\src\sfml\window\windowimpl.cpp @ 106)</avrf:trace>
            <avrf:trace>sfml-window-d-2!sf::Window::pollEvent+28 (e:\myfiles\downloads\laurentgomila-sfml-2.0-rc-68-ga0c1f5f\laurentgomila-sfml-a0c1f5f\src\sfml\window\window.cpp @ 183)</avrf:trace>
            <avrf:trace>BlackBookEngine!main+1d0 (e:\myfiles\dropbox\!programming\blackbookengine\blackbookengine\black book engine\main.cpp @ 121)</avrf:trace>
            <avrf:trace>BlackBookEngine!__tmainCRTStartup+1bf (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 555)</avrf:trace>
            <avrf:trace>BlackBookEngine!mainCRTStartup+f (f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 371)</avrf:trace>
            <avrf:trace>kernel32!BaseThreadInitThunk+12 ( @ 0)</avrf:trace>
            <avrf:trace>ntdll!RtlInitializeExceptionChain+63 ( @ 0)</avrf:trace>
            <avrf:trace>ntdll!RtlInitializeExceptionChain+36 ( @ 0)</avrf:trace>
         </avrf:stackTrace>
      </avrf:logEntry>
   </avrf:logSession>
</avrf:logfile>

I am wondering what would be the correct way to remove processing joystick input, and also if there is any progress on possibly fixing whatever is causing the performance problems with certain joysticks/gamepads.

Thanks in advance!

10

Graphics / Re: Sprite Masking in SFML2

« on: April 13, 2012, 07:53:39 am »

Wow, thanks very much, that's exactly what I wanted, I am definitely going to make good use of this!

Also thanks for the answers to my questions from both of you. 

11

Graphics / Re: Sprite Masking in SFML2

« on: April 12, 2012, 08:07:35 am »

Thanks a lot for your reply and code segment, it is very helpful.

I imagine (as you have mentioned too) that dealing with images instead of textures will probably have a noticeable performance impact.

I was actually thinking about replacing what img.createMaskFromColor(sf::Color::Magenta); does with a fragment shader, such that every magenta pixel will be changed to 0.f alpha, that way the image->texture conversion would not be necessary.

I am not sure if this is possible like that though.

I quess it would depend on whether the shader is applied AFTER the image without shader is displayed or BEFORE. If it is after, then even though the magenta will be changed to transparent, whatever used to be in the background is already overwritten. Common sense would tell me that it is applied before, but I don't have experience about it. Could someone perhaps tell me how it works?


Another thing to Dienes:
Did you write your own particle system? Looks like they are checked for collision even between each other, are you doing some tricky optimization for that? Are you using some wider scope physics engine, or just some minimal footprint one for the particles?

12

Graphics / Re: Sfml 2.0 Flipping a sprite

« on: April 12, 2012, 07:55:25 am »

Sprite.Scale(-1.f,1.f); is the simplest way as far as I know

13

Graphics / Re: parallax scrolling and sf::View.Viewport

« on: April 06, 2012, 08:03:28 pm »

I see.
I figured maybe I could have like 10 possible parallax layers, that way each object on the same layer would get rendered the same time, so the view would be changed only 10times per frame.

I just wanted to keep the object's actual position and velocity separate from the position and apparent velocity due to camera position/movement. So if a star is not actually moving it would have been nice to not have to change its position/velocity only because the camera is moving.

But yes, that is how I currently have them implemented that I actually move them according to their parallax factor.

14

Graphics / Re: parallax scrolling and sf::View.Viewport

« on: April 06, 2012, 09:51:51 am »

You're right, it's the view I meant to change for each object, not the viewport.
So it just comes down to:
Is it expensive to change the view lots of times each frame?

Or would you have some suggestion on how else to implement parallax scrolling?

15

Graphics / parallax scrolling and sf::View.Viewport

« on: April 06, 2012, 07:36:51 am »

I am working on a 2d scrolling shooter, everything in the gameplay is happening in one "layer", and other decorative stuff, like stars in the background, or dust/debris in the foreground are in different layers, each object has a parallax multiplier, 1.0 as default, 0.+ for slowly moving background objects and 1.+ for in front of foreground ones.

Currently the way I have everything implemented is that everything has a default non-zero velocity (even static non-moving objects) accounted just for scrolling, which I would rather change, to take advantage of viewport, which in my understanding would be a better thing to serve as camera.

Using the viewport would be very straightforward if there is no fake depth added by parallax layers.
I am not sure how expensive it is to call  sf::View.SetViewport(), depending on that I am thinking about doing one of the following:

1. if not expensive at all: for every object with a non-default parallax multiplier, during the render I set the viewport according to the objects parallax multiplier and when done set it back to default (there around 500-800 objects with parallax multipliers that need to be drawn each frame)

2. if it is somewhat expensive instead of using any random float 1.f-3.f for parallax multiplier I would instead use a few 10-20 "layers", each with its own parallax multiplier, and objects on the same layer will be grouped together (at least as a bunch of pointers to each on the same layer to be used in the same loop when they are rendered) so the viewport is only set once for each layer.

3. should I not use viewport at all, and go with my own implementation? (doesn't seem like a good idea..) should I do it in some other way than what I thought of above?

Your assistance on this would be much appreciated,
Thanks in advance