load sprites into negative sequence slots - lots of extra slots.
I just discovered this, and the explanation is, I don't know what makes me try this shit, but something does.
have a look at this script:
I played the game. Both sprites were created (sequence -247 and 247)
I need to experiment with this more.. I also tried it with other negative numbers.. it works. I'm a bit gobsmacked to be honest.
EDIT: It works for static sprites. When you try to animate with a brain of 6, or set a base walk, it doesn't work... I'm guessing it's just because these "sp" commands don't accept negative values.. at least create_sprite does. All the frames are loaded in though.. if you change sp_pframe, the frame updates. If only `sp` commands accepted negative values, that would be an extra 999 slots.
EDIT2:
Wtf, the negative values extend back to -7999 in FreeDink and -6044 in Dink 1.08, I changed the above lines to load the red guy into -7990 base slot and it worked in FreeDink.
it only crashes when you load something into -8000 in FreeDInk or -6045 in Dink 1.08.
where in the positive values, it crashes at 1000
have a look at this script:
void main(void)
{
//load red guy into a negative sequence slot number
init("load_sequence graphics\people\merchant\c09w1- -241 100 38 71 -18 -9 24 14");
init("load_sequence graphics\people\merchant\c09w3- -243 100 36 69 -22 -14 23 14");
init("load_sequence graphics\people\merchant\death- -245 100 59 11 -58 -7 17 38");
init("load_sequence graphics\people\merchant\c09w7- -247 100 40 67 -24 -14 23 11");
init("load_sequence graphics\people\merchant\c09w9- -249 100 34 69 -18 -13 23 16");
//create the sprite with the negative sequence value (red guy)
create_sprite(250, 250, 0, -247, 1);
//create a sprite with the same positive value to make sure our exploit didnt simply overwrite the positive value
//should create the girl sprite.
create_sprite(400, 400, 0, 247, 1);
}
I played the game. Both sprites were created (sequence -247 and 247)
I need to experiment with this more.. I also tried it with other negative numbers.. it works. I'm a bit gobsmacked to be honest.
EDIT: It works for static sprites. When you try to animate with a brain of 6, or set a base walk, it doesn't work... I'm guessing it's just because these "sp" commands don't accept negative values.. at least create_sprite does. All the frames are loaded in though.. if you change sp_pframe, the frame updates. If only `sp` commands accepted negative values, that would be an extra 999 slots.
EDIT2:
Wtf, the negative values extend back to -7999 in FreeDink and -6044 in Dink 1.08, I changed the above lines to load the red guy into -7990 base slot and it worked in FreeDink.
it only crashes when you load something into -8000 in FreeDInk or -6045 in Dink 1.08.
where in the positive values, it crashes at 1000
Robj:
It seems you have (re)discovered a very ancient method of hacking.
Early computer systems (mainframes and minis) often had a development environment and operating system sort of all rolled into one big block of code.
And early systems also (at least in some cases) tended to assume that the persons using them would follow the rules and not create any problems.
That meant it was possible to use (for example) the assignment of values to negative array elements, to actually overwrite parts of the operating system! This could be useful (in RARE cases); but usually just caused problems later.
Even today, there are computer languages in use that don't do bounds checking on arrays. But, most operating systems and the processors they are based on help to prevent many kinds of possible opportunities to corrupt any part of the operating system using negative array elements. That being said, while using negative array elements in DinkC probably won't cause your computer to crash, it might cause DinkC to behave oddly later when it goes to use some of that memory that was never officially allocated for the editor sprite array.
So, although this method of loading "sprites into negative sequence slots" is probably one that works (at least at first) without causing any problems, it is not likely to be a good method to use.
It seems you have (re)discovered a very ancient method of hacking.
Early computer systems (mainframes and minis) often had a development environment and operating system sort of all rolled into one big block of code.And early systems also (at least in some cases) tended to assume that the persons using them would follow the rules and not create any problems.
That meant it was possible to use (for example) the assignment of values to negative array elements, to actually overwrite parts of the operating system! This could be useful (in RARE cases); but usually just caused problems later.
Even today, there are computer languages in use that don't do bounds checking on arrays. But, most operating systems and the processors they are based on help to prevent many kinds of possible opportunities to corrupt any part of the operating system using negative array elements. That being said, while using negative array elements in DinkC probably won't cause your computer to crash, it might cause DinkC to behave oddly later when it goes to use some of that memory that was never officially allocated for the editor sprite array.
So, although this method of loading "sprites into negative sequence slots" is probably one that works (at least at first) without causing any problems, it is not likely to be a good method to use.
