Re: How do I put a sprite into a dynamic area ?
- From: Andrew Hill <user@xxxxxxxxxxx>
- Date: Sun, 01 Feb 2009 21:11:53 +0000
Martin Hansen wrote:
Dear All,
Thank you very much for the time you've taken over getting me up to
speed on this topic. My application is working just as well from its
dynamic area as it previously did from its Wimp slot, but now it's not
restricted to < 28MB on the Risc PC & Virtual Acorn emulator.
My worries over 'protecting' my dynamic area stem from all the stuff
about system messages in the PRM suggesting that my allocation might
be taken away from me - PreShrink, PostShrink, Service_PagesUnsafe
etc, all of which I found confusing. (as a newcomer to the topic with
a weak grasp of what some of the terms being used meant)
They're basically for use if you wanted to use the Dynamic Area to be resizeable and behave like a cache in a similar manner to the Font Manager.
What the Font Manager does (approximately) is to cache a lot of its images into the font cache. However, the Task Manager shows the font area's dynamic area as red meaning 'resizeable'. When you resize it, these calls are used to allow the font manager to choose how to rearrange its memory before and/or after the memory has been reduced in size, to make sure that it keeps the most useful bits.
At its simplest, if you wanted to just store your application's data in it you want to use a non-resizeable dynamic area into which you load the entire file. The user can't interfere with the size, and you have fewer headaches. BUT - you've taken a great big chunk of memory up, and restricted the user to only using files that are smaller than the amount of memory in the machine.
You might later want to speed up the application, or allow it to use significantly less memory. As I understand it your application is going to load up multiple images from a sprite file? So in this case if you had lots of very large images in there you might want to load just one up at a time into the memory area. Saves a lot of memory, but would be significantly slower.
A better solution but more complex is to make the area resizeable, with a minimum area size of the largest sprite in the file. If you have more memory than the minimum free, you see if you can fit in more images, and then load in images immediately before and after the one you're using (assuming you can view two-way, otherwise just following images if just one way).
The more dynamic area you have allocated, the more sprites you cache, and the faster the application runs. Run out of memory? No problem - just allow the user to dump some of your cache and trade performance.
When you show a new sprite, you would then want to dump your 'used' images (or the images least likely to be needed soon,) and update your cache with the next best images.
Best wishes,
Drew
.
- Prev by Date: Re: Adding functionality to ARM BASIC
- Next by Date: Re: Adding functionality to ARM BASIC
- Previous by thread: Passing a message between WIMP applications
- Next by thread: Canonicalising filenames
- Index(es):
Relevant Pages
|
