Cool dink.ini exploit: Adding Static Frames onto Character Sequences
I've discovered a way to add on other sprites at the end of dink/enemy/character/animal/etc sequences without disturbing the respective sequences at all.
Neat, eh?
For an example, we'll pick on the Pillbug. This assumes that all bmps in the directory are not in dir.ff form, and are all extracted bmps. Compiling in a dir.ff shouldn't cause any problems... but it will not allow you to add on new frames.
Location: graphicsfoespillF1-W1-##.BMP
The original pillbug sequence take up 5 frames... we can add a good 44 new static frames on top of that (and probably more, as the 50 frames-per-sequence isn't a very harsh rule, which I think SimonK found out with SOB).
First, the frame after the original sequence ends cannot be used (in this case, Frame 6). I suggest using a 1x1 bmp. The other frames can be whatever static sprites you want.
Here is what we do in the dink.ini:
load_sequence graphicsfoespillf1-w1- 861 75 24 29 -18 -12 19 7
set_frame_frame 861 6 -1
Where 6 is the 'blank frame' as discussed above. Now you can use Frames 7 through 50 (and possible higher) however you want in your D-Mod, and the original sequence isn't disturbed at all.
There might be a couple (smallish) downsides when using this technique: lets say we give a sprite Brain 7 and set the sequence to 861 (assuming the above dink.ini lines are being used). I haven't tested it, but I'm pretty sure the sprite would act like a Brain 6 sprite, just looping over and over.
Another downside is I'm pretty sure this would only work for walking/idle/looping sequences and not attacking sequences; attacking sequences don't repeat, and setting a frame to -1 using set_frame_frame sets the sequence to repeat when using that frame (I think). And this would make the attacking sequence loop forever (I think, I haven't tested that though).
I also think it might be possible to add on other non-character sequences onto character graphics... lets use the example above and say frames 7 - 17 are some special sequence like a fireball, for example. I think this would work:
sp_brain(&current_sprite,7);
sp_frame(&current_sprite,7);
sp_seq(&current_sprite,861);
But I haven't tested it. I'm pretty sure you wouldn't be able to make the sequence loop at all, like with a Brain 6.
I realize this isn't written in the most clear manner, so if you need clarifications let me know. I'll probably do some new tests and such.
Neat, eh?
For an example, we'll pick on the Pillbug. This assumes that all bmps in the directory are not in dir.ff form, and are all extracted bmps. Compiling in a dir.ff shouldn't cause any problems... but it will not allow you to add on new frames.
Location: graphicsfoespillF1-W1-##.BMP
The original pillbug sequence take up 5 frames... we can add a good 44 new static frames on top of that (and probably more, as the 50 frames-per-sequence isn't a very harsh rule, which I think SimonK found out with SOB).
First, the frame after the original sequence ends cannot be used (in this case, Frame 6). I suggest using a 1x1 bmp. The other frames can be whatever static sprites you want.
Here is what we do in the dink.ini:
load_sequence graphicsfoespillf1-w1- 861 75 24 29 -18 -12 19 7
set_frame_frame 861 6 -1
Where 6 is the 'blank frame' as discussed above. Now you can use Frames 7 through 50 (and possible higher) however you want in your D-Mod, and the original sequence isn't disturbed at all.
There might be a couple (smallish) downsides when using this technique: lets say we give a sprite Brain 7 and set the sequence to 861 (assuming the above dink.ini lines are being used). I haven't tested it, but I'm pretty sure the sprite would act like a Brain 6 sprite, just looping over and over.
Another downside is I'm pretty sure this would only work for walking/idle/looping sequences and not attacking sequences; attacking sequences don't repeat, and setting a frame to -1 using set_frame_frame sets the sequence to repeat when using that frame (I think). And this would make the attacking sequence loop forever (I think, I haven't tested that though).
I also think it might be possible to add on other non-character sequences onto character graphics... lets use the example above and say frames 7 - 17 are some special sequence like a fireball, for example. I think this would work:
sp_brain(&current_sprite,7);
sp_frame(&current_sprite,7);
sp_seq(&current_sprite,861);
But I haven't tested it. I'm pretty sure you wouldn't be able to make the sequence loop at all, like with a Brain 6.
I realize this isn't written in the most clear manner, so if you need clarifications let me know. I'll probably do some new tests and such.
I'm too lazy to try it, but cool.
--WC
--WC
Very nice but... it's the limit of SET_SPRITE_INFO take I find the most limiting in terms of putting in lots of static sprites. I find that I have to create a graphics sequence with a generice hardbox that works for all statics in the sequence to keep the SET_SPRITE_INFO stuff under control.
(ie - a got some new trees for Pilgrim's Quest, so I just define the sequence using the
load sequence graphics...... xx xx xx xx xx xx without seting NOANIM and then I don't need 6-50+ SET_SPRITE_INFO lines.
(ie - a got some new trees for Pilgrim's Quest, so I just define the sequence using the
load sequence graphics...... xx xx xx xx xx xx without seting NOANIM and then I don't need 6-50+ SET_SPRITE_INFO lines.