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.


Topics - Andrew

Pages: [1]
1
Audio / For the SFML Developers: SoundStream Chunk
« on: July 15, 2014, 02:17:43 am »
Hi,

This may seem like a minor request, but could you make the SoundStream Chunk's "samples" field be non-const?

https://github.com/SFML/SFML/blob/master/include/SFML/Audio/SoundStream.hpp#L55
(Line 55)

It's hard to explain why this is such a big deal for me, but basically it would make my code a lot cleaner, faster, and easier if I could change its value over time. I guess this is the best way to explain why:

I'm generating sound data programmatically, and I am not using a file or stream source of any kind. I would prefer to be able to just store the sound data and add to it all within the Chunk. Instead, I have to do something more like this:

short* soundData = new short[200000];

for (blahblah)
{
    soundData[whatever] = etc.;
}

sf::SoundStream::Chunk c;

c.samples = soundData;

In addition, I might want to make modifications to the Chunk over time. I would prefer not to have to maintain two arrays/vectors/etc. when there only needs to be one. Hopefully this makes sense.

(I'm also a little curious as to why it was made const in the first place and why that would be necessary?)

Thanks,

- Andrew

2
General / CMake Libraries Version/Dependency Problem
« on: May 23, 2014, 12:49:47 am »
Hello,

I had a project in Visual Studio 2012 with working code that used SFML-2.1. I updated it to Visual Studio 2013 and quickly discovered that I needed to get the 2013 version of SFML libraries. Here are a few of the errors I got:


(click to show/hide)


I would much prefer to simply download and use them, however there's no 2013 version on the SFML website and the only files I found for it in the forums were dynamic; I'm using the static libraries.

I got CMake gui to work properly using the tutorial: configure, configure, generate, etc. No problems. I used the VC++12 compiler option or whatever (version 12 is for VS2013).

Then I opened it in VS2013, built the debug and release libraries, copied them over into my now 2013 project, updated the include header files for SFML as well, and tried to run it. I got a whole bunch of linker errors that I have never seen before, which seem to be related to SFML's dependencies now. Here are a few:


(click to show/hide)


Just for the heck of it I tried adding this line to my code:

#pragma comment(lib, "OpenGL32.lib")

The GL errors seem to go away, and now I seem to get GLEW errors. Is it possible that this statement in the CMake tutorial:

Quote
On Windows and Mac OS X, all the needed dependencies are provided directly with SFML, so you don't have to download/install anything. Compilation will work out of the box.

would somehow not be true? I followed the tutorial by the letter, I'm confident I did not miss anything, I triple checked that I used the updated version of SFML's include header files and library files, I tried running in release and debug mode, etc. What should I do?

Thanks,

- Andrew

3
Window / SFML Window Overlap Bug?
« on: May 01, 2014, 04:54:20 am »
I think I may have found a window overlap bug.

I'm on Windows 8 using c++ Win32 in Visual Studio 2012. I have two SFML windows that I have created, and I display, poll the next event, and clear for both windows in a loop, all in the same thread.

Here's how I can initiate the bug:
  • Window A is bigger than window B.
  • Window A is created last, meaning it shows up on top.
  • I click on window B in my taskbar; it appears in front like normal.
  • I try to click on the title bar of window B (and in the window itself as well), but nothing happens and none of the buttons on it work. I suspect that even though window A is in the background now it is still receiving the mouse events. (Keep reading and you'll see why this makes even more sense later on.)
  • If I move window A off of window B completely, window B then responds as expected.
  • I have also figured out how to get window B to respond while window A is mostly overlapping it. Here's how:
  • Drag window A slightly off of window B so there's at least 1 pixel of window B not covered by window A. Window A should now be in focus and in the foreground.
  • Click on window B in the taskbar. As before, window B seems unresponsive.
  • Move the mouse over the sliver of window B that is uncovered (no overlap), e.g. as if to resize it. No clicks necessary; just move the mouse over it.
  • Now window B responds to the mouse as expected.
Here's some illustrations:

(1-4)
 ________
|    ___     |
|   |     |    |
|   |___|    |
|________|

(5)
 ________
|               |   ___
|               |  |     |
|               |  |___|
|________|

(6-10)
 ________
|           __|_
|          |     |
|          |___|
|________|

Did I do something wrong, or have I truly discovered a bug? How can I fix it, or can you fix it please? :)

Also, another note: this is not just about the windows' creations; it happens over and over again if the process is repeated without restarting the program.

Thanks,

- Andrew

4
Graphics / Massive Graphics Optimization
« on: May 28, 2013, 04:51:14 am »
Hello,

I am in the "scoping" phase of a project I'm working on which will use SFML graphics heavily. What I am wondering is: how can I make the graphics as fast as possible, generally speaking? After searching through these forums, this is what I have found:

1. Limiting the number of SFML "draw" calls.
2. Using VertexArrays (although I have no idea what you mean by this and why).
3. Using OpenGL directly (although would there be a reason for me to use SFML anyways then?).
4. Using multithreading.

Also, would it be faster to use pre-existing, reusable sf::VertexArray's and other Shapes and such to optimize the speed of drawing things (since their constructors and deconstructors wouldn't be called more than once)?


Obviously the context of what graphics is being drawn is of some relevance here, so I will state it. There will be any number of different sections of graphics ("in-window windows") that can be moved around and stacked on top of each other and such. Inside each section can be any number of lines, shapes, texts, and etc. It is possible for any of these 3 scenarios to happen in each section at any time (and I'll know about it ahead of time):

1. The section could have everything drawn differently every time it's displayed.
2. The section could have everything drawn exactly the same (but possibly being moved? (possibly not as well)) every time it's displayed.
3. A combination of #1 and #2.

From what I can understand, it would be beneficial to use RenderTextures and Views for this sort of thing, but when and where would it be applicable and efficient?

Any help you can provide on this subject would be greatly appreciated, thank you!



EDIT: Okay, after doing more reading of the RenderTexture and View documentation, this is what I have found:

RenderTextures should be used whenever it is possible that something will be drawn more than once. I would then call all of my draw commands from the RenderTexture rather than from the RenderWindow, and when I am ready I would draw the RenderTexture onto the RenderWindow. Why is a Sprite needed to do this transfer, though, and will I need to create a new Sprite every time or can/should I reuse the Sprite for the same (and different?) RenderTextures?

Views should be used whenever something needs to be drawn at a different position, size, and/or rotation than normal. Most of the functions for Views are for setting its source rectangle ("from where on the source am I taking graphics?"), and setViewport is used for setting its destination rectangle ("where at on the destination am I placing graphics?"). Are the first two parameters of the FloatRect in a View the coordinates, or are they percentages as well (just like the last two parameters)? Before drawing things, I would need to set the View on the RenderTexture/RenderWindow, draw stuff, and then potentially set the View back before drawing something else if desired.

Is the above correct? Also, would it be faster to draw e.g. 10 lines on a RenderTexture and then use a View to draw that RenderTexture onto a RenderWindow at a different position, OR would it be faster to draw those 10 lines straight to the RenderWindow and adjust each line's position individually? What about for 1 line or 10000 lines? Do RenderTexture's store data differently than the drawing operations themselves, etc.? That's primarily what I need to understand.

Thanks!

Pages: [1]