Mail Archives: djgpp/1997/06/04/10:05:02
Shawn Hargreaves <Shawn AT talula DOT demon DOT co DOT uk> writes:
> That would work, but I'm very wary of an API that exposes the internal
> workings of the implementation like that. Designing an interface that is
> dependent on this kind of implementation detail could cause no end of
> problems in the long run, and would restrict the ways in which the
> routine could be developed in the future. It makes me nervous :-)
It's a point. Though as I will elaborate on, the caching strategy still
appears to spin its wheels uncomfortably long even for little sprites.
> It can be done even more simply than that, and there's no need for the
> copy! At the start of the function, push the values of _scratch_mem and
> _scratch_mem_size into some local variables, and reset _scratch_mem to
Thanks, it was easier that way.
I wrote it in C++ (but not tested it yet) the way you suggested, and I
discovered some things:
There are enough free variables for every stretcher that it still
will probably take a while to search the cache. I introduced a hash
for trivial rejections to speed it up, but still it wants to spend a
while searching. The cache searching could be sped up further with
heroic measures like a hash table proper instead of hash-rejection,
but I don't think it's worth it when the user could just handle it.
The functionality-split that I talked of falls naturally out of
doing it the cache way. A little tweaking of the interface and it's
there.
It wasn't an issue when compilations and uses were 1-to-1, but on
separating them there are a couple of issues WRT how precise a match
a user will demand. For example, I can easily imagine that a user,
stretching a sprite, would not care whether the stretch began on the
correct fractional pixel. In other cases, I can imagine a user might
care very much. I coded the cache-test in the most restrictive way,
but it's another reason why the user might want to handle it
themselves.
Tom
- Raw text -