Another programming opportunity

[vicassembly]

Assumptions:

1. The screen area is 7 x 10. This is logical positions as opposed to physical (not that it matters). The issue is there are 70 possible positions.
2. Each logical screen position can contain up one of three different characters.
3. I want to predefine 20 (or so) screens for my game.
4. I wanted to stay within the limits of the unxpanded Vic. I now have doubts this is possible.
4. This is in machine language

Possible Solutions:

1. Create 20 different arrays that define the 70 characters and the exact graphic character that populates the position. This takes 2K or so.
2. Come up with some kind of bit patterns that represent the screen. For instance x1111111 would indicate that each character on the screen line is populated by something. x1000001 would indicate the first and last position have a character and the center 5 do not. The limitations of this are obvious because I want to have 3 possible characters in each space as opposed to 1.

Are there any other ways of representing this that comes to mind? Something with modulas 3 arithmetic? My mind just doesn't feel sharp enough.

Thanks.


Jonathan

[Wilson]

If I am understanding correctly, you could simply expand upon your second possible solution but use two bytes per row. That way each character would be represented by two bits (capable of representing up to 4 characters).

For the first and last positions to represent the 1st character, you'd end up with something like this:
01000000 00000100

Obviously, the last two bits would go unused.

[vicassembly]

Thanks, Wilson.

I am growing to love this forum but it is causing me not to think as much.

All I need is to calculate the bits and come up with a little conversion routine. Perfect!!

[Mike]

Something with modulas 3 arithmetic? My mind just doesn't feel sharp enough.

If you encode each "screen" as base-3 number, memory requirements derive as follows:

Maximum representable number: Q := 3^70-1 ~= 2.503 * 10^33

This should be encoded in N bits: N := ln(Q) / ln(2) ~= 110.9

You need at least 111 bits to encode the number. They fit into 14 bytes. 20 screens -> 280 bytes. As for the data, this is the most compact representation provided no better model of the data is available.

Of course the decoding routine takes another hit on memory requirements. For the overall small amount of data involved, Wilson's encoding is most probably a better method, as the decoding is a lot simpler, and it also leaves leeway for inclusion of a fourth character.

[TNT]

If there are enough identical row patterns you may be able to save memory by using 7 bits as an offset to previous rows if "unused" bit is set. Routine fetching one screen is 30+ bytes longer than without compression and you have to store screen start address (unless you always process them sequentially) so whether you save memory or not depends a lot on your data.

Code: Select all

GetRow
  ldy #0
  lda (data),y
  bmi .packed
  sta pat1
  iny
  lda (data),y
  iny
  bne .cont

.packed
  clc
  adc data
  sta tmp
  lda #$ff
  adc data+1
  sta tmp+1
  lda (tmp),y
  sta pat1
  iny
  lda (tmp),y
.cont
  sta pat2

  clc
  tya
  adc data
  sta data
  bcc *+4
  inc data+1
  rts

Row bits are returned in pat1/pat2.

[vicassembly]

My design has changed such that 3 bits are required now. Each screen position can have the following states.

1. Blank
2. 1st level character
3. 2nd level character
4. 4th level character
5. solid, unchangeable character
6. 1st level with special power
7. 2nd level character with special power
8. 3rd level character with special power

It will take 30 bytes to layout each screen. It looks like my game will be branching into the realm of the expanded Vic. I have never written for expanded so I need to start revisiting screen/color changes.

Jonathan