We've just updated MediaWiki and its underlying software. If anything doesn't look or work quite right, please mention it to us. --RanAS

SpriteCreationWithDyzen: Difference between revisions

From SnesLab
Jump to: navigation, search
Line 73: Line 73:
</li>
</li>
</ol>
</ol>
== State Machines ==

Revision as of 01:01, 27 March 2021

English Português Español 日本語

The following tutorial will explain how to create sprites using Dyzen. This tutorial covers not just how to use the tool, but also general functions for the creation of regular, cluster, and extended sprites.

For this tutorial, it's assumed that the developer has previous knowledge of ASM like using basic commands, branching, and indexing. This tutorial is based more on how to construct the logic of a sprite.

Also, it should be noted that this tutorial can also serve for sprites which are not created with Dyzen, though the focus is ultimately based on those.

Sprite Structure

A sprite is structured in the following manner:

  1. Sprite Init: This is the routine which occurs when the sprite is spawned. In Pixi, this routine begins with the line:
    print "INIT ",pc
    

    And should end with an RTL.

  2. Sprite Main: This routine is called in each Game Loop (SNES Frame) and is used for updating the sprite and its logic. In PIXI, this routine begins with the line:
    print "MAIN ",pc
    

    And should end with an RTL. Usually this routine would be like so:

    print "MAIN ",pc
    	PHB
    	PHK
    	PLB
    	JSR SpriteCode
    	PLB
    RTL
    

    This calls a routine named SpriteCode which will have the real contents of this routine. This is performed to better organize the code. Also, the Program Bank is set so that the tables can be indexed with short absolute indexing ($XXXX,x o $XXXX,y), instead of using long indexing, optimizing the number of cycles the code uses.

  3. SpriteCode: It basically contains the Main routine, as described above. This routine is called by others which will carry out the logic of the sprite. We will separate these routines into DynamicRoutine, GraphicRoutine, InteractionWithPlayer, InteractionWithSprites, StateMachine, AnimationRoutine, etc., depending on whatever the sprite requires. The basic structure of this routine is:
    SpriteCode:
    
    .AlwaysExecutedZone
    	JSR GraphicRoutine                  ;Calls the graphic routine and updates sprite graphics
    
    	;Here you can put code that will be excecuted each frame even if the sprite is locked
    
    	LDA !SpriteStatus,x			        
    	CMP #$08                            ;if sprite dead return
    	BNE Return	
    
    	LDA !LockAnimationFlag				    
    	BNE Return			                    ;if locked animation return.
    
    .ExecutedIfNotLocked
    	%SubOffScreen()
    
    	JSR InteractMarioSprite
    	;After this routine, if the sprite interact with mario, Carry is Set.
    
    	;Here you can write your sprite code routine
    	;This will be excecuted once per frame excepts when 
    	;the animation is locked or when sprite status is not #$08
    
    	JSR AnimationRoutine                ;Calls animation routine and decides the next frame to draw
    RTS
    Return:
    RTS
    

    Here we can take note of 2 main zones (blocks of code):

    • .AlwaysExecutedZone which encompasses the area from the beginning of the routine until the first check LDA !SpriteStatus,x. This zone always runs, even if the game is paused or the animations are stopped, normally we don't put a lot of code in this zone, except for graphics routines.
    • .ExecutedIfNotLocked encompasses the area after the check LDA !LockAnimationFlag. This zone runs when the animations aren't stopped, the game isn't paused, or the player is not in the death animation, etc. Also, it should be clarified that this sector is only executed if the !SpriteStatus,x has the value 8. This means that the sprite has the status "Normal Routine". This RAM address corresponds with the table $14C8. It should be noted that the check of !SpriteStatus,x can be modified so that the sprite executes the code in other statuses. One common state is 2, which means the sprite is dying. In this area, we can note that it calls other routines that we're going to detail further along in the tutorial. For now, it's important to know that below, we call JSR InteractMarioSprite. This is where we will execute the code for the sprite's logic.

State Machines