vidak's Blog - Guerrilla Game #5.2

[RSS Bot]

 

I Problems

One thing doesn't add up in my analysis of how the Y Register in the Stay Frosty kernel is formed. This code forms the Heights variable:

The first inconsistency is this: There is only 53 bytes of information apart from game logic in those sections of ROM. 

The second inconsistency with my analysis is: there are only 6 or 7 bytes of information in ROM under those labels that could be construed as the Height of things.

The third inconsistency is this: There are only 5 bytes set aside for Heights in the RAM. This equals the number of sections of Height that the variable is supposed to store. The STA operation in the above code is using Absolute Indexed addressing. This means the Y register is used to increment the memory location relative to Heights, not the value in the Heights memory location. This means if we increment the memory location more than 5 times we are starting to store data in other memory labels than Heights.

I am thoroughly confused. If anyone can help me understand this, I would be very grateful. I feel as if I don't understand the order of operations being done with the constants in the first LDY operation. I also don't understand what DATA_BYTES_PER_SECTION refers to. I cannot find any groups of 11 bytes of data anywhere.

I know there are 4 unused bytes for drawing the platforms. Anyway let's continue attempting to understand how the kernel is drawn.

II The Actual Pointer

Remember, this is how the kernel is drawn:

A     FrostyImagePtr 
The first element of the kernel we need to trace is the Image Pointer. This pointer contains the 16 bit memory address that contains the main player graphics. How is this pointer formed?

            MAC SET_POINTER.POINTER    SET {1}.ADDRESS    SET {2}                LDA #<.ADDRESS  ; Get Lowbyte of Address                STA .POINTER    ; Store in pointer                LDA #>.ADDRESS  ; Get Hibyte of Address                STA .POINTER+1  ; Store in pointer+1            ENDM

There are two arguments for this macro. The first argument is the pointer variable in memory. The second argument is the memory address. What this macro does is store the 16 bit memory address location inside the 2 bytes of pointer memory. Simple enough to understand.

For your reference, this is what exists at the memory address we have now stored inside the FrostyImagePtr: FrostyGraphic is a label in ROM:

LINE 1979:                  sec                  lda FrostyImagePtr                  sbc FrostyY                  sta FrostyImagePtr                  lda FrostyImagePtr+1                  sbc #0                  sta FrostyImagePtr+1

This adjusts the line of graphics we load into the kernel. The variable FrostyY stores the vertical position of the main player character on the screen. So what we are doing is adjusting the line of graphics we load into the kernel relative to what FrostyY contains. What happens in this game is that Frosty--the main player character--melts. As Frosty melts, we load less and less of the player graphics as Frosty sinks into the ground.

The above setting of the pointer is sufficient for a game that does not have a kernel which is repeated in bands down the screen. Because we have a game with bands, we need to adjust the graphics pointers. If we do not adjust the pointers for the main player character, it will only be visible on a single band. The main player character needs to (a) be visble in different bands; and (b) be visible moving between bands. I assume this can all be achieved by adjusting the pointers relative to the values of the heights of the different bands up and down the screen.

This is how SpiceWare prepared the graphics pointer for Sections 1-4. This means the main player character must appear at Section 0 at the beginning of the game, and is the origin for the Y position of the main player character.

We loop through this above code 5 times - as many times as there are bands up the screen. (5 times)Everytime we move through the loop, the Y Register increases by 2. So the 5 times we move through the loop Y increases through these values:0 -> 2, 1 -> 32 -> 4, 3 -> 54 -> 6, 5 -> 76 -> 8, 7 -> 98 -> 10, 9 -> 11

• This means we are increasing the graphics pointer memory address by 2 every time--both the lower byte of the pointer, and the higher byte. We are shifting the line of graphics by 2 up every band of the screen. This is confusing - why do we need to do this?
• What seems to be happening to the lower byte is that we increment its memory address by the number of bytes equal to the height of the band. Why don't we also do this to the higher byte? Wouldn't this lead to the lower byte increasing something like 30+2 locations forward, where the higher byte only moves 2 locations forward?
• I need some clarification on the above issues.

   

  The final process of forming the main player's graphics pointers is tweaking the pointers so that the memory addresses they point to don't cross any page boundaries. When the kernel uses the LDA (ZP),Y operation in the kernel, it needs to take a precise amount of time. If the CPU has to cross a page boundary in memory in order to fetch the data at the pointer's address, it will add a cycle and disrupt the very precise timing of the kernel.
  

   
  This is about all I can achieve for now...

http://atariage.com/forums/blog/703/entry-14389-guerrilla-game-52/