Messages

1

General discussions / Re: A book on SFML -- looking for author(s)!

« on: April 16, 2013, 05:48:30 pm »

Tell me when you're in Zurich or Lucerne

Currently...
Zurich: Monday - Friday
Lucerne: Monday - Sunday



I'll send you a PM as soon as I have bought the book. I'm quite sure we will find a possibility to meet.

2

General discussions / Re: A book on SFML -- looking for author(s)!

« on: April 16, 2013, 02:26:03 am »

Will there be signed books? I want one signed by nexus

3

General discussions / New naming convention

« on: January 24, 2012, 11:36:50 am »

Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Let me turn that around: why does the Java naming convention explicitly endorse camelCase and every Java library follows it? If it was that bad, they would have switched...

You missed my point there. I said the people are using the naming convention of the standard library. In C# the standard library is using PascalCase. In Java the standard library is using camelCase.

In most languages the people are using the naming convention of the corresponding standard library. C++ is the big exception.

4

General discussions / New naming convention

« on: January 23, 2012, 01:37:52 pm »

@Mikademus,
Name me a language where threading is part of the language. Where date and time is part of the language. Where I/O is part of the language. Containers are part of the language. You can use C++ without using the standard library. The standard library (btw. isn't the same as STL) isn't a part of the language! It is a library like Boost too. I have no knowledge of a language that has all the functionality of Boost implemented in the language itself. Your argument simply makes no sense at all.

And apart from that: Why is it important that I know that a given class is coming from the standard library or boost? Why do I need that knowledge while reading some code? And don't I already have it through the use of std:: or boost:: ?

It is normal that unique styles and conventions evolve around the language symbols, and claiming that userland code must or should stay as close to the "language style" as possible is unacceptably restrictive and potentially damaging.

Name some example. I don't see this in lua, python, c#, java, etc.
There is only one place where this is happening: C++. Because the people don't like camel_case.

..., the most pedagogical and ergonomic being camelCase.

Is there any evidence except from your personal preference? Why is C# using PascalCase and the majority of the libraries in C# are using PascalCase? If camelCase would be that much better, they would have switched or at least the userbase would have switched.

Why are the boost people using camel_case? To be consistent with the standard library. And boost isn't part of the language!

In sum: It is a move for consistency, pedagogics and ergonomics to move SFML to camelCase. Using camelCase is not being inconsistent with the language itself.

It has nothing to do with consistency, pedagogics or ergonomics. There is no evidence for this. It is only personal preference.


But it seems Laurent made his choice already. Lucky me I haven't changed to use SFML 2.0 yet

Imagine people who start to convert all their code, and suddenly I go back to the original naming convention...

Well it is an unstable API :lol:

5

General discussions / New naming convention

« on: January 22, 2012, 11:14:54 pm »

So unless you really don't want to see SFML 2 released soon, ...

I don't want SFML 2 to be released soon. "soon" often means not in the next two years :lol:

Probably they want to know which naming convention you will choose and try to influence you with a poll. So you choose the majority and not the wisest.

6

General discussions / New naming convention

« on: January 22, 2012, 05:07:45 pm »

@Groovy,
There is no half consistency. Like you said, there will be for example no consistency in the naming of classes.

And you only rarely use the standard library? std::vector? std::string? iostreams? std::unique_ptr? std::shared_ptr? And what about boost? What are you using instead?

7

General discussions / New naming convention

« on: January 22, 2012, 04:07:58 pm »

Naming conventions are always completly personal preference. And to be honest what you choose normaly doesn't really matter much. I worked with several different naming conventions over time. The one main thing for me is rather consistency.

When you work in C++ you will work with the C++ stdlib and Boost. Now you know which naming convention you have to use. Always go with the naming convention for public members of the standard library of your language.

I use camelCase in java.
I use PascalCase in C#.
I use camel_case in C++.

Even if I don't really like camel_case, I'm undecided about PascalCase and I like camelCase. It doesn't matter what my personal preference is. I can read all three without problems. But it is really annoying if you have no consistency in source code.

If you decide against the naming convention of the c++ stdlib, you will never ever have consistency in any program written with SFML.

8

General discussions / SFML 1.6 released soon

« on: February 11, 2010, 04:03:15 pm »

These are linker warnings about debug symbols not being found. I don't know why some people get them, it doesn't happen on my computer.

Well, because they aren't in the package. Probably they are on your computer, because VS automaticly creates them, but you didn't add them to the archive you distribute.

But it is really simple to resolve those warnings. Simply rebuild the SFML project with VS.

9

Graphics / Code Generated Image does not display on Windows

« on: February 03, 2010, 07:31:04 pm »

Tried the code on Win7 64 Bit with TDM MinGW 4.4.1:


Works like a charm. Well the points are perhaps a bit small.

10

General discussions / New strategy for the internal rendering code in SFML 2

« on: January 28, 2010, 11:55:58 pm »

With a very simple particle system I get around 8 FPS more compared against SFML 2 batching. I don't remember how much better the SFML 2 batching was against SFML 1.5, but it was better. So the current SFML 2 system is the best.

Will this now mean, that you will introduce a sf::Batch class? Or isn't this an option anymore?

11

General / Mouse click in circle

« on: January 12, 2010, 03:09:16 pm »

What the? The following lines are just nonsense:

Code: [Select]


if (dx < 0) { dx = dx - (dx * 2); }
if (dy < 0) { dy = dy - (dy * 2); }

1. You don't need them. If a value is negative, then the value multiplied with itself will be positive anyway.
2. It would have been easier to write: dx = -dx;

Also as an recommendation:
Don't take the square root. Instead compare against the squared radius.

And perhaps you should read this:
http://en.wikipedia.org/wiki/Euclidean_vector

Dravere

12

General discussions / Joystick fix in SFML 1.6

« on: January 10, 2010, 09:10:29 pm »

Ok. Couldn't find anything else in the final test. So I would say: It works!

... which makes you a very good beta-tester / debugger. Please always stay around on the forums :lol:

I don't know if I should be happy about this or not
But I'm glad I could help and I will try to help in the future too. Currently building a new test rig, so I can get all the different OS on the same rig. *g*

Dravere

13

General discussions / Joystick fix in SFML 1.6

« on: January 09, 2010, 07:52:38 pm »

Ok, thank you a lot

np, only get back on your SFML 2 branch

Now everything should be ok right? :lol:

I will do a final test tomorrow, because I'm now too tired to startup the second computer with Vista and Linux, download the changes, recompile sfml, recompile the test application, plug in the joysticks and test it ...

At least, if you didn't change anything at the Windows implementation, I can already say, that it did function for:
Win Seven x64
Win Seven x86
Win Vista x86
Win Vista x64
Win XP x86

I couldn't test U and V axes, like I already said once.

Dravere

PS: I have way too much operating systems ... or perhaps not enough, Mac OS X is missing :lol:

14

General discussions / Joystick fix in SFML 1.6

« on: January 09, 2010, 06:41:58 pm »

Unfortunately. I'm thinking about buying a cheap joystick just to be able to maintain this code properly :?

They can be really cheap. Or ask a friend if he has an old one

Thanks for your fixes. Do the corrected POV values match those given on Windows?

Yes, that is how I correted them. They now conform to:

Code: [Select]


         0°
  315°   |   45°
       \   /
270° -   o   - 90°
       /   \
  225°   |   135°
        180°


Dravere

15

General discussions / Joystick fix in SFML 1.6

« on: January 09, 2010, 04:20:58 pm »

Thanks, it's fixed

But still infested with bugs

I had to change the following commented things in sfml/window/linux/joystick.cpp, starting at line 122:

Code: [Select]

// break; <- moved down, so the if/else can be executed ;)

if (myPovX > 0)
{
    if      (myPovY > 0) myState.Axis[Joy::AxisPOV] = 135.f; // 315.f;
    else if (myPovY < 0) myState.Axis[Joy::AxisPOV] = 45.f;
    else                 myState.Axis[Joy::AxisPOV] = 90.f;  // 0.f;
}
else if (myPovX < 0)
{
    if      (myPovY > 0) myState.Axis[Joy::AxisPOV] = 225.f;
    else if (myPovY < 0) myState.Axis[Joy::AxisPOV] = 315.f; // 135.f;
    else                 myState.Axis[Joy::AxisPOV] = 270.f; // 180.f;
}
else
{
    if      (myPovY > 0) myState.Axis[Joy::AxisPOV] = 180.f; // 270.f;
    else if (myPovY < 0) myState.Axis[Joy::AxisPOV] = 0.f;   // 90.f;
    else                 myState.Axis[Joy::AxisPOV] = -1.f;
}
break; // <- inserted

And while testing this I found a new bug ... I feel somehow sorry
Under Linux, if you move the window, the joystick status vanishes and resets. I don't know if this has something to do with linux or sfml and probably isn't so important, because you won't play a game and move the windows around at the same time *g*

Dravere