5851
General / Stack arround variable is corrupted
« on: November 30, 2008, 12:09:56 am »
You propably link to the wrong libraries. Make sure you use the libs with "-d" suffix in debug mode, and the ones without in release mode.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
5852
General / Separation of logics and graphics
« on: November 22, 2008, 02:07:16 pm »
Okay, thanks for your advice.
I think I won't have loads of sprites on my screen at the same time, so creating them every frame shouldn't be a big problem (at least not in near future). But the way you handle it now seems to me very efficient, too. You just have to change the sprite's position and maybe rotation every frame, but the sprite itsself isn't created again.
Probably I won't use this system right now, but I will keep it in mind. I guess changing the design from the first to the second option won't break up the whole code. Once I've separated graphics and logics, I think it's easy to be flexible.
I think I won't have loads of sprites on my screen at the same time, so creating them every frame shouldn't be a big problem (at least not in near future). But the way you handle it now seems to me very efficient, too. You just have to change the sprite's position and maybe rotation every frame, but the sprite itsself isn't created again.
Probably I won't use this system right now, but I will keep it in mind. I guess changing the design from the first to the second option won't break up the whole code. Once I've separated graphics and logics, I think it's easy to be flexible.
5853
General / Separation of logics and graphics
« on: November 22, 2008, 12:40:18 am »
Thanks for your answer. You certainly mean the design of separation between graphics and logics, dont you? (I ask because "That" is not very clear) 
By the way, I am programming a side-scrolling tile-based game, too - a jump'n'run. I have already done similar things before, but this is the first time I really bear design matters in mind...
By the way, I am programming a side-scrolling tile-based game, too - a jump'n'run. I have already done similar things before, but this is the first time I really bear design matters in mind...
5854
General / Separation of logics and graphics
« on: November 21, 2008, 10:17:14 pm »
Hi, up to now i let my objects derive from sf::Sprite. Like this, it was easy to iterate through containers and just write App.Draw(...) using the implicit conversion to base class Sprite.
Now I thought a stricter separation between the game logics (object's positions, velocities, further information like hitpoints, and so on) and graphics (the used image, color, source rect, ...) wouldn't be bad. Even though sf::Sprite is described as small, lightweight class, its size is 132 bytes. And besides of that it contains a lot of unused information (see next passage).
An example is a 2-dimensional sequencial container of tiles. The tiles' position is already given by their index in the container, so using a sprite would double the information. If there are 4 different tile types, it is sufficient for each tile to save the according type - like that, the source rect doesn't have to be changed for each tile. Many variables do not differ between the single elements. The same would be if I used sf::Sprite as an aggregate.
What do you think about this design? I consider it being more abstract and making changes and maintenance of the code easier. Is it a great loss of performance to create each frame lots of new sprites?
Now I thought a stricter separation between the game logics (object's positions, velocities, further information like hitpoints, and so on) and graphics (the used image, color, source rect, ...) wouldn't be bad. Even though sf::Sprite is described as small, lightweight class, its size is 132 bytes. And besides of that it contains a lot of unused information (see next passage).
An example is a 2-dimensional sequencial container of tiles. The tiles' position is already given by their index in the container, so using a sprite would double the information. If there are 4 different tile types, it is sufficient for each tile to save the according type - like that, the source rect doesn't have to be changed for each tile. Many variables do not differ between the single elements. The same would be if I used sf::Sprite as an aggregate.
What do you think about this design? I consider it being more abstract and making changes and maintenance of the code easier. Is it a great loss of performance to create each frame lots of new sprites?
5855
Feature requests / Vectors and scalar operators
« on: October 19, 2008, 10:42:55 pm »
Okay, sorry for misunderstanding you.
So I think we reached the end of the discussion...
So I think we reached the end of the discussion...
5856
Feature requests / Vectors and scalar operators
« on: October 19, 2008, 01:56:20 pm »Quote from: "heishe"
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:
Quote from: "heishe"
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.
5857
Feature requests / C++ (And others too) aliases for functions
« on: October 12, 2008, 03:24:14 pm »Quote from: "quasius"
I'd rather continue to ignore this silly thread, but now I feel compelled to say that I'm sure 99% of the people using SFML appreciate the work Laurent et al have been doing and aren't hung up on the naming convention.Agree. Anyway, I got the impression that most of feature requests would only make less than 1% of SFML users satisfied... :roll:
5858
Feature requests / Vectors and scalar operators
« on: October 12, 2008, 03:16:22 pm »
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.
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.
5859
Feature requests / Vectors and scalar operators
« on: September 26, 2008, 04:39:14 pm »Quote from: "heishe"
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.
5860
Feature requests / Vectors and scalar operators
« on: September 25, 2008, 09:44:21 pm »
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.
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.
5862
Audio / Audio compatibility on other computers
« on: September 15, 2008, 07:28:45 pm »
Thanks a lot, it works now! 
Dependency Walker seems to be a very useful tool
With it, I found out the file wrap_oal.dll is required for OpenAL audio, too.
Dependency Walker seems to be a very useful tool
With it, I found out the file wrap_oal.dll is required for OpenAL audio, too.
5863
Graphics / Re: Strings
« on: September 15, 2008, 01:35:12 pm »Quote from: "ravenheart"
but how can i convert the float into a sf::String ?That is not part of the SFML library.
Just use the C++ class std::stringstream
5864
Audio / Audio compatibility on other computers
« on: September 14, 2008, 09:15:59 pm »
Hi,
It is always the same. On the computer where programs are compiled everything works perfectly, but as soon as I want to use them on other computers, there are problems and errors occuring. :?
In the meantime, I even managed to make programs using SFML graphics run on other systems. Now I have got the same problem with sound. Sometimes, the program doesn't even start (windows error "... doesn't work any more" (translated)), or it starts, but sound doesn't work, and suddenly, the program is hanging. While not using sound, everything behaves well. In the cmd console window, I get the error message: "Failed to open the audio device".
Before, I just linked statically to the SFML libs and provided the CRT DLLs in the same directory. Now with SFML audio, there are two more DLLs to provide, am I right? These are libsndfile-1.dll and OpenAL32.dll. Are there other dependences?
What could be the reason for those problems? I rather don't want to force the users of my applications to install anything, that's why I provide all the DLLs. I would be glad if you didn't start a discussion about "it's no great thing to install the ... package, other apps need the .NET binding which is much bigger"
If there is a possibility to avoid any downloads, packages, redists and setups, I would like to use it. And I still think there is, since even MSVC redistributable needn't be installed anywhere.
It is always the same. On the computer where programs are compiled everything works perfectly, but as soon as I want to use them on other computers, there are problems and errors occuring. :?
In the meantime, I even managed to make programs using SFML graphics run on other systems.
Now I have got the same problem with sound. Sometimes, the program doesn't even start (windows error "... doesn't work any more" (translated)), or it starts, but sound doesn't work, and suddenly, the program is hanging. While not using sound, everything behaves well. In the cmd console window, I get the error message: "Failed to open the audio device".Before, I just linked statically to the SFML libs and provided the CRT DLLs in the same directory. Now with SFML audio, there are two more DLLs to provide, am I right? These are libsndfile-1.dll and OpenAL32.dll. Are there other dependences?
What could be the reason for those problems? I rather don't want to force the users of my applications to install anything, that's why I provide all the DLLs. I would be glad if you didn't start a discussion about "it's no great thing to install the ... package, other apps need the .NET binding which is much bigger"
If there is a possibility to avoid any downloads, packages, redists and setups, I would like to use it. And I still think there is, since even MSVC redistributable needn't be installed anywhere.
5865
Graphics / sf::WindowSettings access violation
« on: September 12, 2008, 04:29:06 pm »
At me it works now. Thanks a lot, Laurent!
BTW: In the last days, performance of SFML was very bad in my programs. This seems to be fixed now, too! Thank you!
BTW: In the last days, performance of SFML was very bad in my programs. This seems to be fixed now, too! Thank you!