jdg@elmgate.UUCP (Jeff Gortatowsky CUST) (02/13/90)
Anyone out there able to give me a clue on how fine scrolling is accomplished on an ST? I'm more interested in horizontal than vertical, but, desire info on both. do we Blit? If so, what "limits" are placed upon the Blit in respect to amount .vs. algorythm degradation? How do we keep it "smooth"... Etc. I know SOMEONE! out there must know.. Is there a DOC on this someplace? Any/all help appreciated. (this is the 3rd time Ive asked... Please!?). -- Jeff Gortatowsky-Eastman Kodak Company .....rochester!kodak!elmgate!jdg (use uuhosts or such to find path to rochester) Eastman Kodak makes film not comments. Therefore these comments are mine not theirs.
barry@gpu.utcs.utoronto.ca (Barry Lay) (02/14/90)
Jeff, I tried to mail to you directly the last time, but the message got sent back "userid not known". This seems to happen a lot on this network nowadays. Hopefully others will be interested too. Having done some playing around with scrolling methods, I would say that blitting is definitely the way to go. Figure out the screen size in pixels, subtract the offset of the scroll amount (1, in your case), and use a raster copy opaque (vro_cpyfm(), if memory serves me right) to shift the screen by the offset amount. You will now need to overlay the "vacated" screen space. If you are working within a window, v_gtext() will work fine. It doesn't care what pixel it starts on, although it is faster if it is snapped horizontally to a byte boundary. If you are dealing with the alpha screen, you are in for some work, unless somebody in netland knows a quick way to do this. I would build the text line image in some buffer (alternate Logbase?) and blit a portion of it into the screen. I don't have much experience with the alpha mode, so I will defer to better advice here. If you would like to see a code fragment for a window, send me a note. Perhaps personal mail works better. Barry
jdg@elmgate.UUCP (Jeff Gortatowsky CUST) (02/16/90)
Well, a few reponses are in. And, A few of my Own experiments. I have tried the VDI raster form functions. And, the results were poor (specially movin' the entire screen (over itself if you will, boy, is it POKEY!). So, I decided to go straight to the BLIT Line-a function. After some finaglin' I got it working, It too is unacceptable, and the screen gets all funky unless one VSyncs(). So, I decided, to see what'd happen if I just Blit one plane (What we are doing here, BTW, is taking 3 logical displays (making up a "playfield") if you will, in low-res, that are to be horizontally scrolled either left or right, smoothly, and at a decent rate of speed) and It too was unacceptable. All of "my" tests of the scrolling have been all "on screen", which, If a blit has any brains about should "make a difference" (as in my tests, the source & dest rects overlap). And it's a REAL sad performer, matter o' fact, I'd bet bottom dollar that it could be DRASTICALLY speeded up. This eve I will try from my actual playfield. One reply I recieved (of all 2 so far) stated troubles with sprites. Using the BLIT I'd see no real problems. The obvious way to implement color sprites (an virtually any size (though collisions can be another matter)) is to take your image, Shift it all the way left in your buffer (so your "lead pixel") aligns on a word boundary (or long word) and start shiftin the image through each and every permutation of the 16/32 bits, then all one need do is bleam the proper permutation onto/into your screen/buffer et el. All one need do is find the pixel index into the word/longword where ones coordinates lay, use it as an index to your sprite permutations. Zippity aye' it works too, I've done it. It's quite simple actually, just a little memory hungry and that can be finagled if one wishes to do an on the fly RLE or some such item. I have never pushed it (never had the need) over the amount of 16 32 bit sprites, but, the performance is more than adequete. -- Jeff Gortatowsky-Eastman Kodak Company .....sun!sunrock!elmgate!jdg (716)-726-0084 Eastman Kodak makes film not comments. Therefore these comments are mine not theirs.
stefan@spcc386.UUCP (Stefan Posthuma) (02/16/90)
Horizontal fine scrolling on the ST is not very easy. I have some experience
with demo/game programming on the ST and I'll tell you, nobody likes to do
it because it guzzles processor time.
Forget the blitter, you might be able to scroll 30-40% of the screen with it,
and lose all processor time.
Since the screen of the ST is just a dumb memory map, pixel-scrolling can
only be done by actually shifting the screen image. A long list of LSR of
LSL instructions will do this for you, but no way you can make this work
properly, because you simply haven't enough time. You might be able to do it
in 4-5 vbls, but then it looks awful. Add to this that the low-res screen
is divided into four planes and the horror is complete.
Now clever tricks will help you a bit, but scrolling the whole screen still
is very hard to do. Storing your images pre-shifted and blitting the right
frame is one trick, but this uses lots of memory (imagine storing everything
shifted 16 times) Using screen buffers and clever code is also possible.
One last alternative is 'Sync scrolling'. This is a incredibly difficult
trick that uses a glitch in the Shifter/MMU to open screen borders. Mess
around properly with them and screen borders will be opened ('Overscan'),
mess around even more and the physbase will start moving around, scrolling
the screen, but this is only for the superfreaks amongst us.
Happy hacking!
--
--------------------------------------------------------------------------------
"Oh my God, it is the attack of the Half-Crazed Mutant Teenage Alien Computer
Junkies!!" +------------------------------------
"Relax! It are just some SPCC employees" | uunet!mcvax!spcc386!stefansoohoo@cory.Berkeley.EDU (Ken "nmi" Soohoo) (02/17/90)
[Article related the woes of attempting to fine scroll using a full screen blit, through both VDI and LineA] Jeff, First of all, if you want to see fine scrolling of the entire screen done smoothly and well, take a look at NEOSHOW... I've been toying with writing games and other such nonsense on the ST for quite some time, and the ways to fine scroll are various and sundry, but they amount to this: 1) You MUST double buffer -- i.e. draw to a second screen while you show the user another screen, then swap the two when you have a new screen created. 2) It's much better if you want to vertical scroll and NOT horizontal scroll, 'cause you can word align your blit area. 3) If you want to horizontal scroll, the fastest way is to pre-shift the entire playfield that you're scrolling, and word-align blit the rasters into your double buffer. 4) You can keep a gigantic map elsewhere and blit sections of it to a "window" within your screen, scrolling within the screen, so that you avoid the hit to scroll the entire thing. 5) Generate your scrolling screen on the fly by blitting lots of little pre-shifted squares (16x16 is the usual choice), using your own bit blit routines. 6) If you don't need the functionality of the logic operations from the VDI and LineA routines, then write your own blit routines. If you're using 16x16 sprites, even a bitblit written in C will outstrip the system (I know, I wrote one for grins). Larger areas must have assembly. 7) Use the blitter if possible. 8) Buy an STE, they have hardware support for fine horizontal and vertical scrolling, and darn if it ain't pretty to see! Hope my ramblings help ;-) --Kenneth "kens" Soohoo (soohoo@cory.Berkeley.Edu) Atari Hacker (Atari's Hacker...) "It could be worse, you could get hit by a bus..." My opinions are my OWN, _not_ necessarily Atari's. But "hey", who knows?
dac@ukc.ac.uk (David Clear) (02/21/90)
Recently there has been a query about smooth scrolling on the ST and the
technique of using overscan was mentioned. Well, here is my offering. The
source code below is in 68000 assembler and implements the overscan
technique. The code allows physbase to be positioned on any 8 byte
boundary.
I hope the code is self explanatory. The overscan code takes 20 scan lines
to play with overscan and 2 for overheads. To remove this loss from the normal
playing area I've put the overscan in the top border. This gives rise to
two `features':
a) The screen is now around 208 lines long.
b) Screen memory is offset by two bytes.
So, your screens start at address $78002, $7800a, etc.
The 208 lines bit can be sorted out as it's just a matter of when the palette
is re-loaded. Just hack off the end of the code and set a raster interrupt
(timer B) to restore the palette.
The program loads a .pi1 file into screen memory (defined as $78002) and
allows you to scroll around it using the cursor keys. The only way out is
to reset the machine. Sorry, but I use a program I wrote that throws me back
into my assembler (DevpacST) on pressing RESET.
You can play with the code to your heart's content. If you know any games
programmers who don't have scroll code then please make sure they get it.
The new STE has a video address low byte. The old ST doesn't. We NEED
high speed action on STs. This and similar code is a step towards it.
PROGRAM SOME FAST GAMES NOW!
Imagine Speedball with hardware scrolling...
This code gives smooth vertical scrolling. Horizontal scrolling can be done
by building N screens and flipping between them. For example, 8-pixel
scrolling can be done with 2 screens, 4-pixel scrolling with 4 screens, etc.
Figure it out. There may be alot to keep track of but it'll be DAMNED fast.
One last thing. And it's important.
The top border code runs from timer D. The timing of the interrupt is critical.
There are potential problems:
1) The interrupt may be delayed whilst a long 68000 instruction is
executed. Something like a divide or movem with LOTS of registers.
I don't know if this will effect the code but if something goes
wrong then careful time planning can solve the problem.
2) Another MFP interrupt may trigger just before the timer D one.
This is a SERIOUS problem. The interrupt acknowledge all by itself
will throw the timing out. The solution is, fortunately, quite
simple(ish):
Set another interrupt to go off just before the timer D one.
In it, disable all other MFP interrupts. At the end of the
scroll code (after re-loading the palette), re-enable the
interrupts. This should be done using the mask registers
rather than the enable registers.
3) Along similar lines: As timer D is set up from the VBI, if the
VBI is delayed by an MFP interrupt then, again, the timing will
go wrong. A solution works along the same lines as for (2):
Assuming the scroll code is solid, at the end of it start
another timer which will interrupt just before the VBI. In
it, disable the MFP interrupts. After timer D initialisation
in the VBI, re-enable the interrupts.
4) The scroll code takes around 1.4ms (about 7% processor time).
During this time no keyboard interrupts will be handled. It is
possible, therefore, to lose keyboard packets. There is a
solution:
The border code is full of nops. These are for timing. Each
nop gives an 8 cycle delay. During the longer nop delays
it is easy to put in code which checks the 'buffer full'
bit of the keyboard ACIA and stores the data byte if
appropriate. Be sure to calculate cycle times accurately
as a single timing miscalculation will produce all sorts of
weird effects.
Although these problems have to be ironed out the technique is VERY powerful.
Enjoy,
Dave.
PS. As it is the program will not assemble as a line has been commented
out. The line is:
* .fname dc.b 'picture.pi1',0
The asterisk should be removed and the quotes filled with the name of your
favourite .PI1 picture.
------------------------- GO FOR IT ------------------------
* This code implements hardware scrolling on an Atari ST (NOT STE).
* This code is (c)1990 David Clear and is free.
* Feel free to use this code or modifications of it for whatever
* you so desire - commercial or private.
*
* NOW LET'S HAVE SOME DAMN FAST NEW GAMES!
*
* Note:
* A 'feature' of this code is that it displays around 208
* scan lines instead of 200. If you want to force 200 scan lines
* then you can:
* a) Re-write the top border code and extend the
* timer D delay.
* b) Remove the palette re-load at the end of the
* scroll code and set a raster interrupt lower
* down to re-load the palette.
*
* Important routines:
* myvbi - Timer D startup code & register loading.
* topb - Top border scroll code.
* setscrn - Screen address setup.
* Macro to create a given number of NOP instructions.
* Used for timing.
* eg:
* nops 4
* creates:
* nop
* nop
* nop
* nop
*
* 1 nop is 8 cycles. Long numbers of nops can be replaced by dbra loops
* and the like.
nops macro
dcb.w $4e71,\1
endm
* Picture data
SCREEN equ $78002 * Address of image
PICTURE equ SCREEN-34 * Address to load .PI1 picture
PALETTE equ PICTURE+2 * Address of palette
* Hardware labels
vbi_vec equ $70
timerd_vec equ $110
vid_baseh equ $ffff8201
vid_basem equ $ffff8203
vid_countl equ $ffff8209
vid_sync equ $ffff820a
vid_shift equ $ffff8260
vid_palette equ $ffff8240
ikbd_data equ $fffffc02
mfp_iera equ $fffffa07
mfp_ierb equ $fffffa09
mfp_isrb equ $fffffa11
mfp_imrb equ $fffffa15
mfp_tcdcr equ $fffffa1d
mfp_tddr equ $fffffa25
* This just demonstrates the routine. It is non-exitable. You have
* to reset to get out of it. Nevermind.
start lea vars,a6 * a6 -> variables
clr.l -(sp) * Go into supervisor mode
move.w #$20,-(sp)
trap #1
addq.w #6,sp
move.l #mystack,a7 * Set my stack pointer
clr.w -(sp)
move.l #-1,-(sp) * Set low res.
move.l #-1,-(sp)
move.w #5,-(sp)
trap #14
lea 10(sp),sp
bsr drawscr * Draw the screen
move.w #$2700,sr * Kill interrupts
move.l #SCREEN,d0 * Set the screen address
move.l d0,screen(a6)
bsr setscrn
clr.b (mfp_iera).w * Clear IERA
clr.b (mfp_ierb).w * Clear IERB
andi.b #$f8,(mfp_tcdcr).w * Stop timer D
bset.b #4,(mfp_ierb).w * Enable timer D
bset.b #4,(mfp_imrb).w * Mask enable timer D
move.l #myvbi,(vbi_vec).w * Set VBI address
.die stop #$2300 * Enable VBI
bra.s .die * Forever and ever...
* Load a .PI1 screen into screen memory
drawscr clr.w -(sp)
pea .fname(pc) * Fopen()
move.w #$3d,-(sp)
trap #1
addq.w #8,sp
move.w d0,d3
move.l #PICTURE,-(sp)
move.l #32066,-(sp)
move.w d0,-(sp) * Fread()
move.w #$3f,-(sp)
trap #1
lea 12(sp),sp
move.w d3,-(sp) * Fclose()
move.w #$3e,-(sp)
trap #1
addq.w #4,sp
rts
* Replace this string with a suitable Degas file
* .fname dc.b 'picture.pi1',0
even
* This is the VBI code. The VERY FIRST thing to be done is to set up
* the timer D interrupt.
myvbi move.l #topb,(timerd_vec).w * Set timer D interrupt vector
move.b #$65,(mfp_tddr).w * Set timer D data register
andi.b #$f8,(mfp_tcdcr).w * Set timer D subdivider mode
ori.b #4,(mfp_tcdcr).w * Start timer
*---------------------------------------*
* This code is not time critical but should stay here
movem.l d0-d7/a0-a6,-(sp) * Save all the registers
move.b bscan(a6),d0 * Move the overscan registers
ext.w d0 * into working registers
move.w d0,wbscan(a6)
move.b rscan(a6),d0
ext.w d0
move.w d0,wrscan(a6)
move.b nscan(a6),d0
ext.w d0
move.w d0,wnscan(a6)
*---------------------------------------*
* Now just a little keyboard control code.
* VERY poorly written, but what do you want for nothing?
move.b (ikbd_data).w,d0 * Get key code
cmpi.b #$4b,d0 * Left arrow?
bne.s .nl * No
subq.l #8,screen(a6) * Screen = screen - 8
bra.s .yes * Set the address
.nl cmpi.b #$4d,d0 * Right arrow?
bne.s .nr * No
addq.l #8,screen(a6) * Screen = screen + 8
bra.s .yes * Set the address
.nr cmpi.b #$48,d0 * Up arrow?
bne.s .nu * No
subi.l #160,screen(a6) * Screen = screen - 160
bra.s .yes * Set the address
.nu cmpi.b #$50,d0 * Down arrow?
bne.s .no * No
addi.l #160,screen(a6) * Screen = screen + 160
*---------------------------------------*
* Call setscrn to set the screen address
.yes move.l screen(a6),d0 * Set the screen address
bsr setscrn
*---------------------------------------*
* What is done finally is to set the video chip's screen pointers.
* This should be done after the call to setscrn.
* NOTE:
* The physbase register is latched on the VBI. This means that
* this change will not effect the screen about to be drawn but will
* effect the following screen. Anyone who uses double buffered screens
* will know this already.
.no move.b vidh(a6),(vid_baseh).w * Set the video pointer
move.b vidm(a6),(vid_basem).w
*---------------------------------------*
movem.l (sp)+,d0-d7/a0-a6
rte
* This function sets the screen base address. Well, it doesn't
* really load the video pointers, it just sets up variables which
* the vbi will use.
*---------------------------------------*
* IMPORTANT
* ---------
* The screen can be moved on 8 byte boundaries. There is a 'feature'
* of the top border code that means the screen is shifted two bytes.
* This means that if you call this function with #$78000 in d0, the
* REAL beginning of your screen will be $78002.
*---------------------------------------*
* Set screen address
* Input:
* d0.l = Address to put screen.
setscrn subi.l #320,d0 * The magic offset
move.b d0,d1 * Save low byte
lsr.l #8,d0
move.b d0,vidm(a6) * Store mid byte
lsr.l #8,d0
move.b d0,vidh(a6) * Store high byte
lea normal(pc),a0
lsr.b #3,d1 * Multiples of 8
ext.w d1
move.b 0(a0,d1.w),nscan(a6) * Normal scan lines
move.b right-normal(a0,d1.w),rscan(a6) * Right overscan
move.b both-normal(a0,d1.w),bscan(a6) * R & L overscan
move.b offset-normal(a0,d1.w),d0 * Video base offset
sub.b d0,vidm(a6) * Subtract from video base
bcc.s .ok
subq.b #1,vidh(a6)
.ok rts
screen rs.l 1
* Variables used by the code
vidh rs.b 1 * Video address
vidm rs.b 1
rscan rs.b 1 * Number of lines of overscan
bscan rs.b 1
nscan rs.b 1
wrscan rs.w 1 * Working variables
wbscan rs.w 1
wnscan rs.w 1
* This is the scroll code. It uses overscan to allign the screen.
* The overscan takes 20 scan lines but 22 are required to make things
* look nice. So that the 22 scan lines aren't eaten from the play area
* the top border is removed and the overscan done in there.
* IMPORTANT:
* The top border removal shifts the screen by 2 bytes.
zeroes dc.l 0,0,0,0,0,0,0,0 * Zeroes for palette
topb andi.b #$f8,(mfp_tcdcr).w * Stop timer D
movem.l d0-d7/a0-a3,-(sp) * Save some registers
movem.l zeroes(pc),d0-d7 * Clear the palette
movem.l d0-d7,(vid_palette).w
*---------------------------------------*
* Load some important registers
lea (vid_sync).w,a0 * a0 -> video sync
lea (vid_shift).w,a1 * a1 -> video mode
lea (vid_countl).w,a2 * a2 -> video low byte counter
moveq #0,d0 * 60Hz/Low res
moveq #2,d1 * 50Hz/High res
*---------------------------------------*
* Pick up the number of respective overscan lines needed
move.w wbscan(a6),d3 * Left & right overscan
move.w wrscan(a6),d4 * Right overscan
move.w wnscan(a6),d5 * No overscan
*---------------------------------------*
* Remove top border
lea .skip(pc),a3 * a3 -> Sync buffer
move.b d0,(a0) * 60Hz
nops 81 * Wait for next line
move.b d1,(a0) * 50Hz
*---------------------------------------*
* Sync on raster
.loop tst.b (a2) * Screen running?
beq.s .loop * No
move.b (a2),d2 * Get low byte
adda.l d2,a3 * Add to sync buffer
jmp (a3) * Jump into sync buffer
.skip nops 100 * Sync buffer
*---------------------------------------*
* This code performs left and right overscan
bra btest * Branch to overscan test
lboth nop
move.b d1,(a1) * You really think I can
move.b d0,(a1) * be bothered to comment
nops 89 * all these nops and
move.b d0,(a0) * loads? You must be out
move.b d1,(a0) * of your mind.
nops 13
move.b d1,(a1)
nop
move.b d0,(a1)
nops 9
btest dbra d3,lboth * Do next line
*---------------------------------------*
* This code performs right overscan
bra rtest * Branch to overscan test
lright nops 87
move.b d0,(a0)
move.b d1,(a0)
nops 13
move.b d1,(a1)
nop
move.b d0,(a1)
nops 16
rtest dbra d4,lright
*---------------------------------------*
* This code does nothing but is used for timing the palette re-load.
* If you only want 200 raster lines then just remove this code and
* set up a raster interrupt for a few lines down.
* DON'T remove the d5 loading code at the beginning as this may throw out
* the top border removal code. If it does then increment the number of
* nops in the top border code.
bra ntest
lnorm nops 125
ntest dbra d5,lnorm
*---------------------------------------*
* Reload the palette
nops 75 * Wait for end of line
movem.l PALETTE,d0-d7
movem.l d0-d7,(vid_palette).w
end movem.l (sp)+,d0-d7/a0-a3 * Restore registers
bclr.b #4,(mfp_isrb).w * Clear MFP ISR bit
rte
* This is the magic table which makes it all possible.
* DON'T MESS WITH IT!
normal dc.b 9,10,4,5,6,0,16,10,11,12,13,0,1,2,3,4
dc.b 20,14,0,1,10,11,12,6,0,1,2,3,12,13,0,0
right dc.b 5,2,8,5,2,8,4,10,7,4,1,16,13,10,7,4,0
dc.b 6,4,1,6,3,0,6,12,9,6,3,8,5,20,0
both dc.b 6,8,8,10,12,12,0,0,2,4,6,4,6,8,10,12
dc.b 0,0,16,18,4,6,8,8,8,10,12,14,0,2,0,20
offset dc.b $f,$f,$10,$10,$10,$11,$d,$e
dc.b $e,$e,$e,$10,$10,$10,$10,$10
dc.b $c,$d,$11,$11,$e,$e,$e,$f
dc.b $10,$10,$10,$10,$d,$d,$f,$11
even
vars ds.b __RS
even
ds.l 100
mystack
--------------------------- END ----------------------------
--
% cc life.c | David Clear <dac@ukc.ac.uk>
% a.out | Computer Science, University of Kent,
Segmentation fault (core dumped) | Canterbury, England.neil@cs.hw.ac.uk (Neil Forsyth) (02/21/90)
In article <590@spcc386.UUCP> stefan@spcc386.UUCP (Stefan Posthuma) writes: >One last alternative is 'Sync scrolling'. This is a incredibly difficult >trick that uses a glitch in the Shifter/MMU to open screen borders. Mess >around properly with them and screen borders will be opened ('Overscan'), >mess around even more and the physbase will start moving around, scrolling >the screen, but this is only for the superfreaks amongst us. I ran a DEMO that does this on an STE and the video hardware really chucked up on it. The custom chips on the STE no longer have the same quirks as the old ones so if you don't want to lose compatibilty don't do it. Also the sync scrolling technique uses frequency toggling and I believe loses on a native 60Hz display. +-----------------------------------------------------------------------------+ ! DISCLAIMER: Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "spam spaM spAM sPAM SPAM, lovely SPAM" ! +-----------------------------------------------------------------------------+
dac@ukc.ac.uk (David Clear) (02/22/90)
In article <4474@brahma.cs.hw.ac.uk> neil@cs.hw.ac.uk (Neil Forsyth) writes: [about sync scrolling] > >I ran a DEMO that does this on an STE and the video hardware really chucked >up on it. The custom chips on the STE no longer have the same quirks as the >old ones so if you don't want to lose compatibilty don't do it. Also the >sync scrolling technique uses frequency toggling and I believe loses on >a native 60Hz display. I ran "The Cuddly Demo" on a STE and, sure enough, the sync scrolling died. Its use shouldn't be ruled out though. It is the fastest way to do high speed scrolling on a ST. If you're planning on writing a fast scrolling game on a STE using its hardware support then, if the design is portable, it may be worth writing a dual version with two screen handlers for the two STs. As far as I know most games run in 50Hz anyway as this gives the code 1/50th of a second per update rather than 1/60th (obvious). So you get more time per frame using 50Hz. If you can't run every frame then every other frame at 60Hz looks smoother than every other frame at 50Hz (my scroll code forces a 50Hz screen - I haven't tried to make it run on a 60Hz screen and I'm not sure that it's possible). The code I posted last night to do sync scrolling was very fragile timing-wise and I suggested using two timers to make everything solid. Well, in the light of day I realised that the HBL can be used to sync at the top of the screen (and a nop is 4 cycles, not 8 as I said). Anyway, using the HBL can make the whole thing very solid. Maybe you've noticed, I really am trying to plug sync scrolling. I haven't the time to write anything commercial but I really do like high speed shoot-em-ups and believe that fast, every frame update is a must. Sooner or later such games will appear for the STE and older STs will be left standing. Fast scrolling CAN be done on a ST. You have the code. Read it, understand it, re-write it and use it. Games for the ST will never have the sound quality of the STE, or the BLiTTER speed, or the specialised video chip functions, but it's gameplay that really counts and fast scrolling is it. Dave. PS. I always wanted LucasFilm to do "Rescue On Fractalus" for the ST... Hey! What ever happened to "Defender"? A *real* version (with original(ish) graphics)? -- % cc life.c | David Clear <dac@ukc.ac.uk> % a.out | Computer Science, University of Kent, Segmentation fault (core dumped) | Canterbury, England.
stefan@spcc386.UUCP (Stefan Posthuma) (02/28/90)
Almost a week ago (I have been out of the office some time), David Clear
posted a source that does the 'Sync Scrolling'. I just had a look at it
and I must say I am a bit sceptical about it. This Overscan stuff is VERY
sensitive and for different MMU/Shifter versions you will need different
routines. Some ST's have an upper border of 16 scanlines and others have
32 (give or take a few). I haven't tried the code yet but my bet is that
it will work on some ST's and fail on some others. (But since I haven't
tried it yet, I am not 100% sure on this)
The stuff I have first finds out how many scanlines the upper border actually
has and sets a flag that the overscan code uses.
David asks for fast games using this technique, well I can say that the
German software house Thalion that employs the guy that invented sync scrolling
and some more VERY (EXTREMELY) talented people is busy working on some very
technical games that use Sync scrolling. "Leavin' Teramis" which has been
designed by a friend of mine (Richard Karsmakers, co-conspirator of ST NEWS),
is one of them, a scrolling shoot-them-up and should be out very soon.
Thalion is also doing a 3D game ("No second prize"), which makes every other
3D game look pathetic. It is written by a guy from Switzerland and when Jez San
beheld the demo at the PCW last year, he became very silent...
--
--------------------------------------------------------------------------------
"Oh my God, it is the attack of the Half-Crazed Mutant Teenage Alien Computer
Junkies!!" +------------------------------------
"Relax! It are just some SPCC employees" | uunet!mcvax!spcc386!stefandac@ukc.ac.uk (David Clear) (03/02/90)
In article <592@spcc386.UUCP> stefan@spcc386.UUCP (Stefan Posthuma) writes: > >Some ST's have an upper border of 16 scanlines and others have >32 (give or take a few). I haven't tried the code yet but my bet is that >it will work on some ST's and fail on some others. Thanks for the tip. I wasn't aware of the different screen sizes. I wrote the scroll code over a couple of hours after getting the left and right border overscan working (finally!). I put in the top border bit to get over the loss of screen. I always assumed STs were all the same. All I know is that my code works on my ST so I'm happy :-) But no matter, I'm sure any hackers who've seen my code and understand the principles can sort out the technicalities. >German software house Thalion that employs the guy that invented sync scrolling >and some more VERY (EXTREMELY) talented people is busy working on some very >technical games that use Sync scrolling. "Leavin' Teramis" which has been >... Great news! Dave. -- % cc life.c | David Clear <dac@ukc.ac.uk> % a.out | Computer Science, University of Kent, Segmentation fault (core dumped) | Canterbury, England.