Language…
16 users online: Children's Digest 1950-2009, Chondontore, Darknubs,  Devazure, GRIMMKIN, Jordan, LightAligns, Murphmario, NightMareBalon, NikSik1, Ringo, Romano338, Rugal, SirMystic, Sixcorby, SubconsciousEye - Guests: 81 - Bots: 147
Users: 54,913 (2,072 active)
Latest user: El pepe mama

Freeze Sprites with L/R

Waiting UberASM Repository → Freeze Sprites with L/R

Submission Details

Name: Freeze Sprites with L/R
Author: JamesD28
Submitted: by  JamesD28
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 Idyllic.
Tags: freeze sprites lorom sa-1 sprite
Comments: 5 (jump to comments)
Rating:
0.0 (0 ratings)
No rating
Download 3.21 KiB | 52 downloads

Screenshots

View all

Comments (5)

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.