Sprites in Memory?

[Cybearg]

I'd like to have player 0's sprite be held in memory so it can be modified easily on the fly without many variations necessary.

 

I'm using the multisprite kernel, and it just so happens that I only need 3 out of the 6 possible sprites, so I went through the memory map and commented out any memory assignments that weren't being used and instead just gave all those variables a constant value of 0. This seems to work fine as I've not noticed any problems since making these modifications.

 

By my estimations, this frees up approximately 27 bytes for my use, which is great because the player 0 sprite is only 12 pixels high. Additionally, it would leave me another 15 bytes to use for whatever beyond the memory sprite.

 

However, I need help with two things:

1. In order to use the free memory in array-form, as I presume would be necessary for a memory-based sprite like I described, the memory locations would have to be in line, not random memory locations separated by chunks of used memory.
    
   I've tried reconfiguring the Multisprite memory map by moving all memory locations down in the memory. For instance, I'm not using missile0x or missile1x, which have memory locations of $80 and $81 respectively. The next used memory location is ballx, at $82, which IS being used. So I'd move ballx up to $80 and shift all other memory locations up three as well, etc.
    
   The problem is, especially when dealing with the memory locations for sprite pointers, it doesn't seem to like them being shifted around. I keep the same number of bytes free (for instance, PF1pointer and PF2pointer are actually 2 bytes large, so the map skips two memory locations to make sure that they have enough space allocated), but it still results in problems. I'm not sure if this is because the kernel is pointing directly to a memory location instead of using the definitions, because there's something special about certain memory locations, or what, but it's definitely a problem.
    
   Does anyone have any idea what could be the matter? I've attached my current Multisprite memory map, which DOES presently work, but it needs to have all the values shifted up. Maybe someone else will have more luck with it than I've been having.
    
   For reference, the memory I recovered should be in these locations:
    
   

   
   rem borrowed memory
   dim aa = $80
   dim ab = $81
   dim ac = $87
   dim ad = $88
   dim ae = $89
   dim af = $8A
   dim ag = $8B
   dim ah = $90
   dim ai = $91
   dim aj = $91
   dim ak = $93
   dim al = $94
   dim am = $95
   dim an = $96
   dim ao = $97
   dim ap = $9A
   dim aq = $9B
   dim ar = $9C
   dim as = $A8
   dim at = $A9
   dim au = $AA
   dim av = $AD
   dim aw = $AE
   dim ax = $AF
   dim ay = $B3
   dim az = $B4
   dim ba = $B5

   
    
   

2. How do I modify the kernel to look at the memory for sprite definitions, rather than to the ROM?
   

multisprite.h.txt

Edited July 28, 2013 by Cybearg

[Omegamatrix]

You can try this. No guarantee it will work, but if it does then $9F-$B5 should be free for you to use.

 

Basically I took the multisprite source and cleaned it up a little last week so that I could at least read it. I didn't really change it other then to chop a few bytes out to make it more leaner, i.e. better wastes of time then using the SLEEP macro.

 

So for you the problem was inside the multisprite kernel there are lots of places where it goes through a loop and expects the each block will be in groups of 5. You can see this in the header file as everything for P1 is grouped into stacks of 5. At the top of the header file I put "NUMBER_OF_P1_SPRITES = 2-1 ; 5-1 ; changed for Cybearg", and then put "NUMBER_OF_P1_SPRITES" everywhere it needed to be in the multisprite.asm file. Next I did what you did in moving the ram around except I freed up $9F-$B5 instead. I didn't want to disturb the ram above and below what I could free since you never know if something is hardcoded somewhere.

 

 

Hope this helps,

Jeff

 

 

multisprite_kernel_9f_to_b5_free.zip

 

 

Edit: found a bug, and uploaded a new version

Edited July 28, 2013 by Omegamatrix

[Cybearg]

Works perfectly aside from one little typo:

 

player1pointerlo = $98
player2pointerlo = player2pointerlo+1 ; $99
; player3pointerlo = player2pointerlo+2
; player4pointerlo = player2pointerlo+3
; player5pointerlo = player2pointerlo+4

 

should be:

 

player1pointerlo = $98
player2pointerlo = player1pointerlo+1 ; $99
; player3pointerlo = player1pointerlo+2
; player4pointerlo = player1pointerlo+3
; player5pointerlo = player1pointerlo+4

 

Thanks so much! And, with minimal tweaking, this should be able to be adjusted for any number of players, right? Just do some counting and set the memory values appropriately and uncomment the necessary number of memory locations?

 

Now, any idea about a memory-based sprite?

Edited July 28, 2013 by Cybearg

[+Gemintronic]

What's this? Someone's paying attention to the multi-sprite kernel?!?

 

Maybe when it's graciously cleaned up by Omegamatrix we can look into permanently adding in multi colored backgrounds again

 

http://atariage.com/...isprite-kernel/

 

http://atariage.com/...ured-pf-kernel/

[Omegamatrix]

Works perfectly aside from one little typo:

 

player1pointerlo = $98
player2pointerlo = player2pointerlo+1 ; $99
; player3pointerlo = player2pointerlo+2
; player4pointerlo = player2pointerlo+3
; player5pointerlo = player2pointerlo+4

 

should be:

 

player1pointerlo = $98
player2pointerlo = player1pointerlo+1 ; $99
; player3pointerlo = player1pointerlo+2
; player4pointerlo = player1pointerlo+3
; player5pointerlo = player1pointerlo+4

 

Thanks so much! And, with minimal tweaking, this should be able to be adjusted for any number of players, right? Just do some counting and set the memory values appropriately and uncomment the necessary number of memory locations?

 

Now, any idea about a memory-based sprite?

 

Good catch! I also made an error. The "bug" I found was not a bug (just me rushing out the door), and I need to change:

 

;--some final setup
   ldx    #NUMBER_OF_P1_SPRITES+1
   lda    #$80
.loopCycle74_Hmclr
   sta    HMP0-1,X
   dex
   bne    .loopCycle74_Hmclr

 

Back to:

 

;--some final setup
   ldx    #5
   lda    #$80
.loopCycle74_Hmclr
   sta    HMP0-1,X
   dex
   bne    .loopCycle74_Hmclr

 

 

With the header file it is better to set up some conditional statements with "ds" or designated space. I tried seg.u but it compiled a zero byte rom as it didn't know where the code started. Looking at vcs.h I might just have to put a "seg" at the bottom of the header file to get it to work. I'll try and post the changes.

[Omegamatrix]

What's this? Someone's paying attention to the multi-sprite kernel?!?

 

Maybe when it's graciously cleaned up by Omegamatrix we can look into permanently adding in multi colored backgrounds again

 

http://atariage.com/...isprite-kernel/

 

http://atariage.com/...ured-pf-kernel/

 

Maybe, but I'm a bit squeezed for time, so no promises.

[SeaGtGruff]

I haven't read all the posts in this thread and checked all the code, but I'd like to suggest an alternate approach-- if not for use with this project, then for future consideration.

 

Rather than rearranging everything so the reclaimed bytes of RAM are contiguous, how about using the already-contiguous "user varables" memory, a through z, for the sprite data, and use the reclaimed bytes with dims for your other program variables?

[Omegamatrix]

Here is a new build with a define at the top of the header file that lets you choose how many copies of P1 (1-5) you are using. When you compile the output window will tell you what range of zero page ram you have to play with. It also has the bug fix mentioned a few posts above.

 

 

multisprite_select_number_of_P1.zip

[Cybearg]

I haven't read all the posts in this thread and checked all the code, but I'd like to suggest an alternate approach-- if not for use with this project, then for future consideration.

 

Rather than rearranging everything so the reclaimed bytes of RAM are contiguous, how about using the already-contiguous "user varables" memory, a through z, for the sprite data, and use the reclaimed bytes with dims for your other program variables?

 

Good suggestion, and it may be what I end up doing, though, at the time of me making the original post, I already had two 8-byte arrays out of the primary memory.

 

Now that Omega has generously spent his time fixing all this together, I'm back to wondering about how one would go about reading a sprite from memory. Currently, hi and lo pointers are set, but I'm not clear on how that would translate to putting a sprite in memory. Could the pointers be set to the high and low points of the memory that contains the sprite data? For instance,

player0pointerhi = $80

player0pointerlo = $87

player0height = 8

 

Would it then run through the 8 memory locations, loading each line of the sprite?

 

I somehow doubt it'd be that simple.

[Omegamatrix]

Ignoring mirrors, zero page ram has an absolute address of $00xx. I believe player0pointerhi holds the high part of the address, and player0pointerlo holds the low part of the address. Just load player0pointerhi with a value of zero (if might be zero already from the game initialization). Next load player0pointerlo with the start address of sprite, whichever ram location that is, ie. $9E, $83, etc... Then your pointers are set up. After that you just have to load the actual sprite into ram.

[Cybearg]

Hm... I've tried doing like so:

 

dim aa = $93
dim ab = $94

...etc.

aa = 0
ab = %00101000
ac = %00111000

...etc.

asm
LDX frame
LDA aa
STA player0pointerlo
LDA #00
STA player0pointerhi
LDA #13
STA player0height
end

 

... And I didn't seem to have much luck with that. I'll try again later, but I'm probably doing something wrong, eh?

[RevEng]

Change this...

LDA aa

 

To this...

LDA #aa

 

You're trying to store the address of the "aa" ram byte in the low byte of player0pointer, not the memory contents of the "aa" ram byte.

[Cybearg]

Ahh, I see. So if I do LDA aa, it's the equivalent of deferencing the pointer, while LDA #aa maintains the memory address?

[RevEng]

That's one way to put it, for sure. More formally, the # tells dasm to use the immediate addressing version of the opcode, rather than the zero page version.

 

I mention that only so you understand the difference is attached to the opcode rather than the symbol.

[Cybearg]

If I was referencing a memory location of, say, $83, how would it know the difference between me loading the hex number of $83 versus the address of the memory location stored in $83?

[RevEng]

LDA #$83 ; stores the literal value "$83" in the accumulator

LDA $83 ; stores the contents of memory location $83 in the accumulator.