Copy Link
Add to Bookmark
Report
Ictari Issue 51
ICTARI USER GROUP ISSUE 51 November 1997
___ ______ ___ _________ _________ ___
\__\ \ __\ \ \__ \______ \ \ _____\ \__\
___ \ \ \ __\ _____\ \ \ \ ___
\ \ \ \ \ \ \ ____ \ \ \ \ \
\ \ \ \_____ \ \____ \ \__\ \ \ \ \ \
\ \ \ \ \ \ \ \ \ \ \ \
\__\ \_______\ \______\ \________\ \__\ \__\
* m a g a z i n e *
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
I C T A R I U S E R G R O U P
G Greenway, 8 Denmark Road, Reading, Berks, RG1 5PA. 0118 756668
http://www.elis.demon.co.uk/ictari/ictari.htm
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
INDEX FOR ISSUE 51
==================
ASSEMBLY: Translator program
GFA: Sampled sound routines
HISOFT BASIC Cadenza address book with sources
STOS: GEMMA (Use GEM from STOS. Latest version.)
Scrolling routines
STOS updater
STOS Falcon Extension
Joystick extension
Code to display Spectrum 512 images
Starfield code
STE extension
Quartet track player
MISC: Current membership list
Index for issues 1-50
-------------------------------------------------------------------
EDITORIAL
=========
Hello again. Well, this issue was almost on time. (Don't hold your
breath for issue 52. it'll be out in the new year.) It's been a very
good month for ICTARI on the WEB. Since I last updated the pages the 5Mb
site has shifted 47Mb of data ! There are three sorts of feedback the
form on the WEB-site generates:
1) An e-mail with no comments and half the fields left blank.
(Response: "Harrumph, more mail to delete !")
2) A short reply something along the lines of "great site" or "I wish I
had found this ages ago".
(Response: Well, you might not get added to the members list, which is
largely an irrelevance if you get ICTARI from the 'net, but it does
cheer me up and the next issue might come out quicker !)
3) Offers of submissions or questions to go in the magazine.
(It *can* happen !)
This seems to have turned into the STOS special issue. Well, so be
it. The idea of "STOS 2000" really excites me. Tracking down the authors
and setting up a small consortium to sell STOS as cheap licenseware
would be a great thing to happen. Imagine an integrated set of
extensions along with a compiler version of GEMMA and a GEM friendly
editor ! In terms of power and ease of use, STOS could become the ST
equivalent of Visual BASIC. How's that for an idea ? Visual STOS anyone
? (There's a visual assembler for the Falcon, I will investigate...)
Hello to another new member !
Have Fun,
Giles
-------------------------------------------------------------------
CORRESPONDENCE
==============
To: ICTARI
From: Paul Jones
Re: GEMMA
* Official GEMMA document by Paul Jones
* GEMMA now, the myths and the future...
If I now could go back in time to when I started the GEMMA project
and tell my old self about what it's like now...
A few people fail to realise that GEMMA - GEM in STOS - is possible.
In fact, a few also think that GEMMA "imatates" GEM, having some sort of
routines to bring up alerts/dialogs/menus etc. Don't believe it! GEMMA
uses the *REAL* GEM system on your machine.
It is also said in the rules of STOS that it cannot multitask, use
the GEM mouse pointer et al. Again, this is completely wrong. As from
GEMMA v1.62 the new STOS loader (GEMMA STOS) can work with MultiTOS,
effectivly multitasking. However, you can't multitask with real STOS
programs, just programs which use the GEMMA system. You can create real
GEM programs which multitask and are unidentifiable from STOS programs.
GEMMA programs can even register their name in the 'Desk' menu and other
programs can be started alongside it. The system can even execute
programs with command lines and send VA starts to programs which support
it.
GEMMA can also work in any number of Falcon resolutions, effectivly
returning back to the one you were in before STOS changed resolution.
There are no memory problems anymore. The mouse works fine... I am now
working on a system which lets you edit your STOS files in a GEM
window!! But this won't be available for some time in the future.
If you have any replacement fileselectors, or just even the plain
TOS one, they can be called too. The new modern GEMMA programs can even
use Thomas Much's BubbleGEM and if programmed correctly, OLGA!! I have
even programmed routines to make GEMMA programs display .HYP files via
ST-Guide.
In short, with the GEMMA/STOS combo you can access ALL of GEM, not
some, or even immatate it - all.
* The technical details, what GEMMA actually does.
* A brief rundown...
It's pretty easy to access GEM from machine code, which is what
GEMMA actually does. All it required is a list of addresses in d1.l and
the function code #200 in d0.w, then a trap 2.
move.l #aes_params,d1
move.w #200,d0
trap #2
aes_params dc.l control,global,int_in,int_out,addr_in,addr_out
control ds.w 5
global ds.w 14
int_in ds.w 16
int_out ds.w 7
addr_in ds.l 3
addr_out ds.l 1
The opcodes for the AES command go in global, with the extras in
int_in/addr_in, and after the call, possibly coming out of
int_out/addr_out.
Using this method you can access every AES command, but will not be
able to access it fully. STOS won't let you click on object etc. To do
this you first need to restore the GEM pointer.
There are two things to do to return the pointer, first you need to
restore the actuall code. The address of the mouse routine is at
kbdvbase+16. Get this before STOS and return with initmous in STOS.
Also, do display the mouse first hide the STOS one, then return the VBL
pointer in the VBL list to the GEM one... et volia the GEM mouse pointer
will be around. To see it, try changing the palette to $777,$700,$70,1.
Memory is another problem, STOS assumes it has all memory, malloc -1
(trap 1,$48,.l-1) will return a very small amount of memory for the
AES/VDI to use. This is terrible since now we can't use
windows/resources/menus etc. The only solution is to reserve some memory
before STOS starts, STOS then checks memory and reserves it all. We then
deallocate the memory and we have memory space for the AES, this is one
of the functions the GEMMA acc served for.
Now we need to restore the screen. GEM assumes the screen is at
physic and logic, but STOS changes these address, so we need to know
what they were before, and change them back later. If you are bothered
about Falcon resolutions you need to know about vsetmode -1... as you
can see it's a bit of a nightmare. The GEMMA acc was needed to return
these addresses, but that was too tedious.
So GEMMA STOS was created. This is a modification of the STOS
loaded, which before changes all the settings, makes a copy of them in
it's data storage space. In STOS, the initgemma command finds where this
information is and sets the settings back unnoticed to the user.
* Editing STOS files
Currently you need to be in a standard ST resolution to edit in
STOS. If you aren't, you get garbage as text output. I'm hoping to
create a new input system which replaces WINDO102.BIN in your STOS
folder you can edit in any resolution, Falcon or not.
--
_____ _____
/\ _ `\ * It's good to talk, but even better to email! * /\___ \
\ \ \L\ \ * Internet email: paulat.jones@zetnet.co.uk * \/__/\ \
\ \ ,__/ * PJCO & GEMMA member 1. * _\ \ \
\ \ \ * Check out the homepage at: * /\ \_\ \
\ \ \ * http://www.users.zetnet.co.uk/pjones/home.htm * \ \____/
\/_/ * HBASIC tutorial writer for Atari Computing * \/___/
-------------------------------------------------------------------
To: ICTARI
From: John Nicholas Oakes
Re: Gasteiner hard drives
Please could you help me with my hard drive. I have been recently
getting an odd noise from it like something is slipping inside. It is a
105 Mb from Gasteiner, is it serious as nothing is affected by it at the
moment.
-------------------------------------------------------------------
To: John Nicholas Oakes
From: Giles Greenway
Re: Gasteiner hard drives
I have a Gasteiner drive attached to my old ST, and I have cause to
regret my decision ! Do you have one with a cable with nasty silver
plastic connectors ? That's the Top-link, its rather sketchy
implementation of the SCSI command set gave me all sorts of trouble when
I wanted to connect a CD-ROM drive. Sometimes I needed to wiggle the
cable to get the machine to boot ! This is beside the point however...
Do you get the noise all the time or just when the drive is being
accessed ? Maybe some of the partions are a bit fragmented. If not, then
I don't know. If it works, I suppose it's okay, but you should address
the issue of back-up anyway. I just about managed to back up a 270Mb
drive using ST-Zip and floppies, but it was quite painfull. A nice
option would be to get a SCSI Zip drive (go to an ST dealer to get the
software, you might try HiSoft) as they have removable 100Mb cartidges,
perfect for back-ups. I'm sure the through-port on your current hard
drive could take it. If the worst happens and it dies completely then
the Zip drive would make a respectable main drive anyway. You'd have to
ditch the Top-link and get the much better ICD link II instead. There
remains the slight problem of what to back up the Zip drive with ! Good
luck.
-------------------------------------------------------------------
To: ICTARI
From: Mario Becroft
Re: Scrolling in GEM Windows
Hello,
I did send you an email about the smooth scrolling in a GEM window
for ICTARI, but it doesn't seem to be there in issue 50 that I just
looked at.
Anyway, some comments more on the subject and particularly letter
included in issue 50 from Levien van Zon:
You don't need to bypass the rectangle list to do smooth scrolling.
Instead, simply handle each rectangle as you would the entire window.
Well perhaps this is slower, maybe the slight slowness of walking the
rectangle list realy does make a difference. Perhaps 1% slower? 0.5%? I
really don't think it makes any practical difference.
I don't follow the bit about the slow scrollbars. Perhaps this was
under a slow AES like AES 4.0.
Double buffering is really not possible under GEM. There's no point
even trying to hack together something like this that half-works, IMHO.
Yes, you could do it if you locked the screen, but why use GEM at all if
the screen is simply going to be locked all the time anyway? Blitting
the whole image into the window (as explained in ICTARI #50) is like
double buffering. But if you have slow blitting, there really isn't any
way around it. Just get a better graphics card.
Also a custom blitting routine is certainly not recommended, since
it would be impossible to make it fully compatible with all displays.
So, provided the blitting is fast enough you don't have a problem.
If the blitting is slow then you just have to put up with it (or upgrade
your hardware).
But even on my TT in VGA 16 colour mode, where the blitting seems to
be about as slow as it gets, a real-time game I'm making in a GEM window
works perfectly smoothly (I guess about 15 frames per second). And
that's with code that is extremely NOT speed-optimised (e.g. using
floating point math for the display of vector graphics). If I was
writing for speed I could probably have got it up even higher than that.
Admittedly that is with the window only about one third of the full
screen size. It does get slow when the window is the size of the whole
screen, but hopefully a graphics card with high-speed blitting
capability would fix that.
-------------------------------------------------------------------
To: Mario Becroft
From: Giles Greenway
Re: Scrolling in GEM windows
Oops, sorrry about that, I *do* get the odd mail problem now and
again. Can't wait to see the game.
-------------------------------------------------------------------
To: ICTARI
From: Philip Eddies
Re: STOS
Dear ICTARI Programmer's User Group,
I am writing to you about the programming language STOS and I was
wondering if you would answer some questions that I have.
1) Do you know of any to play Quartet music in STOS ? If you do, could
you please send me a listing to show me how to do this ?
2) Do you know of any way of loading .SPU files into STOS or of any way
of loading .TGA files ? I know that you can load .TGA files because
there is a program called Spectra which can load up .TGA files and a lot
of other files as well, and this was made using STOS.
3) Is there a limit to the amount of extensions you can have in STOS ?
4) Could you please send me a listing to show me how to do text
scrolling ? If you can't send me a listing then could you just tell me
how to do it ?
5) Do you know of any extension or any other way to read the other
joystick port so that you can have two player games with two joystick ?
6) Now for my last question: HOW THE HELL DO I MAKE STARFIELDS that look
good like in Star Trek or just 2D ones would be very very very helpful.
P. Eddies
P.S.
I have an Atari STe with 1Mb, so could you make sure any listings
that you send me work on this computer ?
-------------------------------------------------------------------
To: Phil Eddies
From: Giles Greenway
Re: STOS
Hello and welcome ! -Don't ask much, do we ? Are all these questions
to do with one single project ? -It doesn't bear thinking about ! It
would be nice to see some work in progress so we can all see how you're
getting on. I'm not much of a STOS user, but I've had a go at trying to
answer your questions, perhaps others would like to chip in ? To
business:
1) I *did* find an extension to play Quartet tracks. Look in
STOSPLAY.ZIP. As I said, I'm not a STOS user so all this is untested.
2) .SPU files ? Certainly, look in SPECSHOW.ZIP. The only TGA decoder I
found was in the STOS Falcon extension. Whoever wrote that other program
probably just had code to load in the binary file and did all the hard
work. Turn your .TGA files into .SPU format with good ol' ImageCopy,
it'll be easier. (I can dig out the specs for the Targa format next
time, if you're interested.)
3) -No idea ! If there is a limit, I'm sure one the extension will
conflict with the others and cause a crash before the maximum number is
ever reached...
4) Scrolling ? I refer you to Mr Railton ! See below. Get your font from
a sprite bank and just paste the characters down I suppose....
5) I found two joystick extensions, one in the STE extension, and
there's also a more specfific, but more limited one.
6) Would you believe, I found a starfield extension as well !
I really ought to thank the people who made this all possible. Tony
Greenwood of STOSSER software maintains and excellent WEB-page, (go see
it from the links section if you are reading this online) Anthony Jaques
wrote quite a few STOS extensions, and his pages are worth a visit too.
All the extensions I put in this issue were grabbed from the STOS file
site. Enjoy.
-------------------------------------------------------------------
To: STOS users
From: Philip Eddies
Re: STOS routines
STOS ROUTINES
---------------
FOLLOW THE LEADER
------------------
SPRITE FOLLOW OTHER SPRITES
10 KEY OFF : HIDE : CURS OFF : MODE 0 : UPDATE OFF
20 LOKE $45A,BUNT(START(1) TO START(1)+LENGTH(1),"PALT")+4 : WAIT VBL
30 DIM X(9),Y(9)
40 FOR T=0 TO 9 STEP 3
50 SPRITE T+1,X(T),Y(T),1
60 NEXT T
70 FOR T=9 TO 1 STEP-1
80 X(T)=X(T-1) : Y(T)=Y(T-1)
90 NEXT T
100 X(0)=X MOUSE : Y(0)=Y MOUSE
110 UPDATE : WAIT VBL
120 IF INKEY$<>" " THEN GOTO 30
130 DEFAULT : END
BOUNCER
--------
THIS LISTING ENABLES YOUR SPRITE TO BOUNCE AROUND HITTING OF THE LEFT
AND RIGHT OF THE SCREEN
10 KEY OFF : HIDE : CURS OFF : MODE 0
20 X=20 : Y=20 : SX=4 :SY=0
30 SPRITE 1,X,Y,1
40 X=X+SX : IF X>300 OR X<4 THEN SX=-SX
50 IS SY<19 THEN INC SY
60 Y=Y+SY
70 IF Y>184 THEN THEN Y=184 : SY=-SY
80 WAIT VBL
90 IF INKEY$<>" "THEN GOTO 30
SPRITE PALETTE
---------------
A QUICK WAY TO GET THE PALETTE FROM A SPRITE BANK
10 H=HUNT(START(1) TO START(1)+LENGTH(1),"PALT")+4
20 LOKE $45A,H : WAIT VBL
CHANGE THE FREQUENCY
---------------------
IF YOU WANT TO CHANGE FREQUENCY WHILE YOU ARE IN A PROGRAM, TRY:
<< FOR 50 Hz >>
(This is the normal freqency)
10 WAIT VBL : POKE $FFF820A,254
<< FOR 60 Hz >>
10 WAIT VBL : POKE $FFF820A,252
ROUND IT
---------
TO ROUND A NUMBER TO THE NEAREST 16
10 X=X AND $FFF0
MAD MAX MUSIC
--------------
ON THE WHOLE STOS CHIP MUSIC IS PRETTY CRAP,SO HERE IS A ROUTINE TO PLAY
MAD MAX CHIP MUSIC
10 RESERVE AS WORK 10,30000
20 BLOAD "MAD_MAX.MUS",10
30 DREG(0)=1 : CALL START(10):REM < INITIALISE MUSIC #1 >
40 LOKE $4D2,START(10)+8 : REM < PLAY ON INTERRUPT >
50 WAIT KEY
60 LOKE $4D2,0 : REM < DISABLE INTERRUPT >
-------------------------------------------------------------------
From: Jason J Railton
To: Stephen Bruce
Re: Atari Monitor Cable
I use a Sony portable TV for my ST, which has a full RGB-Scart
implementation (unlike some equipment which just connects Audio
left/right and composite Video in/out - 'AV-Scart'). When I tried to buy
a lead, I found that it didn't work. I found some instructions on
building my own, and found that this used this 'combined sync' line. It
still uses vertical sync, but has 'combined sync' instead of horizontal
sync.
What it is, in fact, is the composite video line. Your display
device then takes the horizontal sync information from the composite
video image, but takes the colour information from the RGB lines to give
a sharper picture.
The Sony PlayStation also has an RGB-Scart lead available for it,
which does the same thing (although with stereo audio). This leads to
another problem though.
Most equipment, and this includes nearly all video recorders,
satellite systems, cable TV boxes and switcher boxes that have a Scart
connector, have only the AV Scart connected. That is audio left/right
and video in/out. Sometimes there is also a switching line, which
carries an on/off voltage to signal to the receiving device that a
picture is being sent. This is how some TVs automatically switch over to
the video channel when you press 'Play' on the video.
The problem comes if you plug an RGB Scart into one of these devices
rather than straight into your TV. The RGB lines stop there, and the
only picture that gets through to your TV is the composite signal. You
may not even realise what is going on, but you will get a drop in
picture quality.
Now you _can_ buy switcher boxes that switch all 21 lines in the
Scart socket, but these tend to be the big expensive ones. Most salesmen
DO NOT KNOW the difference, and some items will say 'Switches all Scart
lines' when it only does AV-Scart. So, go to somewhere like Maplin (or
Tandy at a stretch) but do not hand over your money unless the assistant
is willing to unscrew the box and show you that all the lines are wired
up. Seriously. Even the guys at Maplin couldn't be sure from the product
descriptions in the catalogue. (By the way, the '21' comes from the 20
pins in the socket plus the shielded metal casing. Connecting this is
only necessary if you're using very expensive screened cable too).
Most AV switchers are little boxes on the end of a cable for under a
tenner, but for the full 21-line switchers expect to pay 10-15 quid for
the box then at least another 10 for a full-line cable to connect to the
TV.
One last chance though - I bought Maplin's AV switcher, which comes
in a pop-apart narrow black plastic box. It has Scart sockets on two
sides, a red push-button at one end and the TV lead out of the other. I
opened it up and found a long 4-pole 2-way changeover switch and the two
Scart sockets mounted on a PCB inside. The ground lines were common, and
it switched video and left/right audio.
I bought this, a length of 9-way cable (of which I needed 7 lines)
and a longer 6-way 2-pole changeover switch, all for about 12 quid. I
de-soldered the cable and the switch that was in there (use a solder
sucker and a lot of patience to ease out all 12 legs) and scratched off
the connecting lines of the circuit board (make sure you get them all).
Then I drilled 6 new holes and fitted the longer switch (it still
fits nicely inside the casing).
Next I took the Scart plug off the lead from the switcher, and
connected it to my length of cable. The connections were as follows,
looking at the _back_ of the Scart plug:
B G R Gnd
| | | /
.----------------------------------------.
| 1 3 5 7 9 11 13 15 17 19 |
| |
| 2 4 6 8 10 12 14 16 18 20 \
'------------------------------------------'
/ | / | \
Gnd L-Audio V-Sync Gnd Composite
In summary (in case that print is slightly off):
Red - 15 (picture)
Green - 11 (picture)
Blue - 7 (picture)
Vert. - 16 (sync)
Comp. - 20 (sync/video)
L-Aud - 6 (audio, left channel only)
Gnd - 4, 17 & 18 (ground lines)
There are three separate ground lines for audio, video and sync
separately (I think), but most systems connect them together internally
so I only used one ground line and wired it to all three.
Note the colour of each line you use, for wiring the other end of
the cable up. Using the red, green and blue cores for R, G & B (in that
order) surprisingly enough is not compulsory... but why not, eh?
If you want stereo audio, tough! They don't do a bigger change over
switch. Anyway, my ST is mono and my PlayStation is connected to the
Hi-Fi.
Handy tip - always fit the Scart plug to the cable first in any job
- that way it doesn't matter if you forget to slide the screw-cap of the
Scart plug onto the cable first!
Another Handy Tip - if you change from first to third person in the
middle of a set of instructions, forget it! Carry on regardless. Anyway,
if you've read this far, you've got to be interested in doing it
yourself.
Then came the wiring - I linked the ground lines together, and to
ground on my new TV lead. To the centre pins of the change over switch I
connected the other six lines. These were for the R, G, B, Vertical
Sync, Composite (for h-sync) and Left audio connections. I preferred to
connect these to the loop connectors on the top of the switch, for a
more secure fit than to the pin legs.
The next bit is to take wires from the two Scart sockets to the
input pins of the switch. Do one whole socket first, then the other.
That way you won't forget which side of the centre pins you're working
to. Note that you can wire to the legs of the switch under the board, or
to the loops on the top. Be careful not to melt the insulation of the TV
lines that you've already connected.
Finally, there's a thick sleeve that grips the old TV cable and
holds it in place where it passes out of the casing. I slit this sleeve
up one side, pulled it off and slipped it around the base of my TV
cable. It still gripped the cable quite well. Then, all I had to do was
clip the casing back on.
And by crikey, it worked!
Now, I can't be held responsible for any of this you try yourself.
If you take my word for it, you must be mad. I'm _pretty_ sure the pin
connections are right, so there you go. If they're not right, then
either I'm wrong or reality is inconsistent. And these were checked
recently. So...
...
... And that's all I have to say about RGB-Scart.
-------------------------------------------------------------------
From: Jason J Railton
To: Stephen Bruce
Re: Parallax Scroll
I'm glad I managed to impress your woman. If nothing else, at least
it gave you a (presumably) well-deserved night off! (That might be
censored. Who knows? But since I got my pink Ictari-subs final demand
last month, what have I got to lose? {Pink is so much more polite than
red, don't you think? Anyway... } Anyway... ) anyway, what was I saying?
Oh, yes, for your information that parallax scroll is very hard to
do. It took longer to get it going that fast than the 3D maze stuff. It
actually relies on a piece of code that re-writes itself based on the
scroll position to be as efficient as possible.
I've added some bits and pieces to the demo for lives and
player-collisions, but there's not much more to see yet. I've also done
a bit of work on my block (map) built version of the parallax scroll,
but that needs to be optimised because although it runs in under 2
frames, I don't have much time left for sprites. It does however have a
small vertical scroll range as well as the horizontal scroll.
-------------------------------------------------------------------
From: Jason J Railton
To: Giles Greenway
Re: Sound from Machine Code
The XBIOS function Dosound wouldn't work in my game because I
replace the system vertical blank interrupt entirely with one of my own.
As for the Giaccess function, does it cause any delay when it operates,
in order to communicate with the PSG chip ?
And if I just write data to the PSG adresses, do I have to wait for
a certain condition before I send another byte (as you have to do with
the keyboard chip) ?
I've considered setting up the three channels to tone,noise and
tone+noise, then varying the volume of each channel when I want a hum,
explosion or a shot.
-------------------------------------------------------------------
To: Jason J Railton
From: Giles Greenway
Re: Sound from machine code
I don't use assembler, so I can't be much help, but I can find no
mention of any delay when using Giaccess. You might have to just throw a
little test proglette together and see what happens. Good luck !
I still can't get Buzzsaw to work on my Falcon, (Wahhhh. Bawl.) the
whole thing seems slow, especially the joystick, and the fire button
doesn't respond. Might it be worth trying some of the STOS update
programs that come with this month's issue ?
-------------------------------------------------------------------
From: Jason J Railton
To: Everyone
Re: Scrolling in STOS
I've been trying out a new method of scrolling. It's currently in
STOS but I'm going to convert it into machine code for use in STOS
programs.
Normally, scrolling is done by storing a backup screen (or screens)
for copying out to the display. This back screen may be shifted around,
and re-written at the edges with data drawn from a map of blocks. This
gives the impression of a continuously scrolling area but cuts down on
the data storage required for a huge multi-screen area.
The main disadvantage is that horizontal scrolling by anything other
than 16 pixels is very time consuming. For 16 pixel scrolls you can just
change a pointer, to offset data by whole words. For 1 pixel scrolls you
can rotate words in memory, using the carry bit to carry data over from
one word to the next. Anything more and you either have to store
multiple copies (e.g. 4 screens, each offset by 4 pixels like I use) or
use a FETCH-SHIFT-STORE method, which is very slow.
Typically the scroll will be optimised for one speed, so you can't
jump around the map or change scroll speed easily. Also changes made to
the map must either be made on the backup screen at the same time, or
they won't appear until that part of the map scrolls off the screen and
back on again.
But what if you could generate the screen every time from the map,
with pixel-perfect positioning? What if you could display the map from
any position? Well, that's what I'm trying to do. (The Sega and Nintendo
8-bit and 16-bit consoles have this built into the hardware. That's why
you get so many blocky 2D platform games for them).
I achieve this by keeping the number of scenery blocks low - only 3
here (0=blank, 1=wall, 2=coin). This gives me 9 possible adjacent pairs
of blocks (0=blank/blank, 1=blank/wall, 2=blank/coin, 3=wall/blank,
4=wall/wall, 5=wall/coin, 6=coin/blank, 7=coin/wall, 8=coin/coin), and
it is these pairs which are the key to the whole thing.
Although the blocks are 16 pixels wide, as they scroll left and
right they do not always line up with the word boundaries of the screen
display. As one block scrolls out of its 16-pixel wide column to the
left, so it will be replaced by the block to its immediate right
scrolling into place. Now, if I store what this looks like for all the
above combinations (9 pairs, 16 pixel-scrolled frames, each 16*16 pixels
in size) you can begin to see how it works.
The map is converted from one which stores the 0,1,2 for blank,wall,
coin to one which stores the pair code 0-9, describing both the block at
that point on the map and the one to its immediate right. You can then
build the display in word-boundary-positioned blocks using the first
image for each pair. To make the whole thing scroll left, you use
subsequent images from each sequence, so all the pieces move off to the
left of their blocks, and are filled in with the correct image from the
right hand side.
Once you reach the end of the sequence, you move the whole thing
along a block (16 pixels) and start again. To go right, you reverse the
sequence. To go up and down, you use offsets to copy the data a bit
higher or lower.
Now, this runs a bit slow in STOS, even when compiled, but it's not
bad when you consider that you have a go-anywhere, at any speed scroll
routine. The machine code version should be very quick.
I've also added a bit of parallax scrolling with a background grid
in a 4*4 pattern. It moves horizontally at 1/4 of the scroll speed by
moving it across behind the blocks as the 16 frames are generated, and
it moves vertically using colour cycling to negate the effect of the
vertical scroll, but letting through 1/4 of the movement for the
parallax effect.
Try my demo, and use the joystick and mouse to see the scrolling.
The joystick does 4-pixel scrolling, the mouse any speed you like.
And yes, there is a game on the way.
-------------------------------------------------------------------
