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!