[Ongoing] Blob Attack II

[Arne]

Hi! Long time lurker here with a project. I hope this is the right section (so many!).

Back in 1995, if I'm to believe the date of the files which survived, I made a simple TBS game using AMOS and released it informally among friends (no BBS access). Anyways, working on a sequel now, for the Amiga! I'm using AMOS Pro v1.12 installed from my originals on a 2.5inch IDE HDD that I'm moving between my A1200 (Blizzard 1220/4) and WinUAE via USB adapter.

Project page: Blob Attack II

Graphics WIP:

I'm using 12x12 tiles, but blitting speed isn't much of an issue with a TBS, I'm wagering. I'd like it to run on OCS so I might have to be careful when writing my retain mode draw-update routines though. 320x256 pixels. Hopefully I won't run into a tile count limit.

I saw someone else here (Metroid project guy) used my 16 color palette. It was made with black background graphics in mind but it might come out a bit dark using real hardware & CRT TV gamma. Easily adjusted anyways.

Milestone 1:
1) Get gfx loaded and tiles grabbed. Lots of coordinates! Use constants (seems to be none in AMOS) to keep track of significants offsets or it'll get messy. Photoshop saved IFFs sometimes doesn't load in DP (byte alignment bug?) so I might have to write a converter myself.

2) I've already extracted my old level data, plotted it using single pixels, and edited it in Photoshop to truncate it into the new playfield size (I like to edit maps as images). I'll probably write an image->byte file editor using BlitzMax on my Mac then load the resulting files in AMOS using BLOAD or whatever. I might make a pure editor in AMOS later.


3) Bring those two together with a basic map display routine.

That's it for now!

[Tsak]

Interesting project... Gfx looks really nice!

PS: Photoshop IFFs don't cope well with amiga generally. But you can save your gfx from photoshop to PNG-8 or GIF format and then convert those to IFF on your amiga (there are some nice converters at aminet, ex. GFXCon: http://aminet.net/package/gfx/conv/gfxcon). Also if you happen to have Personal Paint you can load, edit and convert PNG-8 images to IFF there

[Arne]

Thanks

I suspected there already were converters, but I didn't feel like downloading stuff so I wrote a program which converts an image to a custom chunky 4-bit nibble format. After generating the file it turned out my IFF loaded just fine this time so... well maybe I'll need the program later.

I'm halfway to milestone 1. Map file is ready for loading, I'm grabbing images, but have hit a snag with drawing operations which... I guess suspected was there all along. When mask is disabled on Icons, Blocks or Bobs, then blitting is done with width increments of 8 (edit, no 16!) because of bitplanes. My tiles are 12x12 because it suits the presentation. Solutions:

1) Draw a black 'Bar' behind every refreshed tile to clear to black and avoid overlapping residuals. The only major map update will be on end turn when all of the aliens move, but i'll probably be fine because the game needs no smooth movement.

2) If there is a mask bitmap I suppose I could poke it to form a solid block with a transparent (16-12px) right edge. Right now the mask is automatically generated by AMOS (from color 0) upon grabbing. Edit: Used this solution.

[Retro1234]

I like you web page and art

[s2325]

Yes, not inspired by other Amiga game but still high quality, it's rare today.

[Arne]

Glad you liked it. I've made slow progress. Was careful with my structures, because with BASIC being sloppy early on will come back and bite'ya.

Milestone 1 has to be considered complete though. I have the map data and graphics loaded and ready for gamey happenings! Almost 400 images grabbed. Source is approaching 600 lines. I also made a loading screen because I'm doing so much stuff on boot.

Milestone 2:
A) Clean up the structure of the program so I have clear sections for title, intermission, mission play, turns etc. Make sure I zero variables properly (the entire thing is Gosubs, just for kicks, but apparently Procs can be slow?).
B) Add rudimentary tile/unit selection using mouse and implement individual tile draws (Slightly complicated by my insistence to poke directly in banks/ram rather than using 2D arrays). I'm also doing retain mode so individual redraws must work nicely.
C) Possibly implement a Double Buffer with manual Flip, or a custom equivalent.

[Arne]

And I hit ctrl+p (paste in AMOS) instead of ctrl+v and lost my post as I jumped to a printer page.

Progress report: I now have Mouse "zones" set up and working with the so far relevant GUI stuff. Map cells and units can be selected (using a sprite with flash as cursor). Units can be turned and moved around. Did a fancy half step movement buffer so later when I have lots of moving enemies they won't simply warp so you lose track of who's who. Atm only one unit is moved at a time so I'll hold off with Double Buffer until I can test it's worth. Program is now 1000 lines and 30000 bytes of text buffer. All Gosubs! And a Goto switch! I'm playing with power!

Milestone 3:
A) More cleanup. I can be a bit more dirty with generic routines which doesn't assume that global variable UNIT_ANG has not been hijacked along the way... It's my main source of bugs now. Should delete my depreciated Gosubs for a cleaner look.
B) The game! Well, the mechanics of the old game where I only had very few unit types. This means that I also have to get the main game flow in place with player and enemy turns alternating and small stuff like automatic unit selection when it's the player's turn again. Game Over detection, which can happen for a number of reasons.

That's plenty enough!

[Predseda]

This looks really well, you are now being watched

[Gzegzolka]

Nice project, I hope You will finish it

[Reido]

Good luck with your game!

[Arne]

Thanks all! Sorry I have no screenshots, but almost everything is under the hood atm.

I decided that Alien Invasion and Blob Attack are both generic so I'm going for Gosub Invasion now! Gosub almost sounds a bit Lovecraftian for non-programmers...? Iä! Gosub Nyathol'bolg!

[Arne]

Idea for some time later:
Write a text parser in BlitzMax which goes through my AMOS source, finds the Gosub segments and calls and builds a relation mind-map. Also look at which variables are set or used and mention count. This way I can more easily tell if a Gosub expects to use a variable coming from a particular parent Gosub. I might need this for when I hit 2K+ lines.

[Devlin]

Really looking forward to seeing this finished and then playing it on my A1200

Originally Posted by Arne

Idea for some time later:
Write a text parser in BlitzMax which goes through my AMOS source, finds the Gosub segments and calls and builds a relation mind-map. Also look at which variables are set or used and mention count. This way I can more easily tell if a Gosub expects to use a variable coming from a particular parent Gosub. I might need this for when I hit 2K+ lines.

Instead of using Gosub and indexed variables, wouldn't it be cleaner to use Procedures?

[Arne]

It certainly would, but I was in the mood for some BASIC Gosubs and Gotos. Procs in AMOS are a bit... quirky anyways. And if I wanted to write cleanly and conveniently I'd use BlitzMax.

I just split the code up into 3 inlcudes, Main with logic and includes, Boot stuff and Draw stuff. Was getting tedious to scroll. The disadvantage is that includes must be loaded off disk every run and thus be saved with every change. Also makes it seemingly impossible to get rid of the brown default screen during this include load time.

[Nekoniaow]

First of all, congratulations for the very nice looking graphics.
Graphics are a far cry from an actual game (gameplay is _all_ that matters in the end) but these are definitely increasing my playing desire.

Originally Posted by Arne

[snip] My tiles are 12x12 because it suits the presentation. Solutions:

1) Draw a black 'Bar' behind every refreshed tile to clear to black and avoid overlapping residuals. The only major map update will be on end turn when all of the aliens move, but i'll probably be fine because the game needs no smooth movement.

Actually as long that tile column is not visible yet you do not need to care since the 4 undesirable bits will eventually be drawn over by the next tile before they get displayed on screen right?

Argh, forget that I failed to realize that what you call "tiles" are actually the moving bobs representing player and enemies.
This actually makes my solution below now relevant.

Originally Posted by Arne

2) If there is a mask bitmap I suppose I could poke it to form a solid block with a transparent (16-12px) right edge. Right now the mask s automatically generated by AMOS (from color 0) upon grabbing. Edit: Used this solution.

For 12 bits you actually do not need a physical mask to pass to the blit operation: the blitter A channel (the source to copy from) supports a 16 bits mask that it will use for the first 2 bytes of each copied line.
This means that you can just set that mask to 0xFFF0, 0x3FFC, or 0x0FFF depending on how the tile is aligned respective to 16 bits boundaries and your tile will be properly masked.

I'm not sure Amos exposes this feature in its blit functions but it might be worth looking for it in the manual since not having to rely on a mask located in memory will make your tile copies at least one third faster.

But you do not really need it. If I understand correctly what you are doing, there should be no need to mask copied tiles since the masked part will be overwritten by the next tile anyway.
Forget that, you need it.

[Arne]

Thanks for the reply/idea. I'm actually using "icons". I think they are like bobs but icons can only be pasted and have no coordinate retain or background save. My icons are variable width, so using some kind of general mask (if I understand you correctly) might not work for say, 42 pixels wide images then? I'll look in the manual. If not there chance are that I can get to it low level anyways.
I could perhaps turn off the mask on the 12x12 tiles and perhaps activate this general mask during map draws. Right now I calculate the width mask for each tile. For a 12 px tile it looks like 11111111 11110000, repeated for the height (12).

Letting unmasked tiles overlap when drawn would work if I update the entire map in read order and didn't have to care about the righthand GUI, but I mostly update select tiles.

Anyways, over a thousand lines of Gosubs is beginning to get very unwieldly!

Situation 1: I may have a For-Loop with X that I assume is temporary because my X'es are always temporary, but I call a Gosub which calls a Gosub which modifies X for some other purpose. Ouch! Solution: Be more agressive with unique variables?

Situation 2: I have a register/argument/parameter value of some sort, like YSelect, intended to be accessible, but forget myself and modify it when doing some temporary thing because it came in as an argument. Solution: Chuck such variables into unique variables at the top of the Gosub, even when I think it'll be fine anyways.

I WILL make this thing all Gosub. Here's a battle to be won!

Progress report: Slow today due to losing battle, but blob movement is operational. They all move simultaneously and in half steps so little trains can form.

[Arne]

Progress report: Blobs can now gobble up troops with a special animation. Made a frame layer so I can precalc current frames for units and quickly read during draw. Was one of those big rewrites which just surprisingly worked. 16 troop profiles are somewhat operational. Troops are randomly picked for an (up to) 8 man squad every new level. A selected troop draws his portraits and stats in GUI (except name, rank and medals).

Will have fun coming up with names. I think I'll do images (i.e. name tags) instead of a font routine, for now at least. Source is 50K+. Tomorrow I'll make teleporters operational and move towards the bare-bones-game milestone.

Unrelated question: I have a 44pin IDE Amiga HDD connected to Win7 via USB adapter. When I shut down operations for the day, should I just yank the USB, or properly unmount ? I currently yank it as I don't trust Win7 touching it. I can hear the head parking safely (I assume) when I yank.

[Nekoniaow]

Originally Posted by Arne

My icons are variable width, so using some kind of general mask (if I understand you correctly) might not work for say, 42 pixels wide images then? I'll look in the manual. If not there chance are that I can get to it low level anyways.

Actually that would work too. The blitter has two such masks: one for the first 16 pixels and one for the last 16 of each line.

Originally Posted by Arne

Letting unmasked tiles overlap when drawn would work if I update the entire map in read order and didn't have to care about the righthand GUI, but I mostly update select tiles.

Makes sense.

Originally Posted by Arne

Anyways, over a thousand lines of Gosubs is beginning to get very unwieldly!

Situation 1: I may have a For-Loop with X that I assume is temporary because my X'es are always temporary, but I call a Gosub which calls a Gosub which modifies X for some other purpose. Ouch! Solution: Be more agressive with unique variables?

I'm crying tears of blood just thinking of you right now.
Very seriously there's only one valid solution out of this hell: use named procedures. They might be unwieldy in Amos but this is nothing compared to the brain cells you are sending to hell through the use of gosub.

The control flow of your code must be clear otherwise you will waste time figuring out what you are doing instead of actually doing it.

Originally Posted by Arne

Situation 2: I have a register/argument/parameter value of some sort, like YSelect, intended to be accessible, but forget myself and modify it when doing some temporary thing because it came in as an argument. Solution: Chuck such variables into unique variables at the top of the Gosub, even when I think it'll be fine anyways.

I WILL make this thing all Gosub. Here's a battle to be won!

Actually, it's a *VERY* good practice to avoid modifying variables as much as possible. If you think you need to use and modify a variable which has other uses, just create a new one. But in general, aside from loop indices and results of computations most variables should be compute-once-read-many.

Ex:

Let YSelect = <value from the argument>
<some code here>
Let YSelectForPurposeABC = YSelect + some formula
<then you can use both variables here without confusion>

This will help make your code much more readable.
And readability is the most important quality of any code, especially in the early stages.

[Nekoniaow]

Originally Posted by Arne

Unrelated question: I have a 44pin IDE Amiga HDD connected to Win7 via USB adapter. When I shut down operations for the day, should I just yank the USB, or properly unmount ? I currently yank it as I don't trust Win7 touching it. I can hear the head parking safely (I assume) when I yank.

For the love of all that is cute and fun on this planet please unmount.
You will lose data if you do otherwise.

Windows 7 knows exactly what it's doing in this case. Trust it.


I might have misunderstood your setup.
Is this an Amiga formatted drive? And why is it connected to your PC for? Just for the power or is the IDE ribbon connected too?

In any case Windows doesn't know anything about Amiga partitions and file systems so it will not attempt to modify the drive unless you ask it to format it.

I highly recommend unmounting though: assuming the drive will have enough time to park the heads if you cut the connection is a very risky gamble.

[Arne]

Alright, I will try unmounting then.

As for the Gosubs, I'm indeed hellbent. How could it be Gosub Invasion if I use Procedures?

AMOS' IDE/editor is pretty bad at presenting readable code. It despaces and ALLCAPS like mad, and no color coding. I've survived this far because of my naming conventions and having the structures fresh in my head. Oddly enough I've had no mistyped variables causing bugs, otherwise that's pretty common in BASIC. Guessing the game is at 40% now with most of it being in the engine department. I've been eating the frogs as they appear so right now I feel like I have some easy implementations ahead.