Island: A Game Of Survival

I was going through an image I took of an old hard drive that died in 2005 or so that my brother and I had in our computer starting from the late 90's. Came across a lot of old stuff, games, old school assignments, code I had written ... and this game that I apparently had copied from one of the school computers at some point probably in the late 90's.

Island: A Game Of Survival, title screen and credits roll

I went to school in Ontario, Canada in Durham Region (Sunderland Public School, and then later Brock High School if anyone knows the area) where the schools are run by the Durham Board of Education. Apparently this game was produced by them. As I understand it, the game itself is a recreation of a C64 game originally created by someone else. Was kind of funny to discover that this particular version of the Island game was written in QuickBASIC 4.5!

Anyway, all of the school computers had a number of education games on them, including this game. I remember playing this game quite a bit on the computers at school back then. Looking back at it now, it certainly wasn't the best game ever... not by a long shot! But it was a lot of fun re-discovering this recently and playing it again for the first time in 20 years or so.

Island: A Game Of Survival, title screen
What will you do today?

In this game, the player is stranded on a small island and must survive alone by collecting rain water, catching fish for food, and making sure not to die from exhaustion. The goal is to escape the island either by being saved by passing ships (possibly by random chance and/or by sending a message in a bottle), or to collect enough planks to build a raft. You can die in a number of ways, and in fact sending a message in a bottle can backfire with you getting picked up by pirates and being forced to walk the plank! After 30 days on the island a hurricane always comes and destroys the island and the game ends.

Choosing a message to send in a bottle
Catching fish
Collecting planks
Dieing from a lack of water

As you can see, it's a very simple game. I'm not actually sure how this port of the original C64 Island game compares as I've never played it. At any rate, I found it to be surprisingly still kind of a fun distraction. Might also be a fun little project to turn into a mobile game one day.

If there is anyone else out there who went to school in Durham Region that remembers this game and wants to play it again, you can download Island: A Game Of Survival right here. Works great in DOSBox.

Follow-up: Unisys CWD 4001

I figured that I would post a follow-up regarding the Unisys CWD 4001 mini 486 PC I picked up earlier this year. I've had a few people now ask me various questions about it. It is certainly an interesting PC, especially for those looking for a nice compact retro PC to play around with so I certainly don't mind posting some more information about it to help out anyone else with questions regarding it.

Almost six months later and I'm actually not using mine that much, as I ended up building another 486 PC in a baby AT case. This was mainly because I wanted to be able to toy around with different hardware customizations, have more options for sound cards and have internal CD-ROM and 5.25" floppy drives. Otherwise my CWD 4001 is still working perfectly fine.

Hard Disk

As mentioned in my previous post earlier this year, the hard drive it originally came with died so I replaced it with a CF-to-IDE adapter. I got a StarTech IDE2CF and a Transcend CF200I 512 MB Compact Flash card. I had to cover the bottom of the adapter with electrical tape as otherwise some of the pins on the bottom would short against the metal part of the case it is resting on (and I could not find any kind of mounting bracket to fit in there instead).

The jumpers I have configured on the CF to IDE adapter set it for 3.3V power and master mode, drawing external power from the adapter you can see plugged in in the photo.

The BIOS configuration that I use for this is 987 cylinders, 16 heads, 63 sectors. If you end up using a CF card to replace a hard disk, make sure you do a FDISK /MBR or you may end up puzzled for a while like I was as to why you are mysteriously unable to boot from it!

You should be able to use a larger CF card if that's all you have (for a short while I was using an 8.4GB IDE hard disk without issue). Though with MS-DOS 6.22 you will only be able to use partitions with a max size of ~500MB.


Mine came with an AMD 486 DX2-66 already and that's what is still installed as I write this. However, these should work fine with up to a DX4 (some even had a DX4 pre-installed). On my CWD-4001 there is a voltage regulator on the motherboard so this should support 5V and 3.3V CPUs just fine, but I've not actually tried this. Do your own research first before trying!

On the underside of the motherboard on my CWD 4001 there is a motherboard diagram showing jumper settings. I've heard some people didn't have this, so I'll share what mine looks like:

The CWD 4001 doesn't include any L2 cache but since these are 486 machines, I believe all CPUs that these would ever have shipped with had 8KB L1 cache. The BIOS has an option to enable CPU write-back cache so if you have, for example, an Intel 80486 SX955 (P24D) then you can make full use of it. Though you will also have to configure the jumpers as shown in the diagram above. However, probably most people won't have a CPU with write-back cache support. Not to worry if you don't, it doesn't make a massive (real world) performance difference anyway.


For MS-DOS, you'll want the NE2000 packet driver. Then you'll want to add this to your AUTOEXEC.BAT with something like the following:

C:\NET\NE2000.COM 0x60 10  

Where the 10 is the IRQ for the network adapter. Mine was set to 10, yours might not be (IRQ 10 or 11 were very commonly used for network adapters). I didn't have to tinker with any BIOS settings to make this work (not that there really is much of anything that you could change that would affect this to be honest).


As mentioned in my previous post, I'm using a Creative Sound Blaster CT4170 (Vibra 16XV). Your options for sound cards are quite limited with a CWD 4001 due to the compact size of the case. As far as Creative cards go, you'll probably be stuck to only a few of the later models that were more compact. Probably the best choice is one of the AWE64 value cards that is more compact but I don't own this card personally. I'm unfamiliar with what other Sound Blaster clone cards may fit.

For me, using IRQ 5 and 7 both worked. Remember that IRQ 7 is also used for the parallel port (LPT1), so if you're using any parallel port device you may want to configure your sound card to use IRQ 5 instead.

I have the following in my AUTOEXEC.BAT for my CT4170:

SET BLASTER=A220 I5 D1 H1 P330 T6  


The CWD 4001 I would say is pretty average for a 486 DX2-66 system. It does not have VLB graphics, but the Cirrus Logic GD5424 isn't too bad really. The lack of L2 cache is also unfortunate, but the RAM speed seems a bit faster than other 486 systems I've tried... maybe something specific to the chipset/motherboard? Not sure really. The two RAM sticks installed in my CWD 4001 are nothing special, two HYM532220W-70 (72-pin 8MB 70ns) sticks.

Versus the other 486 system I built (Intel 80486 SX911 CPU, FIC 486-PVT motherboard, S3 Trio32 VLB, 16MB RAM) just for a slightly apples-to-oranges comparison:

How does this translate to "real world" performance? Well, I can share with you the results from running Phil's DOS Benchmark Pack on both of these systems:

CWD 4001 FIC 486-PVT, SX911, S3 Trio32 VLB
3DBench 1.0 41.6 fps 50.0 fps
3DBench 1.0c 40.4 fps 48.2 fps
Chris's 3D Benchmark 26.9 fps 31.4 fps
Chris's 3D SVGA Benchmark 9.1 fps
PC Player Benchmark 10.1 fps 9.6 fps
PC Player Benchmark (640x480) 4.0 fps 3.8 fps
Doom (min. details) 71.4 fps 70.0 fps
Doom (max. details) 24.3 fps 26.1 fps

Not really too surprising here when comparing ISA graphics to VLB graphics (in particular the S3 VLB graphics cards tended to be top-tier, performance wise).


A few people have asked questions after obtaining their own CWD 4001 (or 4002) after seeing that they were missing some internal components. In particular I've seen some people missing the ISA riser card and/or the bracket that fits onto the inside back of the case which the back plate of an ISA card would slide into when installing one. I'm unsure what people are doing for replacements for these and even if they are easy to come by, but for people's reference I've taken a bunch of photos of the ISA riser card and the ISA back plate bracket thingy.

Anyway, I hope the above helps anyone else looking for information about these Unisys CWD mini 486 computers. Feel free to email me though if you have any additional questions of course (my email address is on the "About" page linked on the left).

DOS coding

Last month I picked up a copy of Fabien Sanglard's Game Engine Black Book: Wolfenstein 3D. In fact, I was eagerly waiting for the day I could order a copy. When it arrived I was totally engrossed in it the whole way through. It's an amazing book, well written and well worth the read for anyone interested in those kinds of topics. Fabien really did a great job with it and I'm eagerly awaiting the next book in the series which will cover the DOOM engine.

It also got me thinking about some DOS code I had started to write a couple months prior and then set aside temporarily. I had begun writing a simple VGA Mode 13h library I had called "DGL" for "DOS Game Library" because naming is not a strong suit of mine. So, I'm going to pick it up again and hopefully continue writing about it here as I work on it and then soon after, some little game demos written with it also.

Of course, there's absolutely no good reason to re-invent the wheel from scratch like this. Libraries such as Allegro exist and any of the 3.x or 4.x versions for DOS would perfectly meet all my requirements and is probably far better implemented than anything I'd cook up myself. But that would be less fun.

Anyway, what I want out of this library is:

  • Support for VGA mode 13h (320x200x256)
  • Primitive drawing (pixels, lines, boxes, circles, polygons, etc)
  • Bitmap/Sprite drawing (aka. "bitblit"-ing)
  • Palette manipulation (loading, rotating, fading)
  • BMP, PCX, IFF image support (period-correct file formats)
  • Font rendering (using BIOS font format). Also add non-fixed width support?
  • Keyboard, Mouse, Joystick input device support
  • PC Speaker sound (maybe even rip off QBasic's PLAY command?)
  • Sound Blaster (and compatible) support (MIDI music, FM synth and digitized audio sound effects)
  • Math function suite (vectors, matrix, etc)

The only thing in this list that I think is (currently) outside my skillset (but totally possible to learn, of course) is the Sound Blaster stuff... simply because I've actually never written an audio engine of any sort, and certainly not ever written code directly for Sound Blaster hardware.

In fact, the only time I've added audio to game projects of mine was via DirectX. Not sure how DirectX is nowadays, but I remember at the time I was using Visual Basic 6 and the libraries for it had play/pause/stop functions for both sound effects and background music out of the box, so it was extremely simple to hook into the projects I worked on. Most game projects of mine tend to get dropped before I get to the point where I need to add audio, heh. And in more recent years, it was always my intent to use something like SDL_Mixer to take care of the lower-level details anyway, but I just never got around to it.

So, needless to say, when it comes to audio for this project I have a bit of fundamentals learning work to do.

Also on the topic of audio, I would like to look into adding support for Gravis Ultrasound cards. These cards are interesting as I think they were the first sound card for PCs to have full hardware audio mixing support. As I understand it, Sound Blasters lacked hardware mixing capability, so game engines would do this in software. But this will be a nice optional extra for later if I feel like it.

Originally, I had planned to use Borland C++ for this and do it all in real-mode DOS code. That probably sounds like totally unnecessary pain to anyone who understands the differences that brings along with it. I even went and bought a copy of Borland C++ 4.0 off eBay:

However, after fiddling around with it for a while I remembered how easy it was to crash your system with real-mode C code and how the debuggers of the time were helpful, but not that helpful in tracking down these types of bugs. This was less clear in my memory prior to this because during this time period I was primarily using QBasic which obviously shielded you from these types of bugs much more.

So instead, I plan to continue using a period-correct version of DJGPP (meaning, a version from the late 90's). Better debugger support for dealing with these types of crash bugs. Still possible to crash your system in weird and wonderful ways of course, but more support than Borland for catching these bugs. Plus having a 32-bit flat memory model is obviously very nice.

I plan to keep the code for this library on Github somewhere when there is something to show for it.

Mini 486 PC: Unisys CWD 4001

UPDATE: I posted a follow-up here where I go into to more details about this PC which may be of some interest to you.

A couple weeks ago or so, I came across a forum post with someone showing off a mini 486 PC by Unisys. After a bit of searching, I discovered that there was a seller on eBay who had a bunch of these for sale so I would easily be able to get one. When I saw this, I instantly thought to myself "I must get one of those!"
EDIT: It seems a video someone posted about these got a bunch of people buying them from this eBay auction which in turn caused the seller to bump up the price considerably. I only paid $97 CAN for mine!

However, I decided to sleep on it and wait a few days first and see if afterwards I still wanted it. I had originally decided that I did probably want to either buy or build a 486 PC at some point -- actually scratch that. While I had initially thought it would be cool to go as far back as a 486, when I thought about it some more I realized that getting at least a Pentium would probably make more sense. This was because in addition to wanting to use it for some "old school" development purposes, I'd also definitely want to use it to play games. And a 486 wouldn't cut it for that use for me personally. And with this thought in my mind, the question of what exact hardware specs I should go for was left unanswered and I realized that I had to do more thinking on it all. And regardless, I wasn't in any rush as I was still having fun fiddling with Amiga-related things.

Well, after a couple days passed by I still found myself thinking about it quite a lot. Space is at a bit of a premium for me as lately I keep buying random electronics toys that I don't really need. But what other small 486 PCs am I likely to find or be able to build myself anyway? Plus it wasn't that expensive (well, shipping to Toronto cost more than the PC itself, but even so, I can afford it ... meh). So I bought one!

It arrived pretty quick (4 days). And my god, it is small!

There's little information out there about these that I was able to find, just a few web pages with spec lists and some French videos on Youtube from some guy doing both an overview and a tear-down. Evidently, the exact hardware that these come with can vary a bit, but mine was:

  • Model: Unisys CWD 4001-ZE, Manufacture date: Sept 10, 1995.
  • CPU: Am486DX2-S 66MHz, socket 1 LIF PGA 169-pin with star-shaped heatsink.
  • RAM: 16MB. 2x HYM532220W-70 (72-pin 8MB 70ns DRAM).
  • Graphics: Cirrus Logic CL-GD5424, 1MB VRAM
  • Network: Accton/Unisys UK0022 (based on Novell NE2000)
  • Sound: PC speaker
  • Hard Disk: Fujitsu M1612TAU (545MB) IDE
  • Floppy Disk: Teac FD-05HG-4684-U (Slim)
  • Expansion: One unused ISA slot
  • Ports: 15-pin VGA, DB25 parallel port, 2x DB9 serial port, 2x PS/2 port (keyboard/mouse), RJ45 network port
  • PSU: Built in (proprietary).

Total dimensions: 29cm x 22cm x 6cm (width/depth/height).

Here's what the motherboard looks like for those curious (click for full picture):

In the above picture, the floppy drive, hard disk, and ISA riser have all been removed of course. But with them all in there it's packed in pretty tight! I was a little bit concerned about what the temperature might be like when it's been running for a while, especially since the only fan in the whole computer is a small one for the PSU only.

Honestly, I'm quite happy with these specs! I knew it was possible that these could come with anything from a 486DX2 33MHz to a 486DX4 100MHz, and I was hoping for at least a DX2 66MHz since it's what's largely regarded as a minimum spec necessary for playing games like Doom at a decent speed (you can do it with less of course, but then it all depends on your tolerance for lower framerates). 16MB of RAM is plenty and for a 486, you won't need any more at all. I was a little bit unfamiliar with the graphics cards of this era since I was younger at the time and had no money anyway, so I just used whatever was available to me (heh), but a GD5424 with 1MB VRAM is not too shabby either. Not amazing, just average really. Onboard LAN is quite nice, means I don't have to use floppy disks to transfer stuff to it since it's obviously lacking a CD-ROM drive.

Aside from the lack of a CD-ROM drive, the other big thing that is missing is sound. With no onboard sound capabilities aside from the lovely PC speaker and with a single ISA port available, getting a Sound Blaster card seemed like the obvious next step.

Of course, since this is such a small computer, one needs to take into account whether any given expansion card will actually fit into the case. Most of the better Sound Blaster card options are unfortunately too long.

I eventually settled on two possible options: a Sound Blaster AWE64 or a Sound Blaster Vibra 16XV. The few people I could find that had these computers all seemed to go with the AWE64 (something like a CT4520 is small enough to fit). I ended up going with a Vibra 16XV CT4170 mainly because I found one locally for cheaper, but would've gone for an AWE64 otherwise myself.

The only other thing of note was that within a few days of having this computer, the Fujitsu hard disk it came with died. I didn't intend to use that disk over the long term and had already ordered a CF-to-IDE adapter to replace it with. However, since the adapter hasn't arrived yet, I ended up replacing the drive temporarily with an 8.4GB Maxtor drive I still had sitting around. The BIOS only recognizes 2GB and is only able to boot from a partition that is 504MB (max) however.

For the first several days I was using an old SyncMaster 943N 19" 4:3 LCD monitor but grew tired of the poor upscaling of low MS-DOS resolutions. Picked up a cheap CRT monitor (a 15" Sony Trinitron CPD-100SX) from someone on Kijiji and now I really feel like it's all come together as a real old-school DOS PC!

In the above picture, the text editor on-screen is RHIDE for use with DJGPP. I was fiddling with some VGA Mode 13h C code... a nice trip down memory lane.

Overall, I'm glad I got it. It runs great, it's quiet, for a 486 it's decently specced and runs pretty much any games I throw at it from up until about 1996 or so (then you start getting into games really intended for Pentiums). Even Duke Nukem 3D is playable at 320x200, though barely. I actually think that the CF-to-IDE hard disk would help here as I do notice the game does load stuff from disk during game play here and there, and it seems like those disk accesses usually correspond with a slow down.

After the computer has been running for a while, the PSU does heat up quite a bit and the case does get warm to touch on that side. It still does concern me a little and I might investigate to see if I can get a better fan. Also, I would hope that once I remove the "big" hard disk and replace it with a much smaller CF card that it might help improve airflow inside the case and possibly reduce the internal temperature a little bit. However, from what I can tell from the few other forum posts that I've found from others who own this computer, heat doesn't seem to be a problem. So, fingers crossed that it remains that way as I'm not sure what else I could do (nowhere inside the case that I could install an additional fan or anything like that).

Shmup Game First Steps

After playing with both AMOS and Blitz Basic, I initially had an overall poor impression of Blitz Basic mostly due to stability issues. This was disappointing to me because it seemed pretty clear that AMOS was a little bit slower, but at least it did seem more approachable.

Ultimately though, when I reflected on the various game ideas I had floating around in my head, I really figured I would end up quickly outgrowing AMOS from a performance perspective. So I decided I would look at Blitz Basic again, but try to see what I could do (if anything) to work around the stability issues I had run into earlier. I should note at this point that yes, I did have the runtime debugger enabled, so I don't think that was the cause of any of the crashes I was seeing. That was the first thing I checked when I was having issues. Some of the crashes weren't even occurring while a program was running anyway...

First, I decided that I would not use the "mousable labels" support. Blitz's editor "TED" pops up a side navigation pane showing your program's labels for quick navigation only if your program has any. A "mouseable label" is just an ordinary label that you would use with GOTO or GOSUB with the exception that it should start with a period, e.g. .renderPlayfield: instead of renderPlayfield:. I had noticed some random crashing that would occur when I was fiddling around with some of the sample programs that included these types of labels. Additionally, I had encountered a severe problem with the updated TED version included in the Blitz Support Suite ("SuperTED" I believe it was called? Or might have been the update before that?) where it would immediately crash when opening a program with any of these types of labels. Definitely seemed to me that the editor support for it was at least partially broken... at least for me, though I'm not sure what I could have done to cause these issues, heh.

Second, I had finished completely reading through the user guide (which is honestly a quick read, less than 100 pages) and had run across the recommendations and warnings for using "Blitz mode" (which you will undoubtedly want to use for performance reasons). Most importantly, any disk access or other concurrent OS processing that occurs while a program is running in Blitz mode (or as it first enters Blitz mode) can cause crashes! How about that. I suppose it's possible that this accounts for at least some of the instability I was encountering before. The user guide recommends doing something like VWait 120 just before a BLITZ call to ensure that any disk buffers have had time to be flushed (evidently the OS does so every two seconds?). It notes that there is no software method to check for whether stuff like disk activity has completed so this seems like the only way to protect against this kind of crash. Also it is important to note that none of the sample programs that use Blitz mode do this, thus furthering my belief that this was at least part of the problem I had run into when previously toying about with Blitz Basic.

Anyway... so far so good! I've only had one crash all weekend, and I believe that actually was related to my misuse of Blitz mode and/or of some dual playfield slice functionality. For most of the weekend, I was booted up into a Blitz Basic 1.7 floppy and not using the hard disk functionality provided by my ACA500plus. I wanted to remove as much other possible factors as I could and that seemed like a big one. Late this afternoon I resumed using the ACA500plus and CF card hard disk and have so far been running completely stable as well with that configuration. Fingers crossed that it stays that way.

Without having to worry about crashes, I was able to get a lot of experimentation and learning done and got some very preliminary work done on a basic vertical shmup type game. Nothing fancy, but I'm happy for a few hours work with lots of flipping around through manuals slowing things down (really want to get a physical copy of the Blitz Basic Reference Manual... I hate having to constantly look up commands in PDFs).

I'll try not to make posting big code dumps a habit on this blog, but here's what I've got so far:

; shmup test

#KEY_UP = $4c
#KEY_DOWN = $4d
#KEY_LEFT = $4f
#KEY_RIGHT = $4e
#KEY_SPACE = $40

#SPEED = 2





ASSET_ROOT$ = "Projects:resources/"  
ASSET_SHAPES$ = ASSET_ROOT$ + "shmup.iff"  
ASSET_STARS_BG$ = ASSET_ROOT$ + "shmup_stars_bg.iff"


Statement ASSET_LoadPalette{pal}  
  LoadPalette pal,ASSET_SHAPES$
End Statement

Statement ASSET_LoadStarsBg{destBmp}  
  BitMap destBmp,320,512,5
  LoadBitMap destBmp,ASSET_STARS_BG$
  Scroll 0,0,320,256,0,256,destBmp
End Statement

Statement ASSET_LoadShapes{}  
  BitMap 0,192,256,5
  LoadBitMap bmp,ASSET_SHAPES$

  GetaShape #SHAPE_LRG_ENEMY,0,0,32,32
  GetaShape #SHAPE_LRG_ENEMY+1,32,0,32,32

  GetaShape #SHAPE_MED_ENEMY,64,0,32,16
  GetaShape #SHAPE_MED_ENEMY,96,0,32,16

  GetaShape #SHAPE_SML_ENEMY,64,16,16,16
  GetaShape #SHAPE_SML_ENEMY,80,16,16,16

  For i=0 To 4
    GetaShape #SHAPE_PLAYER+i,0+(i*16),32,16,24
    GetaShape #SHAPE_PLAYER+i+5,0+(i*16),56,16,24
  Next i

  GetaShape #SHAPE_BULLETS,80,32,16,16
  GetaShape #SHAPE_BULLETS+1,96,32,16,16
  GetaShape #SHAPE_BULLETS+2,80,48,16,16
  GetaShape #SHAPE_BULLETS+3,96,48,16,16

  For i=0 To 5
    GetaShape #SHAPE_EXPLOSION+i,0+(i*16),80,16,16
  Next i

  GetaShape #SHAPE_POWERUPS,80,64,16,16
  GetaShape #SHAPE_POWERUPS+1,96,64,16,16
  GetaShape #SHAPE_POWERUPS+2,80,80,16,16
  GetaShape #SHAPE_POWERUPS+3,96,80,16,16

  Free BitMap 0
End Statement

Statement ASSET_Load{}  
  NPrint "Loading palette ..."
  NPrint "Loading stars background ..."
  NPrint "Loading shapes ..."
  NPrint "Done loading assets!"
End Statement

; -------------------------------------------------------------------

Statement GAME_Init{}  
  VWait 120

  Buffer #BMP_PLAYFIELD,16384

  Slice #SLICE_STATUSBAR,44,320,#STATUSBAR_HEIGHT,$fff8,5,8,32,320,320
  Use Palette #PAL_GAME

  Use Palette #PAL_GAME
End Statement

Statement DRAW_StatusBar{}  

  Cls 14
  Print "TODO: Awesome statusbar here"

End Statement

Statement DRAW_Playfield{}  
  SHARED scrollY, playerX.q, playerTiltOffset, animateOffset


  Show #BMP_PLAYFIELD,0,scrollY

  tile = #SHAPE_PLAYER+2+playerTiltOffset+(animateOffset*5)
  y = #PLAYFIELD_HEIGHT-32+scrollY
  BBlit #BMP_PLAYFIELD,tile,playerX,y

End Statement

; -------------------------------------------------------------------



animateFrame = 0  
animateOffset = 0

playerTiltOffset = 0  
playerHorizAccel.q = 0  
playerX.q = 320/2-32/2

scrollY = 0


While NOT RawStatus(#KEY_ESCAPE)

  scrollY = QWrap(scrollY - #SPEED, 0, 256)

  animateFrame = QWrap(animateFrame+1, 0, 5)
  If animateFrame = 0
    animateOffset = QWrap(animateOffset+1, 0, 2)

  If RawStatus(#KEY_LEFT)
    playerHorizAccel - 1
  If RawStatus(#KEY_RIGHT)
    playerHorizAccel + 1
  playerHorizAccel = playerHorizAccel * 0.7
  playerX = QLimit(playerX + playerHorizAccel, 0, 320-16)
  playerTiltOffset = Int(playerHorizAccel)




So yeah, very basic and/or crude for now. It doesn't look very impressive running yet either:

All you can do is fly the ship back and forth (but hey, it animates and the ship tilts a bit from side-to-side as you move left and right... exciting, right!?). I'm using the art assets from this package on OpenGameArt. Packaged everything together with a separate simple star background and exported as an IFF.

Actually the asset management has been a slight bit of a pain so far. I first noticed that Photoshop has the ability to save as Amiga IFF, so I would pre-convert the image I was working with to indexed colour mode and set up a 32 colour table and then save as an IFF. This seems to produce something that always is loadable by Blitz Basic (and AMOS for that matter), but occasionally produces a file that Deluxe Paint says is "mangled." Also sometimes, when loaded in Blitz Basic, the palette is somewhat off. Some colours will be totally different, but most will be correct. In this case, I've noticed I can fix the problem by opening the IFF in Deluxe Paint, and if it doesn't complain that it's mangled, I can simply re-save the file and the problem goes away. My suspicion is that Photoshop saves the palette information in a different way then what Blitz Basic is expecting, but I have not investigated this fully yet. I also tried using XnConvert by exporting from Photoshop as a indexed colour PNG or GIF and then converting to Amiga IFF with XnConvert, but still have run into the same issue (I think? I might also have mixed up my working files, heh, so will need to confirm that first I guess). At any rate, I definitely still have lots to do to nail down my asset preparation process.

Next steps will be putting together some custom font routines (I'm not sure how to generate the "Blitzfonts" that Blitz Basic supports, but at any rate, I don't think that supports bitmap fonts which is what I really want to use anyway). Following that will be adding the ability for the player to shoot and then adding enemies. I'm really curious to see how quickly I run into slowdowns.