31
Network / Packet Send - Fragmentation?
« on: December 10, 2008, 07:26:27 pm »
So I don't have to care about this? Thats great... 
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.
32
Network / Packet Send - Fragmentation?
« on: December 10, 2008, 01:04:56 am »
I have a little question here:
Does the SocketTCP make sure that what the client is sending as ONE packet can be received by the server also using SocketTCP as ONE packet? Or do you have to use packet length values? (huge difficulties and potentially dangerous possibilities of programming errors (e.g. allowing Exploitation/Remote Code Injection, we all know Teardrop a.s.o. working with packet fragmentation; demonstrating that it may be a complex topic to handle fragmented packets) may arise - I would request a socket class automatically handling this issue.)
Then, if you have to do so, how do you measure the amount of data that is still left to read? Use Packet::GetDataLength()?
Does Receive() Append() or first Clear() and then Append() (last case would really be crappy)?
Will something like this do the trick (assuming the length value (packet length including the length value itself) is sent first - the whole thing is multithreaded and has to listen to a bool "running" value, so we can't use sf::Selector to do timeouts...):
Packets coming fast one after the other could cause problems too - in fact, this should be very likely (would be treated as an error here, but that is some kind of really unwanted behaviour... So this causes even more pain, using serial numbers for each packet or likewise and treating the stuff read from a socket unwillingly... I would like to have a receive function giving me the power to say which amount of data I am requesting AND using sf::Packet. What if I use the Pointer/Length Receive function? Will the received data on the socket NOT fitting in the buffer given STAY there on the top of the socket?
I think this would be important to point out in the tuts...
Does the SocketTCP make sure that what the client is sending as ONE packet can be received by the server also using SocketTCP as ONE packet? Or do you have to use packet length values? (huge difficulties and potentially dangerous possibilities of programming errors (e.g. allowing Exploitation/Remote Code Injection, we all know Teardrop a.s.o. working with packet fragmentation; demonstrating that it may be a complex topic to handle fragmented packets) may arise - I would request a socket class automatically handling this issue.)
Then, if you have to do so, how do you measure the amount of data that is still left to read? Use Packet::GetDataLength()?
Does Receive() Append() or first Clear() and then Append() (last case would really be crappy)?
Will something like this do the trick (assuming the length value (packet length including the length value itself) is sent first - the whole thing is multithreaded and has to listen to a bool "running" value, so we can't use sf::Selector to do timeouts...):
Code: [Select]
sf::SocketTCP sock; //(this will be properly initialized)
sf::Packet p;
Uint32 length = 0;
sf::Clock clock;
sf::Socket::Status sstate;
sock.SetBlocking(false);
do
{
sstate = sock.Receive(p);
if(sstate == Socket::NotReady)
{
Sleep(0.05f);
continue;
}
else if(sstate == Socket::Done)
{
if(!length) //we do not have a length value now
{
if(p.GetDataSize() > 4) //can we read 32 bit?
{
p >> length; //will this decrease the "GetDataSize()" value by 4???????
}
}
else
{
if(p.GetDataSize() < length)
{
continue;
}
else if(p.GetDataSize() > length) throw 1; /*error - what happens with 2 packets sent with VERY low time gap? With packets send at the same time?*/
else break; // we have collected all the data and nothing MORE
}
}
else throw 1; //error
}
while(clock.GetElapsedTime() < 5.f); //Timeout
Packets coming fast one after the other could cause problems too - in fact, this should be very likely (would be treated as an error here, but that is some kind of really unwanted behaviour... So this causes even more pain, using serial numbers for each packet or likewise and treating the stuff read from a socket unwillingly... I would like to have a receive function giving me the power to say which amount of data I am requesting AND using sf::Packet. What if I use the Pointer/Length Receive function? Will the received data on the socket NOT fitting in the buffer given STAY there on the top of the socket?
I think this would be important to point out in the tuts...
33
System / Unicode class
« on: October 13, 2008, 12:29:56 am »
Could you add a function ToWstring?
I am asking this because wstring (std::string<wchar_t>) can be UTF16 (most 32 bit systems) or UTF32 (as with me, 64 bit system, where sizeof(wchar_t) == 4).
Would be convenient, but I can add these functions myself.
Which locale does the Unicode::Text-Class use?
I am asking this because wstring (std::string<wchar_t>) can be UTF16 (most 32 bit systems) or UTF32 (as with me, 64 bit system, where sizeof(wchar_t) == 4).
Would be convenient, but I can add these functions myself.
Which locale does the Unicode::Text-Class use?
34
Audio / Some weird audio problems
« on: October 11, 2008, 02:01:20 pm »
Hm... the thread calling "Music* globalMusicPtr = new Music;" is the main thread while the Music is played by another one, this works fine. The other threads do not execute these commands, so the context seems to be thread-global.
35
Audio / Some weird audio problems
« on: October 10, 2008, 10:58:06 pm »
After experimenting a bit, something strange (again):
I have now a map which stores file names of sound files as keys and Music* as values.
It works well... but only the first time.
When the music is stopped (or finished), the Music (that was dynamically allocated before) is deleted and the pointer in the map is set to NULL (while the key stays in the map). Now, if I want to play the same piece of music again (or another piece of music, I suppose...), I use this line of code:
which immediately kills my application with a SIGSEGV (Access violation).
It is NOT the map. I tested
Strange:
This seems also to affect sf::String (or maybe sf::Font maps??), because the strings in the Messagebox (my handler for SIGSEGV) look pretty fucked up (with other SIGSEGVs I had before, they mostly looked quite normal.)
Normally, Music* m = new Music; m = new Music; works without exceptions... this is quite strange. Maybe it has to do with the fact that the code that controls the maps, adds new Music* to the map and deletes the old ones runs in a special thread?
All accesses to the map and to the music requests are secured with a sf::Mutex.
Well, it couldn't get weirder: As I checked Music* m = new Music; m = new Music; after starting the Music (or Sound), I realized that the SIGSEGV vanished.... so I removed these two instructions, and the SIGSEGV was there again. So I put these instructions back in - and it works again.
Are there any global/static vars possibly not initialized?
Behaviour for Sound is exactly the same.
One single static pointer seems to be sufficient, so this is not that bad.
I have now a map which stores file names of sound files as keys and Music* as values.
It works well... but only the first time.
When the music is stopped (or finished), the Music (that was dynamically allocated before) is deleted and the pointer in the map is set to NULL (while the key stays in the map). Now, if I want to play the same piece of music again (or another piece of music, I suppose...), I use this line of code:
Code: [Select]
musics[fname] = new Music;
which immediately kills my application with a SIGSEGV (Access violation).
It is NOT the map. I tested
Code: [Select]
musics[fname] = (Music*)123; in the line before, and this does NOT lead to an Access violation.Strange:
This seems also to affect sf::String (or maybe sf::Font maps??), because the strings in the Messagebox (my handler for SIGSEGV) look pretty fucked up (with other SIGSEGVs I had before, they mostly looked quite normal.)
Normally, Music* m = new Music; m = new Music; works without exceptions... this is quite strange. Maybe it has to do with the fact that the code that controls the maps, adds new Music* to the map and deletes the old ones runs in a special thread?
All accesses to the map and to the music requests are secured with a sf::Mutex.
Well, it couldn't get weirder: As I checked Music* m = new Music; m = new Music; after starting the Music (or Sound), I realized that the SIGSEGV vanished.... so I removed these two instructions, and the SIGSEGV was there again. So I put these instructions back in - and it works again.
Are there any global/static vars possibly not initialized?
Behaviour for Sound is exactly the same.
One single static pointer seems to be sufficient, so this is not that bad.
36
Audio / Nasty CPU consumption
« on: October 10, 2008, 08:10:43 pm »
Now, with the new version of the Audio-Lib, the problem with the sound (interruptions, clicks) vanished.
But now, the whole thingy takes 100% of the CPUs power...
Edit: Ah, think I found the problem. One of the two soundfiles was corrupted...
Btw... great library
thanks.
But now, the whole thingy takes 100% of the CPUs power...
Edit: Ah, think I found the problem. One of the two soundfiles was corrupted...
Btw... great library
thanks.
37
Window / How to get Mouse-Position
« on: October 10, 2008, 07:49:57 pm »
If you simply want to retrieve the mouse pointer for a given window, you should use the sf::Input-class.
Code: [Select]
//Given an instance of sf::RenderWindow (hereafter called app)
const Input& i = app.GetInput();
Vector2i mousePositionRelative(i.GetMouseX(),i.GetMouseY());
//Fills a Vector2i (2 integer values) with the mouse position which is returned as int
38
System / Some simple questions about the Thread class
« on: October 10, 2008, 07:45:09 pm »
Thanks.
39
System / Some simple questions about the Thread class
« on: October 10, 2008, 07:34:58 pm »
How is the thread class implemented in Linux?
Are they kernel threads (via clone() or sys_clone()?), or fibers?
Is SFML-Thread based on libraries like pethread or GNU-portable-threads?
Are they kernel threads (via clone() or sys_clone()?), or fibers?
Is SFML-Thread based on libraries like pethread or GNU-portable-threads?
40
Window / How to get Mouse-Position
« on: October 10, 2008, 07:28:44 pm »
Can't you retrieve the position of your window?
Than simply add it, I'd suppose...
Hm... doesn't look like...
Why can you set the position via "SetPosition" but not get it?
Somehow, that doesn't make sense...
There should be ways to retrieve window positions on all platforms...
Maybe you can implement it specific to the platform your project has to run on or just seek another possibility...
Than simply add it, I'd suppose...
Hm... doesn't look like...
Why can you set the position via "SetPosition" but not get it?
Somehow, that doesn't make sense...
There should be ways to retrieve window positions on all platforms...
Maybe you can implement it specific to the platform your project has to run on or just seek another possibility...
41
Audio / Some weird audio problems
« on: October 10, 2008, 06:16:16 pm »
But make does not work anymore with the new makefiles. This is kinda funny...
Ah. Now it works... Dunno why it did not work ??.??
Quote
sudo make install
Makefile:5: *** missing separator. Schluss.
Ah. Now it works... Dunno why it did not work ??.??
42
Audio / Some weird audio problems
« on: October 10, 2008, 06:03:23 pm »
Okay. Will see if that works.
43
Audio / Some weird audio problems
« on: October 10, 2008, 05:02:53 pm »
Now, I am encountering some further problems with the sf::Music class.
First, the Music clicks from time to time (I think when the buffer is reloaded) and is not fluent. Other music players did not have any problems with these files.
(No, this is not the clicking bug with the optimizations for ogg-Files, I encountered this problem too but setting optimization to -O instead of -O2 for std_vorbis.c fixed it)
The CPU power for playing Music is kind of extraordinary too (every 2 seconds, I think on reloading the buffer, it consumes up to 80%) for an ordinary 4 minute ogg music file with 128 bps.
The other problem is kind of weird:
Most sound files shorter than one buffer (I am taking 2*44100 samples as buffer for it reduces clicking noises) do not even work. They are loaded successfully (OpenFromFile returns true for this .wav-file), but Play simple does nothing, while longer music files work without any problems (except this clicking noise).
Do I have to build in another interface for playing sf::Sound's to fix this?
Because I wanted the soundfiles to be replacable without changing the code, I really dislike this idea... what if someone wants to exchange a little notification sound or the initialization sound of an application with some longer piece of music? This would, for sf::Sound, stay in memory until the application dies (I really need a call-and-forget interface for playing Music, so I am thinking about an own soundManager with its own thread, but this is surely a nice amount of work). And for the normal application state, it would consume even more CPU power and memory than the other solution...
Ah yes, and sometimes (somehow by random, but not very often) if the sound device is already opened by another player, my app gets a SIGSEGV signal from out of the "Play()" call.
Currently testing on the following system:
64 bit Ubuntu
AMD Athlon 64 3500+
First, the Music clicks from time to time (I think when the buffer is reloaded) and is not fluent. Other music players did not have any problems with these files.
(No, this is not the clicking bug with the optimizations for ogg-Files, I encountered this problem too but setting optimization to -O instead of -O2 for std_vorbis.c fixed it)
The CPU power for playing Music is kind of extraordinary too (every 2 seconds, I think on reloading the buffer, it consumes up to 80%) for an ordinary 4 minute ogg music file with 128 bps.
The other problem is kind of weird:
Most sound files shorter than one buffer (I am taking 2*44100 samples as buffer for it reduces clicking noises) do not even work. They are loaded successfully (OpenFromFile returns true for this .wav-file), but Play simple does nothing, while longer music files work without any problems (except this clicking noise).
Do I have to build in another interface for playing sf::Sound's to fix this?
Because I wanted the soundfiles to be replacable without changing the code, I really dislike this idea... what if someone wants to exchange a little notification sound or the initialization sound of an application with some longer piece of music? This would, for sf::Sound, stay in memory until the application dies (I really need a call-and-forget interface for playing Music, so I am thinking about an own soundManager with its own thread, but this is surely a nice amount of work). And for the normal application state, it would consume even more CPU power and memory than the other solution...
Ah yes, and sometimes (somehow by random, but not very often) if the sound device is already opened by another player, my app gets a SIGSEGV signal from out of the "Play()" call.
Currently testing on the following system:
64 bit Ubuntu
AMD Athlon 64 3500+
44
Audio / Something about function names
« on: October 10, 2008, 04:34:14 pm »
Well, there is a little mention of Open in
http://www.sfml-dev.org/tutorials/1.3/audio-music.php
http://www.sfml-dev.org/tutorials/1.3/audio-music.php
Quote
The call to Open or OpenFromMemory actually doesn't start the music, only a call to Play does.
45
Audio / Something about function names
« on: October 10, 2008, 12:08:53 am »
No, this is not another request about "How about obeying C++-naming-conventions", but I think it is rather annoying that the function for opening a music file is not named "OpenFromFile" (as in tutorial and documentation), but simply Music::Open... (even in the tutorial, it is also mentioned as Music::Open and Music::OpenFromFile, but the first one not very explicitely...)
How about changing docu/tuts?
How about changing docu/tuts?