Skip to main content
gamedev.net
🔒 Locked

[MDX] Sprite Performance

Started by phb5000 8 replies 1.2k views
Original Post
phb5000
phb5000
Im building a GUI system. My controls consists of several "parts" so that they can be resized. Each part is drawn using the Sprite class: Sprite.Begin() Sprite.Draw(Part1) Sprite.Draw(Part2) Sprite.Draw(Part3) Sprite.Draw(Part4) Sprite.Flush() Sprite.End() However, im experiencing weird performance issues. Is it a bad idea calling the Draw method for every part. How can I improve the performance? It would seem a lot better to somehow combine all the parts into one Draw. Should I not use the Sprite class?
Scet
Scet
For my game Snake.Net I was drawing about 1500 tiles per frame. In debug mode I would usually only get about 20FPS, in release mode though it would be the normal 75 and in immediate / release mode about 400FPS. However I only had two Begin calls and only one of those had alpha blending.

How many of these controls do you having going and are you compiling in debug mode?

Also you should definatly use the Sprite class, it's the best way to do anything 2D with D3D. I don't know why people say it's slow, you won't find anything faster.
phb5000
phb5000
I tested in Release mode:

20 controls, each with:
- 5 Sprite.Draw calls (3 different textures)
- 1 Font DrawText call

At around 220 fps
Without Text: 250 fps)


I'm just making sure Im getting a good a possible fps, currently my cursor renders dependently of the FPS.
Staffan E
Staffan E
Earlier when I was benchmarking the Sprite class (or rather the unmanaged ID3DXSprite interface upon which it is based) I found that using Sprite gave the same performance as making one DrawPrimitive() call for every texture drawn, which is as fast as can be done manually. The primary limit to my Sprite performance was the maximum fill rate of the video card, i.e. the maximum numbers of pixel writes per time unit. So there would be nothing slow about Sprite that could be made better by drawing manually, at least if you're using the same functionality.
Hack my projects! Oh Yeah! Use an SVN client to check them out.BlockStacker
phb5000
phb5000
Thats good to know!
Thanks for the info :)
phb5000
phb5000
Okay, back to some sprite perfomance questions.

I have a problem that is Killing me!

When I call the Draw2D method of a sprite WITH a new Size (So that it stretches) it renders with blur around it. The blur is like a gradiant towards the pixels around the Rectangle that i specified. However, this only happens when the new Size's width and height arent equal.

How can I stretch a sprite (but only for example the width)???
Staffan E
Staffan E
Have you made sure that the dimensions of the textures you are using are powers of two, i.e. 128, 256, 512, etc.?
Hack my projects! Oh Yeah! Use an SVN client to check them out.BlockStacker
phb5000
phb5000
Yes, everything should be ok with the texture loading. My textures are ^2 and rendering without a size change works correctly, and rendering with an equal size change works correctly (size width = N & height = N).

Its just when I stretch it unequally that I get some weird blur from surround pixels :S

There must be some way to just simply Stretch the image. No advanced filtering or alpha blending. Just a simple pixel stretch :S
Jonas B
Jonas B
The interpolation routine might not clamp around the source rectangle boundary, but use adjacent texels as well.

Dunno if there's a way to force clamping, but if you're using fixed rectangles in the source texture (e.g. a tileset) an alternative is to add a 1-pixel border around each rect that duplicates the pixels *on* the border when you're assembling the texture.
phb5000
phb5000
How can I load a region of a texture (just like the sprite class does). If I load the part outside the sprite class than when I render using the sprite it wont have to cut out a region there, and may not cause the blur.

Can I use the TextureLoader.FromFile() override with the Width and Height parameters?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.