Language…
23 users online: bMatSantos, bradcomp, DanMario24YT, DashGamer, eltiolavara9, Green Jerry, GRIMMKIN, hhuxy, Knight of Time, lo fang 123, Michel2023, Nayfal, nonamelol1, playagmes169, prisvag, Serena, Shomi,  shovda, SMW Magic, steelsburg, TheXander, Torchkas, Tulip Time Scholarship Games - Guests: 278 - Bots: 348
Users: 64,795 (2,375 active)
Latest user: mathew

Changing Dynamic Sprite Standard

  • Pages:
  • 1
  • 2
Hi, as a lot of people should know, i released a new version of Dynamic Z.

This version is completly incompatible with old Dynamic Sprite Patch.

Reasons?


Well the Old Dynamic Sprite patch is a very very old technology that Dynamic Z obsoletes a lot, If i give retrocompatibility to this patch, people won't be able to use any of Dynamic Z features if they use a dynamic sprite of DSX.

Dynamic Z V3.5 solved this problem deactivating Dynamic Z if a DSX Sprite is detected, but that was a big error. Why? Because people still do DSX sprites and didn't change to the new Standard and then people wasn't able to enjoy Dynamic Z features.

This time I learned about my error and I Won't add a Retro-Compatibility and I need to ask staff if they are agree with do a Dynamic Sprite Remoderation.

Why a Dynamic Sprite Remoderation is important?

The final result of keep using the Old Dynamic Sprite Patch is that Dynamic Sprite were still very hard to do and almost nobody developed sprites for them, during 10 years only 28 sprites were submitted to Sprite section, In contrast in just 6 months I did like 20 sprites that i will upload to SMWC's Sprite Section very soon.

Removing Old Dynamic Sprite patch and use Dynamic Z as a new standard opens the door to have a lot of new Dynamic Sprites on the Sprite section and They have a lot less restrictions than sprites made for Dynamic Sprite Patch, also allows to use all Dynamic Z Features.

Here a complete list of reason why this should be done:

Regular Users Reasons:

-Dynamic Z allows the double or more Dynamic Sprites on the screen than Old Dynamic Sprite Patch, this allows a lot of more level design options for any hacker that wants to use Dynamic Sprites.

-Dynamic Z Sprites have a lot better performance than Old Dynamic Sprites, for people who use Lorom, they will prefere a lot use Dynamic Z instead of DSX if we do a remoderation. Here an example on Lorom:



As you can see, a lot of Dynamic Sprites without any Slowdown.

-Insertion of Dynamic Z's Resources is standarized and use a system similar to Pixi to insert the resources, this fix a lot of problems of users to install Dynamic Sprites.

-Dynamic Z's sprites in general (could be dynamic or not) allows to load the palette of the sprite in any of the 8 Sprite Color Palette, this allows a lot more flexibility in Level Design and also allows to have more differents kinds of sprites on the level. Also is more confortable because user don't need to load the palette on the level.

-Dynamic Z allows to change what space and how much space the dynamic sprites will use in VRAM using a simple Uber ASM code that i will upload later. This allows to users to use Dynamic Sprites in differents Places of SP3 or SP4 then if they want to use a sprite that requires to be used in SP4 they can change Dynamic Space to SP3.

-If you use a uberasm code that I will submit later and you deactivate Vanilla Exanimations, you can use Bigger Dynamic Sprites (Max Size = 24 16x16 tiles like a 80x80 sprite), this allows to use very Big sprites, gimmicks or Dynamic Bosses like this:



Allowing this also allows 50% more dynamic sprites on the screen or even more if you have more shenaningans.

Users who creates graphics Reason:

-You can edit graphics of Dynamic Z's Dynamic Sprites very easy on your favorite Sprite Editor if you have the sprite sheet of the Dynamic Sprite, i usually use Aseprites but you can use any that you want. Here a tutorial how to do this:



ASMer Users Reasons:

-It is a lot easier create a Dynamic Sprite for Dynamic Z than a DSX sprite, this is because Dynamic Z is supported by Dyzen and It rips automatically Sprite Sheets and allows you to do the animation and hitbox very fast. If you already have a Sprite Sheet you can do a Dynamic Sprite in less than 5 mins. Here a Video:



-Dynamic Z is a lot more efficient than DSX, it is because:

1. Dynamic Z doesn't use a buffer, It loads graphics to VRAM directly, this save a lot of cycles, because fill that buffer in DSX every frame waste up to 2048 or more cycles per frame.

2. Dynamic Z only does the Dynamic Routine of sprites when it is needed. This saves a lot of cycles and also reduce a lot the flickering and the time used by dynamic resources during NMI Handler.

3. Dynamic Z doesn't use Fixed sizes and always sends to VRAM the minimum data possible.

4. Dyzen optimize the graphics to use the minimum number of OAM Tiles and VRAM Space.

-Dynamic Z compacts space used in VRAM for Dynamic Sprites.

-You can use the Dynamic Z to do crazy color effects for sprites like the effects that i showed on that boss. Some of options:

*Change Palette as you want.
*Change Hue, Saturation or Value of colors.
*Mix colors of the palette with a base color.

-You can syncronise DMA Routines to VRAM using DZ_Timer to avoid flickering.

-Dynamic Z is safer than DSX because DSX doesn't have a system to avoid DMA Overload and potentially can corrupt all graphics of the level if there is enough slowdown and flickering.

-Dynamic Z has a lot more support than DSX, because i can solve doubts and problems of users and also because it has Dyzen to help in the Dynamic Sprite Creation.

-Dynamic Z Also allows others types of Dynamic Sprites like Semi-Dynamic, Shared Dynamic and Mixed Dynamic sprites that doesn't have restrictions in number like Dynamic Sprites.

-Dynamic Z has Autodefragmentation System, this means that if a Dynamic sprite is killed or despawned, the patch compacts Dynamic Sprite space to use the minimum possible and allowing more dynamic sprites on that space.

For all this reasons a lot more. SMW Hacking community needs a Remoderation of Dynamic Sprites. They are just 28 on the section and shouldn't be a lot of work change them to use Dynamic Z system instead.

for that i need the help of SMWC's ASM Mods, I can help with the remoderation and do most of the job, but i need a confirmation that this remoderation will exists on the future. It is not necessary to start it right now, but I would like to know if it can be done during this year.



(mod edit: tablestretch)

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
i have trouble getting behind a dynamic sprite moderation without this patch being thoroughly tested first. beyond that, i'm also worried about a few things... firstly, i feel like this appeals to asmers first, and the average user second. the readmes you included with your dynamic sprites aren't very intuitive nor are they written too well - and i know english isnt your first language, which is okay! but i'd recommend maybe having someone proofread and give input, especially if you're wanting this to be standardized to an english site. i also wasn't sure where your readme was in your submission of the dynamic z patch, i found an .html file, but it didn't seem to have any of the supported pages.

secondly, i can't see us doing a sprite remoderation until we have some form of support from the actual community that they want dynamic z over dsx - currently, dsx is pretty simple to apply, and is included in sa-1. the dynamic sprites in the section are fairly easy to insert, and don't rely on any external tools like dyzen (and from what i understand, there's a dynamic sprite specific version of dyzen...?). so far i've really only seen you harkening for a dynamic sprite remoderation and to standardize dynamic z, which... isn't enough to really justify us doing it. do asmers actually prefer developing with dynamic z over dsx? are asmers unhappy that we host dsx instead of dynamic z? how do non-asmers feel about using dynamic z instead of dsx? i'd like to have that kind of input.

i worry this system you've built - while super cool and grand, might not actually be globally appealing in the ways dsx is. i saw your hack at c3, and it looks super cool! and i can see how this system works so well for that hack. but... i haven't really ever seen other people worry about the kinds of issue you've had with dynamic sprites, and while this might be revolutionary for you, it might be counterintuitive to standardize without explicit support from the community.

i hope some of my asm mod brethren can give better input than i.
Thanks for reply, also for the last paragraph speaking about my hack :). Sorry for giant Wall Text. But it is required to reply you.

Originally posted by idol
i have trouble getting behind a dynamic sprite moderation without this patch being thoroughly tested first. beyond that, i'm also worried about a few things... firstly, i feel like this appeals to asmers first, and the average user second. the readmes you included with your dynamic sprites aren't very intuitive nor are they written too well - and i know english isnt your first language, which is okay! but i'd recommend maybe having someone proofread and give input, especially if you're wanting this to be standardized to an english site. i also wasn't sure where your readme was in your submission of the dynamic z patch, i found an .html file, but it didn't seem to have any of the supported pages.


I recommend you check the part of the post that says "Regular Users Reasons".

That html probably is very out-dated. I already uploaded 2 installation guides (1 in video and other on this post: Guide

I am working in more documentation, Now the patch is very simple to install, the only problem is that Vitor included DSX by default in SA-1 then if you install SA-1 you need to deactivate DSX from sa1.asm first, that is not my fault, DSX shouldn't be included in SA-1 by default, that limits any other dynamic sprite patch.

I know that first the patch requires a hard test and be approved by Staff, also more documentation, but i did this thread before that because i want to know if exist that option, all testing and documentation thing is something that will be fixed in very short time.

I just need to know if it is possible to do the remoderation, It doesn't need to be right now, but I need to know that will happend on the future because people will not be able to use all the cool things that the patch allows without that if they use DSX. DSX is a very obsolete tech today, use it instead of Dynamic Z is like to use Addmusic Carol instead of Addmusic K in 2020, there isn't any advantage in use DSX instead of Dynamic Z.

Originally posted by idol
secondly, i can't see us doing a sprite remoderation until we have some form of support from the actual community that they want dynamic z over dsx - currently, dsx is pretty simple to apply, and is included in sa-1. the dynamic sprites in the section are fairly easy to insert


Install Dynamic Z is very simple, just open "Dynamic Z Installer.exe" select the features that you want, put the paths and press install.

Dynamic Sprite Installation is also not hard, Just i included an standarized way to install them, because In Sprite Section There are some Dynamic Sprites that uses more than 1 bnk, those Dynamic sprites usually requires special patches that can use slogger and freespace or things like that to install them, i added that "Dynamic Resource adder" to fix all those problems during Dynamic Sprite Installation and it works similar to Pixi. This is to help regular users and do all easier.

Originally posted by idol
don't rely on any external tools like dyzen (and from what i understand, there's a dynamic sprite specific version of dyzen...?).


Dyzen is not necessary to use Dynamic Sprites, you can use Dynamic Sprites without even open Dyzen. You can use Dyzen to create NEW Dynamic sprites, you can do them manually too but do the Dynamic Routine, the Graphic routine and GFX for a Dynamic Sprite (a DSX or dynamic z dynamic sprite, this is a problem of any dynamic sprite in general) usually is a very hard task, for that i created Dyzen to help ASMers to to that in less than 5 mins.

Also the use of Dyzen is also good for regular users, because for example i did a guide to Edit graphics of dynamic sprites with Dyzen then they can edit those graphics just using their favorite graphic editor like aseprites.

Originally posted by idol
so far i've really only seen you harkening for a dynamic sprite remoderation and to standardize dynamic z, which... isn't enough to really justify us doing it. do asmers actually prefer developing with dynamic z over dsx? are asmers unhappy that we host dsx instead of dynamic z? how do non-asmers feel about using dynamic z instead of dsx? i'd like to have that kind of input.


During the last 10 years, only 28 Dynamic sprites of DSX are uploaded to SMWC sprite section, that say you a lot about how asmers feels with DSX patch, in contrast i did 20 in just 6 months, i already uploaded 3 of them but i will upload the others soon, i am just doing testing and also i will create and upload more on the future, i also already did remoderation of a couple of them (Midway Flag and YI Piranhas).

Dynamic sprites for Dynamic Z are a lot easier to do than DSX Dynamic Sprites, I already teach to some asmers how develop dynamic sprites with the tool and they didn't have any problem, as i showed on my C3's thread the final boss of casio mario world was made by wyatt using Dynamic Z, codfish also did some sprites, i also teach to do dynamic sprites to Von Farenheit, Runic and maxell. I am pretty sure that in the future DSX sprites will be very few compared with Dynamic Z sprites.

I think that even someone with very small ASM knowledge can do a Dynamic Sprite for Dynamic Z using the resources that i released this C3.

All the problems that you say are just because Dynamic Z is still new, for people who all time used DSX could have some problems at the start to use another Dynamic Sprite Patch. This also happends when you change any standard, Still there are people who use Romi's sprite tool. Now i think that this is not a lot of problem, because as i say There are only 28 dynamic sprites on sprite section, almost nobody develope dynamic sprites.

Originally posted by idol
i worry this system you've built - while super cool and grand, might not actually be globally appealing in the ways dsx is. i saw your hack at c3, and it looks super cool! and i can see how this system works so well for that hack. but... i haven't really ever seen other people worry about the kinds of issue you've had with dynamic sprites, and while this might be revolutionary for you, it might be counterintuitive to standardize without explicit support from the community.

i hope some of my asm mod brethren can give better input than i.


That is because in this community Dynamic Sprites are not very popular, in SMW you can do a lot of things just with normal sprites, because graphics are simple and without a lot of frames, regular enemy in the most of cases just have between 2 or 4 frames and they reuse a lot of tiles. Also in Sprite section there are very few Dynamic sprites available and most of people dont use them a lot and people don't overuse dynamic sprites, usually they just use 1 or 2 on the screen in the most of cases.

But what happend if you want to do a more complex hack or do a hack with other content, see people like Deeke, he does awesome pixel art with very smooth animations, obviusly someone like him would do a lot of magic for a SMW hack using this system.

Also how about enemies of others games? in SMBX community they use a lot of custom enemies of a lot of differents franchise, we can't do that with DSX but we can with Dynamic Z, do enemies of franchise of Metal Slug, Doom, DKC, Bosses of others games that looks impossible in SMW, enemies of newer games, even games like kirby or megaman X sometimes have enemies that could be very helpful to do them as Dynamic Sprites, The options of the patch are unlimited.

Almost all dynamic sprites already uploaded to Sprite Section are from Yoshi island, i used DSX before and use those enemies on lorom is awful, they produce a lot of slowdown and you can't spawn them a lot, you feel very restricted, i used for example 4 piranhas in the same screen and that produced a lot of slowdown, not even that, i put just some more enemies with the 4 piranhas and the patch just corrupted all my graphics on the level, i tested DSX a lot and i am pretty sure that is not good, in sa1 is a bit better but still if you do some heavy processing things you can have problems also still you have those restrictions and lacks of flexibility.

They don't worry about those problems of DSX because they doesn't have a lot of dynamic sprite options and they don't use Dynamic Sprites a lot, if the sprite section instead of just 28 have 300 dynamic sprites and people use a lot of dynamic sprites on their hack, Probably a patch like dsx were replaces a lot of years ago with all the limitations that it has.

Also some years ago, on ASM Subforum a pinned thread was created speaking about a "New Dynamic Sprite Standard" and a lot of people commented on that thread saying what should have a new "Dynamic Sprite" system, that thread was closed and sent to Trash Can when i replied that thread and released Dynamic Z V3.5, but the standard didn't change because Staff never did a remoderation.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
I'm really interested in seeing what non-coders think about this sort of thing. I have a suspicion that the average user doesn't really care about the quality of the tech, as long as it's easy to use. I think you might be intimidating people with how long the post is. I see that your argument is complex but it can also be difficult to engage with for people. But as I said, most likely the majority of users sit in the grey zone where they don't really care whether their dynamic sprites use DSX or DynamicZ. If the mod team and Vitor decided that from now on DynamicZ is supported and DSX is not, the majority wouldn't even notice. A small handful (notably Roberto Zampari) would love the change, and a slightly larger handful would oppose it, citing issues such as intrusiveness and legacy compatibility. The average hack quality would improve very slightly. That's the prediction of Von Prophet, anyway.

My perspective probably doesn't reflect on the average user but I'll share it anyway. If I was making dynamic sprites I'd be interested in the code you use, as it seems far superior to DSX. There's no doubt that DSX (and SMW NMI stuff in general) is terrible, so I'd definitely be interested in a superior alternative. Because of this I likely want to use the DynamicZ patch, but not Dyzen. I don't like tools in general because they add little black boxes in my hack and I hate that. I don't like sprite tools, block tools, uberASM tools, and I have a pronounced love-hate relationship with Lunar Magic. You get the idea. I want everything in patch form. That's just easier for me. That opinion probably doesn't even reflect on the average coder here, so take it with a grain of salt.

allow shy guy emojis in post footers you cowards!
Originally posted by Von Fahrenheit
I'm really interested in seeing what non-coders think about this sort of thing. I have a suspicion that the average user doesn't really care about the quality of the tech, as long as it's easy to use. I think you might be intimidating people with how long the post is. I see that your argument is complex but it can also be difficult to engage with for people. But as I said, most likely the majority of users sit in the grey zone where they don't really care whether their dynamic sprites use DSX or DynamicZ. If the mod team and Vitor decided that from now on DynamicZ is supported and DSX is not, the majority wouldn't even notice. A small handful (notably Roberto Zampari) would love the change, and a slightly larger handful would oppose it, citing issues such as intrusiveness and legacy compatibility. The average hack quality would improve very slightly. That's the prediction of Von Prophet, anyway.

My perspective probably doesn't reflect on the average user but I'll share it anyway. If I was making dynamic sprites I'd be interested in the code you use, as it seems far superior to DSX. There's no doubt that DSX (and SMW NMI stuff in general) is terrible, so I'd definitely be interested in a superior alternative. Because of this I likely want to use the DynamicZ patch, but not Dyzen. I don't like tools in general because they add little black boxes in my hack and I hate that. I don't like sprite tools, block tools, uberASM tools, and I have a pronounced love-hate relationship with Lunar Magic. You get the idea. I want everything in patch form. That's just easier for me. That opinion probably doesn't even reflect on the average coder here, so take it with a grain of salt.


I try to avoid black boxes, my tools and patches usually have commented codes and asm files that can be read or edited for anyone who knows asm.

Some asmers doesnt like tools, i dont share that but i can understand why, now in the case of Dyzen, all generated asm is based on asm codes in "asm" folder, if you dont like black boxes you can edit or read the codes of that folder, probably you are more interested on the tables generated by the tool to save you time. The code of dyzen is also open source, you can check it on the repo if you have any doubt, i think that do Dynamic Sprites in general (dsx or dynamic z sprite) could be very hard without any tool, but you also can do them manually, the tool is only to save a lot of time to developers, you always can do all manually if you know what to do.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by Von Fahrenheit
I don't like tools in general because they add little black boxes in my hack and I hate that.

This is a bit offtopic since it doesn't have to do with dyzen but with tools in general.
Some tools are not actually black boxes, for example, Pixi is completely open source and 90% of the thing it applies are available in patch form under the asm directory. It is true that they require a bit more digging into but if you really care you just open it and dissect it to see exactly what is it doing to the rom.
I feel like some numbers here are needed. How many hacks (in development or finished) are using Dynamic-Z? Obviously a standardisation is not really justified if nobody is using the target platform.

The 'average user' will not care about the dynamic sprite functionality because it already exists in the form of dsx.
No matter how superior the system is under the hood. The 'average user' doesn't care.

Dz allows for some other neat features that the 'average user' would probably care for - hot swapping tilesets is probably the biggest one. But is rewriting dsx sprites even needed to cash in on other features like this one?

Obviously, the best would be to just have a tool that converts dsx code to dz code. I have no idea how feasible that is, but it would solve the issue, provide an easy way into Dz, allows everyone to choose their favourite system, and remove the need for any recoding of existing sprites.
Average user will care about when some cool sprites for dynamic z will be uploaded, i already uploaded like 20this C3, also i am pretty sure that the slowdown caused by dsx specially on lorom cares to average user, also the big amount of restrictions of dsx, only 4 dynamic sprites of 32x32 with dsx vs 8 or more with dynamic z, with MaxTiles, that is needed today. I gave a lot of reasons why an average user would care about this change, reasons like:

-You can use the double or more Dynamic Z Sprites than dsx sprites on the screen.
-Dynamic Z sprites can load their palette on any of the 8 sprite palettes doing them a lot more flexible to use.
-Dynamic Z sprites use a lot less space in rom than dsx sprites.
-Standarized method to install Dynamic sprites that use more than 1 bnk instead of having extra patches with "!Freespace"
-Is a lot easier to edit Dynamic z sprites's Graphics
-You can use all the others features of Dynamic Z.
-Dynamic z has more support.
-Is a lot easier do a Dynamic Z sprite than a DSX sprite, even people without a lot of ASM Knowledge can create their own Dynamic Sprites.

There are a TON of reasons why a regular user would prefer Dynamic Z.

A tool i dont think is a good solution, there are only 28 dynamic sprites, do a whole tool for only 28 sprites i think is not optimal. Also do the remoderation shouldnt be very hard, just replace graphic and dynamic routine and do some small changes on animation routine, almost allthe job is made by Dyzen.

About "Numbers" obviusly Dynamic Z is new, The "numbers" argument is not valid because, how many people used romi sprite tool when pixi was new? How many people used AM4 or AMM when AMK was new? Obviously if a tech is new, the old will have more people,but that changes if that tech have support and staff helps making it a new standard.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
Average user will care about when some cool sprites for dynamic z will be uploaded, i already uploaded like 20this C3

i suppose as an average user, i have to say i don't think that the various DKC sprites you've made are as accessible to general level design as some of the current dynamic sprites are. it was impressive you released so many sprites, but i hesitate to see their use outside of your own project...

but i suppose i'm speaking more as my values as a level designer - i find the dkc sprites generally don't translate well into the interactions with how smw plays. it's hard for me to see the actual potential with dynamic z since the current dynamic sprites made with it aren't very appealing.

Originally posted by anonimzwx
-You can use the double or more Dynamic Z Sprites than dsx sprites on the screen.

how often is this a problem...?

Originally posted by anonimzwx
-Is a lot easier to edit Dynamic z sprites's Graphics

as someone who has edited dsx dynamic sprite graphics, i've actually found it to be pretty easy. you just open a .bin and edit it. doesn't really get simpler than that.
Throwing my support behind Dynamic Z.

I'm sure anoni has some good points about Dynamic Z's value for the average user, but for a second let's forget about the average user's experience with inserting/editing sprites.

Right now, there are eight (8) people who have created dynamic sprites. This is because creating dynamic sprites is an extremely daunting task without a tool like Dyzen.

To me, there's a clear parallel to the AddMusic revolution. In the early 2010s, only a handful of people were making sampled music ports, because the tools to make sampled ports were awful. Everyone just dealt with this and used unsampled music, and the regular user didn't complain, but every hack ended up a little less cool than it ought to have been.

The average user may not care how easy it is to make a dynamic sprite, but they do care that barely any dynamic sprites exist.

Anoni is not the only person making dynamic sprites with Dynamic Z. Codfish is too. If I had more time for hacking I know I would be.

In the discussion of advantages/disadvantages of a dynamic sprite remoderation, to me, advantage #1, by far, is Dynamic Z's compatibility with Dyzen, since it makes asm noobs suddenly capable of making dynamic sprites.

(To be fair, I do think there are disadvantages to a remoderation, including the effort required to convert the existing sprites, the lack of clarity in the current documentation, and the confusion of Dyzen being two separate programs for dynamic/non-dyanamic instead of being one program that handles both. Obviously it should mostly be on anoni to address these issues if a remoderation were to be considered.)
When i said tvat "i already uploaded 20" that is only the start, how many sprites do you think that will be on the future? Not only of dkc or nsmb, there are a ton of options for Dynamic sprites and as wyatt said, i am not the only one who creates dynamic sprites, codfish and wyatt also creates and i am teaching to use the patch to others asmers who also will creates dynamic sprites on the future.

About "edit sprites", edit graphics on format ".bin" is painful soecially if you have 50 or 60 frames, is a lot easier edit a png on a tool like aseprites or any other modern graphic editor.

Also i dont know how you feel confortable with only 4 32x32 sprites or just 1 of 64x64 on the screen even with Max Tile and sa1 in the patch moderation. It is obvious that is a heavy limitation of DSX.

If Dynamic Z solves any issue during and is ready to be approved, there is no reason to keep DSX, a remoderation is by far the best option for the community.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
About "edit sprites", edit graphics on format ".bin" is painful soecially if you have 50 or 60 frames, is a lot easier edit a png on a tool like aseprites or any other modern graphic editor.
I disagree with you on that. I prefer to edit bin files. On a similar note, I find that dsx bin files make more sense and are easer to edit. Yes, you do save more space, however we have up to 8MB of space. Also, I prefer not have to use tools to make sprites.
Filler
Originally posted by MarioriaM
I disagree with you on that. I prefer to edit bin files. On a similar note, I find that dsx bin files make more sense and are easer to edit. Yes, you do save more space, however we have up to 8MB of space. Also, I prefer not have to use tools to make sprites.


A regular Dynamic sprite without optimize space requires in average between 12 and 64 kb of space, it is true that you have a lot of space but, take in consideration levels, music, others graphics, etc... with optimize graphics you save between 20 and 40% of space.

Other consideration is the amount of sprites in screen if you dont optimize space, you use more oam tiles and vram, then you have less capability for sprites, also you say that because you only use yychr, tbh yychr is an awful and painful tool to edit graphics, specially when you do sprites, you cant do animations fine in yychr, any other modern graphic editor is a lot better than yychr, specially if you work with a sprite with several frames and animations.

About "a tool to do sprites" you still can do dynamic sprites manually if you want, Dyzen is not mandatory, but it saves a lot of time and work, if you want to do a dynamic sprite without dyzen you just do the gfx and you just call a few macros, almost all is done for Dynamic Z Library; you need to do the graphic routine and dynamic routine by yourself but is not very hard, dynamic routine is 1 line of code + do the tables, graohic routine is similar to the regular graphic routine but with very few changes.

Now i am almost sure that nobody wants to do that manually for that smwc only have 28 dynamic routines on the Sprite section.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Hey there, anonimzwx! Sorry it took a bit to get an "official" response to you, there's still quite a bit to unpack on the ASM front after this last C3.

I'll give you the direct, honest answer - Dynamic Z as it exists at this moment is not ready to become the new standard for dynamic sprites. We are not opposed to the idea of it becoming standard at some point, but this current version isn't quite the one. I've read your installation guide, and there are a small handful of lines like this:

Originally posted by anonimzwx
I Will improve the API of that system later to avoid that kind of problems.

Originally posted by anonimzwx
After Install the patch, you can Install it again, this sometime fix some problems with the Library set up. Sometimes if you don't do this, the Dynamic Sprites when appear on the screen doesn't point to Dynamic Z Library properly and can Crash, if you install twice that is fixed.

Bits like this tell me that Dynamic Z is still in need of some polish. In fact, the patch in waiting is explicitly listed as a Beta. I'd be rather wary about making anything with "Beta" right in its title into the new standard for anything. Would you be able to elaborate upon what elements are missing from a "complete," non-beta release? I did notice you have other features planned for Dynamic Z:

Originally posted by anonimzwx
I will add some features that will be available on V4.0 that I hope It will be the last Dynamic Z version such:

-Block Change System
-Two-Phase Dynamic Sprites Support
-Widescreen mode (SA-1 version only)
-50% More mode
-Add support to others popular patches that happends during NMI
-NMI Handler Optimization

Double-take at that last one:

Originally posted by anonimzwx
-NMI Handler Optimization: This is the most ambitious feature and probably will be completly incompatible with a lot of others resources, basically it replace the whole Vanilla NMI Handler routine and replace it with a custom one that is very well optimized saving a lot of cycles during NMI... Now it is a very big feature and probably i won't include it on Dynamic Z V4.0 because requires a lot of job. When i finish this feature, Dynamic Z will change of name and will be called Dynamic X.

Emphasis mine. Granted this last item is probably a very long ways off, but do you suppose that a re-written NMI will be an optional feature? Or will it be enforced as part of Dynamic X?

Another concern is Dyzen. There have been arguments that working with Dynamic Z sprites is difficult compared to DSX, and some of the counterarguments maintain that "Dyzen makes it easy". I notice the dynamic sprite version of Dyzen hasn't been submitted. Do you plan on submitting it later? It doesn't matter how easy it makes things if nobody can get it. I've not seen the tool itself, but I would hope there's no great learning curve involved - interest will go down if everyone is all but required to figure out both Dynamic Z and Dyzen together. Speaking of Dyzen, I'll remark that it's really not in your favor to have "Dyzen" (the dynamic sprite tool) and "Dyzen" (the identically-named but completely separate tool for regular sprites), not to mention "Dynamic Z which will become Dynamic X at some later date, not to be confused with DSX." Identifiability is important for a community resource!

I was going to bring up worries about Patreon-gated resources, but that issue seems to have come up elsewhere, so I trust we're all good on that end!



Usability and branding aside, concerns of "interest" were raised a few times, as well. Around the Discord server and forums, including this thread, response from coders and non-coders to Dynamic Z has been mixed. For one, the lack of backwards compatibility slows things down. I understand full well why you've chosen to eliminate support for DSX, it's a completely valid choice, but it means we have to be that much more picky about its replacement. I don't think the "preference" argument holds much water, on either side:

Originally posted by idol
do asmers actually prefer developing with dynamic z over dsx? are asmers unhappy that we host dsx instead of dynamic z? how do non-asmers feel about using dynamic z instead of dsx? i'd like to have that kind of input.

Originally posted by anonimzwx
During the last 10 years, only 28 Dynamic sprites of DSX are uploaded to SMWC sprite section, that say you a lot about how asmers feels with DSX patch

Nobody to my knowledge (aside from yourself, arguably) has stepped forward and said, "I have avoided creating dynamic sprites specifically because I hate DSX." Does this mean people don't care for Dynamic Z? Perhaps they don't really care about dynamic sprites at all? I think the whole question is "shooting at the wrong target," so to speak. I agree with pretty much all of Wyatt's post in that regard - it'd be a shame to turn away from Dynamic Z's potential, but I'd argue there's still some work to be done on your end. These are my recommendations, moving forward:

Continue to work on Dynamic Z
Obvious enough: the more complete and accessible the whole thing becomes, the greater it's odds of gaining a foothold.

Create comprehensive English documentation
This one is a bit of a balancing act. If Dynamic Z requires a 100 page technical manual to use and troubleshoot, it's not going to be very popular. At the same time, all of its features need to be explained well enough that the people who will be using them know exactly what they'll do, when to use them, and how. My personal suggestion is to break things down into a set of short "basic" instructions, and more detailed "advanced" instructions. The basic version should allow a non-coder to efficiently use or edit 99% of all dynamic sprites, and should allow a coder to build a "regular" dynamic sprite without any extra headaches. The advanced version would be for coders who want to tap into all the extra options and features, and who want complete control over what happens to their ROM. Then, after all this, consider seeking out the help of a native English speaker (and if possible, coder) to refine your documentation. I mean no offense with this! I think you're easy enough to understand in normal conversation, but to get such a technical resource standardized in an English-speaking community, every little bit counts.

Encourage people to use Dynamic Z
If enough of the community is receptive to and wants to try Dynamic Z, then making it the new standard will be that much easier. I would encourage you to keep showing off what the patch can do. I would also personally recommend showing off more stuff that doesn't use the pre-rendered look. Your own hack is a wonderful demonstration of this graphical style pushed to its utter limit in SMW, but I worry that you're accidentally creating a strong association of "Dynamic Z" with "pre-rendered sprites," which most hackers don't have a ton of use for. The Mets you showed off are a good start, but dynamic sprites are capable of so much more! Wyatt's boss, for instance, is an excellent example of Dynamic Z being used for super-smooth pixel art. Try to stimulate the development of dynamic sprites that the average hacker would want to use.



Originally posted by anonimzwx
Also some years ago, on ASM Subforum a pinned thread was created speaking about a "New Dynamic Sprite Standard" and a lot of people commented on that thread saying what should have a new "Dynamic Sprite" system, that thread was closed and sent to Trash Can when i replied that thread and released Dynamic Z V3.5, but the standard didn't change because Staff never did a remoderation.

This is a bit of an aside, but with all due respect this isn't fully accurate, and it colors staff response rather unfairly. That thread was never trashed, or even closed - it's right here. Yours was indeed the latest post, but the thread wasn't destickied until almost two full years later. The standard didn't change because there was no agreement as to what the standard ought to include; Dynamic Z and its options were brought up but not well explored, and the only other endorsement came from a single poster who didn't explain why. I just want it to be clear, we have nothing against you or Dynamic Z in particular; it's just not quite at a level of function and friendliness that we can confidently embrace it as a standard. With all that said -

Originally posted by anonimzwx
...i need a confirmation that this remoderation will exists on the future. It is not necessary to start it right now, but I would like to know if it can be done during this year.

- I'm afraid we aren't in a position to promise any timelines, either. The remoderation will exist when and if it makes sense for it to exist. We will continue to work with you as we have done to best figure out when that is.

And I'm sorry if this is too blunt, but those Dynamic-Z-dependent sprites you've submitted are going to be in waiting for an extremely long time. I pretty much guarantee it. As you yourself had noted, their acceptance or rejection has implications beyond a single sprite, so we'll need to weigh their moderation carefully.

Few will argue that what you've achieved with Dynamic Z isn't impressive. But the decision to make something into a standard for the entire community involves more than just raw technical superiority. I hope you can understand where we're coming from, on all counts.
Originally posted by anonimzwx
I Will improve the API of that system later to avoid that kind of problems.


That is from "Hue-Saturation-Value" System. not Dynamic Sprite System. Dynamic Sprite System is very solid. It is almost impossible that a big software have all perfect at the first try, The most common is sometimes change some elements of the API or things like that. In this case i am not very happy with the API of HSV System, i am planning to do some little changes to that system to make it easier to use.

Originally posted by anonimzwx
After Install the patch, you can Install it again, this sometime fix some problems with the Library set up. Sometimes if you don't do this, the Dynamic Sprites when appear on the screen doesn't point to Dynamic Z Library properly and can Crash, if you install twice that is fixed.


That will be fixed soon, for now i am not on Chile where i can work fine, i am traveling and i don't have enough time, i return in march 12 then i will improve that kind of problems, there are some little details to fix.
I spoke with Majorflare about that the other day, he said me that i should update the current version in waiting and all should be fine. Just i need a few time.

Originally posted by Maarfy
Bits like this tell me that Dynamic Z is still in need of some polish. In fact, the patch in waiting is explicitly listed as a Beta. I'd be rather wary about making anything with "Beta" right in its title into the new standard for anything. Would you be able to elaborate upon what elements are missing from a "complete," non-beta release?


It is a beta, because the "full version" i wanted to add the followed features:

-Block Change System: You can change any number of blocks of Layer 1 or Layer 2 without restrictions.

-Two-Phase Dynamic Sprite: A special kind of Dynamic Sprite that upload 1 half of a frame in one frame and the other half in other frame, allowing Very Big Dynamic Sprites sacrificing more space in VRAM.

Originally posted by Maarfy

After finish both features, It won't be a beta. As you can see is not a reason related to Regular Dynamic Sprite System.

Emphasis mine. Granted this last item is probably a very long ways off, but do you suppose that a re-written NMI will be an optional feature? Or will it be enforced as part of Dynamic X?


All features of Dynamic Z are Optative. Even the NMI Optimization. The idea is create a whole Framework that users can use the features that they want for they hacks. The reason why i want to rewrite NMI is because SMW NMI Routine is awful and very unoptimized, Von Farhenheit already did some experiments doing a Custom NMI Routine and he said that send 4 or 5kb of data per frame (Vanilla SMW just allows 2kb) is totally possible with a good NMI routine. That means that all limits of Dynamic Sprites dissappear with that.

Originally posted by Maarfy
Another concern is Dyzen. There have been arguments that working with Dynamic Z sprites is difficult compared to DSX, and some of the counterarguments maintain that "Dyzen makes it easy". I notice the dynamic sprite version of Dyzen hasn't been submitted. Do you plan on submitting it later? It doesn't matter how easy it makes things if nobody can get it. I've not seen the tool itself, but I would hope there's no great learning curve involved - interest will go down if everyone is all but required to figure out both Dynamic Z and Dyzen together. Speaking of Dyzen, I'll remark that it's really not in your favor to have "Dyzen" (the dynamic sprite tool) and "Dyzen" (the identically-named but completely separate tool for regular sprites), not to mention "Dynamic Z which will become Dynamic X at some later date, not to be confused with DSX." Identifiability is important for a community resource!


This have a lot of things that i will reply:

-Dynamic Z without Dyzen is not hard to use, It requires like 5 things:
Request a Dynamic Slot on the sprite init (1 line of code)
Do the Dynamic Routine (1~5 lines of codes)
Edit Graphic Routine (Requires like 3 lines of code)
Edit Animation routine to be 30FPS sync (not requires for 60FPS and needs likes 3 lines of code)
Do the tables to call the GFX.

I will explaing all those steps on the Tutorial, but in general it is not hard to do, the difficult is very similar to do a DSX sprite, They are always the same steps and you can save a lot of work using dyzen because Dyzen also do the GFX. Usually do the GFX of a dynamic sprite manually (for DSX or Dynamic Z) is a hard task that requires a lot of time, for example in my youtube channel i have a boss of Allen O'neil that i did some years ago, that boss required like 1 week to just do the GFX because it has several frames, The same today would take me just 2 hours and just because i must do the sprite sheet, not because Dyzen.

About Dyzen It does the GFX just pressing the button if you have a sprite sheet, also it does all the hard work for you then is very confy and fast to use, The reason why the Dyzen for regular sprites and Dynamic sprites have the same name is because is the same tool but i already didn't have time to merge both versions in 1. In the future both versions will be included on the same tool and you select if you want a regular sprite or a dynamic sprite.

About uploading Dyzen i am not Fully convinced about upload it to "Tool Section" because rule C1, I feel that i lose all my rights over the tool if i upload it here. I uploaded Dyzen for Regular sprites to Tool sections but to be honest that rule repel me a lot when i upload resources to this website, i don't have problems to upload it Dyzen on a Thread or the description of Dynamic Z, but i don't feel comfortable uploading it to Tool Section because It is a licensed software and i would like to keep my rights over that software. It always will be uploaded to the "Dyzen Workshop Thread" and Dynamic Z Description. Maybe if Dynamic Z start to be more popular i can upload that version to Tool section, but i am not sure for now.

Originally posted by Maarfy
Usability and branding aside, concerns of "interest" were raised a few times, as well. Around the Discord server and forums, including this thread, response from coders and non-coders to Dynamic Z has been mixed. For one, the lack of backwards compatibility slows things down. I understand full well why you've chosen to eliminate support for DSX, it's a completely valid choice, but it means we have to be that much more picky about its replacement. I don't think the "preference" argument holds much water, on either side:

Originally posted by idol
do asmers actually prefer developing with dynamic z over dsx? are asmers unhappy that we host dsx instead of dynamic z? how do non-asmers feel about using dynamic z instead of dsx? i'd like to have that kind of input.

Originally posted by anonimzwx
During the last 10 years, only 28 Dynamic sprites of DSX are uploaded to SMWC sprite section, that say you a lot about how asmers feels with DSX patch

Nobody to my knowledge (aside from yourself, arguably) has stepped forward and said, "I have avoided creating dynamic sprites specifically because I hate DSX." Does this mean people don't care for Dynamic Z? Perhaps they don't really care about dynamic sprites at all? I think the whole question is "shooting at the wrong target


Not really, when you have a bad support for something, it have very few users, because it is hard to use, it have several restriction, is bad optimized, etc. That doesn't mean that people will say "heey i hate X tech", that just means that people doesn't know about something better and just try to toe the line with the tools that already has. With dynamic sprites you have several options like sprites of Fire Emblem, Donkey kong country, metal slug, several indie games, NSMB, Super Mario Maker, etc... But nobody did them because work with that is very slow with dsx and very few people have time to use in that case of projects. That is what i want to change with Dynamic Z, do Dynamic Sprites more Accessible.

Originally posted by Maarfy
Create comprehensive English documentation
This one is a bit of a balancing act. If Dynamic Z requires a 100 page technical manual to use and troubleshoot, it's not going to be very popular. At the same time, all of its features need to be explained well enough that the people who will be using them know exactly what they'll do, when to use them, and how. My personal suggestion is to break things down into a set of short "basic" instructions, and more detailed "advanced" instructions. The basic version should allow a non-coder to efficiently use or edit 99% of all dynamic sprites, and should allow a coder to build a "regular" dynamic sprite without any extra headaches. The advanced version would be for coders who want to tap into all the extra options and features, and who want complete control over what happens to their ROM. Then, after all this, consider seeking out the help of a native English speaker (and if possible, coder) to refine your documentation. I mean no offense with this! I think you're easy enough to understand in normal conversation, but to get such a technical resource standardized in an English-speaking community, every little bit counts.


This is one of my priorities, I will do a quick guide and an advanced guide, This will be in spanish and English (spanish because is my main language, i will ask to a friend to translate it to english because my english is not very good and if i translate it, maybe it wont be very easy to read).

Originally posted by Maarfy
Encourage people to use Dynamic Z
If enough of the community is receptive to and wants to try Dynamic Z, then making it the new standard will be that much easier. I would encourage you to keep showing off what the patch can do. I would also personally recommend showing off more stuff that doesn't use the pre-rendered look. Your own hack is a wonderful demonstration of this graphical style pushed to its utter limit in SMW, but I worry that you're accidentally creating a strong association of "Dynamic Z" with "pre-rendered sprites," which most hackers don't have a ton of use for. The Mets you showed off are a good start, but dynamic sprites are capable of so much more! Wyatt's boss, for instance, is an excellent example of Dynamic Z being used for super-smooth pixel art. Try to stimulate the development of dynamic sprites that the average hacker would want to use.


Well those mets are "Semi-Dynamic", but yes i am planning to do sprites with others art styles, i did "Pre-Render Style" sprites first, because they looks very impressive and because it is for my Hack project, but i also wants to do sprites with others art styles like sprites from metal slug, paper mario and fire emblem that should fit better on a smw rom hack.
I am teaching to more asmers how to do sprites with Dynamic Z, i think that the best way to encourage people to use the patch is have more resources uploaded to smwc, then i am teaching to others asmers how to do dynamic sprites easy with the patch, also i am planning to do streams explaining how to use Dyzen and Dynamic Z and do things.

Originally posted by Maarfy
Originally posted by anonimzwx
...i need a confirmation that this remoderation will exists on the future. It is not necessary to start it right now, but I would like to know if it can be done during this year.

- I'm afraid we aren't in a position to promise any timelines, either. The remoderation will exist when and if it makes sense for it to exist. We will continue to work with you as we have done to best figure out when that is.

And I'm sorry if this is too blunt, but those Dynamic-Z-dependent sprites you've submitted are going to be in waiting for an extremely long time. I pretty much guarantee it. As you yourself had noted, their acceptance or rejection has implications beyond a single sprite, so we'll need to weigh their moderation carefully.

Few will argue that what you've achieved with Dynamic Z isn't impressive. But the decision to make something into a standard for the entire community involves more than just raw technical superiority. I hope you can understand where we're coming from, on all counts.


I know that those sprites will be on wait section for a long, but i want that people can download them easier, I would like to upload more (basically all sprites that i uploaded on C3) but Maxodex said me that is not a good idea because asm mods can give me a "section ban" if i continue upload them. Can i continue uploading Dynamic Z Resources during the year while it is on waiting section?.

About the last paragraph, I think that shouldn't be a big problem because there are only 28 Dynamic on sprite section, Obviously that number will be surpassed very easy on few time with Dynamic Z, as i said i will upload like 20 sprites and i did them just in 6 months, i will do more sprites during the year and also i am not the only user of Dynamic Z, there are more people for example wyatt, codfish and others asmers who i am teaching them, Use Dynamic Z is not hard for a regular user, you just use the "Dynamic Z Installer.exe" i think i will upload a version even easier to install later. Use the Dynamic Sprites is almost the same than use Pixi, then user shouldn't have any problem.

Obviously there are things that needs a change, specially i need to do the complete documentation and fix any little detail that cause problems, but i don't think they are a big problem to not allow Dynamic Z to be new standard, DSX is a lot worse in all things, we are speaking about a change like change from AM Carol to AMK, even that is a harder decision because AM Carol had several ports, DSX just 28 sprites. I would like if you can do a list of the things that staff would like a improvement and i can upload a version later with all that fixed.

My main problem is that i don't want to upload Dynamic Z if will happend the same than V3.5 that very very few people used it and never had a dynamic sprite remoderation then people couldn't use the features of that version properly, i know that you said "there was no agreement" but nobody on the staff said me something like "we are discussing about use Dynamic Z V3.5 as new standard but we have the following issues that needs to be solved". I don't have problem if the remoderation needs a lot of time, i just need to know if staff will help me with that, obviously if the remoderation will happend then i will help with all and do a lot of the work.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
-Dynamic Z without Dyzen is not hard to use, It requires like 5 things:
Request a Dynamic Slot on the sprite init (1 line of code)
Do the Dynamic Routine (1~5 lines of codes)
Edit Graphic Routine (Requires like 3 lines of code)
Edit Animation routine to be 30FPS sync (not requires for 60FPS and needs likes 3 lines of code)
Do the tables to call the GFX.

what? you understand this is... not something everyone knows, right? this isn't user friendly in the slightest. i'd argue that, realistically, dynamic z needs dyzen. the average user is not gonna know what code to do. not everyone is an asmer. in fact, the vast majority of smwc does not know asm. that isn't changing anytime soon.

Originally posted by anonimzwx
About uploading Dyzen i am not Fully convinced about upload it to "Tool Section" because rule C1, I feel that i lose all my rights over the tool if i upload it here. I uploaded Dyzen for Regular sprites to Tool sections but to be honest that rule repel me a lot when i upload resources to this website, i don't have problems to upload it Dyzen on a Thread or the description of Dynamic Z, but i don't feel comfortable uploading it to Tool Section because It is a licensed software and i would like to keep my rights over that software.

i understand that, but if you're suggesting a new standard for dynamic sprites that uses a tool, we need that tool in the smwc tool section to link to. we wouldn't standardize pixi sprites and then not host pixi. if you're not comfortable with hosting dyzen (dynamic sprite verwsion), thats fine, but we can't standardize dynamic z without it.

that being said...

Originally posted by anonimzwx
but nobody on the staff said me something like "we are discussing about use Dynamic Z V3.5 as new standard but we have the following issues that needs to be solved"

maarfy did, and considering he's an asm section manager the concerns he had should probably be addressed before we move forward with this.
Originally posted by idol

what? you understand this is... not something everyone knows, right? this isn't user friendly in the slightest. i'd argue that, realistically, dynamic z needs dyzen. the average user is not gonna know what code to do. not everyone is an asmer. in fact, the vast majority of smwc does not know asm. that isn't changing anytime soon.


Doing a dsx sprite manually is the same difficulty, please don't give an opinion if you don't have the technichal knowledge to reply. An average user doesn't do sprites or asm, that is for developers. Half of the dynamic sprites i did them without using dyzen. You can use Dynamic Z without Dyzen, i will include how to do that on the documentation.

Originally posted by idol
i understand that, but if you're suggesting a new standard for dynamic sprites that uses a tool, we need that tool in the smwc tool section to link to. we wouldn't standardize pixi sprites and then not host pixi. if you're not comfortable with hosting dyzen (dynamic sprite verwsion), thats fine, but we can't standardize dynamic z without it.


Again you are confusing "use sprites" with "create new sprites." Dyzen is an extra tool that you can use to save time when you create the sprite. You can make them manually if you want, too, but nobody is forcing you to use Dyzen. This is almost like not making AMK the standard because NintSPC isn't hosted in SMWC; the situation is the same: a tool that helps create a resource that you can insert with its respective tool/patch, but one that's not needed in the slightest. I shouldn't be forced to create a tool for making dynamic sprites without ASM knowledge in order to make my patch a standard; that wasn't a requirement for any other tool or patch in the site and it's unfair to expect me to comply to that.

If you want me to upload that version of Dyzen to SMWC then make an exception about rule C1 and allow me to keep my rights over my licensed software or wait until Dynamic Z becomes popular and people want to use Dyzen.

Dyzen will be hosted for now in other place and linked on Dynamic Z Description and on the thread about Dyzen Workshop.

Originally posted by idol

that being said...

Originally posted by anonimzwx
but nobody on the staff said me something like "we are discussing about use Dynamic Z V3.5 as new standard but we have the following issues that needs to be solved"

maarfy did, and considering he's an asm section manager the concerns he had should probably be addressed before we move forward with this.


That 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.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
If you want me to upload that version of Dyzen to SMWC then make an exception about rule C1 and allow me to keep my rights over my licensed software or wait until Dynamic Z becomes popular and people want to use Dyzen.


Would rule C1 makes you lose the right to your stuff in any way? It seems to me like it just allows smwcentral to host and redistribute it. It says "non-exclusive" after all. Either way we're all pirates so it seems like a strange thing to care about honestly

love this thread btw

allow shy guy emojis in post footers you cowards!
The reason Rule C1 exists is essentially so that if people who submit things get pissy for one reason or another, they can't just go off and say "Fuck it, since I'm angry* I'll make sure I'm not the only one that suffers," a mindset which usually results in making sure nobody else has access to the stuff they submitted. Rule C1 from what I understand simply allows people to continue to download the resources you've made available.

It's one thing if you want stuff removed because either it doesn't function or it's just shit, it's another to remove a resource simply because a person is pissed off; and that's why Rule C1 exists. As far as the rest of Rule C1 goes, nobody out here is an asshole enough to largely modify a file that somebody submitted unless it's to fix a bug or something, and most of the time if the user that submitted the asset is around, they'll be the one asked to fix bugs or something similar.

All in all, your stuff is still yours, just once you submit it through the official system, you give up the right to "take away its access to other people".
In any file hosting service you have the option to delete your own resources, especially if it's licensed software. Even Github with very important projects used by thousands and even millions of people allows you to delete said reprositories.

Rule C1 is a disrespect toward any content creator and I'm almost sure it's illegal for licensed software. The reason behind it isn't good because it's your own resource and you share it with others if you want; it's not SMWC's property. If someone wants to delete their resources it's their decision, even if the users or staff don't agree with it. Also, I'm not the type of person to remove important submissions from a site because I'm pissed off, I just want to keep control over my own resources and I don't like that SMWC is forcing me to resign my rights because of an arbitrary and unfair rule.

Now let's please return to the main topic; this thread is meant to discuss Dynamic Z. Dyzen and Dynamic Z are two separate things that don't need each other to function. I can't stress this enough. Maybe later we can open a thread discussing rule C1 or whether I'll upload the latest Dyzen to SMWC, but discussing that in this thread is only going to derail it further.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
  • Pages:
  • 1
  • 2