AADevLog #6 - Merry Christmas! And, yes, it will become a game.

Merry Christmas everyone! So it's christmas, and I thought I'd pull out a couple of things from my harddrive.

You might have noticed this, well, attempt at a platformer that goes by the name of "Wheelchair Hero". I'm working on it on-and-off, but there is actual progress. One of the issues I had postponed was some sort of rudimentary color management, meaning some basic strategy regarding palette use. Another one was to add some strategy elements, so the... game?... doesn't get too boring too quickly. Anyway - here's another work-in-progress screenshot of "Wheelchair Hero", and, yes, it looks as if this will become a game. :-)

Wheelchair Hero with new elevators, NPCs, items, better colors

Also a little bit of work has been done on "reed" texteditor: a little update to the GUI layout, and it now shows actual settings' values.

"reed" on AmigaOS3.9

And while we're at it: When creating a game, why not create two? Or even three? So I started drawing assets for more playable stuff. This next one might be called "Attack on the Beach", and maybe you can make a guess what it's all about from this mockup-picture:

"Attack on the Beach" concept picture

Finally, something that I had on my mind for decades. With all the knowledge gained from hundreds of programming experiments and attempts, I thought it's about time to somehow tackle the challenge. I'm pretty sure everyone gets a "rough" idea what this one might be about from this early title picture. ;-)

"Airborne Trooper" work-in-progress title picture

* * *

Thanks for reading, happy holidays & stay healthy!

AADevLog #2 - Sprites, tiles, scrolling... a game!

Another project I've been working on is slowly taking shape, and there was quite some headache involved to get it going.

In my pursuit of creating... a game! ...I've arrived at VSprites, tiles, and scrolling. The Amiga is a technical marvel, but it has it's pitfalls. So you read the docs, set up your default, low-res PAL display "View", create a "ViewPort", adjust ViewPort offsets, re-read the docs, adjust the ViewPort offsets properly, read the docs again, re-adjust... and it still behaves weirdly. At some point you try a high-res display mode. Either way, in the end result some VSprites are missing, or the scroll offset is wrong. Well, after hours and hours of experimenting, it turns out that ViewPort->RxOffset and ViewPort->RyOffset are indeed the correct variables that need to be changed to move around a larger source bitmap, but they get interpreted differently by different Kickstart/OS/chipset versions - it looks as if KS3.0 on AGA chipset, and KS3.1 SetPatch'd by OS3.9 on AGA chipset, might be messing up VSprites when scrolling, and earlier KS versions always scroll by low-res pixels, regardless of actual display (high) resolution. As a quick fix I'm focusing on what is probably still the most common Amiga configuration: Amiga 500, OCS chipset, Kickstart 1.3. I'll work on compatibility or maybe a separate version of the game later.

Basic screen mockup, to get an idea of object's sizes, and screen layout

And a "bug" in the docs was discovered: When using VSprites, you "reserve" some hardware sprites from VSprite usage by setting/clearing bits in GelsList->sprRsrvd. The docs give contradictory information about what "reserve" actually means - bit set or clear? It has now been proven and confirmed that bits need to be set to allow VSprite usage of that hardware sprite, and bits need to be cleared to "reserve" the corresponding hardware sprite from VSprite usage. Einstein-alike.

Anyway - after overcoming these obstacles it's beginning to look like... a game!

ViewPorts are a great thing, by the way. There are a couple of limitations, but whenever you run low on colors, need a different origin for your drawing coordinates, or maybe are thinking about an alternative to a dual-playfield, a new ViewPort might solve the problem.

So now it's got a scrollable bitmap, separate status bar, sprites, tiles, game map files, and a rudimentary "physics" engine that allows sideways movement and drops. That's a huuuge step forward!

No, that's not the... game! Just an early tileset.

Linux IFF picture viewer xiffview, which was created as a side-product of game development, now really comes in handy. I use it regularly, it has become part of my makefiles, and I add features as I need them.

When writing software that's handles data for different architectures, you have to pay attention to a lot of details. The reversed endianness (MSB on m68k vs. LSB on x86) has been mentioned many times. Also different compilers on different CPU architectures may have different data storage types - an "int" on a modern x86 machine is not be the same size as an "int" on Amiga. I encountered this just recently, when adding some code to xiffview that writes Amiga UWORD values to a text file, using something like fprintf("0x%04x", value). The UWORDs written had too many digits, too large for an Amiga 16-bit number. It looks like a bug on first sight, but the Linux x86 compiler is simply made to handle larger numbers (by default) than an Amiga C compiler. The solution is simple: you have to explicitly cast the value to a 16-bit data type, like this: fprintf("0x%04x", (short int) value).

Thanks for reading, c u next time!

* * *

Click here for an overview of all AADevLog articles