Messages

1

SFML projects / cpGUI - Anyone interested in developing?

« on: October 29, 2010, 03:27:41 pm »

 - int8_least_t, int16_least_t unsoweiter are simply redundant, char, short, long and long long are guaranteed to be at least 8, 16, 32 and 64 bits long, respectively.

Not exactly. From the standard:

There are five standard signed integer types : signed char, short int, int, long int, and long long int. In this list, each type provides at least as much storage as those preceding it in the list.

It is entirely plausible for all of these types to be, for example, 8-bits long.

2

SFML projects / cpGUI - Anyone interested in developing?

« on: October 29, 2010, 03:57:30 am »

Boost.Threads, Boost.ASIO, Boost.Function, and Boost.Date_Time are the most useful libraries in boost. Nearly everything else is not very useful for 99% of computer applications (ie Boost.Graph, Boost.Spirit) or provide a wrapping over something that already exists in common form on most/all C implementations (ie Boost.Integer, Boost.Python).

I can only respond to this with a list of libraries I make frequent use of, off the top of my head: Array, Bind, Conversion, Foreach, Lambda, Lexical Cast, Math, Multi-Array, Operators, Pointer Container, Program Options, Property Tree, Random, Ref, Regex, Serialization, Singals, Smart Ptr, Test, Tuple, Unordered, Utility.

Allow me.

Code: [Select]

typedef unsigned char uint8_t;
typedef signed char sint8_t;
typedef unsigned short uint16_t;
typedef signed short sint16_t;
typedef unsigned long uint32_t;
typedef signed long sint32_t;

typedef struct {
    uint8_t red;
    uint8_t green;
    uint8_t blue;
    uint8_t alpha;
}Color_RGBA32;

Less than 20 lines of code to remove a dependency; it's well worth it.

This is not portable. You incorrectly assume that, for example, signed short is always a 16-bit integer. This is not guaranteed by the standard and may vary by compiler; otherwise there would be no reason for cstdint to exist in the first place. Please see here.

At least you've got a good reason for it. I won't pester you about this anymore.

Not at all. These kinds of discussions are very important to ensure that our development decisions are well thought-out.

3

SFML projects / cpGUI - Anyone interested in developing?

« on: October 28, 2010, 05:46:53 am »

Okay then, I'm checking out github now.

Check out recruit0's branch for something reasonably up-to-date; mine is supposed to be the "master", but I haven't given it the attention it deserves.

Can't say I'm a fan of the boost dependency. Boost is an awfully large library to have to download for such a comparatively small one.

Boost is not a library so much as a collection of much smaller libraries. Frankly, it's nearly as close to standard and portable as the STL itself. Unless there is a known issue, I make a point of taking advantage of Boost's facilities whenever appropriate; development time is a premium. Looking at the amount of boost usage currently in the repo, I assume recruit0 agrees.

Boost's build system is also prone to issues with MinGW, at least in my experience;

If there is any valid criticism of boost, unfortunately, this is it; the build system leaves much to be desired.

although IIRC boost::reference_wrapper<> is implemented in header files.

The majority of boost is implemented in header files, for a variety of reasons.

I think a custom implementation (or just including the header for boost::reference_wrapper<> in the repository, since the boost license is fairly permissive) would be better, and realistically such a thing is very unnecessary anyway.

It is always preferable to use existing, well-tested code rather than reimplementing it yourself.

The dependency on boost::gil for colors and on boost int types is just unnecessary, #include <cstdint>.

There might be some merit to your suggestion for boost::gil, but <cstdint> is not included in all modern C++ distributions. As we depend on Boost anyway, it is safer to make use of Boost.Integer. If I recall correctly, when the compiler provides it, Boost merely wraps around <cstdint> anyway.

I also see you're using boost-style naming conventions for classes and functions now, as opposed to the SFML naming conventions. Although it's your call, I would recommend using SFML naming conventions because it makes life easier on the developer using your library. Personally, though, I prefer the naming convention you're using; it's what I use myself.

Recruit0 and I discussed this at length when we took over the project. My position is that language libraries should try to adhere to the conventions of the language standard; Boost uses the same naming conventions as the STL, and we adhere to that as well. By my reckoning, it is libraries such as SFML that make life more difficult by using conventions that do not adhere to C++ styling (although their technical merits alone more than make up for it).

4

Feature requests / File system functions

« on: September 04, 2010, 01:18:45 am »

There's a nice, detailed summary here.

5

Graphics / Cover an image except for a little part

« on: July 05, 2010, 06:56:13 pm »

This can be accomplished with sf::Image::CreateMaskFromColor.

Basically, if your image is a white circle with black background, just pass the image the color you want to be transparent with that function.

6

Graphics / Why cant sprite take a pointer to the location of the image?

« on: July 01, 2010, 12:06:25 am »

You know what they are, but that doesn't necessarily mean you understand how they work in the semantics of C++.

Exactly!
(Edit: I see pdusen removed his post... I hope it's not dramatic if I leave the quote )

Nah, I just missed the last two posts before mine before I posted. Afterwards I realized my comments were redundant.

7

SFML projects / Re: SFML powered / crossplatform - SideScroller Construction

« on: June 25, 2010, 01:46:30 pm »

    - Linux (KDE)

How can you possibly only support a specific desktop environment? They will all run each others' programs.

8

General / Statically linking to SFML on Ubuntu

« on: June 24, 2010, 07:48:45 pm »

If that's now how things work on Linux, are you supposed to specify SFML as a requirement to run your program?

Yes. Typically on Linux your package manager handles all of the dependencies, though.

9

General discussions / SFML2 API concerns

« on: June 24, 2010, 07:29:54 pm »

...You know a programmer who gets confused by the word "const"?

Not in general, but it partially obscures situations and requires more time to understand a context. The problem of overusing a language feature is that you don't differ anymore between important and useless cases.

I don't necessarily think it's important to const-qualify in this case, but I think you're massively overblowing the impact of doing so on a user.

What's your basis for believing that? It's been my experience that C++ programmers generally go out of their way to const-qualify when a passed value won't be changed, copy or not.

It's my experience from looking at code. SFML is such an example, the C-library OpenGL is another one. I just skimmed through some Boost and MSVC++ StdLib headers, and I never saw a top-level-const in a function declaration.

I'd like to point out that OpenGL probably is that way because it's a C library and const wasn't in C when it was created.

Of course, the whole topic is also a matter of style. I personally like expressive code, and I don't like redundancy or irrelevant information. But we should at least agree that top-level const-qualifications in function declarations (not definitions) are meaningless.

I think it is really a style thing. My personal preference is, if I'm not modifying something, it becomes const, period. I see no reason to make an exception here for function parameters, or for pass-by-copy.

10

General discussions / SFML2 API concerns

« on: June 24, 2010, 01:31:43 pm »

A top-level const appearing in the documentation doesn't provide any relevant information to the user. It's even worse, the const is likely to arise confusion and to deflect from important things.

...You know a programmer who gets confused by the word "const"?

The reason why only a small part of the C++ programmers qualifies copied parameters const is that it has mostly no noteworthy additional value.

What's your basis for believing that? It's been my experience that C++ programmers generally go out of their way to const-qualify when a passed value won't be changed, copy or not.

11

General / Make install did not install correctly

« on: June 18, 2010, 05:00:15 pm »

There appears to be a SFML RPM but it's for mandriva (which may use a different directory setup than Fedora). It's also v1.5. Is anyone managing packages for SFML?

I don't believe there are any Fedora rpms out there; at least, I was never able to find any when I used Fedora.

Incidentally, there are packages in Ubuntu (and Debian, I assume), but their dependencies are incomplete; they don't require you to install OpenGL headers that really are required to actually use SFML.

12

SFML projects / cpGUI - Anyone interested in developing?

« on: June 17, 2010, 10:54:28 pm »

2) I don't plan on doing anything with (developing) the build system. The most I may do is make sure it compiles on my system fine (Fedora 13 x64) I'm mainly going to be using Codeblocks.

I can take care of the build system. Incidentally, it may interest you to know that CMake can actually be used to generate Codeblocks project files, as well as Eclipse, Visual Studio and standard makefiles.

3) Agreed, although the auto_ptr already in C++ now may be enough. I'm not sure if it's because I have Boost installed already but I thought it's already integrated into the C++ library. Another thing is we may be able to eliminate most if not all pointer usage.

We'll have to decide on a case-by-case basis. auto_ptr doesn't work very well in some circumstances. We may have to consider scoped_ptr, shared_ptr where sharing is happening, and even ptr_containers if appropriate.

I noticed a lot of odd choices for data (e.g. pointers vs references). I'm considering which way we should handle this:

A) Start with the current code and modify it to a more preferred interface
B) Just rewrite everything from scratch (and using the current code as reference material)

To be honest, unless you want to make a sweeping architectural change rather than just API changes, I'd rather make changes incrementally from what's already there; it will be easier to handle testing that way, in my opinion.

The suggestion you're referring to, I thought he was talking about SFML2 when he said that (because he mentions SFML2 right after it). I am interested in hearing from forrestcupp. I might end up contacting him later.

Well, he said "release" and "that release wasn't supposed to break anything. " Neither of those are true of SFML2 right now, but they were supposed to be true of SFML1.6

Another thing besides design is I'm concerned about speed. The only way I know of how to make the interface do:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) );

While still being able to only include parts of the interface that you want is with dynamic binding, which comes at a price. Runtime dereferencing isn't that cpu intensive but still, the library should use the least amount of CPU (be fast as possible) because "actual work" needs to be done (i.e. the main program needs as much of the CPU as it can get). It's not just a premature optimization either because we want to avoid changing the interface later.

I'm considering some way to hack up overloaded functions in the class so that the user can still include only parts that they want. At the moment I'm thinking #ifdef precompiler commands might do the trick. If it doesn't work out I guess dynamic binding will have to do.

Dynamic binding seems like the obvious solution, but I can't help wondering if there's some generic programming practices we can use to try and move that work to compile-time. It's something to think about.


Anyway, I recommend we move this discussion to another medium, Google Groups or otherwise.

13

SFML projects / cpGUI - Anyone interested in developing?

« on: June 17, 2010, 07:18:00 pm »

I thought that the current/old API already works in 1.6 but now I see in the wiki it's "based on 1.5" so there may be some adjustments in order. So yeah, agreed (with your plan).

I based the suggestion on what forrestcupp said in the OP:

For some reason, cpGUI doesn't seem to work with the most recent release of SFML, even though that release wasn't supposed to break anything.

I haven't actually had a chance yet to test with SFML 1.6 to verify any problems.

14

SFML projects / cpGUI - Anyone interested in developing?

« on: June 17, 2010, 02:15:27 pm »

Okay, what channel? Do you have gmail? Maybe we could setup a mailing list or something as well. Basically I'd like a remote/internet (not local log) record of communications because well I tend to forget things/details. This forum is an option too (although we may end up "flooding" it with messages XD).

I can be reached at pdusen@gmail.com. I also typically idle at freenode on IRC, but my active times are somewhat irregular. I'm in favor of the mailing list idea (if I'm not mistaken, google has a mailing list service we can sign up for.)

I'm still not satisfied with the previous deprecation technique. It adds bloat and slows down production. I think it'd be better to hack up the current (stable) version and port it to SFML2. Then drop support for it (only provide fixes to critical bugs, if any) so that we can focus more on redesigning the new interface and implementing it. That way the old/current/stable version doesn't get bloated and people have something to work with in SFML2 until the new interface arrives.

First we should code the new interface for SFML 1.x (stable). When SFML2 is officially released then we'll port the new interface there. When we do the new interface it should be labeled version 2-1.x, where the dash 1 will be dropped once SFML2 is released (and we port it over). Anyone still using cpGUI2-1.x with SFML1.x may be supported if the reported bug can be reproduced in cpGUI2.x. This upgrade method will also allow room for minor changes to the interface when we port it to SFML2 if needed (i.e. cpGUI2-1.x is a transition package between 1 and 2).

It will be a bit weird, where the new interface takes over for SFML1 and the old interface gets upgraded to SFML2 but it should work. The old interface can be used as a "testing ground" for SFML2 (so that it'll be easier to port cpGUI2 later).

I'm not really sure all of that is necessary. The way I see it, when someone makes the leap from SFML1.6 to SFML2, they're already making some big changes to account for a new interface; so with that being the case, I see no reason to carry over the old cpGUI interface to SFML2. That would just be two different ports we'd have to do.

What I propose is this: let's take what currently exists for cpGUI and beat it into shape a bit (get it working on 1.6, create an actual build system, etc), then release that as an end-of-life update ("1.5.7" and so on). We then start work on "cpGUI 1.6.x", with the new interface, still based on SFML 1.6 (or whatever the current stable branch is by then). We continue doing updates in the 1.x.x series for as long as SFML2 is unreleased. Then when SFML2 is finally released (or close to release), we port our newest version to SFML2 and release it as "cpGUI 2.0.0". Of course, the naming is subject to change, this is simply my proposal.

I'm not sure how much of the current interface will be rewritten though because some of it might be used as low-level access. I will draw up a diagram later but the idea is that each software layer should provide low-level access to the previous layer. Propagate this idea all the way down and any layer should be able to "directly" access the hardware if necessary (i.e. there's room for speed hacks if necessary).

Agreed.

We need to add all the design documents (e.g. roadmap) on the wiki as well (where it can be peer reviewed so that if we miss something someone can, hopefully, inform us).

If we do this, it should probably be as a footnote on the existing cpGUI page, or on a different page entirely. We don't want new users who are just looking for an existing GUI to use to have to read through our design documents for an unreleased version, after all.

Where should we host the files/source code? Sourceforge?

I have a github account that I've used for a lot of my work. If you'd like, I can go ahead and set up a repository there. You can then sign up to github yourself and "fork" my repo (it's basically github slang for creating your own branch). Then we can easily pull each others' changes from each repo, allowing us to work independently while incorporating each others' work as well.

Incidentally, here's a wishlist of things I'd like to do; it's not comprehensive, just some things that come immediately to mind:

Remove the "cp" prefix from class names. If i'm reading the headers correctly, we're already in the "cp" namespace, so having "cp" as a prefix to class names is utterly redundant.

Set up a CMake build system. I've used CMake for a long time, and its cross-platform capabilities are amazing. Besides, laurent has expressed his wish to switch to CMake for SFML itself, so we'd be going along with that.

Add RAII. I see a few places in the code when manual new/delete memory management is used. I think it would be best to avert this, possibly replacing it with using smart pointers from Boost.

On a side note, I am wondering what the "cp" stands for in cpGUI?

I have no idea. We could always make something up. Or just go along with it.

15

SFML projects / cpGUI - Anyone interested in developing?

« on: June 17, 2010, 03:28:06 am »

I don't see any reason to assign statuses to people in the team (except perhaps a leader to you know, lead the way). Anyone that is able to help is welcome, and encouraged, to.

After glancing at the code I'm already thinking about redesigning the interface. I see in the example CPP file that you need to call the draw function for all of your GUI objects. Everything that can be automated (efficiently) should be. I'm guessing other things must be done manually as well but haven't fully reviewed the code.

Also I notice that some of the function parameters are using pointers instead of pass by reference. Not sure what the design decision behind that was but I'd think that pass by reference would be preferable. Example: with cpGuiContainer::Register() you could techincally push a null value into it (accidentally even). We can use pass by reference to make sure that's not possible (locking mechanism). The purpose of locking mechanisms is to prevent ourselves from making silly mistakes. :wink:

Also I'm sceptical about what the font handler does in Windows. I'm assuming that it's trying to load the default font from windows but what if the user isn't using that font? I'm wondering if SFML has a way to get the system font.

I was thinking any updates should wrap around the current "manual" methods (so as not to break anyone's current code). Then later on deprecate the "manual" methods once the automated ones are stable. Also any interface changes should leave the current interface in tact and later the older interface shifted out (deprecated). Basically all deprecated interfaces should be supported until SFML2 is stable (i.e. "okay guys new version, the interface has changed") Although this may add some bloat to the library, until a more efficient solution is found.

EDIT: I notice that as I read through the code I want to redesign more of the interface (i.e. leading to a complete rewrite of the interface). Example (from example CPP file):

cp::cpDropDownBox dropdownBox(&App, &myGUI, "Select your weapon", 450, 250, 200, 20);

Besides a "using namespace cp;", I would have stored the App inside the library. What I'd like to do is:

myGui.Add( DropDownBox( 450, 250, 200, 20 ) ); // etc, use dynamic binding

And in the main loop just call:

myGui.Draw();

I agree pretty much with all you said. Perhaps we can get together on IRC sometime to form a team and a roadmap of some sort.