Re: A86: Hi! It's Bubbaloo13 (grayscale)

[Prev][Next][Index][Thread]

Re: A86: Hi! It's Bubbaloo13 (grayscale)



On Thu, 20 Jan 2000 09:15:19 -0700 "David Phillips" <david@acz.org>
writes:
>
>> if you move the stack, you have to either set up your own error 
>handler,
>> or be very careful to make sure no errors occur such as fp div by 
>
>In the game I wrote this for, FP calls weren't really my top priority 
>:)

uh, well, yeah...  still, if you use any complex rom calls, you have to
make sure you know whether or not they may trigger errors.  i realize in
most games that's not an issue,   but i wanna be picky!! :)


>> just another reason why i like having the second plane at $f000.  
>along
>> with the fact that i'd rather not go to all the work of copying the
>> stack.
>
>I like to have a contiguous buffer, because it makes scrolling and 
>other
>effects much simpler.

does it?  one loop instead of two??
hmm, do you use a back buffer, or draw directly to the screen?
if you use a back buffer, you can still have it contiguous and split it
when you copy to the display.  (i should talk, i couldn't even get the
stupid level scroll to work properly)


>> i've got a pretty spiffy grayscale routine myself, you know.  it 
>flickers
>> though, i need to move a few things out of the interrupt routine for 
>it
>> to be of any use.  but you get seperate up/down key messages and a 
>fifo
>> key event buffer!  isn't that fun! :P  i was even working on adding
>> automatic link communication.
>
>That sounds pretty cool.  Whether it flickers or not doesn't really 
>have
>anything to do with how fast/slow the routine is, unless it is so slow 
>that
>you start missing interrupts (which would be very bad).  It's the 
>mixing
>ratio.  2:1 is the only way that I've found to get flicker free 
>grayscale,
>although it still flickers a bit in flourescent light, but you can't 
>do much
>about that.  2:3 looks a bit better, but the flicker is noticable.  If 

2:3 looks a lot better, but i've got it switchable (by #defines or
equates or something) as to which ratio to use, usually i use 1:2.  i'm
not sure how slow it is, it could just be a combination of lighting and
battery life.  as i recall it doesn't flicker in vti, if that's any
indication

let's see, it should be at
http://members.xoom.com/_XMCM/rabidcow/ti86/gray.html if you wanna take a
look at it.
it says it's flickerless, but it's only /mostly/ flickerless

the link routine, as i was working on it, was gonna work in a sorta
"multitasking" kind of way.  the link routine had an entire seperate
register set and was set up to count time while it waited for link
transitions.  after a specified number of times through the loop, it
switched back and returned from the interrupt.  it might be better to
occasionally steal the time in between interrupts, like every 10th time
or something.


>> what's a "port drift bug"?
>
>If you disable interrupts entirely or write your own IM 2 handler that 
>does
>not call the one in the ROM, then the keyboard port won't get reset.  
>This
>causes sparatic drifiting of certain keys, such as the down arrow.  
>To
>remedy this, you have to reset the port in your code, such as 
>everytime
>through the main loop:
>
> ld a,$ff
> out (0),a

oookaaay... how odd.

-josh


________________________________________________________________
YOU'RE PAYING TOO MUCH FOR THE INTERNET!
Juno now offers FREE Internet Access!
Try it today - there's no risk!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.
Follow-Ups: