SFML community forums
General => Feature requests => Topic started by: heishe on September 23, 2008, 11:11:47 pm
-
Laurent, could you add them? Shouldn't take too long..
-
Which ones are missing ?
-
Only normalize is missing (really), and I don't know why you'd need those in SFML.
-
Only normalize is missing (really), and I don't know why you'd need those in SFML.
No, others are missing as well. Including at least dot and cross products. And you'd need those if you're using the vector classes to do useful maths. Stuff other then just using them to pass parameters around.
The needed functions are not hard to add. The only reason I'd see not adding them would be to keep SFML "simple" to not scare off the "omg numbers!" people (which I could understand), but that's Laurent's call.
My personal thought would tend to be if your going to ship vector classes with a library, they should handle such things.
-
In this case I would anyway program an own vector class (not struct). Vector algebra is such a wide field, there are nearly no limits - in contrast to SFML, where vectors are primarily used for graphic coordinates on the screen. And where a struct like current sf::Vector is (to my mind) already slightly overweight (in consideration of being a struct and no class).
A specific class isn't difficult to implement, and could be as convenient as you like. One could implement getter and setter methods to make access safer, specific global functions to support additional possibilities, functors to allow the use in associative containers. Some algebraic operators might be implemented inside the class. Compatibility to sf::Vector could be performed by specific methods or overloaded cast operators.
Imagine some examples of mathematical functions:
- Norm (vector length)
- UnitVector (vector / its length)
- Angle (of one vector relative to coordinate system, or between two vectors)
- DotProduct
- CrossProduct
- ... (as I said, loads of possibilities exist)
The implemention of n-dimensional vectors is just another example...
I don't see any reason to add those functionalities to sf::Vector, since SFML is not really thought for maths like this. Otherwise you could add geometry classes like matrices (would be excellent in combination with vectors -> affinity, transformations), or figures (lines, triangles, circles, any polygons, planes, intersection checkers, ...). Why not create polar coordinate classes? Might be helpful in some cases. Yes, why not expand SFML to a mathematical library? :roll:
In my opinion, current sf::Vector serves the purpose, and for advanced requirements an own implemention is no big thing.
-
You're probably right.
-
In this case I would anyway program an own vector class.
I thought not having to program the basic stuff yourself was the purpose of libs like this.
anyways it's laurents call, i think it would be a nice addition and would help the growth of the library.
greetings,
travis
-
I tend to agree with Nexus. sf::Vectors are meant to contain coordinates, nothing more. For more complex maths stuff it's really easy to add what you need on top of that.
-
I thought not having to program the basic stuff yourself was the purpose of libs like this.
That is true. There is just one thing: vector algebra is not basic stuff. SFML is a graphic library and supports easy drawing of sprites, creating windows, handling events, and so on. Those things can be regarded as "basic", but not mathematical stuff like vectors.
Believe me, implementing a dot product or even more is not difficult. It might be a good practice ;)
And if you don't want to write it on your own at all, there are certainly loads of libraries supporting those features, just search on the internet.
-
Believe me, implementing a dot product or even more is not difficult. It might be a good practice ;)
I'd also imagine the intersection of people who would find implementing a DotProduct function difficult and people who would know what to do with a dot product to be very small set.
-
that's not my problem at all. i already implemented it.
the point i'm trying to make with this and several of my other postings: sfml is a really awesome library, but it's not perfect. i don't program that much with sfml these days since i already have to program at work, and it gets boring really fast. but even in the short time, i've come across small missing features on (too) many occasions. and those were clearly things that belong to the lib / engine. vector algebra is one of these things. if you have a vector class, you should make it right. it's not that hard, but i consider it ugly looking code when there are that many things that i needed to implement myself, just because programmer of the lib doesn't bother with such seemingly obsolete and trivial problems (no offense lauren, i appreciate your work).
but here's one of the many 1 hour work things that you could implement that would make your lib even more awesome. it's ok to discuss things like collision detection with sprites, since you want to keep your lib neutral , and cd is not a natural part of sprites themself. but thats not the case with vectors. you added them, and it's my personal suggestion that you should complete them. how can it hurt?
if you don't have the time or if you simply don't give a shit about this simply say it. you're not a business man and you can afford to simply say this. we will still love sfml and we will still appreciate your work 8). just don't pass off every second suggestions by saying "implement it yourself"
-
I think part of the idea is to keep it simple so it's easily approachable. I mean, look at some of the questions on this forum and ask yourself how many people would be intimidated by having to use a math construct with a bunch of functions they've never heard of.
-
I'd also imagine the intersection of people who would find implementing a DotProduct function difficult and people who would know what to do with a dot product to be very small set.
I know how to write cross-platform image loading and displaying, but instead, i use SFML ;)
I think, not going crazy, but just having some something funcs would be nice.
I know how to do a lot of thing I don't plan on doing because someone else already has...
-
how would implemented vector algebra change the usage of vectors in any way? and even if it did in any way, which it doesn't someone who wants to program graphics applications will be forced to learn about vectors anyways.
-
The argument "it won't affect the use of existing things" is not the point. A lot of new features would fit that criterion.
If vector algebra would be fully implemented, why not to write matrix classes for transformations? Why not augment the primitives to vector-based mathematical figures? I already wrote that in my upper post, and I still think that current vectors are enough for most of the SFML users. People who require a dot product will also need further mathematics.
And also the statement, that everyone programming with graphics would be forced to learn vectors, is wrong. Look at the simple 2D applications where SFML functionality is already more than enough. For lots of simple 2-dimensional games you don't need any vectors or their operations. For example, every sprite has already a member with its position stored internally. The Move() or SetPosition() functions allow to set the sprite position. Maybe you could use vectors, as they are already implemented in SFML, or just do it with separate coordinates x and y. Even if you work with vectors, the current implementation of them is far enough. Some of the current operators are not often required. And dot product? You only use it to calculate angles or projections which is hardly required in an average SFML application.
I just don't understand why you bother implementing it at your own. If SFML would do it for you, there is a high probability it wouldn't be 100% of what you imagined. Calling own implemention "ugly" isn't really an explanation (by the way, SFML is a library to support you, not to do your work). What is the problem of creating a header with a class template for vectors and all its required functions? That is done once and then you can include it whereever you need it.
-
ahh ok, who cares. i guess you wont get it. by the way, matrice classes would be nice but mostly useless in 2d applications.
-
ahh ok, who cares. i guess you wont get it.
Okay. I'm sure you are right, you must be right if you are debating like that... :roll:
by the way, matrice classes would be nice but mostly useless in 2d applications.
Just because you never needed them? Okay, that is a really good reason.
-
Here's my take on it.
1) Prologue: I'm making no demands. I can take it as it is. I'm simply offering my personal/professional opinion.
2) If you do need things like dot product etc., you can program them yourself of course. But then you're going to have to either subclass Vector2f and use casts, or use public functions to perform the operations. Neither approach makes sensible use of OOP style; while I'm used to doing most of my coding in 'standard' C, when using a library designed to extensively use elegant classes, it seems a little jarring to not have it go all the way.
3) My personal feeling on this discussion is that arguments *against* putting functions in on the grounds of complexity are kinda redundant; there are currently no functions other than the mathematical operator overloads. What would there be to be scared of? Right now, the documentation doesn't even list those operators - if anything, that would be where the confusion comes from! [Going purely on the docs, Vector2f is nothing more than a 'Point' structure].
Anyway, that's my 3p. The point has been made already that libraries exist for this purpose. It's not a mathematical library, but the Vector classes do already do multiplication/addition etc.. already (some standard vector functions) I honestly see no valid argument against putting additional functions in other than that of priority (which is perfectly valid!).
-
ahh ok, who cares. i guess you wont get it.
Okay. I'm sure you are right, you must be right if you are debating like that... :roll:
by the way, matrice classes would be nice but mostly useless in 2d applications.
Just because you never needed them? Okay, that is a really good reason.
i already said what i had to say, theres no need to "debate" further. you get it or you dont.
and no, matrices classes would not be useless because I don't need them very often in 2d applications, but because almost nobody is going to need them . of course they would be a perfect addition, but laurent is better off using the time to implement that by implementing vector stuff which would actually be useful to most of sfml's users, who decide to go a little deeper with 2d (game-)programming.
by the way, i too, am not making demands. this is still on the suggestion level 8)
-
Okay, sorry for misunderstanding you.
So I think we reached the end of the discussion... ;)
-
In my opinion the Vector class is severely lacking, as others have mentioned. At the moment it may as well be a Point2 for the usefulness it provides. Vectors are an intrinsic part of 2D and 3D graphics and the argument that a newbie may be scared by a few extra member functions is extremely flawed. If a newbie is scared by vectors, no graphics library will ever hope to help them create things. As mentioned there is no great maths needed to be implemented, the entire additions could be restricted to
* Normalize ( Change to unit length )
* Dot product
* Cross product
* Norm (or length)
These things are not difficult to implement, nor are they difficult to understand, I myself have already added these functions my copy of DSFML in order to make use of the library. If this does not suit, the possibility of migrating this to a maths section of SFML, or even implementing an external mathematics library to handle the whole solution.
Things like n-dimensional vectors are largely useless with graphics related tasks, so I don't see why they're mentioned, however matrices are also useful, and this could also be added. At the moment I see the take on maths to be too newbie oriented, focusing on simplifying things they are going to have to learn anyway, rather than catering for more advanced users also.
-
I totally agree that basic vector functionality should be added. Otherwise it should be renamed "Point" or "Coordinate", as "Vector" seems a little misleading for what it does..