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.

Trash - Thrash - and back to the drawing board.

Long time no post - it's been that way. I've been far more invested with the pending arrival of my twins than I have been in game_dev.

Still, since the move I still haven't unpacked my Amiga, so all dev had been done through and emulator - everything seemed to work ok, but when I passed the exe to a friend to test it came up guruing... I never managed to track down the problem successfully, and so I'll wait till I have time to setup things again before I get back to developing either of these ideas.

Yup - 2 years and nothing to show - it's disappointing, but life has a way of tying up your time. I'm no longer in my 20's - and that's just the way it it. Still, things on other fronts progress. I'm putting down all things hardware retro until I get things settled (like getting a bigger place to live - going through the first time dad thing, and other bits)

I can't forsee enough 'Amiga Time' to do anything substantial for a couple of years. (Realistically, with 2 toddlers - that's the way I see it... ).

On the upside - development on retro themed stuff for the PC is much less time intensive. Documentation is available, it's fairly fast to find information, and many languages/engines/tools exist to save time. I have some avenues and ideas I'd like to explore in that direction until I can get the time back for retro development again.

Scramble Map Editor

So, after downloading Amos Pro , wading through installation, finding docs (whew), it turned into a bigger project than I though - and with work to get done in the meantime I only had one day to devote to the Scramble 68k project. I did manage to get a basic functional editor going though. Its not much, not complete, and could use a few features (I find them as I use it). Amos has some quirky features, and it just shows how far I've personally come over the years. I bought AMOS when it was first released, and after 68k Assembly, C, C++, and other languages since, I've found I've gotten accustomed to things like... well... functions, pointers, and other bits and pieces :) going back to what is essentially Basic circa 1990 has been a lil hard. Anyways, although I've not gotten to the point of it spitting out source code for the map (not hard, just going to be a lil tedious) - I have gotten it write them in a very basic format so I can load and save the maps as I work on them. with each section being 500 blocks long (16 pixels per block) , 12 blocks high, and 4 sections to each level.. doing them by hand would have taken FOREVER.

I don't think this editor will be terribly featurefull or user friendly - its only for me and only this game... next time I might try blitz basic - or hopefully put the time in with Amiga C to do them in the future - either way it was a fun lil project to knock out - and still faster than doing it in assembly.

Till next week!
Cheers

Something To Show - PROGRESS!

Progress is being made at a good pace, although stuff to show is pretty minimal. I have the map tile system in place and working, as well as the starfield (that I had to slow down 1 pixel so it travelled slower than the foreground).

I threw up some unfinished graphics as a dummy for where the scoreboard will be (although I might make it smaller - a fuel gauge will be at the bottom).

The initial graphics tiles will be in the old scramble style from the arcade - an homage. I can change them later or expand on them if I want.
After getting the map system working, I've discovered that making maps block by block is a huge pain in the ass.... it will take FOREVER, and its time I'd rather spend coding the rest of the actual game mechanics. I've decided to write a map editor to speed the process up.. nothing fancy, just enough to get the job done. The tile map being done in bytes, so that gives me 255 tiles to play with - I'm going to cut this down to around 200 actual tiles and 55 bytes for 'special instructions' - $ff being 'swap to a new map' and some of the others will be to initialize enemies - so all I need at the moment is something quick to edit basic 16 pixel blocks into a map.

Doing it in assembly is certainly possible, but a waste of time. I'd rather work on the routines I *NEED* in assembly, rather than dealing with things that right now I don't need - I've decided to do the editor in AMOS... back in the day I played around with it, and after loading it up for the first time in nearly 12 years, I have a all new loathing of its interface.

The Amiga had its quirky features already, and getting re-used to workbench (even 3.1, when my old ami had 2.0) and even the minimal quirks of Devpac 3's editor have been a chore.. AMOS has its own new set of quirks to learn... on the upside it has and does all the things I need for a quick and dirty map editor without having to delve back into system libraries and the quirks of C on the amiga:

Load an iff
copy blocks of it from one screen to another
mouse and keyboard input
file requestors
save/load data to disk...

Next time I might muck around in Amiga E, but for now AMOS is the right tool for the job.

Surprised for once!

I had some time on my hands and decided to start getting into this project.. As per usual you spend about 10% of the time on the majority of the code and 90% of the time finding THIS ONE TINY BUG!

In my case it was a errant space in an equate - meh!

Of course it was compounded by the code I had written deciding to write itself into devpac's memory space... so I ended up with bunches of syntax errors in the editor every time I tried to debug.... spend 10 mins fixing errors, 10 mins bughunting, crash, reboot, repeat... argh! well on the upside am using WinUAE (still no room for the Ami.. maybe I'll get a new desk this week).

Already I've discovered about 3 things that make me wonder how EVA even manages to compile without crashing - I'm glad I took this lesser project to sort things out - already I'm working up new code solutions to problems and trying very hard not to overcomplicate them.

I'm not posting a pic at this point, as it would be embarrassing really - you can be proud of something on a technical level but showing it to the world in so rough a state is inviting 'that sucks'. But here's a breakdown of what I've got going so far:

-Clean entry and exit.
-Mock scoreboard (blank rectangle really) as a placeholder on top of the screen. This area will be static and separate from the playfield.
- Memory allocation for the playfield (so for blank and no code)
- A 1 sprite parallax starfield that I'm actually pretty proud of - no biggy but I figure if sprite 7 is turned off (and I will be using sprites in this game - probably for bombs)
The nifty (to me) thing was getting it to work at a single pixel speed. Most sprite starfields work at 2x speed because bit 0 for horizontal control is tucked away in another register. 2x would be a bit too fast for scramble as the background stars would be running faster than the foreground (which I see running at 1 or 2 pixels per update)
it runs in 2 levels (but could with ease be expanded - but I won't - well not now). Originally it was going to be a 'plain jane' one layer, but curiosity got the better of me...

Likewise I'm getting ideas about gameplay and graphics.. I REALLY want to keep close to the original (overcomplications again) till I get a beta version finished and out to play (yay! a FINISHED game! won't that be cool?)
But more about that next week!

Cheer!

A new beginning

It's been a long time between updates, and even longer between coding updates.. much has happened in my life as well.

Work over the last year and a half swallowed my life. More was expected from me in less time, as the company I worked for crumbled away - as did my home life.

Suffice to say I had to pack up my Amiga and other passtimes and knuckle under to try and weather the storm... I've since moved on - in every way possible. I've left Las Vegas for the quiet life of a small country town in Georgia, I've left my job in video production to pursue my home business.. A new life, and soon a new wife, and a little one on the way.

It agrees with me, and although I've not gotten everything in order to a point where I can spend a LOT of time programming (when you work for yourself, the more you work the more you can make - so for now that has a lot of appeal) I can at least get things rolling once more.

Looking back over my code I see the good, the bad, and the ugly. After 15 years since I worked on the original game (which was a constant itself a year and a half passtime of learning and exploring back in the day) my hopes to reach the same level of understanding over the course of months were perhaps shooting a little high... To do EVA justice requires a level of elegance and complexity I've not yet achieved. To retrace my steps I have to go back to basics again and work my way up.. EVA is not getting canned, its being put on the backburner while I learn aknew. There are many things that I'm not yet proficient enough at, and there is too much going on in EVA to learn everything required in one hit. Several times already I've had to rewrite much code again and again because I'd done something either wrong, or not well enough.

A new project is being started - one much simpler with less to concentrate on... I've chosen the old arcade game 'Scramble' (one I spent many 20c coins on in my youth) - it has a fairly simple setup (on the surface of it) .

One main ship (3 lives)
A scrolling landscape (1 speed and constant in one direction)
firing launches bullets (1 pixel dots) and bombs.
Fuel runs out - and can be topped up by firing at fuel depots

Each level has a single enemy type - missiles, saucers,meteors, and a maze at the end.

Touch anything, you die...

Simpler than most games - and a good place to start to get routines built for scrolling, collisions, pixel plotting, scoring, and fuel bars.

I still haven't unpacked and tested my old Amiga 2000 yet - but I have a WinUAE setup identical to it - hopefully I can start on most the things here, then cross it over at a later date to be cleaned up and tested.

I feel good about this - my life is at a point where I can enjoy the journey, and I'm with someone that at least understands my passions :)

Atm I'm devoting weekend time to this project (along with housechores and other 'man work') so my updates should be weekly on Sundays - cheers!