🚀 go-pugleaf

I have been working on this very thing for the past couple of days.  I
first thought that you would need a virtual screen *twice* the size of the
physical screen in order to do it - when you get to one edge and try to move
more, you 'jump' to the other half of the virtual screen and continue.  A few
problems that I saw with it:

1) takes up lots of memory (can't do it in 360x480 - no biggie)
2) you have to deal with the jump from one edge of the virtual screen to the
other. This means you either have to :
    a) duplicate drawing your tiles on both sides (so that when you jump to the
left or right you already have the screen drawn)
    b) do a full-screen bitblt from one side to the other in 1/60sec. (as if!)

I decided not to go with it. It would probrably work with duplicating the
tiles, but I don't like the amount of memory it takes.  Plus, if you're going
to do 4-way scrolling/panning, then you're totally screwed because you would
again have to have a virtual screen twice as HIGH as well as WIDE.  You'd be
completely out of memory, even in 320x200.

This is of course assuming that you are displaying a full screen (no split
and no left/right status bars).  You could also compromise and have a screen
1.5 times as wide as the physical screen.  Then you'd only have to bitblt
HALF of the virtual screen when you moved past it (actually not too bad if you
hardwire it with latched moves).  Of course, imageing the player (or controller
of the map-viewing) moved back and forth over that critical point for the
bitblt - you would DEFINITELY have to do it fast [unless you did the redraw
in the *center* of the virtual screen which actually sounds pretty decent]


My other Idea:

similar to yours (i think).  I have a virtual screen which is only one
tile-width greater than the physical screen (just left/right mapping for now).
(I call it the limbo tile column - don't ask).  I keep track of a 'delta' from
being aligned with the tiles.  When the delta is 0 and you move right, then
update the limbo-column.  When the delta is 0 and you move left, update the
limbo column with tiles.  (duh) Same thing, just different tiles.  Then scroll.
The screen will wrap at that point and everything to the right is shifted
down one (or is it up?).

SO, I have something called 'fixy' which is an error-value for the shifting.
fixy = virtual_width_pix / deltaX.  deltaX is the distance in pixels from the
far left (wherever you started drawing).  When you're drawing your tiles, just
add fixy to your y variable.  Then, scroll the screen up/down by fixy pixels
(this only takes 1 additional virtual screen line per screen-width of
scrolling).  It makes a *small* jump when you do this, but it's really not
that bad.
I was thinking that there might be some way of fixing the shift in hardware.
Like if you could adjust the start-address twice per horizontal scan, you'd
have it! :-]  But really, there may be some solution like that, and I'm
looking for one, but it's really not that big of a problem.


I have code working which I can send to anybody that's interested.  It uses
my sprite-library and Hobbes ModeX library, and works in any planar mode -
320x200/240/400/360x480.  If I'm just using colored-tiles, I can get a full
screen scroll in 320x400 on an OLD Compaq Deskpro/286 with an 8-bit video
card (actually looks exactly the same on my 486/33 because of the retrace
waiting) - with plenty of time to spare.

The code is totally unoptimized (in C++ no less).  Potential BIG optimizations:
if you make the tile size divisible by 4, you can always do ALIGNED transfers!
That means that Abrash-style image alignments are completely unnecessary -
so it takes only 1/4 of the video memory, and is MUCH faster (don't need
so set any masks or anything).  Simple colored-tiles are much faster too
since they're aligned (I have code for this).  [color-tiles are just - well -
one-color tiles instead of a little bitmap].

I think this might have some potential.  If anybody wants to help, please
send me mail.  I can send you a (cheezy) demo and/or the source and/or the
binaries.  Tell me if you already have Hobbes, or if you need the latest
version, so that I don't send it twice.


ugh, that was some major babbling.  hope it made sense..


-court
court+@cmu.edu