Alien Experiment Laboratories

Oh no, not another Learning Experience!

Posted by Chief Experimenter in Journal, Problems at 4:25 pm.

No Comments.

This week, I have mostly been eating…Z88dk include files.

Learning Z88dk and Sprite Pack v3 is definitely not for the faint of heart. Never has the phrase “the source code is the documentation” been so entirely apt.

It becomes even more fun when you realize that the comments in aforementioned source code, as well as the accompanying examples, are not always the best in the world. Fortunately there aren’t too many major areas which need to be understood.

I’m focusing on sp1.h (Sprite Pack), input.h (keyboard/joystick), spectrum.h (general Speccy stuff) and sound.h (beeps and FX) and putting together a simple example program which will allow you to move a sprite around with the keyboard, complete with actual useful comments that I can refer back to at a later time.

On that note, watch this space for something resembling a how-to/tutorial series. Same bat-time, same bat-channel, and so on.

Getting SevenuP to work in Ubuntu.

Posted by Chief Experimenter in Information, Journal at 11:52 am.

No Comments.

This isn’t the gosh-wow-amazing-awesome post I’ve been working on. That, like a 2-month-old iPod, became obsolete when I figured out a way around my graphic editing problems that didn’t involve writing a script. Well, not a big script, anyway. This is another one, though hopefully it too will prove useful to someone.

Getting SevenuP to work in Ubuntu was being a real PITA. The binary version would crap out with “library not found” type errors for the WxWidgets stuff, and building it from source got nowhere either.
Read the rest of this entry »

Pimp my site!

Posted by Chief Experimenter in Journal at 3:52 pm.

No Comments.

This week’s progress has been entirely related to the appearance of the site.

Gone is the old, off-the-shelf look, replaced by what you now see. Certified Firefox, Opera, Konqueror and Safari friendly, looks pretty decent on IE5:Mac with only a few minor breakages, looks OK on IE6 and IE7 too, though there are a couple of bugs to be squashed in both (nothing new there, though IE7’s misdisplaying of some elements is very disappointing).

If you’re using a text browser it should be all nice and semantic. I had visions of removing a lot of the classes and using child/adjacent selectors instead, but it made my head hurt. ;-)

All quiet

Posted by Chief Experimenter in Journal at 2:53 pm.

No Comments.

Nothing much of postworthiness this week. (Apart from spontaneously inventing a new word, “postworthiness”. Go me.)

I am working on something interesting to be posted, but it’s not ready yet. I’m also thinking on re-theming the site. I consulted the project manager for their take on events and they had this to say:

Games that never were - episode 1

Posted by Chief Experimenter in Journal at 12:09 pm.

No Comments.

A little history here to fill in the time.

Around 1990, the people who would later spend a significant length of time working on “Wingnuts” decided that one of our favourite board games at the time, “Dark Future“, could be made into a pretty cool turn-based game.

The project was provisionally titled “Wheels of Steel”, a name I think was used later on for some PC game or other. (Or am I thinking of the rock song?) It was pursued as far as my creating a few screens for use in the game, and a mockup of what it might look like, by which time we were all starting to move to the Amiga.

The story doesn’t quite end there, though. “WoS” was refined a little, and became something we called “Murphy’s Law”. This was being coded in AMOS within a week of me first owning an A500 and might actually have stood a chance if we hadn’t been in such a rush to get started. It stalled out, but not before a half-working demo was up and running. But that’s another story.

Anyway, here are some mock-up screens which I did (and which were the last Spectrum graphics I’d do for about 12 years)

The main game screen would have looked something like this at the start. The idea was to have it pointer-driven, similar to Carrier Command and the like.

And this would have been during gameplay.

Status displays: Weapons selection, vehicle status and detailed damage report.

I reckon it would be fun to resurrect this idea, probably as an open source project using SDL and OpenAL. It would be a good first project for me to get to grips with those libraries without having to worry too hard about realtime-ness, and of course a lot of the code and simple graphics already exist from “Murphy’s Law”. It would also lend itself well to the open source ideal of “release early, release often”, with incremental feature adds, not to mention network play or even play-by-email.

Source control and project management with Unfuddle

Posted by Chief Experimenter in Information, Journal at 5:20 pm.

No Comments.

I’m a recent convert to the idea of using source control systems such as Subversion. There are some huge advantages to be had from it, like being able to tag release versions and recover from stupid user-level mistakes (like the time I tried to copy the contents of my Spectrum +3’s RAM disk to my project floppy using COPY "M:" TO "A:" instead of COPY "M:*.*" TO "A:", erasing everything on the disk).

But I’m not here to discuss those benefits of source control. Others have done that, better than I ever could. I’m writing because it’s a good way of keeping offsite backup, if you have a suitable repository. So, in the event a huge meteor lands on your office, destroying everything within 3 blocks, including the bank vault you kept your CD-R archives in, your work will still be there.

(I assume, of course, that you weren’t in the office when the meteor arrived.)

Berlios and Sourceforge work well for open source projects, but this one is closed source (sorry RMS!). Some hunting around led to Unfuddle, which meets all my needs for this project, and is free (as in beer) for the basic single developer account.

It provides a private Subversion repository where I can keep my work safe, along with some pretty handy management tools, so I can set milestones (and then watch them slide gently by while I’m preoccupied with real-life stuff), track bugs, and generally try my best to keep things on course.

Everything works through a simple to use, slightly AJAX’y Web interface which makes both Berlios and Sourceforge look rather clunky and unwieldy. The SVN repository is available through HTTP for check-in and -out but can also be browsed using the web interface.

I’m impressed with this offering. The free version is limited to one user per project and 15MB of storage; plenty for a typical one-man retro-platform development. If I was running a small independent dev team, with a definite aim of making money, the paid-for accounts would be worth a look too.

Move it!

Posted by Chief Experimenter in News at 3:20 pm.

No Comments.

The site has successfully moved to a whole new server, after some fudging around to get the Wordpress database moved over.

It’s also moved to this, its real home domain name now, not that dumb subdomain it was on before.

If you visited the old address and are not seeing this page instead then…um, never mind ;-)

Tools of the trade, then and now

Posted by Chief Experimenter in Information, Journal at 12:12 pm.

No Comments.

What toolset does a budding retro-programmer utilize, and how does it compare to the situation back when these platforms were current?

Well, back in the 1980’s, we had a glimpse at what a professional ZX Spectrum game developer used, in Crash! magazine’s Cecco’s Log feature.

The Spectrum is actually developed on an IBM compatible PC which runs a fast Z80 cross-assembler that can compile a 200K source file in a few seconds. After the program has been assembled, it can be downloaded to the Spectrum via a parallel link, ready for testing.

The graphics are all designed on an Atari ST using the Advanced Art Studio. This package (programmed by my good friend Chris ‘8-bits are crap’ Hinsley) also features a ‘map editor’ that enables all the screens in a game to be chopped and changed very quickly. The ST format graphics are converted to Spectrum format data to be incorporated into the main program.

All of which was far beyond my wildest dreams. Compare it to the tools I was using around that same time: a Spectrum +3, some blank floppy disks (173k formatted per side), squared paper for designing the graphics, and a crappy little assembler. The 24″ RGB monitor I had back then made up for it somewhat.

The tools I can bring to bear today as a hobbyist, though, leave even the mighty Cecco’s setup looking a bit tame (not to mention space inefficient!).

The basis is a Dell Inspiron 8200 laptop with 512MB memory, an upgraded hard drive (100GB) and a 100GB external USB drive for backup, running the current version of Ubuntu Linux.

The code is written, using the Vim editor, mostly in C, possibly with some embedded assembler, and cross-compiled using the open source Z88DK development toolkit.

Graphics would be done using the SevenuP graphics editor, but right now I can’t get it to run or compile in Ubuntu, so I’ll be falling back to the old-school ways unless I figure that issue out.

The “Spectrum” is provided by the Fuse emulator, which can emulate all the major models and clones of the Speccy, and load the tape image file which Z88DK creates, pretty much instantly. This is especially helpful since I currently have no way of getting my actual Spectrum hardware to put out a useful display on the crappy NTSC tellies here in the US. Running under emulation also allows some pretty complex system monitoring and debugging to take place.

For documentation, I use LyX or plain ASCII text formats.

Total cost, not including the laptop, is $0.00; all the tools are free and open source software. Perfect for on-the-cheap homebrew development!

Now Listening To

Posted by Chief Experimenter in Journal at 3:03 pm.

No Comments.

I’ve always liked old-school chip music, even before it was “old-school”; I grew up with it, after all. At home I have lots of AY and SID modules, and a bunch of Amiga stuff too, but at work, I don’t (and farting around with playlists takes time).

What I do have is broadband access. So, I have the option of listening to internet radio.

Where can a self-respecting chip-tune lovin’, old-school developer go to hear the soundtrack to a day’s hard work, and maybe even get to hear music from retro systems they never owned or had access to back in the day?

Well, there’s Kohina, which has a pretty large, multi-platform playlist (tilted toward the C64, but that’s OK, the SID-chip is still pretty amazing today). If the Spectrum is your thing, AYLand is all Speccy, all the time, with a good helping of newer tracks from the demo scene thrown in with all the game music. SID-heads who want a twist on the old silicon soundmeister can’t go far wrong with SLAY Radio with it’s remixes of old C64 stuff.

There’s also the Blibb Blobb podcast, which isn’t live, but is pretty good listening too.

Now, back to work…

Specifying The Problem

Posted by Chief Experimenter in Journal, Progress at 1:05 pm.

1 Comment.

All programming tasks are essentially the same: you have a problem, and a solution is required.

In this case, the problem is “I want a neat game to play and all the new ones suck” and the solution is “Well, then, write one, you big lazy gimboid”.

OK, maybe not that simple. The basic game idea needs to be specified, then fleshed out. Otherwise, I might start trying to write Space Invaders and end up with Zork III. Or something.

Writing documentation is sucky, but it matters. The general spec. is important as a base on which to build. It reminds me what it was I was trying to do in the first place, and is the foundation of a successful project.

Sure, it might evolve somewhat, but it’s the foundation nonetheless.

Those foundations have now been built, and I’m ready to put together a rather more detailed low-level spec, where I decide just how to convert my bright (hah!) ideas into code.

Clearly those years of working for “large telecomms switch manufacturer” and dealing with their quality compliance has paid off. When I was a kid I could write the entire thing in BASIC in the time it took to do the general spec. But I’d more than likely have written a menu screen then moved onto my Next Big Idea without ever finishing the first. (I wrote some really neat menu screens back in the day.)

My increasingly aged brain, on the wrong end of two decades worth of close-quarters CRT radiation, can’t recall the fine details for long enough, and I can’t sit down for 10 straight hours and write a game from nothing more than an idea any more even if it could.

So I document the process instead, like a good little programmer.