[TI ASM]Title Animation

thegamefreak0134 · Post by **thegamefreak0134** » Mon 19 Jun, 2006 12:16 am

OK, this might get a bit confusing.

I am using Jim e's greyscale package, and I have an effect I want to achieve. I have a title screen whose colors I want to swap out quickly. I want white to stay white, black to become dark grey, dark grey to become light grey, and light grey to become black. Keeping his package in mind, can someone tell me the math I need to apply to the buffers byte by byte to get this to work? I know it's probably something simple, my mind's just not working it out.

thanks!

-gamefreak

Liazon · Post by **Liazon** » Mon 19 Jun, 2006 1:44 am

XOR the two planes together (light and dark) This is the new light plane.

The old light plane becomes the new dark plane.

edit: example:

dark: %11110000
light: %11001100
xor: %00111100
colors: black, darkgray, lightgray, white

new:
dark|%11001100
light|%00111100

colors: dark gray, light gray, black, white

Post by **benryves** » Mon 19 Jun, 2006 11:47 am

EDIT: Oh, Liazon beat me by... a few hours :\

When trying to work out this sort of thing, you could try using truth tables and binary logic:

Code: Select all

A = bitplane 1 in
B = bitplane 2 in
Q = bitplane 1 out
R = bitplane 2 out

(Assuming BA=01 = light grey, BA=10 = dark grey)

BA|RQ
--+--
00|00
01|11
10|01
11|10

From this, we can see:
 
      _   _
Q = A.B + A.B = A(x)B
R = A

So, to get the required effect you need to xor each byte in the two buffers to get the new buffer 1 and to also copy the first bitplane to the second.

At a rough guess, the code for that would be something like this:

Code: Select all

    ld de,buffer_1
    ld hl,buffer_2
    ld bc,768
_loop
    ld a,(de)
    push af
    xor (hl)
    ld (de),a
    pop af
    ld (hl),a
    inc hl
    inc de
    dec bc
    ld a,b
    or c
    jr nz,_loop

(Assuming the two bitplanes are stored as 2 individual 768-byte bitmaps).

Jim e · Post by **Jim e** » Mon 19 Jun, 2006 12:02 pm

You can optimise that a bit.

Code: Select all

	ld hl,buffer_2	;light
	ld de,buffer_1	;dark
	ld bc,768
_loop:
	ld a,(de)
	xor (hl)
	ldi
	dec hl
	ld (hl),a
	inc hl
	jp pe,_loop

NanoWar · Post by **NanoWar** » Mon 19 Jun, 2006 12:54 pm

What is "parity" (jp pe,$NN) and how is it set?

Post by **benryves** » Mon 19 Jun, 2006 1:07 pm

Parity refers to whether there is an even or odd number of bits in the byte. This is where you get parity bits from in communications - for example, if you have a 'parity even' system, you will send an extra bit which is either set or reset with each 8 bits to make sure that there is an even number of set bits (a form of error detection).

However, the po/pe flags* (parity odd/even) also correspond to overflow. In this instance, Jim e is testing for overflow from the ldi instruction (for when bc has reached zero) as to whether to loop again or not.

EDIT: When I say 'flags' there's only one bit (one flag), but two states (set/reset) of course.

Liazon · Post by **Liazon** » Mon 19 Jun, 2006 2:07 pm

too bad I couldn't actually write the code

wait, how does that indicate if bc is 0? I'm guessing he can't use jp nz,_loop because dec and inc reset all the flags?

Jim e · Post by **Jim e** » Mon 19 Jun, 2006 7:01 pm

In this case the parity flag is used to indicate if BC is 0.
Inc hl and dec hl don't set any flags so they are safe.

thegamefreak0134 · Post by **thegamefreak0134** » Tue 20 Jun, 2006 7:00 pm

Y'all are making this much more difficult than it needs to be. As usually happens, I posted for help and then promptly went home and figured it out on my own. It's fairly straightforward.

OK, I want to make B become D, D become L, and L become B right? And I want to completely ignore W? So,

1 -> 1
1 -> 0

1 -> 0
0 -> 1

0 -> 1
1 -> 1

So, here's the solution:

Bit 2 = Bit1 xor Bit2
Bit 1 = Bit1 xor Bit2

In other words, load bit 2 into mem, make bit 2 equal bit1 xor bit2, and make bit1 equal the bit you loaded to mem.

I applied this process to every byte in the buffers, and the effect goes so fast that the greyscale effect is lost entirely. You actually see more of a blur than anything. When I slowed it down, it worked alright. Thanks for the advice though!

-gamefreak

Liazon · Post by **Liazon** » Tue 20 Jun, 2006 9:00 pm

O_o isn't that what we all said?

Jim e · Post by **Jim e** » Tue 20 Jun, 2006 9:59 pm

Liazon wrote:O_o isn't that what we all said?

yeah, I don't know how we made it more complicated. If its that parity talk that was purely to show how optimised the code can be.

thegamefreak0134 · Post by **thegamefreak0134** » Wed 21 Jun, 2006 5:20 pm

O_o isn't that what we all said?

... It is? Oh. Sorry then. Anyways, it works now.