Info on bug fixed in 1.08: "Fixed issue of loading regular bmp sequences over top of previous sequences"
Hi,
In v1.08, in whatsnew.txt, redink1 writes:
- Fixed issue of loading regular bmp sequences over top of previous sequences
(before the animation would be 'corrupt').
Did anybody experience this bug, and could tell what happened before the fix?
Can it be reproduced?
In FreeDink I have another issue in the same part of the code (Dink takes more and more RAM each time a savegame is loaded). Depending on how it's fixed, it may break sequences in existing D-Mods, so I'm looking for more information.
Technical details:
- Dink loads all sprites/frames in memory slots
- Each slot has a number
- A graphic sequence is a list of slot numbers
- Everything is fine until a sequence is reloaded (e.g. with a init() line in ESCAPE.C or in the sword item script)
- If the sequence is in a DIR.FF, the slots that are part of the sequence are overwritten with the new, reloaded sequence
* however, if the new sequence is longer, then this will also overwrite other sprite slots, altering other existing sequences
* this is not fixed in 1.08, but at the same time, maybe some D-Mods have broken dink.ini that actually rely on this
- If the sequence is in BMPs, and a sequence is reloaded, then slots are not overwritten, but new slots are taken; this means the old slots are unused but still stay in memory (memory leak). When all 4000 available slots are taken, the game crashes! This is for 1.07.
* In 1.08 redink1 fixed this, and now it behaves just like dir.ff sequences, with the same overwritten sequence potential bug
Note: this analysis would mean redink1 fixed the memory leak, but _introduced_ sequence corruption, so there must be something I missed.
If anybody experienced the corrupt animation bug, I'd be glad to get more details
I see it first mentioned here: http://www.dinknetwork.com/forum.cgi?MID=57155
In v1.08, in whatsnew.txt, redink1 writes:
- Fixed issue of loading regular bmp sequences over top of previous sequences
(before the animation would be 'corrupt').
Did anybody experience this bug, and could tell what happened before the fix?
Can it be reproduced?
In FreeDink I have another issue in the same part of the code (Dink takes more and more RAM each time a savegame is loaded). Depending on how it's fixed, it may break sequences in existing D-Mods, so I'm looking for more information.
Technical details:
- Dink loads all sprites/frames in memory slots
- Each slot has a number
- A graphic sequence is a list of slot numbers
- Everything is fine until a sequence is reloaded (e.g. with a init() line in ESCAPE.C or in the sword item script)
- If the sequence is in a DIR.FF, the slots that are part of the sequence are overwritten with the new, reloaded sequence
* however, if the new sequence is longer, then this will also overwrite other sprite slots, altering other existing sequences
* this is not fixed in 1.08, but at the same time, maybe some D-Mods have broken dink.ini that actually rely on this
- If the sequence is in BMPs, and a sequence is reloaded, then slots are not overwritten, but new slots are taken; this means the old slots are unused but still stay in memory (memory leak). When all 4000 available slots are taken, the game crashes! This is for 1.07.
* In 1.08 redink1 fixed this, and now it behaves just like dir.ff sequences, with the same overwritten sequence potential bug
Note: this analysis would mean redink1 fixed the memory leak, but _introduced_ sequence corruption, so there must be something I missed.
If anybody experienced the corrupt animation bug, I'd be glad to get more details
I see it first mentioned here: http://www.dinknetwork.com/forum.cgi?MID=57155
Yep, that's about right. The 'overwritten sequence' bug is a fairly well-known issue (its mentioned in dink.ini, where it describes that it loads the sword sequences before the fist sequences to get around this), so that's why I didn't fix it.
Before the other fix, the animation would be... weird, if you used init() with .bmp after dir.ff. I don't remember the exact technical details, but here's a scenario from 1.07:
Dink Sword Sequence: dir.ff
Dink Fist Sequence: .bmp
Load sword sequence in dink.ini
Load fist sequence using init command
Punch something
As I vaguely remember, Dink's punch animation would be strangely jumpy/twitchy, as if it was playing the frames out of order. Sometimes the sequence included frames from other sequences, so if you punched down, Dink would be punching down one frame, punching left the next frame, and so on.
If you have a Windows PC, you should be able to reproduce the problem pretty easily using v1.07
Before the other fix, the animation would be... weird, if you used init() with .bmp after dir.ff. I don't remember the exact technical details, but here's a scenario from 1.07:
Dink Sword Sequence: dir.ff
Dink Fist Sequence: .bmp
Load sword sequence in dink.ini
Load fist sequence using init command
Punch something
As I vaguely remember, Dink's punch animation would be strangely jumpy/twitchy, as if it was playing the frames out of order. Sometimes the sequence included frames from other sequences, so if you punched down, Dink would be punching down one frame, punching left the next frame, and so on.
If you have a Windows PC, you should be able to reproduce the problem pretty easily using v1.07
