The forums have permanently moved to forum.kirupa.com. This forum will be kept around in read-only mode for archival purposes. To learn how to continue using your existing account on the new forums, check out this thread.


Page 1 of 2 12 LastLast
Results 1 to 15 of 27

Thread: Game Graphics: Raster -vs Vector

  1. #1

    Game Graphics: Raster -vs Vector

    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.

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

  3. #3
    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.

  4. #4
    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!

  5. #5
    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

  6. #6
    And the master speaks!

  7. #7
    guys dont brake your heads

    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)

  8. #8
    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.
    Last edited by nih; March 3rd, 2005 at 09:56 PM.

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

    I touched on the subject here for Flash MX.
    aiMarz : v. 11.34c - Current Version

  10. #10

    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.

  11. #11
    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.

  12. #12
    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.

  13. #13
    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!!
    Last edited by dandylion13; November 4th, 2009 at 08:53 PM.

  14. #14
    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.

  15. #15
    Quote Originally Posted by mxrider108 View Post
    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.

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Home About kirupa.com Meet the Moderators Advertise

 Link to Us

 Credits

Copyright 1999 - 2012