frames or rotatation?

Discussion in 'Game Development (Technical)' started by Robert Cummings, May 25, 2006.

  1. Robert Cummings

    Original Member

    Joined:
    Apr 3, 2005
    Messages:
    1,155
    Likes Received:
    0
    Hi all,

    I've found I need about 128 frames to make things rotate really smoothly (it is not a symmetrical object in game) and is 128x128 pixels. This adds up to about 8 megs of video ram. Thats quite a bit... it looks lovely.

    On the flip side there is rotating in software (I am using SDL for this and SDL_GFX lib) however a strange phenomenon occurs - when it is rotated, it jitters a lot left and right. Quite horrible. Anyone experienced in SDL rotating care to comment?

    That said, do you consider 4-8 meg too much for a series of frames to be played in software? how about hardware?

    Thanks for your insight!
     
  2. J.A.W

    Original Member

    Joined:
    May 20, 2006
    Messages:
    9
    Likes Received:
    0
    Personally I prefer pre-rendered frames as you can tweak a frame if it looks dodgy and can add shadows on the object itself, but obviously this uses more mem than a single frame rotated. For a single object 8MB I would consider pretty big, unless this is your primary sprite in the game (ie. the player)? How many actual different colours does it need? perhaps you could 256 colour paletize it? which would then only use ~2Mb.

    Dunno how SDL does rotation, but if its using nearest pixel sampling it will look a bit naff. ;)
     
  3. MibUK

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    84
    Likes Received:
    0
    By rotation, I assume you mean rotation in 2D, around the Z axis.. (for example, rotating a sprite to point in the direction of travel or something).

    If it takes 128 images to have 360 degrees rotation, you can apply a couple of basic systems to free up some space.
    Depending on how your image looks, if your image is flippable, you can reduce to 1/4 images by only doing the rotations between 0 and 90, then using a flip on X and Y axis to make the images for the other 270 degrees as transforms on the 0 to 90.

    I.e. if you have a top down view, you can do an image that points up, and up right. to get the down and down left, you apply a flip on the X axis.
    You can then rotate by 90 degrees and repeat and you'll get 8 directions from just two images.

    If you object looks differant from all directions then you wont be able to use this technique, but I get the feeling from your post that rotating would be possible.

    Rotating by non 90 degree amounts is going to affect the width of your image. You can work this out by cutting out a piece of paper, and physically rotating it. As you rotate it from 0 to 45 degrees, the bottom left point will push out to the left of the image.
    Most image rotation algorithms generate a bigger picture, with transparent sections, so that it doesn't cut any section of the original image off.
    You should be able to use a sine function to calculate how much bigger the rectangle is going to get.
    Alternatively, I think that when I last used SDL there was a way to specify rectangles for images with the middle rather than the top left as coordinates for blitting.

    If that explanation didn't make sense, let me know and I'll try again! :)
     
  4. Hamumu

    Indie Author

    Joined:
    Jul 26, 2004
    Messages:
    557
    Likes Received:
    0
    Why not 32 frames (or probably 16 is plenty), and then use sprite rotation to interpolate between those? I don't know if that would work well or not, the shadows might change too much. But rotations shouldn't look so ugly - I know nothing of SDL, but PTK (i.e. OpenGL or DirectX and textured polygons, doesn't have to be PTK at all) does it very smoothly.
     
  5. Adam

    Original Member

    Joined:
    Oct 13, 2004
    Messages:
    34
    Likes Received:
    0
    A 128*128 image won't have an exact center pixel. So that might cause a slight jitter when rotating.
     
  6. Ryan Clark

    Indie Author

    Joined:
    Oct 29, 2004
    Messages:
    656
    Likes Received:
    0
    If you're just doing this for one game object, then 8meg of RAM/VRAM isn't very much, in my books. And it'll look really nice... as someone said, you can have pre-rendered shadowing included in each frame.

    But if you'll have to do it for all of your game's sprites, then you might start to run into memory trouble.
     
  7. Robert Cummings

    Original Member

    Joined:
    Apr 3, 2005
    Messages:
    1,155
    Likes Received:
    0
    Thanks all, some very good ideas and discussions. Its just for a creature but there will be more than one of them on screen.

    Its a regular thing in the game. I'm really worried about download sizes too. I guess 8 meg is a lot!
     
  8. Fabio

    Original Member

    Joined:
    Sep 30, 2005
    Messages:
    499
    Likes Received:
    0
    Store only one on disk and then generate all the rotated frames algorithmically..

    If you are using some ultrahighquality algorithm (e.g. sinc interpolation) then do it only the very first time the game is run, and cache the generated frames on disk for future use. Or, even better, if you have a custom installer, do it there.
     
  9. sulaiman

    Original Member

    Joined:
    Aug 2, 2004
    Messages:
    20
    Likes Received:
    0
    This jittering is caused by the resulting image being a different size when sdl_gfx rotates the original image. For example a 5x5 image when rotated 45degrees will result in a 7x7 image.This causes the center of the resulting image to change from the original(when using the same destination blitting coordinate).

    What you need to do is apply an offset to the destination blitting coordinate. This offset is equal to the difference of centers for the two images.

    Set destination coordinate for blitting
    dest.x = 23;dest.y = 100;
    Apply offset
    dest.x+=(original->w - rotated->w)/2;
    dest.y+=(original->h - rotated->h)/2;
    or put another way
    dest.y += (original->w/2) - (rotated->w/2);
    dest.y += (original->h/2) - (rotated->h/2);

    Hope you understood that:)
     
  10. gosub

    Original Member

    Joined:
    Sep 10, 2005
    Messages:
    151
    Likes Received:
    0
    I second that. Rotate a 512x512 bitmap, then scale it down to 128x128 with anti-aliasing. Additionally, instead of storing 128 pictures, just store 32 for the first 90 degrees, and rotate by 90, 180, and 270 for the other angles. Also, if the images are symetrical, I think you can get away with only 16 images if you mirror them (vertically and horizontally).

    -Jeremy
     
  11. Michael Flad

    Indie Author

    Joined:
    Aug 4, 2004
    Messages:
    190
    Likes Received:
    0
    Should be a simple decision. Using software rendering you'd for sure have the image on a sysmem surface, so if that'll be ok it should be as ok to have the prerotated images in sysmem to. Softwareblitting without rotation won't be any slower than with rotation.
     
  12. J.A.W

    Original Member

    Joined:
    May 20, 2006
    Messages:
    9
    Likes Received:
    0
    "Softwareblitting without rotation won't be any slower than with rotation."

    Straight software blitting from pre-rendered frames will be much faster than a software rotation (you then got to blit the rotated sprite anyway). Also mirroring and 90, 180, 270 rotates should be extremely fast compared to rotating by some arbitrary angle.
     
  13. Michael Flad

    Indie Author

    Joined:
    Aug 4, 2004
    Messages:
    190
    Likes Received:
    0
    Obviously, but my main point for this case was, as soon as it's at least not slower, it doesn't matter if prerendered images would take a lot of graphicsmem when a fast enough alternative would be putting an image in sysmem and doing software rotation.
     
  14. Robert Cummings

    Original Member

    Joined:
    Apr 3, 2005
    Messages:
    1,155
    Likes Received:
    0
    Thanks to everyone who replied. I decided to go with 128 pre-rendered frames which were palettized so the final file size is only 700k.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer