anonimzwx, it's important to remember that
you're the one who's pushing for the standardization of Dynamic Z. No-one's trying to take your rights over what you've made - that's not the purpose of rule C1 (it even explicitly states "SMW Central does not own your file") - but the rules are there and everyone who submits anything agrees to those rules. We've never bent them for anyone who wished to submit something and we certainly can't make exceptions when it's regarding resources that could end up being a site standard. You can't push for us to make your tools a site standard and then also demand that they be exempt from the rules of the site you want them standardized on.
Originally posted by anonimzwxDoing a dsx sprite manually is the same difficulty, please don't give an opinion if you don't have the technichal knowledge to reply.
Everyone is entitled to give their opinion regardless of technical knowledge. They're going to be the ones who use Dynamic Z sprites should it become standard, and their thoughts on how easy it is to use are just as valid. They might not be making the sprites, but if they want to say, edit graphics, then they'll be interacting with the system and the sprites to do that.
While we're on that sentence, I'm also interested to know how doing a DSX sprite manually is the same difficulty - in my experience with using DSX, it's far easier. DSX sprites use a standardized graphics arrangement - 32x32 frames ordered from left to right, top to bottom. This means that they're accessed by a single index, and therefore the routine that DSX sprites use is always the exact same. You don't even need to make a routine or tables for DSX - you can copy it from another DSX sprite, change the number of dynamic_frame entries to match your number of frames, and it'll just work. DSX is a basic system, sure, but that works to it's advantage here.
You say that doing a Dynamic Z sprite without Dyzen isn't hard, and you list off the things you have to do, including the GFX tables - but you glossed over how much tedious work it will actually be to do the tables for the GFX, even for ASMers. I've seen the asm of Dynamic Z sprites, generated by Dyzen, and there are a
lot of tables. This can also be seen in your video on editing graphics with Dyzen, specifically at
2:45 and
3:23. Unless you already have a very good understanding of what those tables are and do, and how the data is structured, it's unreasonable to expect anyone (ASMers included) to write those tables from scratch without Dyzen. More importantly, it will be
impossible for non-ASMers to edit graphics without Dyzen, if doing so requires those tables to be changed. It's entirely unreasonable to expect non-ASMers to rewrite those tables from scratch any time they change the graphics. Judging by that video, editing graphics for Dynamic Z sprites is already difficult enough - editing graphics with DSX never requires you to go into the .asm and change any tables, unless you're adding/removing frames, and even then, you're just adding/removing dynamic_frame entries - not deleting and pasting dozens of tables from one .asm to another. But people editing graphics for Dynamic Z sprites will still be relying on Dyzen to generate those tables for them in the first place. Therefore, unless a solution is found for graphics editing which doesn't require editing so many tables, I very strongly believe that Dyzen is
required - therefore, it's also relevant to this thread. You mention that you
will include documentation on how to use Dynamic Z without Dyzen (and hopefully it's easier than what seems to be the current method), but this is honestly stuff that should have been sorted out before pushing the system forward to be a standard. There's a lot of "I will", and while I believe that you'll follow through on these things, I'm very hesitant to standardize a system now that's very dependent on things that
will be done in the future.
It's worth mentioning that every tutorial/guide you've put out so far has been with the usage of Dyzen, and in your C3 thread (and even previously on this thread) you always mentioned Dyzen when talking about using Dynamic Z and how easy it makes things. To then turn around here and say "nono you can do it without Dyzen it's easy" seems odd to me.
It's also not as clear cut as "using sprites" vs "creating new sprites" - users may want to edit and tweak existing sprites to their liking, even if they might not know ASM. In that case it's important that the system is clear enough so with a bit of guidance, users can change things about the sprite with relative ease (as mentioned above, editing graphics for example). Making the system only understandable to ASMers and otherwise assuming "well those people don't know ASM so it doesn't need to be possible for them" is a bad mindset, and is only going to hurt the accessibility of the system.
Creator's bias is a thing too - you built Dynamic Z yourself, and everything about it was made based on what you thought it should be. Therefore, you understand everything about how the system works, and using it is very easy for you - but that doesn't mean it will be easy for everyone else.
Originally posted by anonimzwxThat is completely fake, nobody asked me or told me anything about Dynamic Z V3.5 to fix or improve to transform it into a new standard. Staff just ignored the existance of that version. Maarfy didnt ask me, give me feedback or something like that.
I believe idol meant Maarfy's comments about this version, V3.75.
Finally: I don't want to put too much in this post at once since otherwise stuff could get missed, but I do have one suggestion/concern about Dynamic Z that personally I think should be addressed first if the system is going to be standardized. Currently, the dynamic routines use the vanilla SMW misc sprite tables for their own purposes. Examples of this are !C2 as !SpriteMiscTable3, !1504 as !SpriteMiscTable4 and !151C as !SpriteMiscTable6. My issue with this, is that many sprites rely on these misc sprite tables to use for their
own behaviour, and some vanilla sprite routines (such as the SolidSprite routine at $01B44F) rely on these tables as inputs for the routines to function properly, or modify them based on certain conditions. It looks like Dynamic Z has defines for all the misc tables, which makes me think it's possible that they can all be reserved by Dynamic Z. In this case, how is the sprite supposed to utilize any RAM for it's own behaviours/functions? I worry that if these tables are reserved by Dynamic Z then there won't be enough left for the sprite to do it's own functions (especially if it's a complex sprite that needs to hold a lot of data in RAM/tables), and I could see this potentially being a problem when it comes to remoderating the SMWC dynamic sprites.
Additionally, there is a bit of concern with Dynamic Z reserving extra byte 1 for internal use - when a sprite uses more than 4 extra bytes, extra bytes 1-3 hold the pointer to the extra byte data's location in ROM. Will this not conflict with Dynamic Z's reservation of extra byte 1, and cause an error inside Dynamic Z or cause the extra byte data to become inaccessible since the low byte of the pointer is overwritten by Dynamic Z's code?
Personally, I would prefer it, and think it would be much safer and more convenient, if Dynamic Z reserved a chunk of freeRAM for it's own tables, instead of clogging up the SMW misc sprite tables/extra bytes. That way, there's no conflict between what Dynamic Z needs the tables for and what the sprite itself might need the tables for.
I think that sums up my thoughts for now, but:
I'll also use this post as an opportunity to ask you to double-check the Dynamic Resources Adder included in the V3.75 you submitted to the Patches section, as neither me nor KevinM were able to get it to work when
trying to insert stuff.