Thus spake Don Holt: > Having done the same, but with 20/30 kb images, I can > say no, your going to have a big problem. > > 2 work arounds, but I don't think they'll work in your > case. Both are glorified bandaids and not very good. > > 1)In actual play it will take a little less, rather > than in developing the module. Add fewer cards, then > save the module. Perhaps restarting after every save. > > 2)Get a computer with more memory, and allocate more > to the java stack on startup. > > The solution (had I to do it over again, and I may > some day) is to use a background image for the face of > each card, enter the text as a property, and trim your > image to contain only the image specific to that card. > > The B5 module runs with about 400-500 cards (and a > palette of 2300) in play and each image is ~25KB. > > A game will almost always start with about 300-400 MB > and will increase to about 750 MB. I don't think that > the piece rotation algorithms are linear in their use > of space. Large images require a lot more memory to > manipulate. So at 80 KB an image, I really don't see > how you'd survive without 2 GB of memory or more. > --- alejandroanz <[EMAIL PROTECTED]> wrote:
The problem is that images are stored in memory uncompressed. The compressed, on-disk size of images isn't relevant for memory usage, only the resolution of images in pixels. One pixel will require 4 bytes in memory when the image is loaded. There's no way around this if you want the images to display quickly; the alternative would be to uncompress and decode images on the fly, which is rather slow last time I checked. (I may look into this again, however.) How large are your cards in pixels? -- J.
