Langue…
10 utilisateurs en ligne: Jern, Jordan, JupiHornet, kazuke TOG, Lane, OhMuramatsu, RollingRigatonis, Squiggs, TheCrazyBuzzyBeetle, Triple P - Invités: 36 - Robots: 194
Utilisateurs: 55 720 (2 331 actifs)
Dernier utilisateur: taste1122

Freeze Sprites with L/R

Répertoire d'UberASM en attente → Freeze Sprites with L/R

Détails de la soumission

Nom: Freeze Sprites with L/R
Auteur: JamesD28
Soumis le: par  JamesD28
Type: Niveau
Graphismes inclus: Non
Hijack inclus: Oui
En vedette: Non
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.
Étiquettes: freeze sprites lorom sa-1 sprite
Commentaires: 5 (aller aux commentaires)
Étoiles:
0,0 (1 cotation)
Aucune cotation
Télécharger 3,21 Kio | 77 téléchargements

Captures d'écran

Tous afficher

commentaires (5)

spooonsss Lien
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 Lien
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 Lien
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 Lien
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 Lien
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.