Messages

151

Graphics / Animation

« on: May 13, 2008, 05:45:29 am »

To above: You could just have made all of your sprites animated with just one frame for non-animated sprites then you could still call the update function on all of them. I would suppose it would have a small overhead (considering you have an integer to keep track of current frame position).

I could have, but it would be a bad idea.  Treating static sprites as 1-frame animated sprites would add tons of needless overhead, especially in memory.  There are several variables needed to track the state of the animated sprite including frame number, descriptors of the layout of the sprite sheet, etc.
I'm pretty happy with my implementation.  It would have been nice to avoid modding SFML, but all the dancing around would have been a much bigger deal then just changing a couple of things in the library.  This is why using open source libraries is nice.  Might as well take advantage of it when it's useful.

152

Graphics / Animation

« on: May 12, 2008, 07:07:11 pm »

To do it correctly, you should derive an AnimatedSprite class off of sf::Sprite.  Then you can track which cell of a sprite sheet you are using and adjust the subrect of the sprite as necessary.  I found the best place to put these checks was in an overrided render function, since that should be called every frame anyway.  But this required stripping the const-ness out of the base class render functions, since you need to modify the subrect.  (That or declaring the subrect and whatever else you need mutable.  Either way, you need to change a bit of stuff in SFML.)  If you don't want to touch SFML, you can add some kind of update function to your AnimatedSprite class to call each frame, but I didn't like the idea of having to always check if a sprite was animated and call Update() if it was.

153

General discussions / Hi, I'm user n.500 ^_^ What I win?

« on: May 12, 2008, 07:00:53 pm »

I've been using CEGUI and it works great with SFML.  It's also cross-platform as you requested.

154

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.

155

General discussions / Current Mac OS X status

« on: April 26, 2008, 06:03:17 pm »

Are you doing the official Mac port or is this a separate effort?  I was under the impression that the Mac port was back on track and a bit more imminent than a year away.

156

General discussions / Event.Key.Code to correct ASCI CODE

« on: April 22, 2008, 03:17:12 pm »

Why can't you write a function in your app to do it yourself?

157

Graphics / Shapes not scaling properly with resized window

« on: April 18, 2008, 06:00:28 pm »

There's not reason it wouldn't work, the code is common to all drawables. I suspect your variables to be in window coordinates rather than in view coordinates, which would explain the result.

Yep, I was doing something retarded.  Apologies.

158

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;
}


159

Graphics / Why is SFML in Debugconfiguration so slow?

« on: April 04, 2008, 04:07:10 pm »

yes

@quasius: 18 fps in a small one layer map. There'll be more layers, bigger maps and some movement.

Re bigger maps: That shouldn't make a big difference if your code is smart.  Are you culling off-screen objects?  If it's still slow, consider using some kind of quad-tree structure (dividing all objects in the map into "zones" so you don't even have to look at objects outside of your current "zone") instead of doing an on-screen test for every single object.  If your talking about ginormous maps where memory becomes a constraint, you will need to do some kind of streaming or make the maps smaller and link them.
Again, debug is supposed to be slow.  When I was working in professional game dev, I was working on an engine that effectively *didn't run at all* on debug.  It sounds like you're worrying about something that really isn't a problem.
If you really think your code is running too slow, the problem likely isn't SFML.  How old is your dev machine?  Are you running innefficent collision detection?  Did you do something stupid like pass an stl::vector by value in a critical loop?  Are you misusing stl::vector by constantly inserting/removing items to/from the middle?  Are you over-manipulating memory?  Anyone of these things can tank your FPS, so it's really hard to answer a question like "why is it slow?"
But again, it sounds like you really may have no problem at all other than not understanding how slow debug mode is.

Edit:  If you're really worried about this stuff, get a hold of and figure out vTune.  It can profile your code and tell you what's eating all the clock time.  You shouldn't need to worry about the 3DAPI side of things (which has it's own profiler apps) since SFML is taking care of that.

160

Graphics / Re: Why is SFML in Debugconfiguration so slow?

« on: April 04, 2008, 04:52:51 am »

Hi
I recognized that I have a about 15 times faster output when I compile in Release mode, so debug mode is way to slow to debug what I'm doing.
(about 530 fps when showing nothing in both mode, a really small map 32*32 px per tile and 20*15 tiles(always the same tile) has about 18 fps in Debug mode and about 275 fps in Releaseconfiguration)
Is there a way to speed it up?

Run it in release mode?  Debug is always slower.  Depending on what your doing, possibly much much slower.
What can you not debug at 18 fps?  You don't really need a silky frame rate to see if it's working.

161

Graphics / Internal image storage question

« on: March 28, 2008, 09:18:06 pm »

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?

Except that it's left-to-right, yes it is. SFML uses a unique internal representation for textures, it's not going to change. So you can safely rely on it.

The transparent pixels seem to be RGB0, not 0000- at least with .png.  I'll just check for the A byte being 0.

Edit:  It would still be nice to have a consistent pattern to transparent pixels, in case A is 0 for some other reason, but I guess it doesn't matter for my current use.

162

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.

163

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.

164

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?

165

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.