[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lo-res/Double lo-res (was: Wacky Game idea)
In article <110917443wnr@klatch.demon.co.uk> John@klatch.demon.co.uk writes:
>In article: <4kk9se$b10@pith.uoregon.edu> nparker@cie-2.uoregon.edu (Neil Parker) writes:
>[SNIP]
>> >Talking of double lo-res graphics, how well supported is that mode? I
>> >know the //c had routines for it in ROM, but does the IIgs?
>>
>> Yes, it's there in the IIGS too. The machine-language entry points have
>> never been officially published, but it works quite well from BASIC. You
>> can turn it on like this:
>>
>> 10 D$ = CHR$ (4)
>> 20 PRINT D$;"PR#3": PRINT CHR$ (12)
>> 30 POKE 49246,0
>> 40 GR
>
>Aaah, I wondered about that. Is it the CHR$(12) that 'activates' double
>lo-res sensing?
No. The CHR$(12) is just there make sure the 80-column card actually has
some output to chew on, so it can properly intialize itself before we
try to activate double lores mode. CHR$(12) is the clear-the-screen control
code, which I chose because it seemed relatively harmless.
In order for double lores drawing to work, two things have to happen before
the GR command. First, the 80-column display must be turned on (that's
what the PR#3 and CHR$(12) are for). Second, double-resolution graphics
must be enabled (that's what the POKE 49246,0 is for).
>If this 'Wacky Game Idea' goes any further, how about using de-bugged
>double lo-res routines for the project? It could even have auto support
>for DLR mode on a suitable //e, //c or IIGS... :)
Writing good double lores routines certainly wouldn't be very difficult.
But I should probably point out that BASIC may not be a good choice of
programming language for the kind of game under consideration. I have
serious doubts about Applesoft's ability to update the screen with acceptable
speed, even if it is only the lores screen.
- Neil Parker
--
Neil Parker, nparker@{cie-2,cie}.uoregon.edu, http://cie-2.uoregon.edu/~nparker
"Bad move, Neil!" -- The Tick