mirror of
https://github.com/deater/dos33fsprogs.git
synced 2024-11-04 20:06:09 +00:00
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 ???? 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 ???? 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 L2 Memory map: 00 zero page 01 stack 02 ???? 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 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).