A n00b question, which is the better approach? :
I'm using SDL as my framework for graphics in a game I'm working on. I'm proting my Java game to PSP. And I'm curious about how to be most efficient with mem:
1. Should I continue doing what's mem efficient for J2ME application: To load the sprites as one big image, where each frame in the sprites animation is one section of the image, example: [1][2][3][4]...etc...
Or:
2. Can I do what is simplest in SDL, to just load each frame of the animation as a surface and hold them in an array?
Like this tutorial sample does:
http://cone3d.gamedev.net/cgi-bin/index ... fxsdl/tut6
I guess the argument would be that approach 1, loading all frames in one sprites animation as one surface would be memory efficient. But could cause slower blitting as it's a bigger surface? While approach 2. would be faster, but more memory intensive?
The tutorial I've linked to uses approach 1 for "fancy fonts", while it uses approach 2 for sprites.
Does anyone have a preference, or reccomendations?
How to make memory efficient and fast sprites?
Okay, nice to know. How about memory consumption. 10 small surfaces VS 1 big containing all 10 frames. "10" is taken randomly from thin air, it's different number of frames for each of the animated objects.Bytrix wrote:I don't think it would make a whole lot of difference, and as far as blitting goes, I don' think blitting a subsection of a larger image is any slower than blitting an image loaded by itself.
Its not going to make a difference on the PSP because I dont believe it has dedicated memory for surfaces. Its all just memory. Allocate it from anywhere and use it as a texture on a quad... Whether you use one big one or many small ones wont make a difference.
I suggest coding it in the most simplistic way possible. 20MB is a lot of memory to mess with when you are talking a tiny little hand held game. Your textures can be kept very small (We generally scale all textures down to 32x32!) but using mipmapping helps. Optimal texture size seems to be 512x256 when you need something really highres. You can hold 40 of these in memory at any time on the PSP. Thats crazy. :P If you get to the point where you need to start unloading/loading/requesting texture changes, then you can always reduce texture sizes by 1/4 first until you get around to writing a system for requesting texture changes.
I suggest coding it in the most simplistic way possible. 20MB is a lot of memory to mess with when you are talking a tiny little hand held game. Your textures can be kept very small (We generally scale all textures down to 32x32!) but using mipmapping helps. Optimal texture size seems to be 512x256 when you need something really highres. You can hold 40 of these in memory at any time on the PSP. Thats crazy. :P If you get to the point where you need to start unloading/loading/requesting texture changes, then you can always reduce texture sizes by 1/4 first until you get around to writing a system for requesting texture changes.