Language…
10 users online: Cristian Cardoso, Golden Yoshi, Green, Isikoro, Maw, MorrieTheMagpie, nonamelol1, Rauf, Scags, Torchkas - Guests: 257 - Bots: 309
Users: 64,795 (2,377 active)
Latest user: mathew

Freeze Sprites with L/R

UberASM Repository → Freeze Sprites with L/R

Submission Details

Name: Freeze Sprites with L/R
Author: JamesD28
Added:
Type: Level
Includes GFX: No
Includes Hijack: Yes
Featured: No
Description: This code will freeze all sprites on screen when L or R is pressed, while allowing the player to still move around and interact with the level as normal. You can control the duration sprites are frozen for, enable retriggering of the freeze, enable freezing of sprite behaviours as well as their position, and more. Has a lot of potential for interesting kaizo and puzzle setups.

Note that depending on the settings & ROM type, this code can use quite a lot of freeRAM (up to 639 bytes). See the .asm file for usage notes and customization options. To be inserted as level ASM (can be inserted in GM14, but probably not a mechanic that should be enabled for an entire hack).

Requested by Picayune.
Tags: freeze sprites lorom sa-1 sprite
Comments: 6 (jump to comments)
Rating:
0.0 (0 ratings)
No rating
Download 3.29 KiB | 349 downloads

Screenshots

View all

Comments (6)

 Fernap Link
Tested with:
- Lunar Magic 3.33
- SA-1 Pack 1.40
- Snes9x 1.60, Bsnes-plus 05
- UberASM Tool 1.6

Notes:
Accepted. Overall, this is a very impressive piece of work, but it's not without some issues, which are admittedly unavoidable for something like this, especially when done purely in uberasm, but here are some things to be aware of -

- There's definitely some odd behavior with certain sprites. Here are a few specific things I noticed (there are definitely more out there):
--- springs are wonky, see the previous comment
--- pokeys act a bit strange
--- dead sprites continue to fall while frozen
--- lakitu cloud sort of broken (mostly just seems to not draw)
--- even with the platform fix, Mario will move forward a pixel upon freezing
--- dry bones don't collapse after being hit while frozen
--- generators don't freeze, but what they spawn does, so you can fill up with bullets or eeries, etc

- This is fairly expensive computationally; especially on lorom, you'll want to be conservative with sprite usage to avoid slowdown
- Since this uses L/R, you'll probably want to disable L/R scrolling when using

Technical notes/suggestions for the future:
- changed = 0 to == 0 in the if statement for future asar compatibility
- it would probably be good to use %invoke_sa1() if running on sa-1 since this is so processing heavy (the free ram needs to be in bw-ram in this case)
- it would be really nice to have the actual freeze code split out into a library file so that it could be used in other circumstances more easily, like on/off (would require a separate unpatch)
spooonsss Link
Originally posted by simon.caio
Some sprites seem not to work i.e. the spring....


The fix from Discord:

Originally posted by JamesD28

Find this:
Code
LDA !9E,x
CMP #$04
BCC .NotKoopa
CMP #$08
BCC +
.NotKoopa
%RAMToSpr(!1540, 13)
+

And between the LDA !9E,x and CMP #$04, add this:
Code
CMP #$2F
BEQ +

Doesn't seem to affect green beans though so I guess they use RAM elsewhere
simon.caio Link
great timing! (I am using this now instead of d^4s...that one has problems in bsnes..I was able to trigger this also with a block :))
edit: some sprites seem not to work i.e. the spring....
Anas Link
Originally posted by JamesD28
Hammers are an extended sprite (as are baseballs and bones), and due to how the code freezes stuff, each additional table preserved requires more freeRAM. It would also require a separate loop, and the code was already getting uncomfortably long - adding an extended sprites loop may have rendered the code unusable on LoROM without lag. It was also already using a pretty hefty chunk of freeRAM for the normal sprites so I decided to leave extended sprites out, but I may add them as an optional feature in an update.

D^4's version certainly has it's own merits: hers looks to be a lot faster and smaller due to the use of a patch, and hers also doesn't require a chunk of freeRAM, so it's less invasive in that regard.


Oh, I see. I thought your code was less invasive simply because it's one level file.
Anas Link
This is extremely cool! Even better is the fact that it's far less invasive (because of the small optional hijack) than d^4's freezing code: https://www.patreon.com/posts/time-stop-29328089

I noticed this doesn't affect other types of sprites like the hammers in the third GIFs, which is a bit of a shame but understandable considering it would be more invasive likely. Again, nice job!
JamesD28 Author Link
Hammers are an extended sprite (as are baseballs and bones), and due to how the code freezes stuff, each additional table preserved requires more freeRAM. It would also require a separate loop, and the code was already getting uncomfortably long - adding an extended sprites loop may have rendered the code unusable on LoROM without lag. It was also already using a pretty hefty chunk of freeRAM for the normal sprites so I decided to leave extended sprites out, but I may add them as an optional feature in an update.

D^4's version certainly has it's own merits: hers looks to be a lot faster and smaller due to the use of a patch, and hers also doesn't require a chunk of freeRAM, so it's less invasive in that regard.