Messages

1

Feature requests / Texture compression

« on: February 22, 2009, 11:18:58 pm »

I agree with most points except for memory usage. If some people want to have support for huge images, memory usage might become an issue.
I also believe it could have to uses for someone who uses SFML only to use OpenGL and the image facilities to load textures and that want full control over the texture parameters but that's not the majority, obviously.
Just some note about quality: with compression it's possible to have a bigger image that has the same memory usage that an uncompressed image with a lower resolution but the compressed image looks better because it has an higher resolution.

If I have time, I'll try to do some modification to see what is feasible.

2

Feature requests / Texture compression

« on: February 22, 2009, 10:06:57 pm »

Hello,
it's not really a feature request but an idea that came to my mind. Why not implement texture compression ? This can be done in a standard way using extension(ARB_texture_compression and EXT_texture_compression_s3tc I think) and it has many advantages when using lots of textures. It of course improves memory usage but it generally also increase performance with a minor quality loss. That's just an idea but what do you think of it ?

3

Feature requests / C++ (And others too) aliases for functions

« on: September 02, 2008, 11:29:17 pm »

If you want to fork juste because of a naming convention, then you are probably narrow minded.

4

Feature requests / C++ (And others too) aliases for functions

« on: August 26, 2008, 11:00:35 am »

This is going nowhere so I suggest the following procedure instead of debating:
-type "C++ naming convention" in google
-read first three or four answers
-type "http://www.parashift.com/c++-faq-lite/coding-standards.html" in you URL bar
-read the entire page
I believe it shows quite easily that there is no C++ standard even a non-official one.

5

Feature requests / C++ (And others too) aliases for functions

« on: August 23, 2008, 10:56:32 am »

How could you say there is a standard convention ? This is absolutely false, just look at a few libraries and you will see it. Even in the industry, there isn't one.
Furthemore, it's only a matter of style, you can't say "this one is standard" just because the first lettre is lowercase instead of uppercase, this is stupid!

A believe a more intelligent proposition would be to follow the standard of each language(I mean the one use the standard library), for example C++ uses "foo_bar", C# uses "FooBar", Java uses "fooBar" ...

6

Feature requests / Gui package

« on: August 08, 2008, 06:31:24 pm »

I know it"s a bit late but I have implemented an immediate mode GUI for SFML a few weeks ago, see the wiki. It's based on the molly rock's concept so feel free to use and improve it if you want.

7

SFML projects / An simple immediate mode GUI with SFML

« on: June 29, 2008, 07:44:40 am »

Thx,
I'll perhaps do it later, I'm going to Paris for 3 weeks and I'm not sure to have an internet access so I will put it on the wiki in 3 weeks.

8

SFML projects / An simple immediate mode GUI with SFML

« on: June 28, 2008, 09:42:05 pm »

Well, SFML uses freetype to render some text so if you using the dll version of SFMl, just suppress this line. However, if you using the static version of SFMl, you need the binary but I think it is included in the SDK in the external dependencies folder.

9

SFML projects / An simple immediate mode GUI with SFML

« on: June 28, 2008, 07:10:59 pm »

Hello,
I've discovered few months ago what an immediate mode gui was(see http://sol.gfxile.net/imgui/ for an introduction) and wondered how easy it really was to implement some basic controls. Here is the result of my try. I've coded a very simple gui using this paradigm entirely with SFML(I'm not using any Opengl code, only shapes and text) with the following controls:

button: a push button which display some text
scrollbar: a scrollbar(horizontal and vertical) which supports mouse and wheel movements
textfield: a single line edit text field(can be read-only) which support mouse clicking(but no selection) and some useful shortcuts like end or home
statictext: can display some text without any interaction
checkbox: a two state checkbox which displays some text
listbox: a list box with an automatic scrollbar if necessarywhich support mouse wheel and keyboard

All those controls except the static text have basic support for keyboard focus using the Tab and Alt-Tab combinasion and the Space key to action it(button and check box only) and arrows for movements(list and edit).
Furthermore, you can customize the colors of the controls even if it's not really explained in the code(see the source to understand how it works). I think the code is sufficiently commented to be understood(the header is commented for Doxygen even if there few places where its unfinished).

They are still some things that are not perfect(some come from the immediate mode paradigm) but I've tried to make it as usable as possible. I don't really have time to maintain it because so I post the as-is, feel free to copy and modify it if you want.
Here is a screenshort:

And here is the code(the header is 400 lines long and the code is 1200 lines long)
http://amaury.pouly.free.fr/Public/SfmlIMGui.zip

I would also appreciate some feedbacks.

10

General / New SVN Version

« on: June 10, 2008, 07:42:53 pm »

You'll never be able to get a perfect display of text if you scale your string or your font, and I can't help much about that. Look at modern games (eg. Half-Life 2) : they have to use specific techniques using pixel shaders to get a perfect text rendering at any scale.
However, in most cases the text will be nice enough, you don't really have to load the font so many times.

There is one solution however when using TrueType font because there are internally stored as Bezier curves so using a predefined step to approximate them and storing the result in a display list allows to render characters at different scales without recreating them(given a small enougth approximation step). Of course this has the disadvante of being specific to TT fonts and to require more work at the loading times but the result is more beautiful(I believe). I don't know if it's more or less efficient than using textures.

11

SFML projects / TGMs small patches

« on: May 01, 2008, 02:23:00 pm »

Hi,
That's only a suggestion but I believe clipping should be relative to the view. Why ? Because if a clipping relative to window while they are views doesn't make sense in my opinion. Moreover a clipping relative to drawable would be too advanced and probably useless, and it could also lead to poor performance if the clipping region is changed 100 times or more each frame.
For the interface, one interesting question is whether the window should handle it or the view. I mean, it would be interesting that the view handles the clipping region because a clipping relative to a view...without a view is a non-sense .
Perhaps you should create an abstract class named 'ViewClipper' with only two methods for now: "Enable","Disable". When a view is setuped, the Enable method is called and when the view is removed, the Disable method is called. One advantage is that all the logic is in the class that implements it: the window doesn't have to know how to do clipping. Another advantage is that if you want to implement several kinds of clipping, there is no problem(sometimes an advance clipping with stencil buffer can be useful for example whereas for basic things, clipping planes are far better). But one is that if you want to support some non-Opengl back-end(it depends on how you implement the software rendered) then you have to code one implementation for each renderer...

Anyway I'm sure you will find a correct interface for it and I agree with you when you say that's probably the main difficulty.