Language…
5 users online: fanfan21, JinRokhZenobi, Klug, Shiki_Makiro, Swag - Guests: 60 - Bots: 81
Users: 68,016 (2,140 active)
Latest user: rmurso88

Posts by JamesD28

JamesD28's Profile → Posts

File Name: Ceiling Thwimp
Added:
Authors: Mandew
Tool: PIXI
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: No
Description: A Thwimp that jumps down from the ceiling, rather than up from the floor.

Made me realize just how much of SMW's actual programming can be really dumb to work with P:
Screenshots:
Obsoleted by a newer version.

A backup can be found here.
anonimzwx, it's important to remember that you're the one who's pushing for the standardization of Dynamic Z. No-one's trying to take your rights over what you've made - that's not the purpose of rule C1 (it even explicitly states "SMW Central does not own your file") - but the rules are there and everyone who submits anything agrees to those rules. We've never bent them for anyone who wished to submit something and we certainly can't make exceptions when it's regarding resources that could end up being a site standard. You can't push for us to make your tools a site standard and then also demand that they be exempt from the rules of the site you want them standardized on.

Originally posted by anonimzwx
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.


Everyone is entitled to give their opinion regardless of technical knowledge. They're going to be the ones who use Dynamic Z sprites should it become standard, and their thoughts on how easy it is to use are just as valid. They might not be making the sprites, but if they want to say, edit graphics, then they'll be interacting with the system and the sprites to do that.

While we're on that sentence, I'm also interested to know how doing a DSX sprite manually is the same difficulty - in my experience with using DSX, it's far easier. DSX sprites use a standardized graphics arrangement - 32x32 frames ordered from left to right, top to bottom. This means that they're accessed by a single index, and therefore the routine that DSX sprites use is always the exact same. You don't even need to make a routine or tables for DSX - you can copy it from another DSX sprite, change the number of dynamic_frame entries to match your number of frames, and it'll just work. DSX is a basic system, sure, but that works to it's advantage here.

You say that doing a Dynamic Z sprite without Dyzen isn't hard, and you list off the things you have to do, including the GFX tables - but you glossed over how much tedious work it will actually be to do the tables for the GFX, even for ASMers. I've seen the asm of Dynamic Z sprites, generated by Dyzen, and there are a lot of tables. This can also be seen in your video on editing graphics with Dyzen, specifically at 2:45 and 3:23. Unless you already have a very good understanding of what those tables are and do, and how the data is structured, it's unreasonable to expect anyone (ASMers included) to write those tables from scratch without Dyzen. More importantly, it will be impossible for non-ASMers to edit graphics without Dyzen, if doing so requires those tables to be changed. It's entirely unreasonable to expect non-ASMers to rewrite those tables from scratch any time they change the graphics. Judging by that video, editing graphics for Dynamic Z sprites is already difficult enough - editing graphics with DSX never requires you to go into the .asm and change any tables, unless you're adding/removing frames, and even then, you're just adding/removing dynamic_frame entries - not deleting and pasting dozens of tables from one .asm to another. But people editing graphics for Dynamic Z sprites will still be relying on Dyzen to generate those tables for them in the first place. Therefore, unless a solution is found for graphics editing which doesn't require editing so many tables, I very strongly believe that Dyzen is required - therefore, it's also relevant to this thread. You mention that you will include documentation on how to use Dynamic Z without Dyzen (and hopefully it's easier than what seems to be the current method), but this is honestly stuff that should have been sorted out before pushing the system forward to be a standard. There's a lot of "I will", and while I believe that you'll follow through on these things, I'm very hesitant to standardize a system now that's very dependent on things that will be done in the future.
It's worth mentioning that every tutorial/guide you've put out so far has been with the usage of Dyzen, and in your C3 thread (and even previously on this thread) you always mentioned Dyzen when talking about using Dynamic Z and how easy it makes things. To then turn around here and say "nono you can do it without Dyzen it's easy" seems odd to me.

It's also not as clear cut as "using sprites" vs "creating new sprites" - users may want to edit and tweak existing sprites to their liking, even if they might not know ASM. In that case it's important that the system is clear enough so with a bit of guidance, users can change things about the sprite with relative ease (as mentioned above, editing graphics for example). Making the system only understandable to ASMers and otherwise assuming "well those people don't know ASM so it doesn't need to be possible for them" is a bad mindset, and is only going to hurt the accessibility of the system.
Creator's bias is a thing too - you built Dynamic Z yourself, and everything about it was made based on what you thought it should be. Therefore, you understand everything about how the system works, and using it is very easy for you - but that doesn't mean it will be easy for everyone else.

Originally posted by anonimzwx
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.

I believe idol meant Maarfy's comments about this version, V3.75.

Finally: I don't want to put too much in this post at once since otherwise stuff could get missed, but I do have one suggestion/concern about Dynamic Z that personally I think should be addressed first if the system is going to be standardized. Currently, the dynamic routines use the vanilla SMW misc sprite tables for their own purposes. Examples of this are !C2 as !SpriteMiscTable3, !1504 as !SpriteMiscTable4 and !151C as !SpriteMiscTable6. My issue with this, is that many sprites rely on these misc sprite tables to use for their own behaviour, and some vanilla sprite routines (such as the SolidSprite routine at $01B44F) rely on these tables as inputs for the routines to function properly, or modify them based on certain conditions. It looks like Dynamic Z has defines for all the misc tables, which makes me think it's possible that they can all be reserved by Dynamic Z. In this case, how is the sprite supposed to utilize any RAM for it's own behaviours/functions? I worry that if these tables are reserved by Dynamic Z then there won't be enough left for the sprite to do it's own functions (especially if it's a complex sprite that needs to hold a lot of data in RAM/tables), and I could see this potentially being a problem when it comes to remoderating the SMWC dynamic sprites.
Additionally, there is a bit of concern with Dynamic Z reserving extra byte 1 for internal use - when a sprite uses more than 4 extra bytes, extra bytes 1-3 hold the pointer to the extra byte data's location in ROM. Will this not conflict with Dynamic Z's reservation of extra byte 1, and cause an error inside Dynamic Z or cause the extra byte data to become inaccessible since the low byte of the pointer is overwritten by Dynamic Z's code?
Personally, I would prefer it, and think it would be much safer and more convenient, if Dynamic Z reserved a chunk of freeRAM for it's own tables, instead of clogging up the SMW misc sprite tables/extra bytes. That way, there's no conflict between what Dynamic Z needs the tables for and what the sprite itself might need the tables for.

I think that sums up my thoughts for now, but:
I'll also use this post as an opportunity to ask you to double-check the Dynamic Resources Adder included in the V3.75 you submitted to the Patches section, as neither me nor KevinM were able to get it to work when trying to insert stuff.
File Name: Ganon (1.0)
Submitted: by Von Fahrenheit
Authors: Eminus, Von Fahrenheit
Tool: PIXI
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: Yes
Description: GANON! That's right, it's Ganon. This is a boss sprite, and a pretty involved one at that. It should be placed in a room that is 2 screens wide with no pits in the floor. Will not work in vertical levels.

Ganon has a lot of defines and is pretty customizable, though he is designed to work primarily with the default settings. Ganon has full interaction with Yoshi. This boss was designed to be a believable take on Link to the Past Ganon in SMW, sort of how we imagine it would be done in Mario Maker. This boss is designed around the player being able to attack at any time, and as such the boss has a very high abount of HP by default.

See the comments at the top of ganon.asm for more information.

Requested for the Strongest Sprite Workshop 2020 by lordkronos100.
Screenshots:
The sprite works rather well, but there's a few issues that need to be fixed before it can be accepted.

The main issue is that when using the No More Sprite Tile Limits patch (and thus SA-1), there are graphical glitches during the phase when Ganon throws a trident. Some of the trident's tiles disappear when in Ganon's hand, but more importantly, it causes the lightswitch block's graphics to glitch out - the tiles will either disappear, move to another part of the screen, or replace the tile of a different sprite (glitching that sprite too). In some cases, parts of Ganon disappeared too.

The other issue is that the fire bats can be starkilled and will simply freeze in place, unable to be killed or despawned (sometimes, this affects other bats too). This can quickly eat up sprite slots (especially on LoROM), and can make it so that new bats can't be spawned.

In some cases Ganon seemed to go idle, and wouldn't attack. I couldn't reproduce this issue often enough to determine a cause though.

Finally, I would add a note somewhere that the !endlevel define glitches out layer 1, due to enabling the "vertical layer 1" bit to freeze Mario.

Tested with:

• Lunar Magic 3.21
• SA-1 Pack v1.32
• PIXI v1.32
• Snes9x v1.60
• bsnes plus v05
File Name: Red Coin
Submitted: by Friday_D0nat
Authors: Friday_D0nat
Act As: 025
Includes GFX: No
Description: A red coin that gives a powerup when all 8 of them have been collected (default powerup is flower, but it can be changed in the .asm file). It plays a sound effect when collected. It doesn't overwrite the item box.

(Inspired by NSMB's red coins)



It uses $7E0058 which is unused, but in the case it is used, it can be changed.



First .asm related submission, yay!
Screenshots:
The block almost works properly, but there's a few issues that need to be fixed before it can be accepted.

The first issue is that the sound effect affects how many coins are needed to get the powerup. This is because you're adding the freeRAM to the SFX value, then checking if it's equal to #$1A (which only works for 8 coins if you're using SFX #$13).

The second issue is that the default freeRAM $58 is not cleared on level load. This means if you collected 7 coins in a level, went to a sublevel, then returned to the main level and collected another coin, it would register as the 8th coin. Since tiles inserted from direct map16 always respawn, this could be used to farm powerups.

Finally, there are some optimization issues with the code which I don't think can be ignored. You're using BRL to jump from Mario labels to the "Collect:" label, which wastes cycles and bytes. You can simply re-order the labels so that all the labels you want to run the code for, are placed above the code. For example:

Code
MarioAbove:
TopCorner:
BodyInside:
HeadInside:
MarioBelow:
	Collect:
	code


Alternatively, you can edit the JMP instructions themselves, replacing the "JMP MarioAbove", "JMP MarioBelow" etc. with "JMP Collect" for all the labels you want to run that code.

Likewise, you don't need to put RTL under every label which you don't want to run code. You can simply re-order them like I mentioned above, and have them all converge on a single RTL.

While not a rejection reason, it would be nice to add SA-1 compatibility (this is why it wasn't working for AyGaAlPa, btw). All you need to do is put "|!addr" without quotation marks on the end of every 4-digit address (e.g. $0DC2|!addr). You can also put "|!bank" on the end of $028008 to give a tiny speed boost for fastROM users.

As a nitpicky sidenote, please don't include defines which aren't used (!Amount in this case).

Tested with:

• Lunar Magic 3.21
• GPS V1.4.21
• Snes9x v1.60
• bsnes plus v05
File Name: Red Coin v1.1
Submitted: by Friday_D0nat
Authors: Friday_D0nat
Act As: 025
Includes GFX: No
Description: A red coin, if you collect 8 (by default) of them, you get an item as a reward (flower by default). It also plays a sound effect, and it doesn't overwight the item box.

Inspired by NSMB's red coins.

Added SA-1 support, a way to change the amount of coins to collect for the reward (+/-), optimized the code and made it more user friendly.
Screenshots:
There's now a different issue with the sound effects - it's coded that if the SFX value + the current freeRAM value is greater than or equal to #$1A, then it will just play sound effect #$19. This makes it impossible to use effects #$1A+, regardless of how many coins have been collected. There's really no need to compare the sound effect value against anything - Just check the value of the freeRAM, and if the required coins haven't been collected yet, just add the current freeRAM value to the base SFX value and play it.

There's also a missing |!addr define for $0DC2, which on SA-1, results in a copy of the item currently in the item box being dropped (or nothing if the item box is empty), instead of the user-defined powerup.
Please test resources thoroughly, both to ensure there aren't any bugs and to make sure it works properly on all the formats it claims to support.

Additionally, there's still an instance where you're using BRL to jump to another part of the code. BRL is usually only used when jumping a greater distance (e.g. to different codes), and even then, JMP is better for that. For jumping short distances like in your block, you can use BRA, which is smaller in bytes and usually slightly faster.
This on it's own wouldn't be a rejection reason since it's only one BRL and the speed loss is minimal, but it's something worth knowing.

Tested with:

• Lunar Magic 3.21
• SA-1 Pack v1.32
• GPS V1.4.21
• Snes9x v1.60
• bsnes plus v05
Originally posted by quietmason
This should be possible to do yourself, using STEAR.

STEAR remaps tiles from one spot in the SP space to another. Putting Yoshi's tongue/neck tiles in GFX33 would also require uploading them to VRAM via DMA, which is something entirely different and well beyond what STEAR is capable of.
Without seeing your files it's hard to know what the cause could be. I recommend that you upload the custom Vine asm and the block asm to your filebin, then link them here.
Claiming this.
We can't really have arbitrary rules about certain things people should be doing when making ASM. The same could be said for a lot of things, like "Make sure you add RTL at the end of your UberASM code" or "Your sprite must use a bank wrapper", both of which are things that very often need to be done, but not always. When you're learning to make those resources you're going to learn the basic checks/setup that needs to be done, so adding rules like that would be nothing more than a "Don't forget!"
Address Length Type Description Submitter
$7FAB34 12 bytes Sprites Custom sprite table used by Pixi.
It holds the second extra property byte of the sprite.
KevinM
Address updated with additional information.
Address Length Type Description Submitter
$7E187B 12 bytes Sprites Miscellaneous sprite table. Has the following purposes:

Sprite stomp immunity flag table - enables stomp immunity for sprites if the flag is set.
Additionally, the changing item sprite uses it to determine which sprite it is (#$00 = mushroom, #$40 = fire flower, #$80 = feather, #$C0 = star), the goal tape determines by this address whether it activates the normal or secret exit, the radius of rotating chain sprites is held by this address, certain Yoshi abilities are handled, etc. More information can be found here.

$7E:1884 is also used to determine what background should be used during the Morton/Roy/Ludwig battle scene. #$00 = Ludwig; #$01 = Morton/Roy.
There is also a bug with the background flames during the Ludwig battle, as they seem to change color upon this address not being #$01. This is responsible for a palette glitch in the original SMW, where the fire turns a greyish blue very briefly. Change $02:8380 to #$80 to fix the bug.
System
Address updated with additional information.
File Name: Lock mario in place with L or R
Submitted: by ageVerrly
Authors: ageVerrly
Type: Level
Includes GFX: No
Includes Hijack: No
Featured: No
Description: I was asked for this very simple level ASM multiple times so I think it is a good idea to upload it.

All this does is set mario's position next frame to his position this frame if L is pressed. That means momentum is stored and can be gained even when locked. You can gain p-speed that way and change your direction midair.

Works in vertical levels as well.
Screenshots:
Rejecting for 2 main reasons:

The first is that the code is able to run in places where it shouldn't, including the No Yoshi/Castle/Ghost house intros, and during the goal walk sequence. A more fatal place where it can run is during pipe transitions - Mario can lock during the pipe exit, trapping him inside the pipe and killing him. Checks should be included so that the locking only occurs when the player has full control over Mario. Additionally, locking Mario during an autoscroll can push him past the screen boundary and kill him.

The second issue is that the code is unoptimized - You're using long ($xxxxxx) addressing for direct page addresses ($D1-$D4 and $94-$97). RAM in bank $7E from $7E0100-$7E1FFF can use absolute ($0100-$1FFF) addressing, and RAM in bank $7E from $7E0000-$7E00FF can use direct ($00-$FF) addressing. This reduces both the insert size of the code, and the processing load (runs faster). You already did this with $17, it just needs to be done for $D1-$D4 and $94-$97 too.

While not a rejection reason, it would also be nice to have SA-1 compatibility. All that needs to be done is to put "|!addr" without quotation marks on the end of $1401 (provided you also reduce the Mario position RAM to direct addressing as mentioned above).

Finally, please add relevant tags when submitting.

Tested with:

• Lunar Magic 3.21
• UberASM Tool 1.4
• Snes9x v1.60
• bsnes plus v05
That define is a bit misleading - that's actually the RAM address where the properties are stored to for one of the tiles. The actual properties value used is just read from $64. Find this:
Code
LDA $64

and replace it with
Code
LDA $64
ORA #$xx

xx being the properties value you want to use. For palette 09, it would be
Code
LDA $64
ORA #$02
File Name: Lock mario in place with L or R
Submitted: by ageVerrly
Authors: ageVerrly
Type: Level
Includes GFX: No
Includes Hijack: No
Featured: No
Description: I was asked for this very simple level ASM multiple times so I think it is a good idea to upload it.

All this does is set mario's position next frame to his position this frame if L is pressed. That means momentum is stored and can be gained even when locked. You can gain p-speed that way and change your direction midair.

You can die if you lock mario during an autoscroll as the screen will go past him.

Works in vertical levels as well.
Screenshots:
The code almost works properly now, but there's one issue; $88 is set on contact with a pipe, not when you enter a pipe. This means that if you step on/touch a pipe, the locking mechanic gets disabled for the entire level and screen scrolling is re-enabled, even if you don't enter the pipe. I recommend using $71 (the player animation trigger) to do these checks - the RAM map lists all it's values and the corresponding states for those values.

As a side note, you don't need to CMP #$00 to check if something is 0 or not - just loading a value into the accumulator sets/clears the zero flag.

Tested with:

• Lunar Magic 3.21
• SA-1 Pack v1.32
• UberASM Tool 1.4
• Snes9x v1.60
• bsnes plus v05
Originally posted by skyekun
I'm getting an error in pixi

"An error has been detected:
[pathway]/pixi_v1.2.14/sprites/eerie_vert.asm:131 (called from [pathway]/kaizo/pixi_v1.2.14/sprites/eerie_vert.asm:131): error: (E5094): Macro 'FinishOAMWrite' wasn't found. [%FinishOAMWrite()]"

Update your version of PIXI. The FinishOAMWrite routine was added in v1.3.
Originally posted by RollingRigatonis
I am trying to insert something into the Lemmy boss sprite without resorting to custom sprites but when I patch the rom, defeating Lemmy crashes the game. What am I doing wrong?

Code
!Base1 = $0000
!Base2 = $0000

org $03CEA0
	autoclean JML Test
	NOP

freecode

Test:
STA AA,x    
JSL $01801A
LDA #$01
STA $0DD5|!Base2
RTS

You can't RTS to end a routine when you've jumped to freecode that's in a different bank. What you need to do is jump back to the game's vanilla routine. In this case the vanilla routine ends at $03CEA6, so you can jump back to there with JML once you're finished with your custom code.
Event numbers work so that a level's normal exit triggers event X, secret exit 1 triggers event X+1, secret exit 2 triggers event X+2, and so on. If you put a secret exit in a level you also have to reserve the next event number for it. Assuming there's only one secret exit in level 4, you should make the Castle use event 6 instead.