The Overworld Design Contest ends in
Views: 905,558,098
14 users online:  AmperSam, Chim, l337f00l,  MarioFanGamer, Natsuz2, Panicdream1, Rammy, Rotciv, SethOsDotEXE, SMWFan2019,  Telinc1, the_pilger, Ultima, WhiteYoshiEgg - Guests: 53 - Bots: 81 Users: 50,758 (2,068 active)
Latest: Florian1996
Tip: If you edit Level 0, make sure you also edit Level 100. Both of them are used for the bonus game depending on the level you're in.
Not logged in.
*solved* looking for pointers for creating 'ddr-like' non-interactive moving arrow sprites
Forum Index - SMW Hacking - SMW Hacking Help - *solved* looking for pointers for creating 'ddr-like' non-interactive moving arrow sprites
Pages: « 1 » Link
edit (2020-11-20):

Note I will submit the sprites and open source the code after I've released my hack. Until then if you want to re-create this here are the general steps:

1. I built a set of custom sprites for the arrows and A/B (non-interacting, act-like 25).
2. I based the movement off the 'Angry Sun' sprite to keep x/y positions on the screen constant while mario moves.
3. I chose the speed to be 0 in the x, and some value in the y corresponding to how frequently I am spawning the arrows (this is dependent on your BPM, so it will change depending on what song you sync it to).
4.I made my own level uberASM based on the shell shooter uberASM to dynamically spawn the sprites (status 08 instead of 09). It reads in a byte sequence to determine which sprite to spawn, and does so every x frames (where x is dependent on your BPM, for 90BPM I think I used 36.75 frames average).
5. I am checking if the user holds down the corresponding button when the sprite is in the y-range to determine if they hit the step early/on-time/late
6. I increment the score counter when the detection in 5 succeeds.

Note I have everything working except step 5 (detecting when the sprite is in a specific pixel range has proven difficult for me). When I solve it I will update this post again.


original post:

I am working on a proof of concept mario hack centered around music and controlling mario with a dance pad (think ddr-like). I am in the early stages but am looking for ideas on how to approach creating moving arrows that go from the bottom of the screen to the top. Even just a few nudges/hints in the right direction is helpful. I will also admit this is my first hack, so I am sorry if there is an obvious answer I have missed.

The requirements I think I need:

1. the arrows don't interact with mario or other sprites (display only)
2. can somehow represent button holds by either repeating the arrows (sprite limit?) or elongate them for the duration of the button press.
3. have the timings consistent so I can script them in time with the song (I assume if I set spawns to an absolute position on the screen and always spawn at the same y-position that this should be relatively easy to keep consistent).

I have a background in embedded software engineering (but admittedly haven't done any actual embedded software for a few years now) so even an idea in pure asm no matter how 'advanced' would be incredibly helpful.

See the image at the bottom for a reference to the types of arrows I am talking about.

My ideas so far:
1. Create an ExAnimation in layer 3 for each arrow and the jump buttons, and somehow control when they play and make multiple play at the same time.
2. Use the skull platform and somehow make it non-interactive, but I don't know how to make it variable length like in smm2.

Some more background on the project if anyone is interested:

I wanted to create something fun that would keep me active during winter. I am aware level design will be a challenge since 'hold right' doesn't exactly work well with ddr style games but that's part of the fun for me. I've been toying with procedural level generation for a while now, and the thing I am thinking of doing is choosing the song, getting the required choreography/inputs and timings, then generating a level around those inputs.

An anonymous user on 4chan has actually successfully implemented a very Stepmania-eqsue version of what you are thinking of making, and the example can be seen in the "party" special world level in this hack:

You can try sending a PM or email to vhack2 and someone connected with a project may be able to reach the anon that coded it, hopefully who is willing to give you some insights, try posting in the hack thread becauze they sometimes check it, or if there is no response, try making a thread on /v/ where it was organized (bear in mind, /v/ moves incredibly fast and your thread is likely to be buried. If that happens, /vr/ allows ROM hacking threads and it's not unlikely that someone in a /v/ SMW collab views /vr/ on the side.)

Landing on that room is a chance because it's reached by a Mario Party-style board and dice roll, so you may have to savestate until you get there. You can selectively disable layers and see what layers the arrows and input sections are run on, and view the level in Lunar Magic to see where any blocks, sprites, scrolls and generators may be placed, although you get no tooltip telling you what they do. You obviously won't be able to know the code they used, but get an idea for how it was set up.

Here are my thoughts on making your own, though there is probably a more optimal way:

1) The common non-solid property is 025, which you can define in Lunar Magic to make any block passable by Mario and sprites. That said, you will want blocks specifically designed to run a routine for checking specific button input when touched by a sprite, increment score, and destroy the sprite. I don't think the sprite itself has to do much other than have a graphics routine to display a frame of an arrow and move straight, If the sprite goes beyond the threshold, or the nearest arrow to the threshold has not touched it yet when up/down/left/right get pressed, maybe the sprite could decrease your score upon that destruction trigger by a set amount, but be sure that anything that would underflow would be set to 0 instead. Why this way? - Blocks only run script when touched by a sprite, but sprites run behavior just being there at all. I think this combination is the best way to set up this sort of feature.

This is the perfect block to base out-of-bounds destruction and score decrement on, as well as score increment on button input when the sprite touches the block:
An UberASM patch could be done to checked if up/down/left/right are being touched when no sprite has reached the determined threshold, and decrement your score for a "miss."

2) RAM addresses $15-$18 check your input: 15 and 16 to run code only once pressed, 17 and 18 to run a script as long as a button is held. Combos could possibly be done creating or recycling a counter (like, say you have no use for coins but want to easily have it on the status bar, you could increment the coin counter by 1 for each successful input and reset it to 0 if there is a miss depending on where the arrow sprite is erased and use that counter to determine additional points given per input.) The RAM map is very detailed. SA-1 will help you get the most sprites possible in, but it must be patched before any other action on your ROM.

3) It will be a lot easier to design the levels in Lunar Magic around the songs and test them than it would be to create a "smart" generator for your sprites (I can't think of a working strategy for this with songs using the #instruments command for percussion or custom samples because it obfuscates things a lot since unlike the Yamaha chips, SPC700 has no built-in samples and uses recorded wavelengths in the game instead - your best bet would probably be to find or make ports that use @10, @21, @24, @25, @26, @27, and @29 on a per-note basis that each have their own preset byte to make it more predictable, but I have no idea how you are going to get the generator to pre-emptively dispatch the sprites versus when the notes play so that they reach the threshold when they are supposed to.) A vertical level with horizontal movement disabled would be ideal and have it slowly scroll downward, fixing the blocks on layer 2 since during auto-scroll, sprites are snapped to the position of layer 1, although there are existing, in-game horizontal scrolls that make it possible and maybe easier to design this entire thing sideways instead.

(I just realized AddmusicK supports sending data from a song - it may be possible for you to include a subroutine for spawning a sprite at a coordinate and call it this way at specific parts of the song, and then you can just put the level on layer 1, have a pretty layer 2 backdrop, and not deal with scrolling at all. If you do this, I would give the song extra rests at the start so that way you can spawn sprites early enough that there is time for them to be seen and move to the slots when it would sync to the music. This method would be infinitely better than trying to code a generator that interprets the song or building a level, if you can get it to work. Just when you patch the subroutine, you must know where it is hooked.)

Just look above you...
If it's something that can be stopped, then just try to stop it!
Wow thank-you for the detailed response. I will attempt to reach out to the vhack team for some hints. I would have never known about that level in the hack had you not mentioned it.

That customizable sprite killer block is perfect, this is a very good idea for how to destroy sprites and check button presses for the scoring system. Thanks also for pointing me to SA-1, this makes me think I should read through as many patches as possible to see what else I may be missing. Your points on 3) are well noted and I appreciate you mentioning some of those to me before I fall in the rabbit hole.

I'm really glad you mentioned that about AddmusicK, having the music interrupt or pass data gives me a better-than-I-expected option.

Thanks again, I have a lot to go through and test out.
Pages: « 1 » Link
Forum Index - SMW Hacking - SMW Hacking Help - *solved* looking for pointers for creating 'ddr-like' non-interactive moving arrow sprites

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2021 - SMW Central
Legal Information - Privacy Policy - Link To Us


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Super Mario Bros. X Community
  • Mario Fan Games Galaxy
  • sm64romhacks