Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Qix

Pages: [1] 2 3 ... 10
1
General discussions / Re: A new logo for SFML
« on: January 24, 2013, 09:35:44 am »
Am I the only one that thinks the hovering icons (in every logo) are clutterish (and ironic with the "simple" in SFML) and detract from the overall attempt of the logo?

No, you're not the only one. The icons add a certain 'cheap' factor to the logo in my opinion.

I loved the one with 2 gears ( https://legacy.sfmluploads.org/cache/pics/176_sfml%20logo%20example.png without the version number and the long text) and it looks really cool animated in a splash screen. :D

Seconded. That one caught my eye the most.

2
General discussions / Re: A new logo for SFML
« on: January 21, 2013, 05:39:01 am »
Just want to note:

http://bp.io/wp/wp-content/uploads/2013/01/sfml_logos.png

^ Looks like a PHP logo knockoff.

EDIT: Removed image embedding. The image is huge.

Googles php logo .. oh its a word in an ellipse, like a million other logos! ;)

I was talking about the color schemes/font being similar...

3
Java / Re: Maven repository ?
« on: January 21, 2013, 03:46:12 am »
+1 on putting JSFML on Maven. It would be a wise decision.

4
General discussions / Re: A new logo for SFML
« on: January 21, 2013, 03:44:25 am »
Just want to note:

http://bp.io/wp/wp-content/uploads/2013/01/sfml_logos.png

^ Looks like a PHP logo knockoff.

EDIT: Removed image embedding. The image is huge.

5
Graphics / Re: Shaders: General questions
« on: January 11, 2013, 09:40:45 am »
Ahh so textures are applied using normalized coordinates per-vertex, much like assigning a color per-vertex? And the shader just works with the color/texture that's already there?

Also, thank you for the discard tip.

I think I was overthinking shaders. Really the whole process is quite simple in theory.

Thanks for all of the answer, Laurent!

6
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.

7
What hardware are you on, out of curiosity? Shaders not being supported suggests it's extremely old hardware or extremely outdated drivers.

8
Graphics / Re: Problem using sf::Rect
« on: January 08, 2013, 12:40:51 am »
What code is on the line c:\users\username\documents\visual studio 2012\projects\brickbreak\brickbreak\ball.cpp : 6? Copy and paste exactly.

Also, without stealing Laurent's inevitable thunder, I will say that a complete code sample would be nice. We can't help you much with the "examples" you've given us.

9
SFML website / Re: AW: How can I know or at least bookmark my own post?
« on: January 02, 2013, 11:17:21 am »
You can also subscribe to posts of your importance and get notified about new entries. ;)

Or you can visit this link to turn on automatic notifications (subscriptions) to all threads you create/post in. Notifications will show up in the Replies page, which can easily be found at the top of the forum's page.

10
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 10:56:10 am »
I think the ATI bug which is solved by the latest beta drivers has nothing to do with that. Your problem is a logic problem in SFML, his problem is purely a driver bug (which happens in monothreaded applications).

Gah, well I feel useless now.

EDIT: Laurent, should I make a bug report for the glFinish() issue?

11
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 10:33:09 am »
Ok... so you actually face a well known problem. We could have saved a lost of wasted time and effort ;D

I've mentioned it was in another thread. I wasn't aware different threads were an issue other than with setActive... >.>

This should be better documented IMHO.

EDIT: I hope to hear from opatut to see if any of this helps solve his issue.

12
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 10:08:16 am »
glFinish() forces all the queued OpenGL commands to execute and finish. The call returns when the driver has executed everything.

If it solves your problem, it means that you use multi-threading, or at least multiple OpenGL contexts (ie. multiple sf::RenderTarget and/or sf::Context). Is that what happens in your program?

Multithreading. :P

13
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 09:23:16 am »
This reminds me two things:
- bigger (and/or more) glyphs need bigger textures; if you reach your graphics card's limit additional glyphs will fail, SFML can't handle multiple textures for the same character size (yet?)
- a font loaded in a thread may not be updated in the rendering thread; in this case you need to call glFinish() after loading the font

Calling glFinish() worked for one font, actually. All subsequent fonts failed to load. It also only works for setting one text object. It's an improvement but not a total fix.

EDIT: CALLING glFinish() AFTER ALL FONTS WORKS. >.> Holy crap.

Are there any implications or warnings/potential side effects with this?

EDIT2: Seems to be a complete fix. Images and text are working fine. Going to test on the Integrated intel (mac)...

14
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 08:52:17 am »
But wait... was it your problem? You were destroying sf::Font instances that were still being used?

Nonono, that was just a test for a workaround. Read the edit in the post before yours. I found a workaround that seems to fix the problem without having to load the same font multiple times for each Text object.

It seems like the perfect workaround (as perfect as it could get).

Just to reiterate, Upon the label creation, yes the font is re-loaded into memory, but destroyed directly after. This seems to work; I'm going to re-work the issue and re-create the Lua scripts to get rid of all the mangled crap. I'll report back here after I'm done.

15
Graphics / Re: Text rendering broken on my machine when using sf::Shape
« on: November 28, 2012, 08:42:52 am »
Unloading the font after the text object is creating causes an access violation. That's probably expected (I was hoping the texture for the text object actually cloned the glyph-sheet).

I guess I'm going to have to live with just a TON of fonts loaded in.

EDIT: While writing this, another test came into my head, and I tried it, and found a complete workaround for the issue without a ridiculous amount of memory (only one font loaded, as it normally would be).

Regarding the previously listed order of operations for the workaround, only the dummy font needs to be (and can be) unloaded safely. Also, the desired font can be reused.

This achieves the desired functionality.

I'm going to put it into effect and try it as it will be in production to confirm this works. Wish me luck.

Pages: [1] 2 3 ... 10