Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New SVN Version  (Read 10231 times)

0 Members and 1 Guest are viewing this topic.

T.T.H.

  • Full Member
  • ***
  • Posts: 112
    • View Profile
New SVN Version
« Reply #15 on: June 11, 2008, 09:51:04 am »
Quote from: "Laurent"
...and throw a message on the standard error output.

And how to read that message e.x. in a windowed application under Windows or e.x. in a "daemonised" application under Linux, both having no obvious "stdout" or "stderr"? Or how to know the reason for an error when a function hidden deep in the inner workings of SFML just saying "uops, didn't work"?

To be honest it took me some serious amount of time at my initial steps with SFML to get things done correctly when something obviously didn't work and the error message had only been dumped to stdout. To actually have access to those error messages I wrote a pretty complex logging system which "bends" stdout over to some std::stream which then puts its input in a list of strings stored in a logging system singleton which then can output its content to several defined outputs, e.x. the GUI of my application or a log file or even back to console if I have one.

In addition some errors can get pretty much "spamming" in an application "doing something wrong every frame, 250 frames a second"  :lol:


Anyway. Personally I work with exceptions since I like them but if you don't use exceptions that's perfectly fine, too. But simply outputting errors to stdout is far less than optimal in my opinion, due to the types of applications named above and due to beginners not being able to recognize errors which are not slapped directly into their face (and, yes, I was a beginner with SFML, too).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #16 on: June 11, 2008, 10:37:46 am »
Outputing to the standard error stream is very flexible, it let users redirect it to wherever they need very easily, just as you do. I don't see the problem with that ?

Regarding spamming messages, I try to remove them as possible. If you still get some of them let me know :)

Anyway, this is purely for information and debugging, the true error reporting is the boolean return of functions which can fail. If you want to discuss error handling then it should be about this, and not about messages ;)
Laurent Gomila - SFML developer

T.T.H.

  • Full Member
  • ***
  • Posts: 112
    • View Profile
New SVN Version
« Reply #17 on: June 12, 2008, 06:33:43 pm »
Quote from: "Laurent"
Outputing to the standard error stream is very flexible, it let users redirect it to wherever they need very easily, just as you do. I don't see the problem with that ?

It might be "flexible" but it is not "beginner friendly"; in my humble opinion.

On the other hand I found freopen() after a short Google search...

Quote from: "Laurent"
Regarding spamming messages, I try to remove them as possible. If you still get some of them let me know :)

Will do.

Quote from: "Laurent"
Anyway, this is purely for information and debugging, the true error reporting is the boolean return of functions which can fail. If you want to discuss error handling then it should be about this, and not about messages ;)

I remember that when I started SFML (a bit before version 1.2) I had an occasion where I called a function returning void or called a constructor which called several functions internally and finally outputted some error message to stdout - and there was no way to determine whether it went right or wrong based on return values. Unfortunately I can't remember which function or constructor that was, sorry.

At that time I didn't want to start a discussion about error handling since I was pretty new to SFML and feared I could not have the "big picture" yet.

Meanwhile I can't start that discussion, too,  since my spare time is limited and when I code I do that mostly on the server part of my application, not the client part which uses SFML - and so I'm not sure what you changed lately. I'm currently using revision 651 from 4. Mai 2008 and I don't intend to update soon because that version simply does what I want and I have made my own changes to it (due to my sub pixel accuracy problem I posted here).

P.S.: sorry for going offtopic...

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #18 on: June 12, 2008, 06:40:44 pm »
Quote
t might be "flexible" but it is not "beginner friendly"; in my humble opinion.

On the other hand I found freopen() after a short Google search...

It's even simpler with standard C++ streams :
Code: [Select]
std::cerr.rdbuf(TargetStream.rdbuf(());
Where TargetStream is any kind of standard stream : ofstream for a file, ostringstream for a string, custom ostream for whatever, ...

Quote
I remember that when I started SFML (a bit before version 1.2) I had an occasion where I called a function returning void or called a constructor which called several functions internally and finally outputted some error message to stdout - and there was no way to determine whether it went right or wrong based on return values. Unfortunately I can't remember which function or constructor that was, sorry.

All these functions should have been fixed now ;)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« Reply #19 on: August 01, 2008, 02:47:10 pm »
Concerning the inconsistences, I found some points:

sf::Sprite:
- the method to get the size on the screen is GetSize().

sf::String:
- the method to get the rectangle (and the size about it) is GetRect().
- but GetSize() returns the font size.

I think this is a little bit confusing. For me, both classes are quite similar, so why once using a Rectangle and once a 2D-Vector?
And another thing is the base class sf::Drawable. I think, there is no GetSize() method because of inherited sf::Shape and sf::PostFX, right? I don't use those 2 classes often, but don't they require a size? If yes, would make polymorphism easier (for example you don't have to overload specific functions for sf::Sprite and sf::String)...

And what I is also not really consistent, is GetSize() vs. GetWidth() or GetHeight() methods. For example Sprites use GetSize().x or GetSize().y, and the "greater" classes like sf::Image or sf::RenderWindow use GetWidth() or GetHeight(). And why did you implement sf::View::GetHalfSize()? Is that for people who don't want to write sf::View::GetRect()::GetWidth()/2? :)  Or because of 2D-Vector (now there's again the question why a Rectangle with 2 specific size methods).

What's the reason for these things? They might follow a simple logic, but at the moment I don't really see it ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #20 on: August 01, 2008, 02:57:04 pm »
Cleaning all this stuff is my next task, actually ;)
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« Reply #21 on: August 01, 2008, 03:07:16 pm »
Quote from: "Laurent"
Cleaning all this stuff is my next task, actually ;)

Oh, so there wasn't any intention behind those names? :P
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New SVN Version
« Reply #22 on: August 01, 2008, 05:11:39 pm »
No, I even agree 100% that these functions are confusing and everything but consistent :)

In fact, when I implemented each of them (at different times) it was just a local feature of each class, I didn't have in mind to get a generic behaviour for geometry testing and collision tests. Now I realize that I need to get a little more abstraction and consistency on this side.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
New SVN Version
« Reply #23 on: August 01, 2008, 06:05:02 pm »
Yes, I can completely understand that. I think it's quite normal to write working code first, and care about things like name consistency later.
I just didnt know, maybe there could have been a special reason for those identifiers. :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything