I did install a 2nd time and added gnawty in my hack. Now it works, but there are other problems. If I stomp on one, I die or worse, the game crashes.
Was I suppose to install Dynamic Z after it was installed? Because in my case, I close the installer, reopened it and specified the paths and installed it and after all steps, it did me to a half-working dynamic sprite.
That probably is because that sprite uses the DKC Contact Effect, you can deactivate it on the routine "DisplayContactEffect" to use the vanilla white star.
I am checking all the sprites to be sure that all works fine on vanilla rom, i am uploading them to sprite section, soon all of them will be on sprite section.
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.
About Dyzen. One feature would be to tell what color doesn't belong to the palette and where is located. That might be nice.
Dyzen says you that message when your sprite sheet has more than 16 colors (15 colors + 1 of transparency), you can use aseprites or any tool to decrease colors to know how much colors has the image, on the future probably i can add a feature to reduce number of colors.
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.
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.
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.
-Paper Mario's Putrid Piranha (Include Boss Version).
-Big Version of DKC2's Zingers Boss.
i'm just catching this now - i'm sorry, but are you planning to paywall some of your smw hacking projects...? or are they free on your patreon but you just dont plan to post them here...?
I upload almost all for free, only very special content is for myself or my patreons. My projects are just a hobby, i dont need a patreon tbh but i have one because i like to see that there are people who support my projects and sometime i give things to them like help them with asm things, do sprites or things like that.
In the case of those sprites, putrid piranha is still in development and i will upload it on the future here but patreons have early access.
King zing is a sprite of my hack, it will be available for everyone some months after release my hack with all the content of my hack, my patreons will have early access to that boss.
It Is dumb think that i am doing this for money, it is a horrible bussiness, A lot of time for very very few profit, i do this just because i like to do asm and i like that people use my resources.
Sorry for the rude reply earlier, whenever you feel like claiming the request, feel free so.
About the graphics, They were made to be easier to work with for asmers as the Armadillo himself has a lot of moving parts. Also, zsnes is really not a good emulator, so I will send a savestate in Snes9x. I hope that helps.
It's the same one used in the video I showed. I'm not sure why you would need it but I won't judge ;p
(Maybe you want him to be dynamic? If so, that would be poggers!)
Lots of love, S1Z2
I need a zsnes savestate to open it with yychr, that sprites is not dynamic, could be done as a regular sprite, if i open on yychr the zsnes savestate i can rip that boss very easy.
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 spritesyou'vesubmitted 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.
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.
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.
Finally i returned from my travel and i can work again.
What will be New?
-SpriteSheet2DZprite: It is basically a tool similar to Dyzen but without GUI, It takes a sprite sheet and transform it into a sprite (a file .asm) with all the tables and code to do the dynamic sprite, also return a GFX and palette for that sprite. It is basically a standalone version of the "Load Sprite Sheet" feature of Dyzen.
-Block Change System: Basically my own implementation about Imamelia system to change Blocks on the fly, with this system you will be able to change all the blocks on the screen in just 1 frame, allowing dynamic level changel, Probably on the future i will do a tool to help with this feature because this kind of features usually are ASMER only and i will try to make it for everyone.
-Two Phase Dynamic Sprite (AKA Giant Dynamic Sprite): This is a way to do Dynamic Sprites that bypass the limit of size sacrificing more space in VRAM, with this feature, do dynamic sprites of 96x96 or 112x112 is totally possible.
-Improved API for HSV System, now will be a bit easier to use that system.
-Full Documentation in spanish and english.
What is improved?
-Dynamic Z Installer: Will include the news features and also will fix some messages and things of the GUI. Also now will be more automatic, with only Dynamic Z Installer you can install Dynamic Z in one click.
-DRAdder: Some messages of the tool will be fixed them, also will include some error messages for common user mistakes.
-Will fix a bug that happend with the current version uploaded that happend in lorom using hsv and palette features. For some reason the patch crash when those features are installed.
-Fix the "Double installation bug" for some reason the patch sometimes requires to be installed twice to work fine.
-Fix all problems related with installation.
-Fix problems with patches that uses hijack $00A300 (Like Retry System) that requires to be installed after Dynamic Z.
Current Sprites and resources:
-Fix all problems with interaction and random crashes then upload them.
-Change the code of current dynamic sprites to use Vanilla SFXs.
-Codes for uberasm using differents features of Dynamic Z.
-Templates of sprites or players.
I would like guys if you can give me feedback about the current version and any problem that you would like to fix or improve to add it to this version.
CLASSES OF DYNAMIC SPRITES
Anyone who wanna learn how to do Dynamic Sprites can send me a DM in discord and i can teach how to do that, i recommend know at least a bit of asm knowledge to understand how to do basic things in asm.