HGE

Since you're simply displaying them, I'd say you don't need to have your sprite sheet in a power of two. You simply need to make a number of sprite datatypes and specify them in the proper location on the sprite sheet.

You don't have to use power of two textures for that. It's a good habit to get into, but isn't necessary for what you're doing. I do the same for background images myself. If I'm running in 800x600, I'll typically use an 800x600 image for the background.

The only reason it throws off animations is because HGE auto-calculates the positions of the frames and doesn't know the image has been expanded. (Although it could know if it checked the original texture width/height instead of the in-memory width/height.)

[quote="ProfEclipse"]The only reason it throws off animations is because HGE auto-calculates the positions of the frames and doesn't know the image has been expanded. (Although it could know if it checked the original texture width/height instead of the in-memory width/height.)

This behavior has been fixed in 1.7.

I automatically do everything in power of two now anyway. The only real issue for me is that that HGE engine uses float types and not many numbers divide evenly into power of two so I'm stuck with not being able to put sprite frames how I want.

For example ifI have a sprite sheet 1024 by 1024 I can't have something like 7 frames wide by 5 frames deep because that would give me sprite frames 146.2857142... by 204.8 which is no good in a float.

I'm sort of stuck with using 4 by 4 or 8 by 4 or 8 by 8 or those sort of numbers. Still I've got used to doing it now. That may not seem like a big deal but it is when you animate big frames. My standard frame size is 512 by 512.

m0ng00se

Huh?

If there's not enough room at the end of a row, HGE automatically skips down to the beginning of the next row. It will never give you partial frames. So, you can have 7 frames wide by 5 frames deep. Each frame would be 146x204. Any fractional part would be wasted space on the right and bottom of the texture. You don't have to do anything special for that to work.

Do you think? I've never tried it because I was too pedantic about the fraction left over. It would add up over 16 frames I would have thought until by the end there'd be quite a bit out.

Some of my animations are very precise with no room at all for error. I can see that it wouldn't matter with a figure dancing for example but a static face that only has a blinking eye animation would move over 16 frames I would have thought or worse over 35 frames in the example I gave. That's why I only use dead exact numbers.

I'm very fussy with my animations. I spend hours on precise placement so muscles move correctly (eg a foot anchored precisely in one spot as the figure animates over 16 frames). I'm not saying you're wrong... I just never tried using frames that don't divide exactly as whole numbers into power of two.

m0ng00se

Ah I understand now... duh!
I was thinking I still had to divide evenly into 1024 (with a fractional result) but only give a whole number value to the float. You mean simply dump all the extra in a border at the end that isn't used.

You're right of course which means I can make them any size I want. How stupid of me. Well that suddenly makes life a lot easier and just in time for the 130 frame animation I finished rendering an hour ago.

m0ng00se

ProfEclipse, would you like a moderator rights in these forums?

haaf said:

ProfEclipse, would you like a moderator rights in these forums?

Sure. I spend enough time on here. ;)

Another moderator would be nice indeed.

ProfEclipse, would you like a moderator rights in these forums?

Sure. I spend enough time on here. ;)

You got it :D

I suddenly feel... powerful. :)

/me hopes haafs made a backup of the forum's DB :)

:twisted:

ProfEclipse...

I could not get your idea to work no matter what I tried. Using any frame size other than power of two (for individual sprites) and with some extra texture margin left over at the edges of the sprite sheet caused erratic behaviour everytime.

In the end I went back to power of two for everything (sprite sheet and the individual frames) and all the problems went away. It's not really an issue anymore because I have over 600 frames so far using 512 by 512 so I might as well just stick with what works for me.

m0ng00se

I've found that even numbered dimensions (not necessarily power-of-2) work better because you don't get floating point precision errors when HGE converts your texture coordinates to the 0.0-1.0 range that DirectX requires. You'll often get strange results when using odd dimensions because of precision errors.

You are probably right although I got the impression that it was the margin left over (to keep the sprite sheet power of two) that was screwing hgeAnimation. The errors weren't small. It would start skipping all over the sheet virtualy at random.

Anyway I'll troubleshoot it some other time when I'm not so busy. Power of Two works so I'll stick with it for my frames as well as the sheets.

m0ng00se

I'm pretty sure the margin isn't the problem, unless your margin is the same or larger than your frame size. I've never seen it cause a problem in my programs.

Okay I'l test it some more. I just made some major design changes to my game so I'd have a far bigger animation window so I might as well take a break for a week and test some of this stuff properly and work out just exactly what is going on.

Thanx if you say it should work then I believe you.

m0ng00se

Well, just because I say it should work doesn't mean it will work. :wink:

I haven't had any problems, and the code all looks right, but there still could be come cases that cause problems.

If your tests show any issues, we'll take a look at them and see if we can figure out what's going on.

It could take awhile because I've started incorporating 3D backgrounds into my animations which has kind of taken things to a whole new level and I have to re-render 600 frames as transparent *.pngs instead of *.bmps.

I just keep getting so impressed with what I can do with HGE just using very simple techniques.

m0ng00se