Another / Out-of-This World Demake for Apple II+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
by Vince "Deater" Weaver (vince@deater.net)
http://www.deater.net/weave/vmwprod/ootw/
Disk and LZ4 routines by qkumba
+ The game "Another World" was released in 1991.
Written by Eric Chahi.
It was eventually ported to many systems (I played it on IBM PC).
It even got an Apple IIgs port (the IIgs is 16-bit with fancy
graphics and sound). However you couldn't play it on
earlier Apple II systems... until now.
+ I was inspired to do this by this amazing PICO-8 version of:
https://liquidream.itch.io/another-world-survival
and thought the Apple II lo-res palette (15 colors, 40x48 graphics)
might be just barely enough to do it justice.
==================
Game controls:
==================
This info appears while loading too, but if you are in an emulator with
fast disk access it might not be on the screen long enough to see.
D -> - move right (twice to run)
A <- - move left (twice to run)
W up - jump
S down - crouch / pickup
space - kick / gun
L - charge weapon
During the intro, you can press R to make it repeat forever.
Hints for those who have never actually played the original game:
+ At initial arrival, hit up a bunch of times to escape the
tentacle monster. On an original II w/o autorepeat
you might have to bang on the keyboard a lot.
+ You can kick some enemies. Crouch-kicking is sometimes
a bit easier than stand-kicking.
+ When running (i.e. after pressing left or right twice)
you can press "up" to run-jump which is faster than
plain running. That might be useful if you need
to out-run something.
+ When you get the gun, use space to fire the laser.
You can use "L" to charge your gun for special actions.
Charge a little bit then press "L" (or any key)
to create a shield.
Charge a longer time (a few seconds, when the charge
ball gets bigger) and it will make a giant blast capable
of destroying doors and shields.
Note: the original Apple II had no up/down buttons, which is why
you can also use WASD for movement. Different emulators handle
this differently, but if for some reason up/down is not working
try using W/S instead.
Joystick support: none yet?
It should be possible, I just haven't had time to implement yet.
Keyboard Limitations:
Note, Apple II has simplistic keyboard support.
In general it's not possible to read more than one key at a time.
Additionally, on older models there's no auto-repeat unless you
hold down the REPT key, which makes running difficult.
This means it's really not possible to use the keyboard the
same way as the original game (which had you do things
like holding down spacebar to charge the gun and then
firing when you release it. Same for running faster
by holding left/right and space at the same time).
==================
Development notes:
==================
Ootw Memory map:
00 zero page
01 stack
02 disk-filename (30 bytes)
03 nibble table/disk data
04-07 GR page0
08-0b GR page1
0c-0f background ($c00 = disk load buffer)
10-13 background overlay
14-16 loader
17-bf program-data (41.25k)
bc-bf earthquake background (shifted)
c0-cf I/O
d0-ff ROM
Intro Memory map:
00 zero page
01 stack
02 disk filename (30 bytes)
03 nibble table/disk data
04-07 GR page0
08-0b GR page1
0c-0f offscreen data ($c00 = disk load buffer)
10-13 offscreen data2
14-16 loader
17-89 program/compressed-data (30.25k)
90-bf currently decompressed level data (12k)
c0-cf I/O
d0-ff ROM
Intro Memory squeeze!
10,748 over all graphics in
10,734 over remove extraneous blank bg image
8,658 over re-arrange memory map, 42k avail now
8,562 over move gr_make_quake out of common code
8,374 over remove extraneous code (mostly put_sprite_flipped)
5,469 over allow changing bg on fly in sequence
4,122 over modify cyan frames to be on fly
2,749 over do same for zappo routines
2,493 over squish disk loader vars to page 3
2,165 over horrible hack to auto-go to next image in sequence
2,114 over move bg loading into seq
2,053 over make elevator indicator a loop
1,347 over use LZ4 instead of RLE
Gave up, see if we can compress in chunks and decompress, sort of like
my chiptune player does.
Let's take a 12k region of memory = $3000
$C000 - $3000 = starting at $9000
ID1 = 1461 2143\
ID2 = 1759 2687|--- together in 01
ID3 = 1195 1879/
ID4 = 2514 8280\--- in 04
ID5 = 1947 3492/
ID6 = 2584 3610\ --- in 06
ID7 = 2834 3606/
ID8 = 3705 4918 | -- in 08
ID9 = 4494 5901\ -- in 09
ID10 = 3397 5558/
===== ======
25890 12k
ootw memory squeeze:
after full rope sequence in: 23065
make transparent overlays: 13971
add end-of-l1 cutscene: 26464
make transparent overlays: 17821
add in rest of end cutscene 23906
make those transparent 21236
ootw2 memory squeeze:
before intro 3872
after intro 9234
LOADER=1400 TITLE=1.75k = 7 pages = load at $D00
2560 max size allowed
L2 Memory map:
00 zero page
01 stack
02 disk-filename
03 nibble table/disk data
04-07 GR page0
08-0b GR page1
0c-0f offscreen data ($c00 = disk load buffer)
10-13 offscreen data2
14-16 loader
17+ game
c0-cf I/O
d0-ff ROM
since there seems to be vague interest in this, reasons to use the
various graphics modes.
lores benefits:
+ 40x48, 15 colors (two greys) (which is fine, as I use one for sprite transparency)
+ hardware page flipping
+ each display only 1kB (leaving lots of room for code) (also fast to clear screen)
+ (software) sprites and animations are relatively small
lores downsides:
+ blocky
+ pixels are rectangular
+ framebuffer is non-linear (to get to next line requires a lookup table, not a simple add)
+ odd/even lines are high/low nibble in a byte, so to draw sprites properly need a lot of shifting an masking (I cheat and only allow sprites on even lines)
+ framebuffer has "memory holes" between lines. These are areas of memory reserved for expansion card use, so you can't just load a 1kB image straight to the framebuffer as it could break things.
+ NTSC artifact fringing between colors
+ lores PAGE2 is not frequently used so is broken in some emulators and on some early IIgs models
hires benefits:
+ 140x192 6 colors
+ hardware page flipping
hires downsides:
+ non-linear framebuffer even worse than lo-res
+ 8kB per page. two pages of hires takes 1/3 of total RAM in an Apple II+
+ NTSC artifact color. If the bit patterns in adjacent pixels is 00 it makes black, 11 makes white, so if you join two different colors you get lines between them
+ you get 7 pixels per 2-bytes. Which means a lot of dividing by 7, slow on 6502
+ each 3.5 pixels has a bit indicating palette (black,white,green,purple) or (black,white,orange,blue). You get zx-spectrum like color clash if you try to mix colors too close together
+ to get fast software sprites usually you make a set of 7 pre-shifted versions of the sprites, which takes up a lot of room
double-lores
+ 80x48, 15 colors
+ requires IIe or newer (80 column card)
+ requires drawing extra 1kB of data to bank-switched AUX RAM
+ AUX ram colors are shifted one bit to left from main bank colors
+ while it's possible to get hardware page flipping, it's really complex
double-hires
+ 140x192, 15 colors!
+ requires IIe or newer and 128k of RAM
+ requires drawing 8k of additional data to bank-switched AUX RAM
+ again, page flipping is complex
In any case, I chose lo-res for the Another World conversion for 3 reasons
1. Another World traditionally has 16 colors (and I like the lo-res colors)
2. I wanted to fit levels in 48k, and as many as possible on a 140k disk
3. I am too lazy to implement a full hi-res sprite library
The recent C64 Another World conversion looks much more impressive and hi-res,
but I think they use a 1MB cartridge just for the intro movie alone
(which is possible larger than the size of the original game for the Amiga).
d8713df1f0