Originally posted by Von FahrenheitI know you work really hard on your project so it's great to see such positive reactions to it. You're doing some awesome things! I think as Dyzen becomes more developed and easier to use it's gonna become more and more of a mainstay here on smwc. I'll gladly join you in the dynamic sprite revolution mate, here's to the new chocolate regime
Thanks Von, Would be very nice to see what you can do with my system. I am very happy to have you on SMWRR: FB Team.
Originally posted by Vitor VilelaImpressive system, impressive tech demo. That sample streaming system reminded of the one I did years ago for C3, I even thought you were using mine until you mentioned that you did for a friend, lol.
The system made by my friend, started using your sample streaming system uploaded some years ago as base, but he modified a lot to improve it, optimizing a lot of stuffs, allowing 24 khz samples and improving the API, also editing AMK code to communicate both better. He is still working on that to avoid all flickering problems.
Originally posted by Vitor VilelaThe SMW hack is pretty cool and Dynamic Z allows for a lot of things. I would like to eventually revise its API and commands available, for ensuring the implementation is solid and it can become part of SMWC's standard. I think DyZ is pretty close to stability.
The implementation of Dynamic Sprite System:
* Exists a Double Linked List where each node has the configuration and important data of the Dynamic Sprite. (Max List Size 48 slots)
* Exists a Queue of Dynamic Transfer to VRAM and CGRAM.
* Dynamic Sprites can be 30FPS or 60FPS (Not recommended, in my experience, is almost never necessary use 60FPS), 60FPS uses the double of slots than 30FPS sprites. 30FPS synchronize their Dynamic Routines to avoid flickering problems.
Steps followed by the Sprite:
Init:
1. When the sprite is spawned, Clear the Dynamic Sprite List, removing all invalid slots (sprites that were despawned or die).
2. The sprite check if it is possible to spawn it, for that It send a Request of X number of 16x16 tiles, If exists that available space, the amount of data send by DMA per frame allows to spawn it and exists a free slot on the Dynamic Sprite List, the sprite reserve that slot and is spawned, if not, then the sprite is despawned (in the case of Normal sprites, it can be respawned if mario enters again on the screen and can be spawned then it will be spawned).
Note1: The maximum number of 16x16 tiles allowed for Dynamic Sprites can be changed with Uber ASM, by default It is 0x20 (32 tiles) and that allows 0x10 tiles per frame, This means that you can have a Maximum number of 32 Dynamic sprites of 16x16 (16 per frame at 30 FPS) or any combination of sprites that uses 32 tiles or less, also the max size of a sprite by default is 16 16x16 tiles, allowing a 64x64 dynamic sprite. If you disable vanilla exanimation and use the uber asm code that i posted on the thread, this can be changed to use 48 16x16 tiles allowing 50% more and the max size in this case are 48 tiles allowing a 80x80 dynamic sprite, that is what i used to do my Master Gnawty Sprite.
Note2: All this is made by the macro CheckSlot, i am doing documentation of this. But basically is just 1 line of code.
Note3: The number 16x16 tiles requested by a sprite is the number of tiles required for the bigger frame, this doesn't mean that always that sprite will load to vram that number of tiles, Dynamic Z always will send the minimum data possible.
Main:
1. Call Dynamic Routine, Dynamic Z already includes a macro that do all the Dynamic Routine for you called EasySpriteDynamicRoutineFixedGFX or EasySpriteDynamicRoutine, again, i am doing documentation to explain this. What this routine Does?
1.1 Check Safe Frame: Dynamic Z has a main timer that increase in 1 each time it is executed on NMI Hander, if Safe Frame is different to Dynamic Z Timer then this means that all worked properly, if they are equals then it means that Dynamic Z wasn't executed on the last game loop, then it skip the Dynamic Routine to avoid any DMA Overload problem. When the Dynamic Routine is executed properly Safe Frame = Current value of Dynamic Z Timer after the routine.
1.2 Check synchronization: If Dynamic Z Timer is even, only Dynamic Sprites registered on Even Frames will execute their Dynamic Routine and vice-versa. In the case of 60FPS Dynamic Sprites, This check is not used.
1.3 FindSlot: This is a routine clear the dynamic sprite list and then does Autodefragmentation, basically it works like if the VRAM has gravity, This is a bit hard to explain but basically then i will explain it with an example:
Imagine you have 3 sprites on the list (DS0 (4 tiles), DS1 (2 tiles) and DS2 (10 tiles)) and DS1 is in between of DS0 and DS2 then on the VRAM they will looks like this:
Then imagine that DS1 dissapear (it was killed or despawned for some reason and was removed by the list). Then the VRAM should looks like this:
Then the routine autodefragments the VRAM and compacts space and the space looks like this:
If the space used by the sprite changed, the routine skip the next check.
1.4 Check if the requested frame (I use the defines !FrameIndex for this) is equals to the Aknowledge Frame (The frame that must be used for the graphic routine, I use !LastFrameIndex for this), if both are equals, then the dynamic routine is skipped. This check is skipped if the FindSlot changed the dynamic space of the sprite.
1.5 Do the Dynamic Routine: It set the parameters to the VRAM DMA Queue and say to Dynamic Z what must be loaded on the VRAM, for that it requires 2 tables (one of 16bits values with offsets of the resource, and one with 8bits values with the number of 8x8 tiles used by the the transfer), each entry on the tables have 2 values per frame, one of the start of the frame, and one of the latest line of the frame that must be loaded on the VRAM. Then the routine fix all the VRAM DMA Queue to do the necessary dynamic routines.
Graphic Routine:
1. Must use the macro GetVramDisp to get the offset of the resources in VRAM.
2. must remap tiles with the macroRemapOamTile
Animation Routine:
1. You only can change frame on the correct frames. If not then you will have a desync then if you change of animation or frame you need this check.
Code
%CheckEvenOrOdd("DZ_DS_Loc_US_Normal")
BEQ +
;Here your code to change frame.
+
In the case of clusters, extended or OW sprites you change "Normal" by "Cluster", "Extended" or "OW".
That is the process that happend behind a Dynamic Sprite.
Originally posted by Vitor VilelaThe only concern is breaking DSX compatibility completely, which is unneeded in my opinion (technically you can have DSX and DyZ co-existing without problem), but I respect your decision.
Sadly is more complicate than you think, If I put DSX's Dynamic Sprites and Dynamic Z Dynamic Sprites, they can't coexists in the same screen, basically to do Compatibility with DSX i must Include DSX on the patch like i did in V3.5 and deactivate all features of Dynamic Z if exist a DSX sprite on the screen, now what happend with that? I Already have a Dynamic Z version uploaded to SMWC, V3.5 for a some years that does that, but Staff never though about a Remoderation of Dynamic Sprites because Dynamic Z included that retrocompatibility, I am afair that if i put a retrocompatibility, that will happends again and then people never will enjoy the features of the patch and also people will still do Dynamic Sprites for DSX instead of change to the new system. Then I won't add retro-compatibility with DSX and I am trying to change the Dynamic Sprite standard, it will be the best for community. There is no reason to use DSX with this new standard it is like use AM carol when you have AMK.
Also thanks for the comment
I am pretty sure that Dynamic Z is very solid, i think you will enjoy it, About the Code quality, it is fine, well It can be a bit optimize it but only some few cycles will be saved. I think that i can improve the quality of the code more, maybe for a future version, to make it more easy to read, It has comments and all but i know that asm could be hard to read sometimes and i think i can add more explanations and sort the code better to make it more readable for others. Now i am pretty sure that Dynamic Z fulfill any standard.
------------------------------------------------------
Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources