Messages

31

Feature requests / SFML should use only types of defined size

« on: October 29, 2011, 03:54:06 pm »

This leads to difficulties to have consistent results on different hardware.

Which difficulties? On which hardware?

Well nothing more than 32 -> 64 bits arch can sometime lead to funcky linking error in klingon (native language of the linker). And people rusually don't have both architectures ready to test.

Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

Which languages? So far, SFML has been ported to many languages without any problem.

Actually any language that have a different type system than C/C++ will experience issues with that. It doesn't means this is impossible (actually, it has been done sevral time) but it is error prone.

I'm currently working on the D port and experiencing issue with that (D has fixed size type system). A java port will have even more problems with that if it's done one day.

gsaurus > I didn't mesure that, so this is speculation, but I don't thnink working on a 32 bit value is slower than on a 64bit one on recent intel's or AMD's CPU.

The point is : 64bit values doesn't make any sense in many places where int are used. Consider Videomode. Do we really expect that the width or height of the screen will be more than 4 bilions pixels ?

The same goes for sampleRate or ChannelsCount in SFML-audio classes. Do we really expect someone have a sound to play with more than 4 billions channels ?

Using fixed size types here would make SFML easier to handle cross plateforms and cross languages.

32

General discussions / Naming conventions - functions

« on: October 29, 2011, 01:41:03 pm »

First I liked the uppercase a lot, but then I started learning Qt and I really loved the lowercase. Anyway, it's too much work to change it and it doesn't really affect anything than code-reading perfection.

Well, code writing involve 90% of code ready. So I think this is a much biggger issue than you may think.

33

Feature requests / Mechanism to detect Intel cards

« on: October 29, 2011, 01:38:20 pm »

Anyway, detect card vendor is mostly a bad practice. You should rely on card capabilities.

Detect the card vendor should be limited to workaround a nasty bug in the driver or some very specific issues like that. You'll go to a maintenance hell if you don't do that.

Just immagine what will happen if the same problem appears with some wideo card that is not from intel, or that intel produce a new videocard where this behaviour isn't anymore ?

34

Feature requests / SFML should use only types of defined size

« on: October 29, 2011, 01:35:05 pm »

SFML uses a lot of types like int. Thoses types has different size on different architecture.

This leads to difficulties to have consistent results on different hardware. Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

If the type depend explicitely on the architecture, the usage of typedef like size_t should be the usage.

What do you think ?

35

D / What libraries to link when building DSFML2? (64-bit Linux)

« on: September 21, 2011, 10:55:57 am »

DSFML require both CSFML and SFML to link against.

The current version of DSFML is outdated and you will experience problem with current versions of SFML. You have to use SFML 1.3 and CSFML 1.3 .

36

D / Proper setup guide and usage tutorial?

« on: July 11, 2011, 01:27:23 am »

To build DSFML, you need dsss.

Then you configure your project compilation setting to link with DSML, CSFML and SFML.

You'll find severals exemples of code in DSML source code repository to know how to use it. This is similar to SFML, but in D.

37

General discussions / Pull request ?

« on: June 16, 2011, 09:35:11 pm »

Why do you think it is complex? Have you read the tutorial on Github, or simply tried to click the "Pull request" button on your Github repository?

Well, . . ., yes, I read this tutorial.

The point is : I have no pull request button anywhere to click on I probably don't have the permission, or the tutorial is outdates (or I'm really dumb).

However, back to the subject, I have no clue who's the last maintener of DSFML2 but I would be happy to help. Is it robogymnast ? Or trass3r ?

Anyway, if nobody is maintaining this piece of code, maybe I could.

38

General discussions / Pull request ?

« on: June 16, 2011, 03:41:19 pm »

Hi,

I recently make a small modification on dsfml. Not a breaking feature, simply a little patch fixing compilation issues on 64bits systems. However, I have no clue how to do a pull request for that modification.

How can I do that ?

In addition, I think pull requests should be as easy as possible. Discouraging contributions because of complex process is counterproductive IMHO.

39

D / .dispose()

« on: June 15, 2011, 07:04:53 pm »

GC.collect is called automatically.

It's triggered when you try to allocate memory and the GC has no mor eleft. In this case, the GC try to free memory before asking more to the system.

40

D / What are main goals of DSFML2 and can I help ?

« on: June 15, 2011, 06:06:45 pm »

I'm currently back into D devellopement, and I love it.

I just saw that SFML has a new version, v2, which isn't finished yet, but seems promizing.

I have basically 2 questions about the D port. The first one is about the objectives.

Does the D port aim D1 or D2, phobos or tango, will it use D2 C++ interfacing where it's possible, will threading will be managed by D stuff instead of C/C++ bonding (the threading in D is wayyyy better) and so on . . .

The second point it what I can do to help ?