Thus spake Don Holt: > I looked at reimaging B5 cards (cut the image from > existing jpg's and resizing). The image is only 4-5 > KB. This would cut the B5 module size down to 10-15 > MB, and would make it play using much less memory.
Something I hadn't considered is that you have 400+ cards in play simultaneously. What's are the dimensions of the cards? (I assume that they're not token sized.) Here's (potentially) what the path from module to screen looks like for an image: 1. extract image from the module 2. cache the image 3. decode the image 4. cache the decoded image 5. manipulate (scale, rotate) the decoded image 6. cache the manipulated decoded image 7. paint the image to screen We don't do all of these things at present (e.g., we don't do #2), but in principle you could cache the result of any process in order to avoid recalculating the result, and you could cache it either to memory or to disc. Caching is a way of spending space to save time. Something we haven't looked at in a while is which steps consume the most time. Last I checked, extracting and decoding images (steps #1 and #3) together were too time-consuming to do frequently, hence the need to cache the decoded images. What I didn't check was what the balance was between extraction and decoding. If, for example, extraction is what's really slow and decoding is relatively fast, then it would be possible to stop caching decoded images (step #4) and cache the (much smaller) extracted images instead (step #2). > Now I just have to figure out how to overlay the card > image on the background. Could you describe in more detail what you're trying to do? -- J.
