1
Feature requests / Re: Configuring SoundRecorder processing frequency
« on: January 01, 2013, 05:15:34 pm »
I haven't found an issue about this in the tracker, so I've created one.
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.
Pages: [1]
2
Feature requests / Re: Configuring SoundRecorder processing frequency
« on: January 01, 2013, 02:37:03 pm »
Oh, okay, sorry.
I have searched for it before posting, but maybe with the wrong keywords, because I didn't find these.
Sorry for bothering again!
I don't mind if it won't be included in the near future, I made it working for myself, just wanted to share the idea.
I have searched for it before posting, but maybe with the wrong keywords, because I didn't find these.
Sorry for bothering again!
I don't mind if it won't be included in the near future, I made it working for myself, just wanted to share the idea.
3
Feature requests / Configuring SoundRecorder processing frequency
« on: January 01, 2013, 01:21:55 pm »
Hello Laurent and everybody else!
I am playing around with spectral analysis (with FFT) and stuff like that, and as SFML can record sounds,
I thought it would be great if I could analyze not only sounds stored in a file, but in real time, as it comes out of my speakers, or goes into my microphone. (You know, everyone loves spectrograms...)
But upon deriving my recorder class from SoundRecorder I have seen that it hands me the samples in batches of roughly 4410 long (10 times a second), which is a bit "laggy", if you are watching the spectrogram.
This is because you have that 100 ms sleep in SoundRecorder.cpp somewhere.
I have hacked my copy of SFML to make this delay configurable, and setting it to 10 ms is quite a lot better.
So I think maybe you should make this option available in the mainstream source too, because some applications require lots of small sample batches very frequently (like this one), while others are OK with a few large ones, and want to spare with resources. (Although on today's multi-core computers a few hundred calls of a function this small every second is not a big deal, especially on a separate thread.)
Greetings:
Attila
I am playing around with spectral analysis (with FFT) and stuff like that, and as SFML can record sounds,
I thought it would be great if I could analyze not only sounds stored in a file, but in real time, as it comes out of my speakers, or goes into my microphone. (You know, everyone loves spectrograms...)
But upon deriving my recorder class from SoundRecorder I have seen that it hands me the samples in batches of roughly 4410 long (10 times a second), which is a bit "laggy", if you are watching the spectrogram.
This is because you have that 100 ms sleep in SoundRecorder.cpp somewhere.
I have hacked my copy of SFML to make this delay configurable, and setting it to 10 ms is quite a lot better.
So I think maybe you should make this option available in the mainstream source too, because some applications require lots of small sample batches very frequently (like this one), while others are OK with a few large ones, and want to spare with resources. (Although on today's multi-core computers a few hundred calls of a function this small every second is not a big deal, especially on a separate thread.)
Greetings:
Attila
4
SFML projects / Re: Kukatz 3D
« on: May 17, 2012, 01:15:28 pm »
Köszönöm honfitárs! 
I have planned several times to impement some kind of "minimap", "compass", or navigation helper to make it easier. So far none of them came into existence, as you can see. Still waiting for the "great idea" that would be greatly useful.
So no, it is not intentional, it's a gameplay flaw. But you can get used to it in a while, if you don't lose your interest...
I have planned several times to impement some kind of "minimap", "compass", or navigation helper to make it easier. So far none of them came into existence, as you can see. Still waiting for the "great idea" that would be greatly useful.
So no, it is not intentional, it's a gameplay flaw. But you can get used to it in a while, if you don't lose your interest...
5
SFML projects / Re: Kukatz 3D
« on: May 13, 2012, 09:24:46 am »
KreditZ is intentional.
Of course, there is a lot of room for smaller and bigger improvements, but overall, I am proud of it.
If not for the gameplay (I hear exactly the same from a lot of people - it is difficult to navigate in), but for the underlaying techniques, the "engine" (especially the way animations work).
I might add new features and improve things in the feature, if I will have time and don't get bored.
Thanks for your time and testing.
Of course, there is a lot of room for smaller and bigger improvements, but overall, I am proud of it.
If not for the gameplay (I hear exactly the same from a lot of people - it is difficult to navigate in), but for the underlaying techniques, the "engine" (especially the way animations work).
I might add new features and improve things in the feature, if I will have time and don't get bored.
Thanks for your time and testing.
6
SFML projects / Re: Kukatz 3D
« on: May 12, 2012, 11:19:29 pm »
There you go.
It is English now by default. The commit is pushed to BitBucket.
Also added a new download containing the new version binary in a zip archive.
It is English now by default. The commit is pushed to BitBucket.
Also added a new download containing the new version binary in a zip archive.
7
SFML projects / Re: Kukatz 3D
« on: May 12, 2012, 03:50:32 pm »
Thanks for fixing it. I will add localization soon.
8
SFML projects / Re: Kukatz 3D
« on: May 12, 2012, 08:36:57 am »
I couldn't test it on Mac OS, since I don't have access to a Mac, so these kinds of errors are expected.
However, SFML claims it works on Macs, and as I see, these are only minor errors caused by one single function call, so it should be easy to fix. I will push a commit soon. Please try to build that version, too!
Thanks for your interest.
EDIT:
The fix is committed, please take a look at it now. Also, you will have to copy the resources.pak file next to the binary executable. I hope it will work now.
However, SFML claims it works on Macs, and as I see, these are only minor errors caused by one single function call, so it should be easy to fix. I will push a commit soon. Please try to build that version, too!
Thanks for your interest.
EDIT:
The fix is committed, please take a look at it now. Also, you will have to copy the resources.pak file next to the binary executable. I hope it will work now.
9
SFML projects / Re: Kukatz 3D
« on: May 11, 2012, 06:57:23 pm »
Thanks for taking time to check it out, and I'm glad you liked it (at least the part you could try out ).
Yes, it would be great if there were translations in the game, I might consider implementing it in the next couple ofdays weeks months (years).
In the meantime, you must first create profiles in the "Játékosok" (Players) menu.
Type in the "név" (name) of the player, select the "fej" (head style), the "típus" (type) of controlling ("ember"-human/"gép"-machine).
For human players, set the controls (bal-left, jobb-right, fel-up, le-down), for AI, select the skill level (ügyesség).
Then in the "Új Játék" (New Game) menu select the players from the left list to right with return, and start the game by selecting the last option.
I hope you will manage to try it out (if you still care...).
).Yes, it would be great if there were translations in the game, I might consider implementing it in the next couple of
In the meantime, you must first create profiles in the "Játékosok" (Players) menu.
Type in the "név" (name) of the player, select the "fej" (head style), the "típus" (type) of controlling ("ember"-human/"gép"-machine).
For human players, set the controls (bal-left, jobb-right, fel-up, le-down), for AI, select the skill level (ügyesség).
Then in the "Új Játék" (New Game) menu select the players from the left list to right with return, and start the game by selecting the last option.
I hope you will manage to try it out (if you still care...).
10
SFML projects / Kukatz 3D
« on: May 10, 2012, 09:23:14 pm »
Hi everyone!
I would like to share with you my final project in my secondary school years.
It is a cross-platform three-dimensional snake clone, made with great help from SFML.
Also, I would like to hereby say very much thanks to Laurent for his work.
See the source and download the MinGW binaries (coming soon) from:
https://bitbucket.org/torokati44/kukatz-3d
As you can see, the GUI is fully in Hungarian, sorry for that.
I hope you might like it anyways, once you have managed to start a game.
Here are some screenshots:
http://imagerz.com/QEAXXEtvAwMHBFkZRwVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEQVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEAVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEwVQ
I would like to share with you my final project in my secondary school years.
It is a cross-platform three-dimensional snake clone, made with great help from SFML.
Also, I would like to hereby say very much thanks to Laurent for his work.
See the source and download the MinGW binaries (coming soon) from:
https://bitbucket.org/torokati44/kukatz-3d
As you can see, the GUI is fully in Hungarian, sorry for that.
I hope you might like it anyways, once you have managed to start a game.
Here are some screenshots:
http://imagerz.com/QEAXXEtvAwMHBFkZRwVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEQVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEAVQ
http://imagerz.com/QEAXXEtvAwMHBFkYEwVQ
11
Network / Packet transmission is unreliable and badly designed
« on: June 11, 2011, 12:08:07 pm »Quote from: "Laurent"
Done.
Great! Thanks!
12
Network / Packet transmission is unreliable and badly designed
« on: June 11, 2011, 09:47:42 am »Quote from: "Laurent"
I think I'll have a more detailed look at it when you describe it officially in the Projects forum (which you should definitely do, by the way).
Okay then, I will do so when it's ready.
13
Network / Packet transmission is unreliable and badly designed
« on: June 10, 2011, 10:05:10 pm »
Oh, what a fast response! Thank you very much! It's "the beauty of open-source", isn't it?
I'm glad you see the problem too, and that you agree with me.
Thanks for your attention, and I can't wait to see the fixes!
BTW what do you think about my project? Well, I don't expect you to read and analyze all the code, your time is surely expensive. But if you find it interesting, or worth inspecting, it would be great if you wrote a few words about it. Well, maybe it'd be better to describe it only if it's finished, and maybe I'll post it then into the "projects" section, so it will be somewhat stable and polished.
My pleasure that I could help make SFML better. Keep up the good work, and thank you for it!
I'm glad you see the problem too, and that you agree with me.
Thanks for your attention, and I can't wait to see the fixes!
BTW what do you think about my project? Well, I don't expect you to read and analyze all the code, your time is surely expensive. But if you find it interesting, or worth inspecting, it would be great if you wrote a few words about it. Well, maybe it'd be better to describe it only if it's finished, and maybe I'll post it then into the "projects" section, so it will be somewhat stable and polished.
My pleasure that I could help make SFML better. Keep up the good work, and thank you for it!
14
Network / Packet transmission is unreliable and badly designed
« on: June 10, 2011, 08:37:17 pm »
Dear Laurent!
I am developing a UDP-based client-server networking framework (netframework) using SFML 1.6. You can browse the whole source code here: https://bitbucket.org/torokati44/netframework. (It is heavily under development, but some parts of it are more or less functional all the time. And yes, I know it is a single executable application, but this is only for testing purposes. I plan to make it a library when it will be more mature.)
Recently I have had serious problems with the sending and receiving of sf::Packets. As you can see, my application sends keepalive packets to keep the connection(s) open. But not on a local network, even on localhost the connection broke after a varying amount of time. I have double-checked all my code, monitored traffic with Wireshark, but haven't got a clue what is causing this.
Only after this looked I into the implementation of the handling of sf::Packets in sf::SocketUDP. I was well surprised. I don't think it is a good idea to keep the ability to split packets into more UDP datagrams, because the whole, assembled packet is not checked for valid reassembly upon receive. And as we know (Because we do know, am I right?) UDP might swap, drop, duplicate, torture, or read Swedish folk tales to the datagrams during delivery. (But fortunately they are checksummed of course.) So you can't be sure that the same data arrives at the other end that you sent on this end. This is why it's wrong to make users believe that sf::Packet will arrive as just the same as it was sent, because it is not sure at all.
Moreover, what could happen if you sent a small packet that fits into a single datagram?
SFML sends the length of the packet (N bytes) first in a separate datagram as a 32 bit integer. (At least in SFML1.6. Anyway, the newer method in SFML2 isn't better either.) Then it waits for N bytes to arrive in whatever number of UDP datagrams. In this case there would be only one, but what if it got lost, and the other end won't send any more data? sf::SocketUDP::Receive(sf::Packet, ...) would wait forever, and dropped any other packet from any other address. I think this is very bad. (In SFML2 the tailing zero-length packet also can be lost, so you merged 2 sf::Packets together. Still dropping ones from any other source in the meantime.)
I suggest to make sf::Packet just wrap a single UDP datagram, and don't ever send it's data in multiple parts. (I'm speaking only about UDP, not TCP.) UDP packets' size is stored in a 2-byte unsigned integer, so theoretically they can be 65535 bytes long. IP will automatically fragment and reassemble the datagrams longer than the MTU, and drop them if some parts of them are lost. But would never let a corrupted UDP datagram through because of CRC checking. (Yes, it is highly recommended not to send Packets longer than the path MTU, I think this is why SFML splits packets. There shouldn't be need to send longer packets though.) And I think dropping data is still better than allowing faulty data through, without notifying, or even knowing about it.
If you don't want to change SFML like this, you should at least make a note of this in the documentation, because it was very frustrating to find.
So I solved the problem by replacing the sf::SocketUDP::Send(sf::Packet, ...) calls with sf::SocketUDP::Send(sf::Packet::GetData(), sf::Packet::GetDataSize(), ...), and making sure that no packet can exceed a constant size, like 500-512 bytes. This way the extra (currently 100%) packet overhead is avoided, and the connections are rock solid even over the internet.
Please don't take this post offensive, I still love and will use SFML, and appreciate your work. This is just a suggestion.
Sorry for my bad English, I'm not a native speaker, and I hope you will understand what I mean. Also sorry for the lengthy post.
Best regards:
TÖRÖK Attila
I am developing a UDP-based client-server networking framework (netframework) using SFML 1.6. You can browse the whole source code here: https://bitbucket.org/torokati44/netframework. (It is heavily under development, but some parts of it are more or less functional all the time. And yes, I know it is a single executable application, but this is only for testing purposes. I plan to make it a library when it will be more mature.)
Recently I have had serious problems with the sending and receiving of sf::Packets. As you can see, my application sends keepalive packets to keep the connection(s) open. But not on a local network, even on localhost the connection broke after a varying amount of time. I have double-checked all my code, monitored traffic with Wireshark, but haven't got a clue what is causing this.
Only after this looked I into the implementation of the handling of sf::Packets in sf::SocketUDP. I was well surprised. I don't think it is a good idea to keep the ability to split packets into more UDP datagrams, because the whole, assembled packet is not checked for valid reassembly upon receive. And as we know (Because we do know, am I right?) UDP might swap, drop, duplicate, torture, or read Swedish folk tales to the datagrams during delivery. (But fortunately they are checksummed of course.) So you can't be sure that the same data arrives at the other end that you sent on this end. This is why it's wrong to make users believe that sf::Packet will arrive as just the same as it was sent, because it is not sure at all.
Moreover, what could happen if you sent a small packet that fits into a single datagram?
SFML sends the length of the packet (N bytes) first in a separate datagram as a 32 bit integer. (At least in SFML1.6. Anyway, the newer method in SFML2 isn't better either.) Then it waits for N bytes to arrive in whatever number of UDP datagrams. In this case there would be only one, but what if it got lost, and the other end won't send any more data? sf::SocketUDP::Receive(sf::Packet, ...) would wait forever, and dropped any other packet from any other address. I think this is very bad. (In SFML2 the tailing zero-length packet also can be lost, so you merged 2 sf::Packets together. Still dropping ones from any other source in the meantime.)
I suggest to make sf::Packet just wrap a single UDP datagram, and don't ever send it's data in multiple parts. (I'm speaking only about UDP, not TCP.) UDP packets' size is stored in a 2-byte unsigned integer, so theoretically they can be 65535 bytes long. IP will automatically fragment and reassemble the datagrams longer than the MTU, and drop them if some parts of them are lost. But would never let a corrupted UDP datagram through because of CRC checking. (Yes, it is highly recommended not to send Packets longer than the path MTU, I think this is why SFML splits packets. There shouldn't be need to send longer packets though.) And I think dropping data is still better than allowing faulty data through, without notifying, or even knowing about it.
If you don't want to change SFML like this, you should at least make a note of this in the documentation, because it was very frustrating to find.
So I solved the problem by replacing the sf::SocketUDP::Send(sf::Packet, ...) calls with sf::SocketUDP::Send(sf::Packet::GetData(), sf::Packet::GetDataSize(), ...), and making sure that no packet can exceed a constant size, like 500-512 bytes. This way the extra (currently 100%) packet overhead is avoided, and the connections are rock solid even over the internet.
Please don't take this post offensive, I still love and will use SFML, and appreciate your work. This is just a suggestion.
Sorry for my bad English, I'm not a native speaker, and I hope you will understand what I mean. Also sorry for the lengthy post.
Best regards:
TÖRÖK Attila
Pages: [1]