Messages

16

SFML website / Switching from phpBB2 to SMF

« on: October 27, 2010, 11:47:03 pm »

I use SMF2 for my personal site. It's pretty good (SMF1 was a bit lacking in features, and required complex add-ons to make it an effective forum. SMF2 is a major improvement) and has been stable for me. There's already a nice number of add-ons (or whetever they call them) available for it, too.

I wouldn't switch from phpBB, though. It may not have been the greatest choice, but it hasn't exactly done you wrong either. The pains aren't worth the gains.

17

Feature requests / RenderTarget::SetScissor

« on: October 27, 2010, 11:43:44 pm »

The first result for "glScissor" says everything about what is (not) implemented and what will:
http://www.sfml-dev.org/forum/viewtopic.php?t=3361

So it does. I guess I won't be limiting my searches to only the forums I expect the desired responses to be in, anymore.

18

Feature requests / sf::HTTP - full HTTP/1.1 compliance

« on: October 27, 2010, 11:37:53 pm »

Yes of course, if there's something that can be fixed and/or improved, I'm always interested. However the HTTP implementation in SFML is not meant to be the most complete one ever, it focuses on the most common stuff.

I don't know all the details about HTTP 1.1 and 1.0, so maybe you can help me. What exactly do you think that SFML should support? What do the 100 and 101 statuses mean, when are they sent?

The 100 status is "Continue", and can be ignored.
More: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.1

The 101 status is "Switching Protocols", it is normally sent when the client has requested to upgrade the protocol to a secure connection (https) from what I've read.
More: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.1.2
Client "Upgrade" command: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42

The entire HTTP/1.1 reference can be read at http://www.w3.org/Protocols/rfc2616/rfc2616.html , but it's a bit overwhelming to try to do all at once. I would begin with those two statuses, maybe chunked transfer encoding if you haven't already, and commonly used client headers (Accept [used to describe what types of responses the client is looking for, and order of preference], Upgrade, Referer, User-Agent [to differentiate between IE, Firefox, Chrome, SFML, etc], and If-Modified-Since [used to hold a client-side cached page]), and support for compressed response bodies (Content-Encoding response header, either "compress" LZW or "gzip" LZ77 compression).

PS: That said, I'm looking at the HTTP/1.0 reference right now, and SFML actually has most of it. Only thing really missing is request parameters.

19

SFML projects / SFGUI (old thread)

« on: October 27, 2010, 11:23:19 pm »

I was expecting BSD licensed, since SFML is also BSD licensed

SFML uses the zlib/png license

Oh. Well, I tend to think of everything as BSD-style vs GPL-style, since those are the two big ones. My bad.
zlib is just as well. The big thing for me is being able to ship it with BSD-licensed systems and being able to statically link to it in a closed-source application.

20

SFML projects / cpGUI - Anyone interested in developing?

« on: October 27, 2010, 10:52:18 pm »

So long as it remains under a liberal license like zlib or BSD, I would be more than glad to assist.

For background on myself;
I'm 21 right now and have been programming since I was 15 (so 6 years now). Most of that was done in C and C++.
I've written my own GUI using OpenGL when I was still learning, so I've done stuff like this before.
I've also helped with the GLICT GUI library that a friend of mine made, although my contributions there have been minor.
Most of my development time has been on a GPL-licensed MMORPG clone called "Open-Tibia", but very little of my code is actually in the project (unfortunately my programming style does not agree with theirs', nor does my preference on licensing -- I've been trying to get them to switch to BSD-style licensing for years now). Within Open-Tibia I mostly worked on "Yet Another Tibia Client", which is obviously the graphical side of Open-Tibia.
Like Recruit0, I'm very stubborn about coding style; but I'm usually pretty adaptable so long as you don't do pointless things.
I'm also in the Navy right now, so my time is a little limited. But programming is my hobby and I like to do it, so you can be sure I'll commit something from time to time.

I will look at the source code right now and see what I make of it.

EDIT:
After a 5 minute evaluation:
1) You use namespace cp, but still precede all widget names with "cp". So using the widget is cp::cpWidget. This redundancy is ugly and pointless.

2) It would integrate much better with SFML if you implemented widgets as sf::Drawable. Example, class cp::Object : public sf::Drawable {...};

3) There does not appear to be a standard interface for handling an sf::Event. This enables the library's user to easily implement his or her own widgets, which is an important feature for any GUI library. Simply attempting to implement every last widget the user may wish for in his application would result in cpGUI being a massive library.

4) cpObject does not define a parent widget, just the sf::Window it is a part of. The sf::Window should be part of cpGuiContainer; another cpObject or cpGuiContainer should be the widget's parent.

That's all for now.

21

SFML projects / SFGUI (old thread)

« on: October 27, 2010, 10:22:26 pm »

"SFGUI is released under the terms and conditions of the GNU LGPL."

O:

I was expecting BSD licensed, since SFML is also BSD licensed. Oh well.

22

Feature requests / RenderTarget::SetScissor

« on: October 27, 2010, 10:16:40 pm »

I searched for glScissor specifically and nothing came up. Guess I should have searched for clipping instead. Sorry, then.

23

Feature requests / sf::HTTP - full HTTP/1.1 compliance

« on: October 27, 2010, 10:15:28 pm »

Well, I see that the HTTP code in SFML is not completely compliant with the HTTP/1.1 standard (it doesn't accept 100 Continue or 101 Switching Protocols, among other things). I'm not even sure if it's completely compliant to the HTTP/1.0 standard.

Are there intentions to improve upon this?

24

Feature requests / RenderTarget::SetScissor

« on: October 27, 2010, 10:09:09 pm »

I have found glScissor(...) quite useful in the past. Although it is simple enough to call the OpenGL functions, I would prefer to use the API exposed by SFML.

The main thing I've personally used it for is to enforce game region and GUI object bondaries (for example, preventing text from overflowing its window). There are alternatives, but glScissor is the simplest and cleanest solution.

25

Feature requests / Choose Window Parent (e.g. to have Win2 always above Win1)

« on: October 27, 2010, 09:37:46 pm »

But I don't think you can use them to do what you want. Maybe you can do it by creating your own window (system specific) and use SFML only for rendering.

This solution would either reduce portability or require him to learn how to do it on all systems supported by SFML (which requires him to play with Obj-C for Mac, which I can personally attest to not being fun).

The functionality requested is very simple to implement, available on every presently supported system, and very common practice in a variety of different applications -- web browsers, video games, media players, etc. It is not a high-level feature and would not be complicated to use. I think it fits SFML nicely.

26

Feature requests / Manually setting Z-order

« on: October 27, 2010, 09:15:29 pm »

Laurent, I believe that OpenGL has had a depth buffer (which provides the requested functionality) since version 1.1 at the very latest; which any modern system (which, unless you intend to port SFML to archaic systems in the future, is all of the ones supported by SFML) will certainly support.

As for the thread starter, if maintaining the scaling/rotation heirarchy is important to you, SFML does provide sf::Drawable::transformToLocal to easily allow you to do the same thing. According to the documentation, this was added in SFML 1.4.

27

General discussions / SFML 2.0

« on: June 23, 2009, 11:33:39 pm »

Long time ago, a software renderer as a fallback was talked about, any plans for this in the future still?

This would make my day. Some systems just don't agree with OpenGL.

28

General discussions / Newb question about LGPL license

« on: June 04, 2009, 03:08:25 am »

Only your modifications to SFML.

No, if you want to keep it for you the zlib/png license allows it

Oh yeah, I keep forgetting that the SFML is under a friendlier license. xD

29

General discussions / Newb question about LGPL license

« on: June 03, 2009, 01:12:41 am »

Hi all

I also have a question about LGPL licence: I'm developing a commercial project that runs on a computer with wacom touchscreen, so I had to modify SFML to add touchscreen support. So now I need to share the source code of my commercial project?

Thanks!

Only your modifications to SFML.
And if the wacom touchscreen is a widely used piece of equipment it very well may be much appreciated (and, who knows, SFML developers may be able to improve your code, so the improvement can get back to you too).

That's the one beauty of open source.

30

General discussions / iPhone Port (in progress)

« on: April 16, 2009, 02:45:37 am »

sdl redefines main and has the event issues I describe. Threading might be an option however I'm not sure if apple allows it and it would be a pain to do.

iPhoneOS is pretty much a stripped-down OS X, isn't it?
I'd assume it'd allow threading...