Topics

1

Graphics / Optimization/ particle system/ rendering mode spin-off thred

« on: September 14, 2008, 08:06:46 pm »

This has almost nothing to do with the thread (http://www.sfml-dev.org/forum/viewtopic.php?t=626) it came from anymore; but it's still interesting so...

this could probably be a whole new thread in it's own since this discussion has severely drifted from the scope of the original question Smile

but as for drawing. i noticed when profiling my particle system that when i had ~1000 particles in a system 50% of my CPU time was spent in the Draw function .. (you can try this yourself by downloading the particle system code(wiki) and running it through AMDs codeanalyst)the only thing that function does is first set states and texture then iterate through all particles and drawing their vertices using immediate mode. This really shows that you get a very large CPU overhead when using immediate mode. as for display lists they are only faster when working with static data. and are probably slower when working with dynamic data Smile. I am in no way an expert in graphics/rendering techniques(I usually stay as far away as possible from that particular subject when it comes to making games) but it would definitely be worth checking out vertex arrays / Vertex Buffer Objects and the like. I have tried to learn how to use them and how to apply them to particles but i have thus far failed to make it work Smile (mostly because the motivation isn't really there)

and as for the never ending collision question. i agree with you but i think it is important to point out that it is in fact possible it's just very hard to make it work well Smile ( and your time is probably better spent making actual games (unless of course you are looking for a career in physics programing))

hmm if i use any more parentheses people are going to start thinking i am a lisp programmer :S

Although I haven't specifically touched particles yet.  (It's on the list though...)  My first thought would be to make a vertex buffer of every pixel in some arbitrary box representing the max size of a particle system.  This single buffer could be statically referenced in every instance of the particle system class.  Then you'd have a local index buffer with each index being a particle.  Update each index as necessary as a "lookup" into your vertex buffer, then you just have to send one index buffer.
The static vertex buffer would always be referenced from the origin, but you'd just translate the modelview based on the particle system's position before the render.

2

SFML wiki / [C++ Class] DrawableLineShape

« on: August 24, 2008, 06:28:56 am »

I've decided to start contributing classes I've made to work with SFML that are clean enough / don't rely on modified SFML / etc. for public release.  I'll have others, but the first one is a drawable-derived class for shapes composed of lines.  While this same effect can be achieved with multiple sf::Shape primitives, my class is specifically designed for this task and is thus much faster (and I think simpler) making use of both GL_LINES and display lists.
Read the comment on top of the header for quick info on how to make a shape.  It's pretty simple.  You define vertices and then connect them however you want with line segments.  The shapes can then be modified dynamically by adding/removing/moving points and line segments.
It should work fine, but let me know if you encounter any problems.
It's released under the same license as SFML, zlib/png and is located under "sources" in the wiki.

I'll probably be releasing an animated sprite class later.  (It works, but isn't ready for public release.)
I also have an extension for SFML to add alpha texture objects that can then be used to make blended/overlayed/shadowed sprites, etc.  But I'm not as sure about releasing that since it requires modding SFML and is not quite as "just-drop-it-in" as the others.

@Laurent:  This is my first time editing a wiki, so if you end up with a log that said someone did like 10 edits before getting it right...  um sorry.  :oops:


Edit:  Here's a screenshot demo.  Both the map border and terrain tile selection boxes are easily done with this class.

3

Graphics / Why does RenderWindow::GetView() return a const View&?

« on: August 22, 2008, 06:17:00 am »

RenderWindow::GetView returns a const View& and RenderWindow::SetView takes a const View&.
I'm just wondering why GetView returns a const View?  You can't directly modify it since it's const and you can't receive it into a local variable and pass it back since SetView takes a ref which will be immediately trashed when the scroll function returns.
So the only current solution I see is too store a class View variable to pass the reference of.  This seems a bit odd and perhaps slightly wasteful.
Am I missing something here?  (It's late and I need sleep, so I might be!)

4

General discussions / "Improved management of dependant resources"

« on: August 09, 2008, 11:26:42 pm »

Any chance we can get a bit more specific information on what you've changed around here with the "Improved management of dependant resources" changes?
The change log mentions something about new Resource and ResourcePtr classes, but I can't find those classes in the SVN browser.  Did you forget to add them to the SVN or am I blind?  What are those classes supposed to do and where are they?
Also, are there any other changes to how resources are handled internally?  (I've been making a couple of my own VideoResource classes, so I'm trying to keep up.)
Thanks.

Edit:  It appears that VideoResource.hpp is still in there.  Is that class still used?

5

General discussions / Render masks on roadmap and the stencil buffer

« on: July 16, 2008, 07:32:29 am »

I see that render masks to only draw to part of the screen are on the roadmap.  Will you be using the stencil buffer to accomplish this?  I was interested in using the stencil buffer for something else, but that requires requesting a stencil buffer when the rendering context is created in the OS-specific code.  I didn't want to touch that, if you'd be adding in a stencil buffer anyway.  So will you?

6

General discussions / Meaning of "High Priority" and "Low Priority&

« on: July 15, 2008, 03:07:52 am »

What do "High Priority" and "Low Priority" on the roadmap mean?  Is everything there scheduled for 1.4 or is the low priority for 1.5?  I though low priority meant not in next the version.  But I'd also thought I read render-to-image and per-drawable shaders would be in the next version, and they are listed as low priority.

7

General / [Resolved] Reason for protected sf::VideoResource destructor

« on: July 04, 2008, 04:32:36 pm »

I was wondering why you chose to make the destructor for sf::VideoResource (already an abstract base-class) non-public.  I added an AlphaMask class derived from VideoResource and wanted to have a container than holds images or AlphaMasks (sf::VideoResource*), but I ran into problems with the protected destructor.
Obviously I could just make the destructor public, but I was wondering why it was protected in the first place, so I don't end up stepping on some other design you have or might have in the future.

8

Feature requests / Option to not save local image data/ use compressed textures

« on: June 23, 2008, 06:28:29 pm »

I've been digging through some SFML code related to images and noticed 2 things...
First, I noticed that when you load an image it leaves a local (uncompressed) copy in the myPixels vector after passing the loaded texture off to OpenGL.  This is only useful if the user later calls resize, setPixel, or something similar.  But I'd be willing to bet that the vast majority of times, people load an image and then never modify it which makes the uncompressed local copy extremely wasteful of memory.
So what about adding an extra bool parameter to the loading functions (with a defualt value to preserve the pubic interface, if needed) bPreserveLocalCopy or something that if false would free the local copy after the first call the Update (to preserve the thread-safeness you added) and then cause the methods that would access it to just do nothing and/or return an error?

Secondly, there is no option to use compressed textures.  A big bottleneck in SFML is likely going to be re-binding textures on every draw call.  (Some simple tests I ran seem to support this.)  You already said that you were not planning to implement some sort of background texture-combining/atlasing to save texture binds, which is understandable.  But allowing compressed textures would be a much simpler way to still help this a good bit since at least there will be less stuff to move around on the GPU.  (Testing this with even only a couple dozen sprites produced measurable speed increases of about 1500->1725 FPS on my rig.)  Also, it will obviously allow more textures to be crammed on the GPU as well.
I know that compressed textures is technically an extension to OpenGL, but I think pretty much every video card supports it and it would be easy enough to do an auto fall-back to uncompressed if the GPU didn't support it.

Are these features you'd consider adding or do they violate your "simplicity" design philosophy too much?  I'll probably do them myself if something like this is not on your roadmap; but if it is, I'll just wait.

Thanks.

9

Feature requests / A simple one- accessors for FlipX and FlipY in sf::Sprite

« on: June 12, 2008, 01:39:10 am »

The subject line pretty much says it all.  There don't appear to be any accessors for the FlipX and FlipY variables in sf::Sprites, only set functions.  This is probably an oversight, but they should be there IMO.  I needed them and added them myself, but I thought I'd mention it here.

10

Feature requests / Dot and cross products for vectors

« on: April 29, 2008, 11:41:30 pm »

Hey.  Obviously this is simple enough to implement myself, but since you are now providing vector classes in SFML, doesn't it make sense to provide dot and cross product function?  (You already have multiply by a scalar.)

Great library, as always.

11

Graphics / Shapes not scaling properly with resized window

« on: April 17, 2008, 10:09:22 pm »

I'm using the shape class and it looks good; but if I draw a line using the static line function, the line does not scale properly if the user resizes the window (as all the other drawables do).
If this was fixed recently, it's possible my build is not up-to-date enough.

If it's somehow relevant, here's a code snippet of what I'm doing each frame:

Code: [Select]


sf::Shape gridLine;

while (fLeftScreenY < fLeftScreenYEnd)
{
gridLine = sf::Shape::Line(0.0f, fLeftScreenY, (float)v2iWinSize.x, fLeftScreenY - fHalfWinSizeX, 1, gridColor);
m_pRenderWindow->Draw(gridLine);

fLeftScreenY += fTileSizeY;
}


12

Feature requests / Actual image resizing

« on: March 28, 2008, 09:11:02 pm »

As far as I can tell, it's not possible to actually resize an image in SFML- only change scale factors.  Is it possible to actually scale down an image, discarding the extra data?  If not, would this be a reasonably easy feature to add?
This would be needed if you wanted to offer multiple resolutions and actually save memory by scaling down the art.

13

Graphics / Internal image storage question

« on: March 27, 2008, 08:36:44 pm »

Hey and thanks for the great library.  I have a question about the internal storage of an image.  (The data you get with sf::Image.GetPixelsPtr())
Is this data always guaranteed to be 4 bytes-per-pixel (RGBA, as far as I can tell), right-to-left, top-to-bottom with 0000 always being transparent?
Is it's true now, will this possibly change in the future?  (I'm trying to decide exactly how deeply to embed this assumption into my code.)
Thanks again and happy Easter.

14

Graphics / Question on internal handling of images

« on: March 18, 2008, 04:17:39 pm »

Does SFML use any kind of texture compression or image re-arranging internally?
In other words, are there any performance gains by making sure images are already power of 2 sized and as full as possible with useful data and not transparent pixels?

15

General discussions / [bug-resolved] Corruption of window title under Win32 debug

« on: March 04, 2008, 06:57:59 pm »

Edit:  NEVERMIND.  I'M ACTUALLY AND IDIOT AND WAS LINKING AGAINST THE RELEASE LIBS IN DEBUG MODE.



Platform:  WinXP
IDE: Visual C++ 2005 express
Build: Debug
To reproduce use the following or similar code:

Code: [Select]

m_pGameWindow = new sf::Window(sf::VideoMode(800, 600, 32), "TestWindow");

while (!m_bQuit)
{
//process events
HandleEvents();


m_pGameWindow->Display();

}


*This will generate a window with the correct tile, but with 4 "garbage" characters before it (ASCII 204 or Ì).  So you get "ÌÌÌÌTestWindow."
*This behavior happens regardless of how you create the window (locally or dynamically as in my example).
*If the title string is 15 characters long, it will generate a window with an empty title.
*If the title string is more than 15 characters long, window creation will fail and cause a crash.
*This does not happen under release build.
*I did not pull down the latest SVN, but I looked at the roadmap page and round no mention of this bug.