Mail Archives: djgpp/1997/06/01/02:43:30
I'm posting this mostly to hear my ideas on the matter spelled out and
to encourage others to put their 2 cents in. I'm probably eventually
going to try it, after I clear some other tasks. (A *lot* of other tasks
-- I never did have much sense about what projects to take on)
Recent discussion made me think about Allegro's sprite-stretching. It
seems to me that there is a major redundancy there in that multiple uses
of the same stretch routine recompile the same thing over and over.
One thing I'm doing in a mini-map with shrinks a grid of 64x64 32x32's
into 4x4's, which currently runs like molasses because the stretcher
rebuilds for every 16 pixels, and there are 64x64 bitmaps! It's so slow
you can easily see its progress with the naked eye. This is almost as
bad a case as you can get, I would think.
Would it be possible to simply split do_stretch_blit to separate the
stretch-compile functionality (make_stretcher and a lot of
do_stretch_blit) and the functionality that uses it (_do_stretch and the
rest of do_stretch_blit), so that a user desirous of speed can compile a
stretcher into memory that they control and pass that to _do_stretch?
There are more opportunities for error, of course, but speed has costs
like that.
At first I thought that there would have to be a lot of changes,
altering the interface to make_stretcher and to all of opcodes.h, though
only COMPILER_BYTE/*_WORD/*_LONG would need substantive changes, as
opposed to passing an address thru.
But then I realized a much easier approach, that also doesn't require
the user to guess, calculate, or overallocate the memory that's needed
is to compile into _scratch_mem as now, and then copy that result into
allocated memory.
Fortunately, the length of the block is kept up to date almost all the
way to the end in compiler_pos, so it need merely be kept up to date a
little bit longer and then returned.
3 possibilities for copying the data over:
a function to copy into a memory block passed to it by the user,
- User has to know how to get the block's size,
+ User controls how memory is allocated (malloc, new,
placement-new, etc)
a function to allocate-and-copy, or
+ Easiest to use
- The block must be freed in the correct manner, without mixing
allocation strategies
just tell the user what to do.
- Hardest for the user
+ Already available, bug free.
Presumptive interface:
define a structure to hold start-of-memory and size.
make a static instance of same, always holding the most recent
version of { &_scratch_mem, compiler_pos }
our data-copier reads from said static instance.
Slight change: It may be better to reject zero-cases by compiling an
immediate return than by (as now) doing nothing or returning some
failure-condition.
As I said, I'm probably going to code this and give it to everyone, I
just wanted to hear if it made sense.
Tom
- Raw text -