Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: Hot_Dog on August 28, 2011, 05:58:57 pm
-
In my topic on the game "Elimination," I mentioned that my grayscale was "almost" flickerless. However, no matter what I attempt (fixed timings for the LCD delay, never using di, etc.) I see wierd gray stripes starting from the bottom and working their way to the top, like a barbership pole. Any ideas as to why? (Note: when you select this program from applications, press 2nd even if nothing appears. Also, YOU WILL NEED TO START YOUR CALCULATOR FRESH when using this program, as entrances and exits are unstable.)
EDIT: Here's the interrupt routine I'm using.
relocate($F6F6)
F:
di
_
push af
push de
push bc
push hl
ld a, (frameage)
inc a
ld (frameage),a
cp 1
jr z, doregular
cp 3
jr z, dogray
cp 4
jr nz, EndInterrupt
xor a
ld (frameage), a
jr EndInterrupt
doregular:
ld hl, regularbuffer
call safecopy2
jr EndInterrupt
dogray:
ld hl, grayscalebuffer
call safecopy2
EndInterrupt:
pop hl
pop bc
pop de
ld a, %00001000
out (3), a
ld a, %00001010
out (3), a
pop af
ei
ret
SafeCopy:
;ld hl, plotsscreen
safecopy2:
ld c,$10
ld a,$80
setrow:
in b,(c)
rl b
jp c,setrow
out ($10),a
ld de,12
ld a,$20
col:
in b,(c)
rl b
jp c,col
out ($10),a
push af
inc c
ld b,64
row:
rowwait:
in a,($10)
rla
jp c,rowwait
ld a, (hl)
out (c), a
add hl,de
dec b
jp nz, rowwait
pop af
dec h
dec h
dec h
dec c
inc hl
inc a
cp $2c
jp nz,col
ret
-
I've got a feeling that the second I see the effect that is happening, I'll be able to tell what's wrong. But, at the moment, the app crashes the moment I start it in wabbitemu. The program works until I press 2nd. Pressing 2nd I believe tries to draw the screen and that is when it crashes. (I can move up or down, but the moment I press 2nd, it locks)
-
what do you do to get past the gemini screen?
-
It looks like you're trying to do grayscale like this (http://otbp.tifreakware.net/images/grayfail.gif) (warning epilepsy :P), but usually we do grayscale like this (http://otbp.tifreakware.net/images/grayscale.gif), which blends together much better. We can't reliably synchronize with the LCD on the TI-83+, plus we usually can't update the screen quickly enough to keep up anyway.
-
It looks like you're trying to do grayscale like this (http://otbp.tifreakware.net/images/grayfail.gif) (warning epilepsy :P), but usually we do grayscale like this (http://otbp.tifreakware.net/images/grayscale.gif), which blends together much better. We can't reliably synchronize with the LCD on the TI-83+, plus we usually can't update the screen quickly enough to keep up anyway.
Actually the first one is how I drew grayscale. So you're saying that grayscale blends much better if I use a checkerboard pattern?
-
I will refrain from suggesting the Axe routine and give you a link to Thepenguin77's explanation.
http://ourl.ca/9538/182589
You can't really apply the crystal timers or the extra ram, but it does have a good algorithm for creating the stripe patterns. :)
Oh, also use horizontal auto increment instead of vertical auto increment.
-
I guess what you're saying is it doesn't work if I have two buffers where pixels alternate in a checkboard pattern?
EDIT: Oh, it's because no matter how fast or how slow you refresh the screen RAM, it displays 60 times a second. I missed that part.
-
I guess what you're saying is it doesn't work if I have two buffers where pixels alternate in a checkboard pattern?
No, that should work if you time the picture properly.
EDIT: Oh, it's because no matter how fast or how slow you refresh the screen RAM, it displays 60 times a second. I missed that part.
Yeah. That might be the problem.
-
I guess what you're saying is it doesn't work if I have two buffers where pixels alternate in a checkboard pattern?
EDIT: Oh, it's because no matter how fast or how slow you refresh the screen RAM, it displays 60 times a second. I missed that part.
You can keep the buffers how they are, but you should combine them in such a way that it takes 2 pixels from the dark buffer, 1 pixel from the light buffer, 2 pixels from the dark buffer, 1 pixel from the light buffer, etc. This can be done with some clever bitmasking. You'll have to do 3 screen updates before the pattern repeats itself.
-
I guess what you're saying is it doesn't work if I have two buffers where pixels alternate in a checkboard pattern?
EDIT: Oh, it's because no matter how fast or how slow you refresh the screen RAM, it displays 60 times a second. I missed that part.
You can keep the buffers how they are, but you should combine them in such a way that it takes 2 pixels from the dark buffer, 1 pixel from the light buffer, 2 pixels from the dark buffer, 1 pixel from the light buffer, etc. This can be done with some clever bitmasking. You'll have to do 3 screen updates before the pattern repeats itself.
I'm only doing 3-color grayscale. I think my problem is the screen refresh.
-
I guess what you're saying is it doesn't work if I have two buffers where pixels alternate in a checkboard pattern?
EDIT: Oh, it's because no matter how fast or how slow you refresh the screen RAM, it displays 60 times a second. I missed that part.
You can keep the buffers how they are, but you should combine them in such a way that it takes 2 pixels from the dark buffer, 1 pixel from the light buffer, 2 pixels from the dark buffer, 1 pixel from the light buffer, etc. This can be done with some clever bitmasking. You'll have to do 3 screen updates before the pattern repeats itself.
I'm only doing 3-color grayscale. I think my problem is the screen refresh.
Oh I see, I misread your code. You can still do something similar with 3-level, by taking alternating pixels from each buffer (which makes good use of the lcd output delay). Either that or you can draw the buffers in a checkerboard pattern to begin with, but that might hurt performance.
-
Thanks to everyone for helping me get this to work. Now I just need to write a calibration routine :)