What are the limits of animated sprites these days?
In particular, I'm thinking about the number of images used to display an action.
Last century, with the original engine, you generally had 8 to 12 images per animation cycle for walking (generally 10 for NPCs) and around 5 or so for attacking animations. Dink dying was 14 images.
Now I've been experimenting with sprites that have around 12 to 30+ images per walk cycle, and more recently up to 26 images for attack cycle - and while I haven't seen any noticeable lags, occasionally weird things happen, like Dink's dying graphics don't always play on his death, and I'm using the init(load_sequence_now ); command along with the preload_seq(); command just to get stuff to play like magic effects.
Getting the animation cycle to look decent (i.e. reduce sliding feet as the sprite moves around) varies, and in some ways using less images per cycle is better as the feet don't slide on the ground as much as they can with higher images per cycle.
These are all png with alpha channel.
What is the best way to test or verify what the limits are, other than just playing the dmod?
Last century, with the original engine, you generally had 8 to 12 images per animation cycle for walking (generally 10 for NPCs) and around 5 or so for attacking animations. Dink dying was 14 images.
Now I've been experimenting with sprites that have around 12 to 30+ images per walk cycle, and more recently up to 26 images for attack cycle - and while I haven't seen any noticeable lags, occasionally weird things happen, like Dink's dying graphics don't always play on his death, and I'm using the init(load_sequence_now ); command along with the preload_seq(); command just to get stuff to play like magic effects.
Getting the animation cycle to look decent (i.e. reduce sliding feet as the sprite moves around) varies, and in some ways using less images per cycle is better as the feet don't slide on the ground as much as they can with higher images per cycle.
These are all png with alpha channel.
What is the best way to test or verify what the limits are, other than just playing the dmod?
I am not aware of any explicit frame limits for things other than the twirling arrows in choice menus, which i've removed on my end, off the top of my head. For normal sprite stuff, the limiting factor should just be Dink.ini.
When it comes to the skating effect, I do wonder if it's just because one isn't accustomed to having so many frames in a walking anim. There are also considerations to be made for stuff like gait in which during certain parts of a natural cycle, a person's movement rate varies, while the engine doesn't change its speed at all. It might be possible to manipulate the mx and my properties upon certain frames of sprites to account for it, however.
When it comes to the skating effect, I do wonder if it's just because one isn't accustomed to having so many frames in a walking anim. There are also considerations to be made for stuff like gait in which during certain parts of a natural cycle, a person's movement rate varies, while the engine doesn't change its speed at all. It might be possible to manipulate the mx and my properties upon certain frames of sprites to account for it, however.
Feet sticking to the floor in animation can be tricky even outside of game engines. Usually you vary how fast the object is traveling compared to the frame rate of the animation and the distance of the step overall. So I mess around with sp_frame_delay() and sp_speed() until something gets close.
So, I've noticed that DinkHD is struggling to keep various graphic/sprite sequences available all the time, like Dink dying, in Necromancer, while YOD doesn't seem to have the same issue, although I need to do more tests.
Now I'm suspecting it is something to do with graphics in buffers or some such thing, and while using init("load_sequence_now blahdeblah"); gets around this for the crawling into holes, maybe I need it in the dinfo.c script as well, as I have dink dying in 4 directions based on his existing sp_dir().
Anyway, is there a way to test/know what the amount of graphics/buffer is?
Now I'm suspecting it is something to do with graphics in buffers or some such thing, and while using init("load_sequence_now blahdeblah"); gets around this for the crawling into holes, maybe I need it in the dinfo.c script as well, as I have dink dying in 4 directions based on his existing sp_dir().
Anyway, is there a way to test/know what the amount of graphics/buffer is?
In theory, it should be possible to check if a sequence is loaded into the graphics cache by checking the length of that sequence. If its frame length and other properties are zero, it means it's not loaded. Unfortunately I don't believe there's any way to actually check dink.ini properties from dinkc unless there's some sort of obscure Robj-style trick waiting to be discovered.
@SimonK
In regards to DinkHD limits. I think this is still accurate:
Max sequences: 1300
Max sprite frames in a seq: 100
Max sprite filename size: 64
6000 sprites addressed at once (HD will unload/load them as needed, but even not being loaded it counts as "addressed")
Max sprites on screen at once: 300
Max scripts active at once: 200
Max script callbacks at once: 100
In regards to DinkHD limits. I think this is still accurate:
Max sequences: 1300
Max sprite frames in a seq: 100
Max sprite filename size: 64
6000 sprites addressed at once (HD will unload/load them as needed, but even not being loaded it counts as "addressed")
Max sprites on screen at once: 300
Max scripts active at once: 200
Max script callbacks at once: 100
6000 sprites addressed at once (HD will unload/load them as needed, but even not being loaded it counts as "addressed")
So, if you have over 6000 sprites active because of dink.ini then the engine is meant to load and unload those above the 6000 mark?
But the crawling into a hole not playing bug disproves this?
Is there any way to check the active sprite count via debug logs or some such?
Oh and I think the sprite frames per sequence limit might be 99, based on the two character default naming structure. -##. I can't remember if I found this out in doing Hack n Slash with the dance moves, or if I just assumed it.
So, if you have over 6000 sprites active because of dink.ini then the engine is meant to load and unload those above the 6000 mark?
But the crawling into a hole not playing bug disproves this?
Is there any way to check the active sprite count via debug logs or some such?
Oh and I think the sprite frames per sequence limit might be 99, based on the two character default naming structure. -##. I can't remember if I found this out in doing Hack n Slash with the dance moves, or if I just assumed it.
Traditionally, it appears that the graphics cache is never purged, and that sequences are only blanked when being innitted over with another one which I haven't changed and don't plan to. I also have vague memories from a long time ago of having to occasionally exit and reload from a save because Dink would run/walk too slowly after a while.
It appears Seth now has a fancy graphics unloader that adds a timer field to the graphics data that is then routinely checked and then purged after an interval has passed, although it appears the interval is only 5 seconds, as specified in the function below what's linked.
It appears Seth now has a fancy graphics unloader that adds a timer field to the graphics data that is then routinely checked and then purged after an interval has passed, although it appears the interval is only 5 seconds, as specified in the function below what's linked.
Not sure the engine reloads things as needed correctly in DinkHD, as stated in the comments.
Until I added init(); commands to dinfo.c I would have Dink a frozen walking sprite as he dies sometimes. And something else I've noticed is that the inventory screen sometimes plays the flashing selection symbol, and sometimes not. This is only two sprites that are meant to toggle. menu-02.png and menu-03.png. I've noticed that when first playing all is fine, but after a while the menu-03.png no longer appears.
Not sure how many graphics I now have as I'm still using a few of the original ones, and may never get around to replacing them, such as coins, status numbers etc, blood bursts, splashes ...
But- if I do a dir *.* /s I get a figure of 10,879 - although there a few redundancies and zip file backups as part of that... so probably around 9,000 say, plus the ones the still get loaded from the original game.
Until I added init(); commands to dinfo.c I would have Dink a frozen walking sprite as he dies sometimes. And something else I've noticed is that the inventory screen sometimes plays the flashing selection symbol, and sometimes not. This is only two sprites that are meant to toggle. menu-02.png and menu-03.png. I've noticed that when first playing all is fine, but after a while the menu-03.png no longer appears.
Not sure how many graphics I now have as I'm still using a few of the original ones, and may never get around to replacing them, such as coins, status numbers etc, blood bursts, splashes ...
But- if I do a dir *.* /s I get a figure of 10,879 - although there a few redundancies and zip file backups as part of that... so probably around 9,000 say, plus the ones the still get loaded from the original game.
I assume you've hit the allocation limit and caused a death spiral in which every frame or thereabouts, you're hitting that 200MB upper limit which is then being purged down to 128MB due to having more graphics concurrently on a single screen than the loader/purger is capable of handling reliably.
Yeah, I think so.
The original graphics are about 3,600 items based on downloading the unpacked version. So I'm over x2 this amount, and past 6,000.
I might have to reconsider the use of 30 frame walk cycles for NPCs and enemies and go back to 10 at the most. And do a graphic cull as I have created multiple directions for various objects, some of which I don't use, and probably won't.
The original graphics are about 3,600 items based on downloading the unpacked version. So I'm over x2 this amount, and past 6,000.
I might have to reconsider the use of 30 frame walk cycles for NPCs and enemies and go back to 10 at the most. And do a graphic cull as I have created multiple directions for various objects, some of which I don't use, and probably won't.
If you switch on the FPS display in the menu, it'll show three different figures, M, T, and A. You should be able to tell when it's purging when one of the numbers decreases. I assume M is main memory and T is textures.
It's interesting watching the FPS display, M: T: A: and a F:
Although not sure what they stand for.
Nothing went over 128 except for T: at one point.
Interestingly the missing menu-04.png file came back after disappearing for a while as I was playing the dmod from the start up to the first 3 quests in the first world.
I might hold off from doing a graphic file cull, even though my amount of graphics is over 6000 based on this little test I ran. Get the dmod to the end of the first part... and then... demo anyone?
Although not sure what they stand for.
Nothing went over 128 except for T: at one point.
Interestingly the missing menu-04.png file came back after disappearing for a while as I was playing the dmod from the start up to the first 3 quests in the first world.
I might hold off from doing a graphic file cull, even though my amount of graphics is over 6000 based on this little test I ran. Get the dmod to the end of the first part... and then... demo anyone?
A is audio, and F is supposed to be "free memory" but isn't ever used on desktop operating systems as far as I can tell, and will always be zero.
So, I've been testing/playing and I run into Dink dying but not playing his dying graphics all the time (again)
M: 61.38 T: 48.61 A: 6.82 F: 0.00
I am now using init("load_sequence_now..."); commands as a replacement for preload_seq(); command as that seems to get around some of the issues, but short of having a sprite with a script that loads the dying graphics each screen, I'm kinda stumped.
So are the M: and T: values dependent on the computer's RAM or some such?
M: 61.38 T: 48.61 A: 6.82 F: 0.00
I am now using init("load_sequence_now..."); commands as a replacement for preload_seq(); command as that seems to get around some of the issues, but short of having a sprite with a script that loads the dying graphics each screen, I'm kinda stumped.
So are the M: and T: values dependent on the computer's RAM or some such?
Yes, however the highest bracket is the same across all desktop platforms as per the aforementioned limits, and isn't tested against the system RAM/VRAM.
It might be possible to shove the init lines into weapon scripts somehow, or alternately rig up a more elaborate and drawn-out death cutscene like in Charlie's Legacy to disguise the need for waits that would be required with a stock dinfo death.
It might be possible to shove the init lines into weapon scripts somehow, or alternately rig up a more elaborate and drawn-out death cutscene like in Charlie's Legacy to disguise the need for waits that would be required with a stock dinfo death.
