Game Graphics: Raster -vs Vector

[Mastese]

I've done quite a bit of research on the differences between Vector and Raster graphics in conjunction with Flash-based games. More specifically looking at how each differs in their ability to impact overall Flash-gaming performance. When speaking in terms performance, I'm talking about raw speed (and consistency thereof) as well as the handling and responsiveness of onscreen objects.

So here's what I think I think I know:


Vector graphics provide the benefit of much smaller file size and flexibility in scaling but can hinder on-screen performance. The performance hit is due to the repetitive calculations required each time an object is moved or with the passing of each frame.
Raster graphics provide the benefit of on-screen responsiveness and speed, however are much larger in file size and will increase initial pre-load requirements. As well, they are limited in scalability without an associated quality hit. But because raster graphics do not require the repetitive calculations that vector graphics do, they ultimately free up cpu resources making them faster.
So I'm just looking for some clarification or validation on this theory from anybody who's in the know. Can anybody tell me if the above is true? If it is, then for an action-based, arcade style game, I should lean towards raster, not vector graphics for the overall performance gain. It does me no good to design a game that ultimately lags or slows due to over-utilization of vector graphics.

[Rossman]

I thought vectors were WAY faster than raster graphics. I could be wrong, though.

[Mastese]

Well, I think that depends on what you're talking about.

Vector graphics, since they are based on mathematical calculations, are small, and fast to download.

But raster graphics, which are based on individaul pixel placements, are larger, heavier and slower to download.

But, that's not what I'm looking at. I'm looking at their overall performance once loaded into memory.

From what I've read, a vector graphic has to be recalculated time and time again; every time the image needs to be refreshed or moved. Whereas the raster graphic, once loaded into memory, is what it is. No further calculating or reloading needed.

But I could be wrong, which is what I'm trying to figure out.

[Rossman]

I'm pretty sure the Flash Player engine is optimized for vectors, which is why I believe them to be much faster than raster graphics. If you were writing something in C++ or whatever, the situation is completely different.

But, I am sure there is someone out there who knows more about Flash than I and can answer your question better!

[senocular]

It all depends on size and quality. Vector graphics can be faster and they can also be slower. Generally, though, for any decent amount of detail, you'd want to keep to raster images. However, for best performance, you'll want to make sure that the area of change in your Flash document is as small as possible. This means favor static backgrounds vs scrolling and try to make your game as small as possible while still playable (if you want to maintain performance)

You more or less had it with your first post Mastese

[Rossman]

And the master speaks! ;)

[mixedtrigeno]

guys dont brake your heads :nurse:

big images like:backgrounds, buildings etc.-jpg or png(preferly png maintains a high quality at a small file size great for scrolling even with games that are graphics heavey)
items/weapons and such:pixel art or gif(i prefer gif or you can just do them in flash and publish in png format as long as you are good at it)

[nih]

In my experience, for raw speed it goes like this:

No transform: Bitmap wins. Actually, 1-bit alpha bitmaps win. 8-bit alpha PNGs are often slower than Vectors, but not always. You'd really need to fill the screen with objects to even notice this though.

Tinting: vectors win hands down. Tinting bitmaps is very, very slow, and the tint seems to be re-calculated on each frame. For obvious reasons vectors take no speed hit at all here.

Transformations: vectors maintain the same speed if the dimensions of the transformed object is about the same. Bitmaps slow down a bit. Not much though. Transformations are more or less negligible.

Complexity: Obviously bitmaps don't have complexity, but vectors do. It's worth mentioning that complexity doesn't make a big difference to vectors. I've been using Swift3D to generate and compare a 50k vector animation to a 5mb one, both with about 90 frames. Almost no difference in playback.

Size: Here's where we see a huge difference. There are two ways of approaching this for both vector and bitmaps.
For vectors, a small complex object is fine, but a large complex object will cause problems. Large simple vectors also cause issues, but not quite as much. The differences related to complexity are negligible.
For bitmaps less pixels is better, no matter how it's scaled. a full-screen bitmap will be slow, but a bitmap 1/2 that size scaled to fullscreen will perform much better.

I found with sizing that large vectors are the best way to cripple a movie, right after tinting bitmaps or transforming a very large bitmap. Just having them on screen slows it down.

Alpha: No idea here. A PNG with an 8-bit alpha mask probably won't take any speed hit from being made 50% transparent, but a 1-bit alpha'ed image probably would. I'm uncertain as to how a vector would perform.

The final thing worth mentioning is that with vectors you can always switch to low quality if you need more speed. There's no real noticable improvement when you do this with a movie full of bitmaps, although they tend to look a bit worse and move off their alignment.

[Marz]

http://www.kirupa.com/forum/showthread.php?t=17698

I touched on the subject here for Flash MX. :)

[ArchitectOfEvil]

In my understanding, for raw speed it goes like this:

No transform: Bitmap wins. Textures can take advantage of hardware acceleration (if available). Vector involves drawing lines, no hardware acceleration.
Textures are buffered and enable you to basically just copy from here to there.
Vector graphics must use a fill function to color it.

Also, as a consequence, vector graphics obviously is not feasible if you want complex color schemes.
If we talk about a polygon with a single color fill, then vector graphics may have similar efficiency, maybe better I don't know.

Transformations: Vector wins. Vectors maintain the same speed if the dimensions of the transformed object is about the same. Bitmaps slow down.

Transformations are "not" negligible.
Think about it. Normally you just retrieve the pixels and blit them. With transformations, there are extremely many more calculations that must be performed to rotate and scale a texture (every bit of it).

So with raster bitmaps, rotation and even scaling takes extra calculations.
Every pixel in the bitmap must be transformed. The new bitmap may have different dimensions to the original. The extra pixels will have to be filled with your transparency color so they don't appear.
Vectors are always performing these calculations, but not on every pixel.
Vector graphics only need to transform the vertices, and drawing is done with line drawing between every 2 points, then it uses the same or similar fill function to fill the vector graphic.


Complexity: Obviously bitmaps don't have complexity, but vectors do. It's worth mentioning that complexity doesn't make a big difference to vectors. I've been using Swift3D to generate and compare a 50k vector animation to a 5mb one, both with about 90 frames. Almost no difference in playback.This is wrong. Actually I don't really know what you are saying.
You did not test it properly anyway.
What do you mean by complexity? It seems you are talking about the quantity of objects.
Either way, the more complex something is, the slower it gets. Are you saying that vectors take ZERO calculations? That's how it sounds. Try going from a 5mb to a 10mb, and then 10mb to 20mb. Then what happens? The 50k to 5mb is 10 times different. The 5mb to 10mb is only twice the difference in size, but it may do more difference to performance because you will eventually reach your computers limitation!


Size: Here's where we see a huge difference. There are two ways of approaching this for both vector and bitmaps.
For vectors, a small complex object is fine, but a large complex object will cause problems. Large simple vectors also cause issues, but not quite as much. The differences related to complexity are negligible.
For bitmaps less pixels is better, no matter how it's scaled. a full-screen bitmap will be slow, but a bitmap 1/2 that size scaled to fullscreen will perform much better.How can storing a bitmap at half size, and then having to scale it when you draw it be faster? It does not make sense.
If it is the exact correct size it is better! Then you can copy pixel to pixel, no calculation.
God!
... and, of course larger or more complex vectors, or bitmaps for that matter will perform worse than less complex ones. But that does not compare vector to bitmap.

The web page Marz has about optimisations in Flash is informative if you want to do vector graphics.

[justkevin]

From what I've seen, there are scenarios where one can be faster than the other. Bitmaps are much faster than vectors for simple, non-transformed blitting using copypixels.

I think the comment on scaling can be correct, because Flash seems to be able to scale fairly efficiently. So if you do all your bitmap operations at 256x256 and then scale up to 512x512, it will probably be faster than working directly in 512, but at the cost of resolution.

[mxrider108]

Umm... the posts you guys are talking about were written in 2005. Things have changed since then: there was no BitmapData or copyPixels() at that point.

[dandylion13]

Hey Guys.. just some observations:

Senocular encapsulated it best: Fewer small things, moving less = best performance. With either bitmaps or vectors, if you make Flash redraw the stage too much it slows down.

Bitmaps have no *mathematical* complexity. They're just boxes that store pixel data. Vector's are mathematical entities and therefore always processor hungry... I think that's what nih meant. (But it doesn't always mean bitmaps are faster, theyre often not, as nih explained very well... good explanations, nih!)

Alpha transparencies and text rendering are the kiss of death for performance... avoid them at all cost if you can!! :)

[ajcates]

Wouldn't it be smarter to just always use vectors.

And when you need to performance gain form bitmaps just draw the vector as a bitmap or you could even draw it out as a bitmap 1/2 the size and then scale it up(making it uglier but even faster). This also keeps file sizes small.

[ArchitectOfEvil]

Umm... the posts you guys are talking about were written in 2005. Things have changed since then: there was no BitmapData or copyPixels() at that point.

Yes I didn't realise how old the posts were.
I was talking generally also, not just about Flash. So, in my case I use C++.
Using C++, you have bitmap textures where every pixel can be accessed.
I don't really know Flash, but the concepts of vector and raster are the same.


I think the comment on scaling can be correct, because Flash seems to be able to scale fairly efficiently. So if you do all your bitmap operations at 256x256 and then scale up to 512x512, it will probably be faster than working directly in 512, but at the cost of resolution.Why would it be faster when you have to scale rather than just move/copy something?
I don't get what you are saying? Flash can scale efficiently?
It's not of complexity 0(1) to scale each pixel.

If scaling up, extra pixels must be created or averaged based on the original image, which is simplified if you stick to power of 2 textures. When scaling down, certain pixels must be discarded or maybe averaged.
Scaling is not trivial, though it seems so compared to rotation.
Yes, and you have quality loss. So it's just lose lose here....
Better to have the images made to correct/exact size and it is a trade off on memory. That is the problem, not speed. Using bitmap is faster but lots more memory is being used.

Obviously the game size will be larger with all those bitmaps, but the quality will be improved, and the performance assuming the PC has enough memory.

Getting pixels from a bitmap is an 0(1) operation per pixel.

[justkevin]

Why would it be faster when you have to scale rather than just move/copy something?
I don't get what you are saying? Flash can scale efficiently?
It's not of complexity 0(1) to scale each pixel.

I'm saying that depending on what you're doing, it may be faster to work on a 250x250 bitmap with a scaleX/scaleY of 2 then to do your work on 500x500.

For example, I'm working on something where there's a parallax layer that's scrolled as the viewer moves. Flash doesn't support scroll with wrap, so I'm doing the scrolling with a custom that copies segments of the bitmap to a buffer and then copies them back to the new position. It's much faster to do all the work at a small resolution and with the end result scaled.

[ArchitectOfEvil]

Hmmmm.
I suppose I don't really know enough about Flash..

[TOdorus]

I'm saying that depending on what you're doing, it may be faster to work on a 250x250 bitmap with a scaleX/scaleY of 2 then to do your work on 500x500.

For example, I'm working on something where there's a parallax layer that's scrolled as the viewer moves. Flash doesn't support scroll with wrap, so I'm doing the scrolling with a custom that copies segments of the bitmap to a buffer and then copies them back to the new position. It's much faster to do all the work at a small resolution and with the end result scaled.

And what would be the advantage of just prerender a scaled parallax tile using draw() and copypixel() them directly to the 500x500 bitmapdata?

[kadaj]

But you could cache the vector images as bitmap(raster images) once its loaded into the memory. In that way both, the file size gets reduced and there isn't any performance lagging.
More over according to me AS 3.0 (AVM 2) is really really fast. Way better than the previous version of the virtual machine.
I hear a lot of comments that flash is slow and lagging and buggy etc.
But most people might be referring it to older version.
I had made a fighting game using the street fighter sprites (5 characters) . Its however raster graphics.After adding high quality sounds, titles and credits (made from After effects which also raster) the original .fla file is more than 300mb
and the output AIR was 27 mb.
There wasn't any performance lag though. And it was my first entry to AS 3.0 programming.
I recommend using vector graphics whenever possible. If you find any performance lagging, go for raster. But most of the systems nowadays are having min 512 mb ram, and 1.8 Ghz processing power. So I don't think that will be a problem!

[ArchitectOfEvil]

And what would be the advantage of just prerender a scaled parallax tile using draw() and copypixel() them directly to the 500x500 bitmapdata?

I don't know about Flash... but I agree, this is my point basically.



But you could cache the vector images as bitmap(raster images) once its loaded into the memory. In that way both, the file size gets reduced and there isn't any performance lagging.

This is true, but it's sort of pointless thinking like this!!!
I don't think it's so easy to create a certain specific texture using vector graphics!
Do you?
Get what I mean?
How are you going to store every single pixel?
It's just going to be a vector with one color (is that what you mean?).. that's not really a texture. It's a box with a fill color.

Making raster images on loadup from vector graphics is not really feasible is it?
Or else wouldn't everybody just do that? A texture doesn't follow a pattern, every pixel is unique! (could be).

So what you said just does not make sense.

[TOdorus]

Making raster images on loadup from vector graphics is not really feasible is it?

That's what the draw() method (http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/display/BitmapData.html#draw()) is for. Just feed it a movieclip with vectors, bitmaps or even combinations and it will return you a bitmapdata of it. Sort of like a snapshot. I use this technique in Dawn of the Hulker for prerendering rotations and animations.


Or else wouldn't everybody just do that?

Now we're moving away from a rendering pipeline and have to look at the asset creation pipeline. Everybody would like to use the best tools for the job, so when an artist creates a texture or whatnot, it uses the tool it is most comfortable with. To create a texture, my guess would be that you'd use something else than a vectorart program, so an artist will probably deliver an asset in a raster form. Recaching that would be pretty pointless, so I guess that's why not everyone is doing it.

The irony is that I use a combination of raster and vector images in Dawn of the Hulker. I put them all in movieclips so the prerenderer doesn't know the difference and can all treat them as movieclips by using draw().

[Jurg]

From my experience, vectors are usually the faster way to go.

[HelgaValerie]

which one works better for appearanece?

[therobot]

which one works better for appearanece?

Really depends on the caliber of the artist producing the work. Both can look good, both can look terrible.

[TOdorus]

From my experience, vectors are usually the faster way to go.

Sure they load in fast, but they are a framerate killer. They're best for games with only a few sprites onscreen.

[rumblesushi]

As far as rendering speed, it's quite simple.

Simple vector graphics (ie very simple shapes) render faster than bitmaps.

Complex vector graphics (ie a proper vector illustration, comprising of several, or many vector shapes/colour) render MUCH slower than bitmaps.

[therobot]

Sure they load in fast, but they are a framerate killer. They're best for games with only a few sprites onscreen.

Jurg may have meant that vectors are are quicker to draw and program with, since that is pretty much what flash was built for.

Bitmaps may allow for faster rendering, but it's a topic that I wouldn't recommend for beginners.