<Start> <Intro> <Install> <Legal> <Screen> <Buffer> <Sprite> <Input> <Misc> <Debug> <Utes> <Author>
Performance

Increasing Speed

Most of the speed in your programs will be lost when the buffer you are drawing into is blitted to the screen, due to the slow nature of video operations. You can lessen the impact of buffer blitting in your programs by drawing as much as possible into a buffer before you update the screen. If you are drawing hundreds of dots or circles then you will gain a speedup by "batch copying" your updates rather than updating the screen after every drawing operation in your offscreen buffer.

Another way to speed up drawing to the screen is to only update those parts of it that have changed. This principle is known as 'dirty rectangles' and is particularly effective when you only have a few moving things on screen. The basic idea is to minimise actual video writes. Also, in some cases you may be able to draw some parts of the screen less often than others. If you want 30 frames per second of smooth scrolling action, no one will notice if you only update the scoreboard part of the screen twice a second. if the scoreboard is 1/5th of the screen this could speed up your program by 15-30%. You should consider optimising your blitting code on a target by target basis if you need absolute top performance.

Decreasing Memory

It is a good idea for both space and speed efficiency to only create a sprite system with room for as many sprites as you will actually use. It is also more efficient to limit the number of frames to the minimum you need to hold all of your frames, and keep SPR_MAX_X and SPR_MAX_Y as small as possible given your projects needs. This will keep down the amount of memory used by your program, limiting any paging that may occur, and giving other processes more RAM in multitasking environments.

The sprite code automatically minimises its memory usage according to the largest sprite frame in the system. if you will only be stamping or stencilling sprites, and not using the drawing/saving/restoring functions, then you can safely free all buffer memory used by the sprite system


Developers Note: There will be a function to do this eventually.


Buffers can also use a large amount of memory, so try to reuse them where you can, and free any structure (i.e. sprite system, buffer, image) as soon as you have finished with it. Good program design is the first step to a memory efficient program.

When you cut out your sprites remember to cut the minimum area around each one, as this means the library will do less work to display it. Use as few bounding rectangles as needed to outline your sprite for collision detection, as each rectangle uses more memory.

Next Section: Contacting the Author and Getting Updates

<Start> <Intro> <Install> <Legal> <Screen> <Buffer> <Sprite> <Input> <Misc> <Debug> <Utes> <Author>