Sprite Rendering, bit blitting, and other questions

[Cyrano]

SFML is a fine library, but once again, I have some questions regarding one of its core areas: Sprite manipulation.

My Questions:

What is the fastest way to render a sprite? (I'm not entirely sure what people on this site mean by "render"; from what I understand, it's fairly similar to bit blitting.)

What's the deal with "arrays of pixels?" I keep seeing this term, but do not fully grasp what it means. Is it perhaps referring to all the pixels in an individual image?

Why do some people say bit blitting is slow? Is there some faster method I was not aware of?

What is the screen tear effect? Is this the phenomenon that occurs when update cycles are faster than the monitor's refresh rate? (Dumb question, but I just want to make sure I get it). Is there a way around it?

Can a screen (game screen) be updated in part? (Ex: A character sprite is updated, but not the whole background with it.)


These are some questions I've wanted answers to for a while, but did not know whom to ask. I put all these questions together so that I don't have to spam other people's topics or create a bunch of topics of my own.

Thanks in advance. Happy programming!

-Cyrano

[Ashenwraith]

Modern graphics hardware is mainly about geometry, pixel data, and buffers.

Blitting the entire screen is slow because you are copying all of the screen pixels and sometimes even editing them depending on what you are doing.

Modern blitting can still be achieved with pixel array transformations, but you want to blit the least amount for performance so you would only 'blit' part of a sprite instead of the whole screen. In most cases you do not need to blit unless you are doing something fancy like a pixel shader.

The fastest hardware techniques for rapid drawing are volatile, meaning they destroy or flush your screen and then quickly rebuild it again at a constant rate. This is the opposite to software blitting which is like going in like a surgeon and cutting pixels out and moving them around on a static image.

[Laurent]

What is the fastest way to render a sprite? (I'm not entirely sure what people on this site mean by "render"; from what I understand, it's fairly similar to bit blitting.)

"Render" just means "draw".
There's only one way to render a sprite in SFML, so there nothing much to discuss about it.

What's the deal with "arrays of pixels?" I keep seeing this term, but do not fully grasp what it means. Is it perhaps referring to all the pixels in an individual image?

It refers to a bidimensional array of pixels (32-bits RGBA colors), usually the pixels that define an image or a portion of it.

Why do some people say bit blitting is slow? Is there some faster method I was not aware of?

Bit blitting is completely deprecated with today's hardware. The most efficient way of drawing things, even 2D geometry, is to create geometry made of triangles, map some texture on it and send it to the graphics card.

What is the screen tear effect? Is this the phenomenon that occurs when update cycles are faster than the monitor's refresh rate? (Dumb question, but I just want to make sure I get it). Is there a way around it?

You can enable vertical synchronization to solve this problem (see sf::Window::UseVerticalSync).

Can a screen (game screen) be updated in part? (Ex: A character sprite is updated, but not the whole background with it.)

This is not a good strategy, you should always clear and redraw the entire scene.

[Cyrano]

What is the fastest way to render a sprite? (I'm not entirely sure what people on this site mean by "render"; from what I understand, it's fairly similar to bit blitting.)

"Render" just means "draw".
There's only one way to render a sprite in SFML, so there nothing much to discuss about it.

What's the deal with "arrays of pixels?" I keep seeing this term, but do not fully grasp what it means. Is it perhaps referring to all the pixels in an individual image?

It refers to a bidimensional array of pixels (32-bits RGBA colors), usually the pixels that define an image or a portion of it.

Why do some people say bit blitting is slow? Is there some faster method I was not aware of?

Bit blitting is completely deprecated with today's hardware. The most efficient way of drawing things, even 2D geometry, is to create geometry made of triangles, map some texture on it and send it to the graphics card.

What is the screen tear effect? Is this the phenomenon that occurs when update cycles are faster than the monitor's refresh rate? (Dumb question, but I just want to make sure I get it). Is there a way around it?

You can enable vertical synchronization to solve this problem (see sf::Window::UseVerticalSync).

Can a screen (game screen) be updated in part? (Ex: A character sprite is updated, but not the whole background with it.)

This is not a good strategy, you should always clear and redraw the entire scene.

Thanks! I was wondering about those things.

I have another question though:

How do I use that "geometry of triangles" you mention? (I'm assuming you are referring to something like a gourad shader?) I'm only using 2D art, and have no use for 3D figures. If it helps, I'm designing and programming a 2D side-scroller game (think mario). I want to use high quality graphics, but I also want high performance too. That's why I was asking if there was a faster way to accomplish bit blitting.

Thanks again!

-Cyrano

[Breakman79]

How do I use that "geometry of triangles" you mention?

You don't need to.  All of the complicated opengl calls for binding the textures to quads for 2D rendering are nicely wrapped up in easy to use objects and methods.  

I suggest taking a look at Drawing Sprites tutorial and the source code example it provides.

[Laurent]

If you use SFML you don't need to ask this kind of questions, just use the API and it will take care of all the low-level details for you.

[Cyrano]

You don't need to.  All of the complicated opengl calls for binding the textures to quads for 2D rendering are nicely wrapped up in easy to use objects and methods.  

I suggest taking a look at Drawing Sprites tutorial and the source code example it provides.

Thanks for the link, it looks good from what I saw.

So if you bind a texture (which seems to be akin to an image ".gif, .png, .jpg, etc.") to quads (some form of coordinates? like x and y perhaps?), that simply  means that you have attached coordinates that can be manipulated to an image?

Answers appreciated!

-Cyrano

[Ashenwraith]

Read and do the NeHe opengl tutorials.

Then come back and do the sfml tutorials.

You can talk about basics all day long and not understand anything because it's meaningless since you have no where to start from.

[Cyrano]

Read and do the NeHe opengl tutorials.

Then come back and do the sfml tutorials.

You can talk about basics all day long and not understand anything because it's meaningless since you have no where to start from.

Sorry, I don't do OpenGL at this time.

I don't need to render 40 gazillion polygonal, gourad-shaded, light and bump-mapped sprites. All I need are the tools to quickly take 2D images from image sheets and put them on a screen. That's why I haven't really looked into OpenGL. I expect it probably has most of the functionality I'm looking for, but I have been under the impression that it is not the easiest API to learn. I've got other things to do with my life than program, so I don't want to spend half of my programming time sifting through loads of documentation just for the few graphics functions I need.

Still, it could save me a lot of trouble...

I'll consider it.

-Cyrano

[Breakman79]

Actually, you don't need to know any OpenGL to use this library to make a 2D game.  

It's just that this library is built on top of OpenGL though so it creates a 2D scene by mapping your images to a texture that is applied to a flat polygon which is then drawn by your 3D video card.  This allows all of your sprites to be hardware-accelerated and thus freeing up your CPU for other tasks.

Works wonderfully for things like alpha-blending and lighting which were extremely slow and CPU intensive with the old blitting way.

[Cyrano]

Actually, you don't need to know any OpenGL to use this library to make a 2D game.  

It's just that this library is built on top of OpenGL though so it creates a 2D scene by mapping your images to a texture that is applied to a flat polygon which is then drawn by your 3D video card.  This allows all of your sprites to be hardware-accelerated and thus freeing up your CPU for other tasks.

Works wonderfully for things like alpha-blending and lighting which were extremely slow and CPU intensive with the old blitting way.

Thank you!

[Ashenwraith]

You do realize you have to write an entire engine with animation, timing, and collision at the minimum? That is unless you are writing a complete turn based/non-animating game.

Doing an OpenGL tutorial is like a breeze in comparison.

[Cyrano]

You do realize you have to write an entire engine with animation, timing, and collision at the minimum? That is unless you are writing a complete turn based/non-animating game.

Writing an engine will be the fun part for me (I already am laying the groundwork for one). Animation, timing, and collisions are areas I'm much more familiar with. Figuring out rendering calls, however, will not be pleasant, as I have virtually no experience with rendering code. I feel fairly confident about the other areas, though.

Doing an OpenGL tutorial is like a breeze in comparison.

Well, I'll take that into consideration, seeing as Ashenwraith appears to favor it highly.

I've got some great ideas, but I'll just have to see how OpenGL will work with them before I go full bore on this.

-Cyrano