Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Messages - Ezekiel

Pages: [1] 2
1
SFML website / SFML Graphic Pathes Block Diagram
« on: July 24, 2022, 11:21:12 am »
Greetings All:

With the tutorials and forums I've found it a wee little bit confusing to figure out how to pass the graphics from object to object, ending up in the Window, of course.

I traced the classes used and where required, then made a block diagram showing the graphics data paths.  I've used this every time I used SFML with any graphics used and it makes it more understandable, well for me at least.

I think the tutorials could use something like this to help, perhaps bright sections or circles around described code.  Corrections, improvements, additions and better drawing quality software appreciated.

If beneficial for anyone, I wish the best.


2
Graphics / Re: Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 18, 2016, 01:48:50 am »
Greetings All:

I forgot to show what my first performance issue was.  See attached picture...

...it was about 10 times slower.  As mentioned in the second post, I solved the pollEvent() issue by only calling once per frame, and it also improved the 1.6 version.  I enabled that issue by commenting out "if(FetchPollTime)" on line 132.  29us every loop is large wast of time, once frame is not a big deal.  Anyone can check that if desired.

eXpl0it3r, the getElapsedTime() time is 3us, not 3ms, so that would be MUCH WORSE if it was in milliseconds.

Modifying the random pixel loop would be easy, since solving each pixel is in a fixed number of assembly instructions, so I could calculate and go through the number of times taking ~16.5ms, then check the time frequently to start the frame draw at the right time.  Fractals are more difficult, some pixels take 1 check (not even an iteration), and some never escape so take iteration limit.  The limit can be in the billions for deep zooms.  So after a pixel is calculated, checking if the frame display time is ready shows the progress.  And now as I recall, on deep zooms, any Event functions can be delayed since a single pixel can take a long time.

Well I have my task in front of me, calculate pixels until frame-time, without asking the clock.  Also I haven't performed using treads for multi-core efficiency or using GPU shading for that as well.  Is there class/functions in SFML that are convenient for GPU processing?  And if so, does the shading prefer float, double or integer math?

3
Graphics / Re: Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 17, 2016, 10:22:39 am »
Greetings eXpl0it3r:

The program I upgraded from SFML 1.6 to 2.4.0 is a Mandelbrot Fractal program.  Since its much larger program, I copied out the small sections needed to check the differences.  Since the fractal section is complicated and uses other classes, I made a random pixel section so it could be done in 20 lines in a single main function, and still behave similar requirements in its graphics.  Both formats do some math to solve a single pixel in an array of pixels, and update the display every frame.

Most of the changes required for the upgrade 1.6 to 2.xx are spelling or capitalization and a few getSize().x rather than GetWidth(), except for the graphics section requiring a texture step displaying an image.  I apologize for my assumption, when the graphics with the only change mentioned was much slower, it seemed to be a graphics changing the speed.  However, as mentioned in previous posts, the time changes are in the poll event call and getElapsedTime call in the main loop, so this should have been placed in the window or system section, respectively.  Both versions display the image in the same amount of time, so graphics are affect by timing changes, but aren't the culprit.

The program does a lot of calculation to solve a single pixel, so waiting for the poll event or getElapsedTime for a longer time slows the progression rate, and image is the only place to modify a single pixel in ram I could find.  If there are any faster ways, let me know and I will see if I can modify my test program.  I will also have to get to know the profiler, I haven't used that before.

4
Graphics / Re: Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 16, 2016, 10:38:33 pm »
Greetings dabbertorres:

The section you mentioned is only done on Event Resized, however around line 300 in 2.4.0 mode, a similar sequence is done except the resizing functions.  In the main loop, every time through a new random pixel is generated (line 200 to 220) and modified the single pixel in the image (230 in 2.4.0 mode).  The image is modified thousands of times during each frame, so this is best done in ram, as I understand.  Any improvements to the display time would be appreciated.

Here are some pictures of the two versions attached below.  The first line shows how many pixels are modified per frame, and the next shows time per loop, while the pixel is updated and the time is checked if it's frame-time yet.  The next 4 lines are tested during each frame, the display time, poll time, solve time, and pixel mod time.  The last 2 lines time is by set the 2 getElapsedTime calls, as the Math Loop time does the same since it calls the function once.

I hope you find that helps.

5
Graphics / Re: Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 16, 2016, 01:25:20 pm »
Greetings Mr_Blame:

I tested both types as mentioned and compared the speeds between them before posting the responses.  I used Release as Debug tends to slow things down quite a bit, so I didn't try Debug.  The timing measurements are posted in the program window when you get it running.  It obviously can be different than my measurements on different hardware or operating systems

If you want to test the 1.6 version, VS 2008 is the latest version of the old SFML library version, so that Visual Studio will be required I believe.

I used 2.3 for a while, and upgraded to 2.4.0 a few days ago, and it required no changes at all, but I'm not familiar with 2.0.  I'm also not very skilled linking all the lib's, so that may cause errors as well.  I use the following in the 2.4.0 include folder, and an older version posted in an old post I made a while ago for the 1.6 version.  The versions less than 2.2 may be more similar than the 1.6 version, but I'm not sure.

include reference to lib's...
(click to show/hide)

I that helps.

6
Graphics / Re: Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 16, 2016, 03:27:33 am »
Greetings All:

I did some additional testing using time measuring by adding clock points in the software loop.  I found 2 changes between SFML 1.6 and SFML 2.4.0 that affect the speed of the main loop.

1st, the speed calling the App.pollEvent(Event) command.  Times Measured:
SFML 1.6    SFML 2.4.0
~3us         ~29us

I improved that issue by only polling the Event's on the loop following the frame display, not every loop.  This change improved the 1.6 version by about 25%, and the 2.4.0 rate about 10 times.  After that, the 1.6 loop speed is still about 2.5 * the 2.4.0 loop speed.

2nd, the speed calling the getElapsedTime was different between the 1.6 and 2.4.0 versions.  Times Measured:
SFML 1.6    SFML 2.4.0
~1.2us         3.000us

As shown, the 2.4.0 is longer by about 2.5 * than the 1.6 time, indicating the difference causes the result I see.  Also as shown, the 2.4.0 time is way more accurate, the 1.6 time was very randomized.  Calling the getElapsedTime frequently is required to perform drawing the frame accurately, so I haven't found a good option to solve this yet.

The good news is the time of the App.Draw sequence is about 2.8ms for both versions, so it doesn't seem there aren't time result changes to the graphics section.

Here is the new version test code with the added time measurement...
(click to show/hide)

Be forewarned, any measurements I made can be dramatically different with different hardware or operating systems.

I hope this is found interesting.  Any suggestions would be appreciated.

7
Graphics / Upgraded from 1.6 to 2.4.0 is ~18 Times Slower
« on: August 15, 2016, 02:26:26 am »
Greetings All:

I have been upgrading one of my sfml 1.6 VS2008 programs to sfml 2.4.0 VS2013 and found the math cycles between graphics frames are significantly slower than the previous version.

I made a simplified version for the comparison, and the math cycles are about ~18 times slower than the original.  The demo code can be pre-compile selected to run on either Visual Studio versions.  Here is the code...

(click to show/hide)

I could use some help to find the faster path using the newer sfml 2.4.0.  There could also be some differences in the compilers and/or computer hardware interface as well.

Specs:
AMD 64 X2 Dual Core Processor 5200+
Windows 7
NVIDIA GeForce 7600 GT

8
Greetings eXpl0it3r:

Indeed, unless I'm missing something, SFML appears as a wrapper for OpenAL, at least for the few functions called as mentioned.  So the issue most likely occurs in the OpenAL=>Windows7=>Driver=>Sound-Card path, and if any step differs (i.e. OS or hardware), the result may be different.

I'm more of an electronic hardware person, and fit the Newbie title I have posted currently, so as far I have looked is in the Sound class forwarding the data to OpenAL class.  The sound-card's hardware interface details are not posted, and if anyone else know more about the OpenAL=>Windows7=>Driver section, that may help finding out what causes it.  With secrets under the hood in the path shown, some suspicions I mentioned may be different in reality.

Unless someone else can verify what experienced, it may not be excepted as a proven issue.  And even if so, it may be posted as unsolved.

Let me know if there's ever a newer OpenAl version sent with a newer release than SFML-2.3

9
Greetings eXpl0it3r:

I first saw the tone on the Visual Analyzer, as I showed already.  I also saw a few level indicator lights on my external mixer, where I send the PC audio to directly.  And no, I never heard it.  I just did a hearing test, running my analog sine HP 204C Oscillator device (10Hz to 1MHz) to my mixer and turn it up (all level indicator lights on), I can only hear up to ~14kHz.

My initial idea was when "loop=false" and it plays to the end, it continue loops, but is pointing the the final sample.  However, changing the final sample to zero did nothing, but worked at >124 samples to zero, and reduces the level as approaching.  As a guess, that means the same "loop pointing at the last sample" is happening, but after the sample rate conversion.

For conversion i.e. 24000Hz to 96000 there are a few steps.  Convert up-sample-rate to match, "sample, 0, 0, 0", increase level *4 (compensate for zeros), filter out anything above 12kHz (i.e. 256-bit software FIR filter), send higher-frequency-samples (4*original) to sound-card or Windows control.

The 124 zero samples needed seems to indicate the "loop pointing at the last sample" happens at the post-up-sample point after a normal 256-bit FIR filter.

In the old days, a sound-card only allowed 1 program to use it at a time (Win95 and earlier), and now Windows hold all the keys, so any audio needs to be passed to using its format, which means converted by software beforehand.

So I think from what I saw, the tone is produced by the "loop pointing at the last sample", post-conversion by software, and then sent to Windows.  I checked out the 'sound.cpp' file, and it appears any issue, if it exists (but my hardware), is mostly in "openal32.lib", as it seems "sound.cpp" behaves as a wrapper, particularly of the functions posted in the demo-code I posted.

I tried adjusting the Playback-Device Sample Rate under Windows and it changed nothing.  And I previously did the demo code test using 22050Hz, which has the audio range up to half that, 11025Hz.  My sound-card claims it uses up to 192kHz on Playback, so everything prior to Windows7, or within Windows7 its self, is up-converted to that.

Below, I posted my Sound Card driver, if that helps...

10
Greetings eXpl0it3r:

I thought about the difference #including SFML modules after I posted it, I hope you've made it easier for others if they want to try it.  I used something that's posted in my previous subject quite a while ago, and it had to be changed with the newer releases as well.

For the remaining 16k tone to be created, press the <space> command, and let the 1.25 second sine wave finish (not stopped by command), and then it put's out the tone, which appears as a triangle with clipped top and bottom, until the program is stopped, or the stop() or getStatus() commands are sent.

I forgot to mention a few things...

Using the sine wave brings a much smaller tone, rather than using the obnoxious random square wave I used to generate the picture I posted.  The sin on my test program shows the 1000.1k tone as ~-10dB, and the 16k tone left behind is at ~-55dB, or smaller and changes every time the key is pressed.  This means it's about ~175 times smaller, or even less.  An analyzer using the FFT like I showed would help, searching for the title "Visual Analyzer" will Google that if interested.  To see a recording as you showed, turn the volume up ~200 times, and look at the line after the sine is finished.

My audio hardware is set up to 96kHz, so the 16k tone as my analyzer checks uses 6 samples repeating over and over, so increase the horizontal range as well.  If your hardware is set to 48k sample rate, the 16k would be 3 samples repeating, or may response differently, i.e. 8k with 6 samples.  And yes, the tone I see could just be something to do with my hardware, however the "getStatus()" shouldn't alter the hardware.

I hope that provides some more required information.  I may have some more test to do myself.

11
Greetings All:

I put together a simple program to demo the remaining tone I previously mentioned.  The program allows a different number of zeros left at the end of sample sequence.  Using the sine wave, it fades away with around ~100 samples zeroed at the end.  The remnant is larger of course, when you have 0 samples zeroed.  I used a static keeping track of the sine position used, so the sine wave won't end in the same position each time played, unless the time is a multiple cycle period, so the level change each time the <space> is pressed.  Calling stop() or getStatus() can be performed, and on my computer, both stops the 16k tone.

I hope this helps, the code follows...
// Remaining16kToneDemo.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"

#define _USE_MATH_DEFINES
#include <cmath>

#include <iostream>

#include <stdio.h>
#include <stdlib.h>
#include <vector>

#include <conio.h>
#include <windows.h>

#include <sfml.h>

using namespace std;

//globals
//configs
int SampleRate = 22050;
double ToneFrequency = 1000.1;
double ToneTime = 1.25;
int SamplesZeroAtEnd = 20;
//used as static, or accessed by functions
int CurrentSample = 0;
unsigned int SamplesNeeded =(unsigned int)(ToneTime * (double)SampleRate);
vector<sf::Int16> SentanceSamples;

//function headers
void RunSequence();
void PlaySentence();
int NumberKey(char value);//returns value, -1 if canceled



int _tmain(int argc, _TCHAR* argv[])
{

        sf::Sound SoundPlayer;
        sf::SoundBuffer SentenceSound;
        bool Running = false;

        //main loop
        for(unsigned char rx_char = 0x00; (rx_char != 27);)//escape exits
        {
                //display commands
                system("cls");

                cout << "<Numbers>\t\t: Set Value\n";
                cout << "<Space>\t\t\t: Play or Stop (If Still Playing)\n";
                cout << "'S'\t\t\t: Calls stop()\n";
                cout << "'G'\t\t\t: Calls getStatus()\n";
                cout << "<Esc>\t\t\t: Exits Program\n";

                cout << "\n";
                cout << "Samples Zero at the End\t: " << SamplesZeroAtEnd << "\n";

                //wait for key here
                rx_char = _getch();

                switch(rx_char)
                {
                        case 27://escape
                                break;
                        case 'S':
                        case 's':
                                SoundPlayer.stop();
                                break;
                        case 'G':
                        case 'g':
                                SoundPlayer.getStatus();
                                break;
                        case ' '://<space>
                                //clear 'Running' if has stopped
                                if(SoundPlayer.getStatus() ==  sf::SoundSource::Status::Stopped)Running = false;

                                if(Running == false)
                                {
                                        //play sentence HERE!!!
                                        RunSequence();//generates audio samples, stored in "SentenceSamples"
                                        //SentenceSamples is a "vector<sf::Int16>"

                                        if(SentanceSamples.size() >= 100)//skip if very few samples
                                        {
                                                SentenceSound.loadFromSamples(&SentanceSamples[0], SentanceSamples.size(), 1, SampleRate);

                                                SoundPlayer.setBuffer(SentenceSound);
                                                SoundPlayer.setLoop(false);
                                                SoundPlayer.play();

                                                Running = true;
                                        }
                                }
                                else//Running?
                                {
                                        //stop playing
                                        SoundPlayer.stop();
                                        Running = false;
                                }
                                break;
                        default:
                                //numbers
                                if(rx_char >= '0' && rx_char <= '9')
                                {
                                        SamplesZeroAtEnd = NumberKey(rx_char);
                                }
                }
        }
       
        return 0;
}

//functions
void RunSequence()
{
        SentanceSamples.resize(SamplesNeeded);
        unsigned int peak = ((1 << 15) - 1);
        double RadiansPerSample = 2.0 * M_PI * ToneFrequency / SampleRate;

        for(unsigned int i = 0;i < SamplesNeeded;i++)
        {
                SentanceSamples[i] = (unsigned int)round(sin((double)CurrentSample * RadiansPerSample) * (double)peak);
                CurrentSample++;
        }
        //change last sample to zero
        for(int i = 1;i <= SamplesZeroAtEnd;i++)
        {
                SentanceSamples[SentanceSamples.size() - i] = 0;
        }
}

int NumberKey(char value)
{
        int number = value - '0';
        cout << value;

        for(char rx_char = 0;;)
        {
                rx_char = _getch();
                if(rx_char >= '0' && rx_char <= '9')
                {
                        cout << rx_char;
                        number = number * 10 + rx_char - '0';
                }
                else if(rx_char == 13)//enter
                {
                        if(number > SamplesNeeded)return SamplesNeeded;
                        return number;
                }
                else if(rx_char == 8)//backspace
                {
                        if(number)
                        {
                                cout << "\b \b";
                                number = number / 10;
                        }
                }
        }
}
 

12
Greetings All

Here are the few sections with the code...

In my Main Loop:
                //wait for key here
                rx_char = _getch();
                //clear 'Running' if has stopped
                if(SoundPlayer.getStatus() ==  sf::SoundSource::Status::Stopped)Running = false;
 

...other than above, if pressing the <space> bar, it calls "PlaySentence()"...
void sentence::PlaySentence()
{
        if(Running == false)
        {
                //play sentence HERE!!!
                RunSequence();//generates audio samples, stored in "SentenceSamples"
                //SentenceSamples is a "vector<sf::Int16>"

                if(SentanceSamples.size() >= 100)//skip if very few samples
                {
                        SentenceSound.loadFromSamples(&SentanceSamples[0], SentanceSamples.size(), 1, SampleRate);

                        SoundPlayer.setBuffer(SentenceSound);
                        SoundPlayer.setLoop(false);
                        SoundPlayer.play();

                        Running = true;
                }
        }
        else//Running?
        {
                //STOP PLAYING HERE
                SoundPlayer.stop();
                Running = false;
        }

}
 

The only other SF code references are the three items, Sound, SoundBuffer, and vector<sf::Int16>, declaried in the header.

The "RunSequence()" generates the samples.  I started using a sine wave, and changed to random sound to check if the 16kHz tone response changed.  When I used the sine, as I changed the number of zeros in the end of sample list, it ran into nodes that show no tone, until passed.

As I mentioned, if I pressed anything when the 16k tone is playing, the command loop called getStatus(), which would stop it.  And if <space> pressed when the generated sound, it would call stop(), which also stop the generated sound, and not leave the 16k tone.

I hope provides enough information, extracting the rest to generate the samples I have would fill many pages.  The small shown should work in a small main function if testing is planned.  Be sure using something visual, such as "VisualAnalyzer" as shown in the attached picture, unless your ears are better than mine.

I hope all find this interesting.

13
Audio / Re: Sounds stop playing too early when using std::vector
« on: August 03, 2016, 02:57:16 pm »
Greetings All:

I notice in the changed to queue section, &soundVtr.front() appears to look at the same position each loop, unless the last loop popped that one out.  So if a long sound is playing there, there could be many finished smaller sounds in the queue that didn't get checked and removed.  Keep in mind, if the longest sounds aren't very long, and there are few others following in that time, it may not be a large issue;

I have used other containers the odd time, but usually find they take some research to know them well, so I can't see if queues or lists also have to copy-paste-destruct issue that vectors have.

Most of the time I use the vector, so I suggest using vector<sf::Sound*>.  Create a "new" sf::sound and pushback the pointer, remove the '&' from "if (!isSoundPlaying(&soundVtr))" and add "delete soundVtr;" before the "erase" command.  The vector can move the pointers wherever it needs to, they will still be the pointers.

I hope this helps, though other containers could be much better.

14
Greetings All:

I noticed something that seems strange.  As mentioned on the Subject, I have been using the SFML Audio Module, and when a tone is finished, it leaves a remaining 16kHz tone.  View what I have seen in the attachment I made, and yes I didn't hear that myself, the testing equipment is necessary, well I only hear about to 12kHz.

I have done some exploring and found out the remaining tone is dependent to the final ~125 samples in the buffer, if the last samples are filled with zeros, it no longer shows up.  I have tried several sample-rate configurations, and it works similar using 96kHz, 48kHz and 22050Hz.  It's strange, 22050Hz doesn't have any range in the 16kHz position.  The volume was lower in the 96kHz rate, and the highest in the 22050Hz rate.  And if I call the 'stop' (playing or finished already), or the 'getStatus' functions, it goes away.  Closing the program also stop it.

I'm currently using SFML-2.3, I haven't updated to see if new version has changed this, but it doesn't appear that any mods in the last 2 revisions has changed anything applicable to that specific issue.  I'm using Windows 7 and have an X-Fi Creative Sound Blaster, if that changes anything.

Has anyone else seen that, or is it specific to my hardware?

I hope this is found interesting.

15
Graphics / Re: RenderTexture Issues.
« on: August 22, 2013, 10:13:27 pm »
Excellent suggestion!  I figured I was missing something, and using Texture was the only place I did not look at, I figured I was already using the RenderTexture and it would do all Texture functions.  Perhaps I was also convinced I couldn't copy the RenderTexture to an image because it is based on NonCopyable.  Things aren't always as they seem.

Thank you for helping.  I will try that as soon as possible.

Pages: [1] 2