Sign in to follow this  
  • entries
    42
  • comments
    61
  • views
    32733

Untitled

Sign in to follow this  
jjd

229 views

After my titanic struggle with libpng, I managed to make a small amount of progress. I can load an save images in a variety of ways, but reading and writing unknown chunks presented an insurmountable obstacle. Perhaps, I'll figure them out in the future. For now I'm content with the progress I've made.

I started working on animations. I've never done anything with animations. So in the spirit that I've approach the rest "where's my bone," I hacked the most naive approach I could imagine. So I just read in a text file that lists the images that should be used in a given animation. Something like


Images/Frame1.png
Images/Frame2.png
...

Then, each of the images was concatenated into one big image that shows the entire animation strip. DO NOT DO THIS IF YOU ARE USING OPENGL! I don't know if DirectX has the same restrictions, but this was a mistake in OpenGL because the dimensions, width and height, of the resulting image are not powers of two (except by luck). OpenGL doesn't like that. So with a three frame animation I ended up having white quads where my animations ought to be. That caused me some confusion. Anyway, the animation I made was a little tail wag that is updated each frame, so the little pup wiggles his tail very quickly (unless I maximize the screen... can anyone tell me why maximizing slows things down so much?)

So I got something to work - yay! It's always nice to get visible results [smile] But it was also clear by the end of my hackery that I need to put a better system in place. The three things I need to do now are:

  • incorporate a better way of scheduling and updating the animations
  • overhaul the AnimationManager because it is duplicating a lot of the work done by the TextureManager unnecessarily
  • Animation frames should be smaller. At the moment they are the same size as the whole puppy quad. It should be easy to use smaller frame sizes with an offset to achieve the same effect.



Sign in to follow this  


2 Comments


Recommended Comments

As far as I know, the power-of-two texture size restriction is dependant on the graphics hardware, not the API. With Direct3D you can query the device caps to see if a card supports non-power-of-2 texture dimensions.

I always assume that they don't though, since it widens the range of hardware the app will run under. I think such cards are on the way out though. I think this will become a relic like the old maximum 256x256 texture restriction that you pretty much never come across any more.

Share this comment


Link to comment
I read that there is an OpenGL extension that removes this restriction. It's not a restriction that bothers me greatly -- it's pretty easy to work within that constraint, but it's frustrating when you forget about it and don't put a check into the code >:(

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now