Re: [dink-develop] Project Status Report

[Dan W. <wa...@st...>]

Hiya folks...

>>Merlin
>>#define Tree TreeGraphics.dgp
>>    Tree.16 // References the 16th file in TreeGraphics.dgp.  Perhaps a
>>colon could be used?

> Deathwish
> Okay, I've discussed this with Des before, and we think it's a good thing,
> too. However, being the speed monkey that I am, I'm concerned about how slow
> it would become if we were referencing things by names as opposed to sprite
> indices. An index into an array just needs one addition and you're at the
> memory, but something referenced by a name requires a search through the
> array until the element is found - much slower.
> 
> Idea: Perhaps have the core engine just use frame/seq indices, but DinkC++
> scripts can reference them by names. The names would be defined in the
> dink.ini, and at either compile time or load time these names in the scripts
> can be 'resolved' by the engine into their IDs by referencing the dink.ini.
> Thoughts?

> Desplesda
> A better (or at least simpler) system for accessing sprites is desperately 
> needed, I agree with you there. Your system is workable, but we need to get a 
> system that also is compatible (or at least, can coexist) with the seq/frame 
> system of Dink.

Erm... I think you're trying to create a solution for a problem that 
doesn't exist, and in turn create wholy new problems that would end up 
breaking nearly everything.  heh.

By eliminating sequence numbers, you break:

1) The ability to manipulate sequences numerically.  While not in great 
use, its used in a few instances in the original game (i.e. adding 100 
to Dink's direction to determine the attack sequence).  To try to do it 
another way (if (sp_dir(1,-1) == 2) sp_seq(1,"DINKATTACKUP"); etc) would 
just bring unneeded clutter into things.

2) Base walks/attacks/deaths.  Unless you can think of a simpler way. 
Right now you just do something like sp_base_walk(1,10); and the game 
knows that sequence 11 is lower-left, sequence 12 is down, etc.  And if 
a sequence doesn't exist (such as with a pillbug, which only has two 
sequences) the game copes by choosing one that is 'close' to it.

3) Breaking every D-Mod ever made.  Seriously, unless my mind is 
seriously being bombed with poisons of stupor, trying to automatically 
convert all sequences and frames from D-Mods that heavily rely on new 
graphics (i.e. Pilgrim's Quest, Stone of Balance) and the previous 
seq/frame numbers.

4) All graphics ever used will be loaded into memory, as it doesn't seem 
possible to load sequences over other sequences (freeing the previous 
memory), if you're doing it the way it seems to me.

5) Probably some other things my just-awoke mind cannot think of.

I think the best solution would be to either have some sort of meta 
layer on top of the dink.ini allowing you to organize the graphics in 
any matter you see fit in any categories or groups the author decides, 
on a frame-by-frame basis or a seq-by-seq depending on which sequence it 
is, while still having the sequence and frame numbers in plain view and 
completely ignoring the meta layer when the engine is running.

Note: I have no idea what 'meta' means, but the word seemed to work in 
the above paragraph.  If it doesn't, my apologies, feel free to replace 
it with a friendlier word.

Oh you could just leave it alone.  Plenty of D-Mods have been made under 
the current conditions, I can recall no complaints except those who 
expect someone to make their D-Mods for them, and making it 'simpler' 
could, in fact, be worse.  Only completely change something because of 
what is necessary, not because it sounds good.

Haven't really read into the rest of the update too much, but this just 
stuck out.

Thanks,

Dan Walma
The Dink Network
http://rpgplanet.com