Jump to content
IGNORED

Is it possible to share sprite color data?


freshbrood

Recommended Posts

Is this better?

 

   set romsize 32k : set kernel_options player1colors playercolors pfcolors : COLUBK = 2
   const _c_frame10lo=#<frame10 : const _c_frame10hi=#>frame10

  player0x = 50 : player0y = 50 : player1x = 70 : player1y = 50

__Main
  goto __P0 bank2

    bank 2
__P0

  player0color:
 10
 10
 10
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 70
 254
 254
 254
 254
 254
 254
 254
 254
 0
 242
 56
 56
 56
 56
 56
 56
 14
 10
 14
 14
 14
 14
 14
 0
 254
 14
 14
 56
 14
 254
 254
 254
 12
 12
 10
 10
 10
 8
 14
 14
 14
 14
 14
 14
 14
 14
 14
 0
 0
 14
 14
 14
 14
 14
 0
 0
 0
 0
 14
 14
 14
 14
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 254
 254
 254
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 30
 30
 30
 0
 0
 0
 0
 0
 0
 30
 0
 30
 30
 30
 30
 30
 0
 30
 0
 0
 0
 0
 0
 0
 156
 156
 156
 0
 0
 0
 0
 0
 0
 156
 0
 156
 156
 156
 156
 156
 0
 156
 0
 0
 14
 14
 14
 14
 14
 46
 194
 194
 194
 194
 194
 194
 0
 0
 46
 46
 46
 194
 196
 46
 46
 46
 196
 30
 0
 0
 0
 0
 202
 202
 202
 0
 0
 0
 0    
 0
 0
 202
 0
 202
 202
 202
 202
 202
 0
 202
 0
 0
 62
 62
 62
 12
 12
 62
 62
 62
 62
 62
 62
 62
 68
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 12
 246
 246
 246
 246
 246
 246
 246
 246
 246
 246
 116
 116
 116
 116
 14
 116
 116
 116
 116
 116
 14
 14
 14
 14
 14
end

  player1color:
 10
 10
 10
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 70
 254
 254
 254
 254
 254
 254
 254
 254
 0
 242
 56
 56
 56
 56
 56
 56
 14
 10
 14
 14
 14
 14
 14
 0
 254
 14
 14
 56
 14
 254
 254
 254
 12
 12
 10
 10
 10
 8
 14
 14
 14
 14
 14
 14
 14
 14
 14
 0
 0
 14
 14
 14
 14
 14
 0
 0
 0
 0
 14
 14
 14
 14
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 254
 254
 254
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 30
 30
 30
 0
 0
 0
 0
 0
 0
 30
 0
 30
 30
 30
 30
 30
 0
 30
 0
 0
 0
 0
 0
 0
 156
 156
 156
 0
 0
 0
 0
 0
 0
 156
 0
 156
 156
 156
 156
 156
 0
 156
 0
 0
 14
 14
 14
 14
 14
 46
 194
 194
 194
 194
 194
 194
 0
 0
 46
 46
 46
 194
 196
 46
 46
 46
 196
 30
 0
 0
 0
 0
 202
 202
 202
 0
 0
 0
 0    
 0
 0
 202
 0
 202
 202
 202
 202
 202
 0
 202
 0
 0
 62
 62
 62
 12
 12
 62
 62
 62
 62
 62
 62
 62
 68
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 12
 246
 246
 246
 246
 246
 246
 246
 246
 246
 246
 116
 116
 116
 116
 14
 116
 116
 116
 116
 116
 14
 14
 14
 14
 14
end

  o = 6
  player0color = player0color + (o*24) - 24 + 1 : player0pointerlo=_c_frame10lo : player0pointerhi=_c_frame10hi : player0height=22

  u = 8
  player1color = player1color + (u*24) - 24 + 1 : player1pointerlo=_c_frame10lo : player1pointerhi=_c_frame10hi : player1height=22

  drawscreen

  goto __Three bank3

  bank 3
__Three

  goto __Four bank4
 
  bank 4
__Four

  goto __Start bank5

    bank 5
__Start

  goto __Main bank1

   bank 6
   bank 7
   bank 8
   data frame10 ; (STAND)
   %11000011
   %11000110
   %00000110
   %11000000
   %11000010
   %01100011
   %01100011
   %00110011
   %00110111
   %00111011
   %00111010
   %00111010
   %00011101
   %00000011
   %00011100
   %00101110
   %01011111
   %11111011
   %11110011
   %10011100
   %01001110
   %01101110
   %00001110
end
 

Link to comment
Share on other sites

20 minutes ago, freshbrood said:

Where am I supposed to see that icon? in the bbasic or text editor? I just copied and pasted directly from bbasic and I'm on a reduced data browser that may not show up all the regular javascript buttons.

 

It's supposed to be above the text box.

 

Example:

 

zz_aa_forum_code_02.thumb.png.7779fac4504f266172b263f7f421ecf5.png

Link to comment
Share on other sites

2 minutes ago, freshbrood said:

Both my code postings seem indented already. I copied them off this site and they pasted into bbasic without issue.

 

How did you keep the forum from mangling the code? Did you use the code cleaner?

 

https://alienbill.com/2600/basic/aabbcc.cgi

Link to comment
Share on other sites

Both times I copied directly from bbasic. I saved in a plain text, copied and pasted here again and it came out the same. So the only other thing I can think of is the low data savings browser settings I'm using- I have a user agent that forces the mobile/lite version of AtariAge on my pc screen for reduced bandwidth. So apparently it's something in the coding of the forum page. See if you can force the mobile version on your desktop and experiment with pasting. It should work.
 

  • Like 1
Link to comment
Share on other sites

If you're going to do it that way you'll have to use 16 bit math

something like



  const P0cphi    = player0color + 1      ;  name the hi byte of the player0color pointer
                                          ;  so you can use it to define a bB 8.8 player0color pointer 16 bit variable 
  dim P0c_pointer = P0cptr.player0color   ;  so you can use it to do 16 bit math in bB

  P0c_pointer = P0c_pointer + 0.094       ; then you'd do your math something like this  (24/256 = ~.094)

Link to comment
Share on other sites

Your color tables are not multiples of 24


I guess what you want would best be done with a look up table for the multiplication


  dim tmp88 = temp2.temp1


  temp2 = 0 : temp1 = mpy24[o]

  P0c_pointer = P0c_pointer + tmp88

  data mpy24
  0, 24, 48, 72, 96, 120, 144  etc
end

  Or you could do the multiplication in bB


  temp1 = ((o * 2) + o) * 8

  • Confused 1
Link to comment
Share on other sites

  • 2 weeks later...

I avoid using the forum to edit replys as much as possible
I use a text editor and then just paste it wholesale then
maybe fix it in the forum editor if I think it relly needs it
Seems like it always messes something up

 

 

Your colors are not a multiple of 24 (or 23, your player defintion is
23 lines)


You avoid division if possible because it takes a long time and quite often
there's something else you can do to avoid or minimize the use of division

 

 

It occurs to me that you may be getting confused by the way the names are used
So here's a bit of a ramble throught some of the intricacies

 

First the processor deals in bytes and, generally, so does bB
A byte is 8 bits and can represent values 0..255

That's not enough for some stuff, memory addresses in particular
So two bytes are used which gives you 0..65535
But they still only get dealt with one byte at a time
It's kinda like a two digit decimal number has a ones place and a tens place
except we have a ones place and a 256 place


Each of the 256 place is a "page" of 256 bytes


With indexing you start with a 16 bit number and add a 8 bit number to it
ie you start with a value 0..65535 and add a value 0..255 to it


Kinda like (in decimal) taking a 0..99 number and adding a number 0..9


If the result of adding the ones places is more than the ones place can "hold"
you need to do a carry.

That takes extra time and that messes up the kernel timing

(Its only going to matter for stuff used in the kernel where timing is tight,

not for ordinary data in bB)


So you need to be sure that the result of adding your index to your base location
doesn't result in a location in the next page, ie doesn't cause a carry into the
256's byte of your 16 bit address


For example, in the case of the your color table with 24 colors,

if the player0colors is a two byte, 16 bit memory location which specifies a memory location (of the color table)
then if the ones byte ie the value contained in player0colorslo is within 24 of 256

ie if it's greater than 255 - 24, then the kernel will try to reach into the next page and that will mess up the timing


Mind you the complete table of colors can cross the page boundary as long as
there's a whole group of 24 on this side of the page boundary and a whole group on the other side
Assuming they're contiguous then the one in the next page must start at zero in the page


As long as they're wholly contained in a page it doesn't matter where they are in the page
and normally that's how it works with individual color defintions


Putting them all in one table means they have to align with a page boundary

(if the overall table straddles the page boundary)

 

 

Player0pointerlo is the name for the memory address for the first byte of the 16 bit address
in memory of the table that contains the player definition

 

To the assembler its a constant, $8A as defined in 2600basic.h
In the kernel it's the first byte of the two bytes of memory that contain the address (location)

in memory of the player definition table

 
bB take it as an alias for the value it contains, the lo byte of that address


So player0pointerlo is also the constant $8A

 

If I define a constant as player0pointerlo + 1 that constant name will be an alias for

the same value as player0pointerhi, $8B which will be the address of the location in

memory after (the location specified by) player0pointerlo, ie it will be location $8B

 

In bB if I say a = player0pointer + 1 it will get the contents of memory location $8A add one to it
and put the result in memory location $D4 (the location in memory of variable a, also specified in 2600basic.h)
(of course, it actually compiles code to do that)

 

Now back to the decimal anology

 

Suppose memory is 100 locations 00..99 

Each "byte" (location) can hold a single digit

Our player height is 3 and we want 5 possible color schemes of 3 bytes each
Our color table will be 15 bytes

 

Say the colors table just happens to begin at location 65
Player0colors will contain 5 and the location after player0colors will contain 6


the kernel will look at player0colors find 65, add 2 to it and look into the table at location 67 for the first color
For three lines (the player height) with three colors the index values will be 0..2.  The locations in the table will be 65..67


The high byte, ie the "page" will be 6 for each of those locations and doesn't change.  No carry.
The second set of colors will start after the first set beginning at location 68


We choose it by setting (the location in memory refered to by) player0colors to 8 and the following location to 6


Now when the kernel looks for line one it gets 68 adds 2 and gets 70.

The page has changed, that needs a carry to the page digit, that takes extra time, that screws up the kernel timing.


The second set of colors straddles the page boundary at locations 68..70.


To fix it we can add padding, two zeros to align the colors boundary with the page boundary

65..66 will contain 0
the colors table will start at 67
the individual color sets will be at locations 67..69, 70..72, 73..75 etc


Each set is wholly contained within a page.


You won't be able to do that if the whole table straddles more than one page boundary

and the color sets are not an integral divisor of the page length

ie (in this decimal anology with "pages" of 10 "bytes") it cant be done for two pages if the player height is 3
but a player height of 5 will work

 

You could add padding to the middle of the table or something like that but it would screw up the regularity of the table

in which case a look up table would definitely work better than multiplying

 

Also the individual color tables don't have to be in one big table, even if you're multiplying to get the index

You would want them to be contiguous if you're multiplying
 

Edited by bogax
typos, clarity
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...