Object Explosions - Scrolling issues.

Got the object collisions and explosions worked out around 90% (there are a couple of bugs I'm trying to work out - but I think I've tracked down most of them).
Some of them came down to a rather dumb oversight that might cost me a bit of time - the scrolling.
The method I chose was one I was familiar with from the scrolling text demo days that lets you scroll forever by making a workscreen twice as wide as the visible and updating both sides of it, when you get to the end you jump back to the start again and scroll across.

Static objects (like missiles) are also drawn this way (as background tiles) in order to save frame time (they take advantage of being scrolled with the landscape - and so dont have to be redrawn each frame). The problem of course is that they have to be erased twice also (otherwise they reappear when the screen jumps). All these blits will quickly add up as more objects and enemies are added... So before things get TOO complicated, I'm going to redo the scroll routine. One that lets static objects continue to take advantage of the scrolling, while not having the jumpback problem.
How to do that?
Well, seems simple enough - just don't jump back to the beginning of the screen - allow it just keep on scrolling through memory.
'But you can't do that!' Sure I can! - for every 40 bytes (320 pixels) I scroll it's the same as going down ONE line of screen. So, add one LINE of screen mem for each full screen I scroll.
The current system uses a double width screen (640 pixels) - so that's 200 screens!
But theres more.. I don't JUST have an entire extra screen - I have an entire extra screen of 5 bitplanes. So - 200 x 5 ... this is 1000 screens.
And more still.
The playable area of the screen is 11 tiles high - that's 160 pixels, not 200. This works out around about 1250 screens of scrolling.

The original Arcade game has a 11406 pixels of map from start to finish on a level. That's around 35.5 screens. Lets call it 36.

So, you'd have to go through the entire original map approx 35 times, WITHOUT LOSING A LIFE (because you reset to the start of screen memory and redraw the start of the stage when you blow up) to reach the end of the memory (as it stands now).

Not impossible, but highly improbable. Just in case, in the final game I'm going to do a cut-screen every 5 times through the map with a 'Good Luck Commander' or some such - award a bonus or something. This will make that improbable, impossible.

At some point I'll tidy it up somewhat (change the screen/blit modulos) but for now I'm going to 'just make it work' and bug free.

Bullets Asploding

I managed to grab a half decent screenshot now that the bullet draw/collide/explode code is pretty close to being wrapped up.
A couple more things to do before I can lay 'Bullets' down to rest and start on the 2 bombs:

- Bullet vs Enemy sorting
- Enemy Explode and remove
- Score updates

The code is pretty decent and will make it easy to add bullets in the future - this is important as I intend to release a fully functioning Scramble Arcade clone as a free game.
However, I'd like to go the route of 'Deluxe Galaga' and re-write / improve the basic game into something much more - testing the waters of the Amiga game market by making it shareware (we're talking $5 here - I'm not going to get rich... but maybe I'll be able to get a cheap web service, or at best enough cash to fix up my A2000 a little bit).

It's not going to be the worlds greatest game - but it will be one of the few new ones released.

Update

As I predicted, time is a little hard to find at the moment. The twins both have colds, which is making it hard for them to get a lot of rest during the day - and seeing how sleep time = code time, that's cutting into the amount I can get accomplished each day.
Spring is on it's way - so I'll be adding yard maintenance to my overflowing list of things to get done in a day as well. Sundays will be dedicated to getting that done.

Does this mean Scramble and Retroromicon games is being shelved, yet again? No! Just means progress will be a little slower than it was over Winter.
The bullet code progresses nicely, I have some fairly fast single pixel plotting routines done and the code in place to fire off 3 bullets (same as the original arcade game) - all the movement, and collision detection for the landscape is also done.
I switched gear back to Dpaint mode for a couple of days to work on explosion graphics for the missiles, bombs, and eventually hitting enemy objects. I'm currently linking up those graphics to the bullet collision routines.

Once that's done, I'll upload some screenshots.

No Bugs!

Grabbed a couple of hours today and did a little optimizing. The flame sprite for the ship I recall being a little jittery last time I did a check on the real A2000, so I separated the code from the ship update routine and shuffled it up to just after the vertical blank, since the updates for the scroll are offscreen, I shuffled as much of the code as I could out of the scroll routine and down to after the ship update.

Exported an assembled exe to the A2000, and man, works like butter - smooth as could be with no jitters, no tearing, no problems.

Now I can progress onto the bullet code.... this could take a little time, and the time atm is rather scarce... the last of my winter months are coming to a close which means time to focus on my projects that are turning a profit, and start getting the yard here at the new place whipped into shape.

Current State - 50% done

Here's the screenshot I promised last post. I'm clocking it in at 50% finished engine-wise. There's still plenty to do, but a LOT of the tedious work has been set down and optimised (note - scantime at the bottom of the screen ... this is running at an 030 speed, on a stock 000 it just touches the bottom of the score pane).

Things that work:
Scrolling with map and enemy map.
Ship animation and collision
Life graphics in the upper corner
Engine code for static enemies and more.

Some minor setbacks have also come up, like my computer setup crapping out after the move and needing some work - the upshot is I had to reinstall everything.. No big deal at the moment. Working in a virtual machine has some advantages here - having all my Amiga utils, emulator, and setup on a seperate drive I just had a couple of installs and away I went.. It was the easiest part of gettihg things back on track. The downside is that setting up things for the work that actually pays the bills takes a bit longer, cutting down on programming time for this project.

Apart from cosmetic changes, it works fairly well. I'm sure some bugs will crop up when I export it to the actual 2000 for testing (the 2000 suffered some minor damage in the double move, its 030 card is no longer working, but I've rigged it back together so it works fine as an 000 machine - probably for the best so far as testing things goes).

From here there is still plenty of work to do, I've been avoiding double buffering on this project - as I think it SHOULD be able to handle it without it. I hope this doesn't come back to bite me later. I'd like to get the baseline demo version running without it.

An overview of things left to do:

Non-Static enemies (missiles,ufo,meteors)
Score, Stage, Level and Fuel updating
Bullets and Bombs

Considering I pretty much had to do a ground up rewrite starting mid November - if I can get a couple of hours a day solid to put in, it might get done in a couple more months!

Soldiering on

Although it's now January 2011, things have been moving forward since November last year. I just haven't had a lot of time, and the time I've had I've spent doing things rather than writing about doing things.
We found and moved house over the xmas break - scoring a much bigger place for LESS money per month, AND A YARD! Also a large office for my work and hobbies where I can sit, smoke and work on larger scale projects.
Scramble progresses, and does so pretty nicely. I discovered I could slot about a half hour, two to three times a day into the babies nap-time (back when they napped at the same intervals, and it was as simple as laying them down). I set up the old A2000 with them, as I was using the 1084 monitor to run Baby Einstein videos through a DVD player.
After tooling around and fixing it (seems the 030 card has packed it in) and not having any way apart from old MS DOS floppy to transfer stuff to it, I decided to look over the old Scramble code and fix up the bugs that plagued the WinUAE version. The only display I have for this machine is an NTSC C= monitor, so some rewriting was done - bugs fixed - enthusiasm regained.

I'll post a few screen shots, but here's a list of things worked on since Nov 2010 (nearly a year to the day I last worked on it)

- Rewritten for NTSC running
- Optimized tile blitting routines
- Main ship blitting - animated sprite frames
- Level and map interpreting (not finished)
- Joystick control
- Main ship - background collisions
- Static object handling (missiles , fuel, bases - non-moving)

Many many under the counter reusable routines for object queues, list handling, hex/decimal digit conversion, score handling, and MUCH restructuring of the code.

Many of these routines will be optimized over time, but the flexible originals will be put aside into a game framework to speed up future development. Apart what screenshots would show - there is a LOT of the grunt work finished.
Workflow at the moment is developing on WinUAE (running fullscreen on one monitor) set up as an approximation of my real Ami (with 030) running at full speed.
I then test major updates regularly on a cycle exact ECS setup before sending it to the actual A2000 via AmiExplorer for a final run over.

Usually this turns up a bunch of timing issues to fix as I want the game to run fullframe with no double buffering.

A lot of work has been done this last 3 months, another two or three of solid work could see this near finished.
That being said, 10% of the work usually takes 90% of the time.