Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

2D All the way! / Extremely large sprites and practicality

Author
Message
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 2nd May 2009 13:48
Link
I'm in the process of making a fighting game similar along the lines of Street Fighter or Mortal Kombat with a friend. Now, each character needs about 180-200 frames of animation. And my friend, the animator, wants 512x512 32-bit colour frames.

I've said this is nonsense. 180 frames at 512x512x4 is the best part of 180Mb. There's no way that would fit into quite a few users' system RAM, let alone their video RAM.

It's got me thinking; as I'm using OpenGL, would there be a huge performance impact if I were to load the sprites into a RAM buffer, and then when an animation was required copy the needed part of the spritesheet into a seperate buffer which would then be loaded into OpenGL? It's the only way I can think of doing it. The problem is that this means copying a whole megabyte into a buffer and then onto the card for EVERY frame EVERY time the animation changes.

Other than chopping down to 256x256 or 128x128 which wouldn't look as clean on a big screen, what else can I do?

Back to top
Profile PM Website
MSon
19
Years of Service
User Offline
Joined: 13th Jul 2004
Location: Earth, (I Think).
Posted: 2nd May 2009 13:52 Edited at: 2nd May 2009 13:53
Link
I had a problem with large spritesheets in DBPro ones, i sepperated the seperate animations to seperate spritesheets, and loaded the new Spritesheet as needed, So you would have one for walking, one for jumping, one for fireing, ect, But that was on an old system so it paused for a fraction when it loaded, but computers have gotten faster since then, so i dont know if this would be a usable option for you now.

Everyone Be Cool, You, Be Cool.
Back to top
Profile PM Email Website
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 2nd May 2009 16:12
Link
Had a bit of a brainwave, actually; GLFW has multithreading. If I load the whole spritesheet into RAM in individual 1mb frames, whenever I want to change texture I can start a new thread which loads the frame into OpenGL in the background and then change to the new texture when it's ready.

Back to top
Profile PM Website
Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 12th May 2009 18:29
Link
If you consider that the 180mb is the lions share of your media, I'd say let your artist run wild. Giving him/her that freedom will only maximize the quality of work you'll get from them - and if the game looks good, then a 250mb download is not a big ask. Having a demo with just 2 characters shouldn't be too big for most people, and if they like it they will take the time to download the whole thing.

If you were using DX, then I'd be suggesting that you use .DDS files, these compress nice and small and load right in, is there any alternative in OGL for compressed textures?


Health, Ammo, and bacon and eggs!
Back to top
Profile PM Email
Diggsey
18
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 12th May 2009 18:42 Edited at: 12th May 2009 18:42
Link
Seeing as most of the frame will be transparent, the file should compress well using png or dds to around 300kb each. (53 MB for 180, which is not too much) If that is still too much, halving the image dimensions to 256x256 would not be that noticeable if you scale it up again, and the file size would go down to less than 100kb each (17 MB for 180, which is nothing!)


New DBPro IDE + integrated debugger!
Back to top
Profile PM Email Website
wildbill
18
Years of Service
User Offline
Joined: 14th Apr 2006
Location:
Posted: 12th May 2009 19:07
Link
Quote: "
I had a problem with large spritesheets in DBPro ones, i sepperated the seperate animations to seperate spritesheets, and loaded the new Spritesheet as needed, So you would have one for walking, one for jumping, one for fireing, ect, But that was on an old system so it paused for a fraction when it loaded, but computers have gotten faster since then, so i dont know if this would be a usable option for you now.
"

What I did was to make several hidden sprites of the character and show the one that was currently active. It worked great and had a low overhead, because the sprites that are not being used are hidden.
Back to top
Profile PM Email
NeX the Fairly Fast Ferret
19
Years of Service
User Offline
Joined: 10th Apr 2005
Location: The Fifth Plane of Oblivion
Posted: 12th May 2009 21:29 Edited at: 12th May 2009 21:36
Link
I've implemented it with multithreading but the lag is pretty unacceptable, mostly because GL has to wait for an opportunity to load the texture into VRAM between frames. The sprite loads from the main sheet into a small single frame buffer in next to no time at all, but then the operation to load it into the card can take anything from 10 to 300ms on my test systems. I might try to make it predict the next frame and load it before it is to be displayed but whether that will actually work or not I don't know.

It also crashes quite often.

Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-04-26 17:41:29
Your offset time is: 2024-04-26 17:41:29