61
Feature requests / Some features
« on: March 06, 2008, 10:14:58 pm »
I guess there are no underlying libaries for Network, windowcreation, threads and timing.. He's simply using the API functions.. I think..
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.
62
Feature requests / Some features
« on: March 06, 2008, 09:48:26 pm »
acctualy I think you misunderstood SFML (as I did too) as a grafics engine..
well, thats not exactly what it is.. SFML is just a Abstraktion layer... Especially Physics is not the point of SFML (though I would like to have it too^^)
Searching for some 2D physics engine I found this one which looks quite promissing: (didn't test jet it thought -_-)
http://wiki.slembcke.net/main/published/Chipmunk
well, thats not exactly what it is.. SFML is just a Abstraktion layer... Especially Physics is not the point of SFML (though I would like to have it too^^)
Searching for some 2D physics engine I found this one which looks quite promissing: (didn't test jet it thought -_-)
http://wiki.slembcke.net/main/published/Chipmunk
63
Feature requests / some suggestions
« on: March 06, 2008, 02:48:50 pm »
Well, I think you misunderstood me.. I realy ment a simple check wether a givenfile is already loaded, and if so it won't be loaded again^^
So you still got full controll over your ress.. you will load&unload them whenever you want... So "resource manager" might be a bit of
So you still got full controll over your ress.. you will load&unload them whenever you want... So "resource manager" might be a bit of
64
SFML projects / Earth Defenders -- Commercial game project
« on: March 05, 2008, 08:46:24 am »
Why do you use Irrklang? (Do not misuanderstand me, I'm using the Irr* thingys too) but SFML already got some Sound handeling..
Screens would be cool. (Got a Linux...)
Screens would be cool. (Got a Linux...)
65
Feature requests / some suggestions
« on: March 04, 2008, 07:01:55 pm »Quote
Quote:
One question: If I would change something inside the read only buffer(tricking the const ptr by typecasting), would that actually change the image?
Absolutely not, that's why it would be a non-sense to get a write access.
Moreover, the Image instance and its OpenGL texture may have a different array of pixels because of potential padding.
dammit.. didn't think about padding -_- sry :oops:
Quote
But I disagree about texture coordinates : they are completely defined by the SubRect property.
and again mea culpa.... :oops: should read the manual more precisely
Vertex offset is not realy neccessary.. (Well, at least, I cannot imagine a real reason why one would have to use this -> allways able to make your own class on base of Sprite) But Vertexcolors might come handy..
66
General / current SVN version: samples Socket Build Problem
« on: March 04, 2008, 06:57:37 pm »
trying to compile the current SVN project I get the following error:
"wurde in diesem Gültigkeitsbereich nicht definiert" means:
"was not defined in this scope"
Lines 128 and 129 are:
looking up that stuff in Selector.hpp SocketTable is a:
std::map<SocketHelper::SocketType, Type>
But I cannot get further but this.. got no clue whats wrong.. some hint?
thx TGM
*Edit*
If I would like to add some functions to the Vec2 and Vec3 class
(dotProduct, crossProduct, scalar normalize, getLengthSQ, GetLength,angle between two vectors etc) would you like it to be a member of Vec or a function like all the other operators?
Quote
/usr/include/SFML/Network/Selector.inl: In member function »Type sf::Selector< <template-parameter-1-1> >::GetSocketReady(unsigned int) const«:
/usr/include/SFML/Network/Selector.inl:128: Fehler: expected `;' before »It«
/usr/include/SFML/Network/Selector.inl:129: Fehler: »It« wurde in diesem Gültigkeitsbereich nicht definiert
"wurde in diesem Gültigkeitsbereich nicht definiert" means:
"was not defined in this scope"
Lines 128 and 129 are:
Code: [Select]
SocketTable::const_iterator It = mySockets.find(static_cast<SocketHelper::SocketType>(i));
if (It != mySockets.end())looking up that stuff in Selector.hpp SocketTable is a:
std::map<SocketHelper::SocketType, Type>
But I cannot get further but this.. got no clue whats wrong.. some hint?
thx TGM
*Edit*
If I would like to add some functions to the Vec2 and Vec3 class
(dotProduct, crossProduct, scalar normalize, getLengthSQ, GetLength,angle between two vectors etc) would you like it to be a member of Vec or a function like all the other operators?
67
Feature requests / some suggestions
« on: March 04, 2008, 06:45:20 pm »Quote
Your manager is already too high-level for SFML. I mean, not everybody will want this kind of management. And it's more the job of an engine than a low-level API like SFML.
true.
Quote
I prefer provide such critical functions directly (and nicely wrapped) in sf::Image. Giving a write access to the internal buffer would be too dangerous for beginners.
is your SFML just aimed towards beginners? One question: If I would change something inside the read only buffer(tricking the const ptr by typecasting), would that actually change the image?
Quote
Quote:
Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...
For what purpose ?
Procedual textur generation (for example Perlin noise)
Quote
Quote:
Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites
These informations are already available, but in a human-friendly interface (Drawable::GetColor, Sprite::GetSubRect, ...). I don't see the point of giving such low-level internal informations to the user.
Hey, it seems you just want to use plain OpenGL... Wink
true.. in a limited way. A Sprite always has to be a rectangel.. accessing the vertex offsets direckt would give one the power to distort the Sprite.. (maybe again a job for a Drawable subclass^^) -> same for texcoord
Accessing the Vertexcolor on per vertex base can be used for Lighting e.g.
Actually I like programming in pure GL.. (and cause you make it that easy to use pure GL in SFML I like it very much.. just had a look in the Drawable class - great
simple OGL code in the render call :lol:)
68
Feature requests / some suggestions
« on: March 04, 2008, 05:32:49 pm »
I think some very simple version of res managment that will simply check wethere a file is already loaded and if so simply will return the already loaded one..
so lets say we create some extra (singelton) class that will check wether a given file is already loaded.. (by path, name and maybe size) for each loaded file it got a void ptr that will be casted to by a special factory class or something (so one could use the res managment for your own files) -should be reference counted
the manager got 3 main functions:
void *isLoaded("file")
void set("file",void *ptr) //if load returned NULL, the loader will give the manager the pointer of the file he did load
drop("file") //will decremten reference count by one and if zero -> delete the resource
so Image would ask the manager: is File ("blub/test.png") already loaded.
If the manager says: Yes it is! Here is the pointer to it: 0x00401234
The image class will simply say ok: The stuff is already loaded, simply return a pointer to it.
if it says:"Nope nothing loaded that looks like this!"
The image class would load it and give the manager the void ptr to itself.
Some other things:
The image::GetPixelsPtr () should return a read/write pointer since this would be way faster in some situations (copying huge amounts of memory for example)
Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...
Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites.
Some minor kind of collision detection would be cool, too (though its not exactly a Media Layer thing.) But having a OBB class that features at least isPointInside(vector2D) and isCollisionLine (Line) and isCollisionOBB(OBB other)
And a last thingy: Drawables should get parents (other drawables). So every thing would be in the parents coordinate systems (Multipling the Parents matrix with the Childs Matrix at render Time) Extremly cool would be to be able to controll which porpertys depends on the parent.
(Like: My position is always relativ to my Parents one but neither my rotation nor my scale, or my sclae depends on my parent, but not my rotation and Position etc.)
greetz TGM
so lets say we create some extra (singelton) class that will check wether a given file is already loaded.. (by path, name and maybe size) for each loaded file it got a void ptr that will be casted to by a special factory class or something (so one could use the res managment for your own files) -should be reference counted
the manager got 3 main functions:
void *isLoaded("file")
void set("file",void *ptr) //if load returned NULL, the loader will give the manager the pointer of the file he did load
drop("file") //will decremten reference count by one and if zero -> delete the resource
so Image would ask the manager: is File ("blub/test.png") already loaded.
If the manager says: Yes it is! Here is the pointer to it: 0x00401234
The image class will simply say ok: The stuff is already loaded, simply return a pointer to it.
if it says:"Nope nothing loaded that looks like this!"
The image class would load it and give the manager the void ptr to itself.
Some other things:
The image::GetPixelsPtr () should return a read/write pointer since this would be way faster in some situations (copying huge amounts of memory for example)
Maybe (woul be very cool.. I already coded this for Irrlicht so maybe I can do a port) Interpolated GetPixel (Linear Biqubic and Qubic)...
Accessing Vertex Color, Vertex Offset and vertex Texcoord might come handy for the sprites.
Some minor kind of collision detection would be cool, too (though its not exactly a Media Layer thing.) But having a OBB class that features at least isPointInside(vector2D) and isCollisionLine (Line) and isCollisionOBB(OBB other)
And a last thingy: Drawables should get parents (other drawables). So every thing would be in the parents coordinate systems (Multipling the Parents matrix with the Childs Matrix at render Time) Extremly cool would be to be able to controll which porpertys depends on the parent.
(Like: My position is always relativ to my Parents one but neither my rotation nor my scale, or my sclae depends on my parent, but not my rotation and Position etc.)
greetz TGM
69
Feature requests / some suggestions
« on: March 03, 2008, 10:10:01 pm »
Hi, I started using SFML for some tiny 2D game...
Got some points that would make SFML way more comfortable to use:
1) Shader for sprites (at least Pixelshader)
2) Lines -> simple drawcall like App.Draw(Line(0,1,3,5)) -> draws a line between (0,1) and (3,5) (not sure about this one.. might be already implemented with:"Added a class to draw simple shapes (sf::Shape)")
3) a memory manager for resources (I know already on the list^^) but that ones REALY neccesary
Oh, and bevor I forget: GREAT Software!!!!
greetz
Got some points that would make SFML way more comfortable to use:
1) Shader for sprites (at least Pixelshader)
2) Lines -> simple drawcall like App.Draw(Line(0,1,3,5)) -> draws a line between (0,1) and (3,5) (not sure about this one.. might be already implemented with:"Added a class to draw simple shapes (sf::Shape)")
3) a memory manager for resources (I know already on the list^^) but that ones REALY neccesary
Oh, and bevor I forget: GREAT Software!!!!
greetz