Starting Over - part II

Yep  - it's been around 6 years since I started this blog.  All those years ago when I decided to get back to retro programming and create/finish something.. well.. that didn't quite work out as planned.

I would have loved to make old games for the Amiga, but to tell the truth there's nothing in it..  I still enjoy programming in assembly (I even kicked right back to the c64 the other month and tooled around pushing sprites and writing code) - but to be honest, it takes way too long to get things done and there's ultimately no future in it for anything more than a fun hobby (and I really don't have the amount of time needed to invest  in something that will only ever be 'a fun hobby').

I'm sure the fan community will disagree, but from where I'm sitting there isn't a market for new Amiga software, in the form that I'd be willing to put it out (digitally) - my take from forums and such is that they would be willing to pay for something that came with full color art, nice box graphics, and an actual 3.5 inch disk that works...  Which at the end of the day is a big outlay for the same 'pennies on the dollar' you'd get publishing it yourself digitally for 5 bucks.

Also, although the community is willing to pay outlandish amounts of money for hardware (both old original and newly minted add-on and replacement parts), it seems for software there is very little enthusiasm at all.... So by all means program for the platform, if you have the spare time and energy, but make sure it's for the right reasons (fun only).  If you look at as a potential market - even just to cover 'smokes and cokes' consumed in development... you're best off looking to (the much more active) C64 scene.


So... that's what I've stepped away FROM.. where have I gone TO? And why am I reviving/revamping this blog?

Well.. I still have the desire to write games, I still have the goal to eventually supplement my income by doing so (even if it's just smokes n cokes, or a new computer every 5 years).  I still want to write the style of games I played and loved in my youth, and all the various games I tried to design and create back then.
Nowadays we have a great variety of platforms - and unlike the 'old days' people have a variety of them that they use personally - there's the PC, Mac, Linux, Android devices, iPhones/Pads/whatevers and the web...  I don't think it's enough to write a small game and say 'this is just for platform x' - a much nicer solution would be writing a small game and saying 'you can play this on just about everything you own, and take it with you'... and this is what I'm working towards (eventually).

Now you could roll eyes and think 'well - another 6 years of watching and waiting' - but truth be told, I've already finished more in the last 4 months than I've don in the last 4 years... choosing Java as my development language of choice I've already written 2 games and started working on my third.. over the next couple of weeks I'll make posts to catch up and detail them, then keep folks updated on what I'm working on currently...

Cheers!

Sig.

Well....crap.

After slogging it out all week the cpu and fans arrived. I waited till the kids were in bed, busted out the screwdrivers and went to work. I cleaned out the case good and proper, took out cards, put in the cpu and fan and..... nothing.

Honestly, this is the most problems any computer has given me for over a decade - even my clunker A2000 was easier, and I had to bust out the soldering iron and chip extracter to get that running.

So, after some chat with some buddies over skype we all agree - I may as well soldier on rather than just trying to put together a brand new PC.. so hitting up NewEgg yet again I decided on a new motherboard that fits what I have (easy choice, there's only one).

I'll be possibly ordering it tomorrow if I have time - I have another weeks work out at the farm, and some more money for the house will be a good thing.. So I'll see where I stand at the end of the day before I cut myself a paycheck from my online business.

Given that I have at least another week before I can work on that again, I've set out to getting this laptop set up to do a bit of development. I'll be backing up everything I do so I can load it back onto whatever permanent system I end up using, and back to the amiga. I've managed to engineer as many dodgy parts as I could find to rig up a system to get code to/from the A2000, and a copy of the game-shell resides here now. I'll post what I've been tinkering with tomorrow.

Cheers.

Mo progress, mo work

Don't know if it's a good or bad thing, but everything kinda travels around in a ying/yang lately, not that I'm complaining as it's all good.
Project CodeShell is making good progress this week with a bunch of basic blitter routines brought over from older projects, keyboard input working rather nicely and mouse handling finished. All the routines are nice and generic (although my joystick routine could do with a bit of a re-think).
My older code for Scramble and EVA didn't really take into account splash screens and other things - so doing a nice framework from the ground up has worked out very well.
Some polish routines, like palette fades are in there - and the core stuff is coming together rather nicely.

I have another week of work out on the farm coming up, so hopefully my dev PC will be back online by the end of it (barring any other unforseen problems) - if not I might start putting together something that will utilize some of the things I'll need for Scramble anyways. A chance to write some code that is needed, and be working on something more than just some test demo. I have some pretty good ideas for an Arkanoid style game, some features such as bonus levels and the like that I don't think have been thought of before and might really breathe some life into that genre.

Stuff to think about... for now I'm going to finish up some optimizing and some tidying, then perhaps hit DPaint for a few hours.

Cheers.

Countdown for computer parts!

A few curveballs thrown at me this month made ordering a new cpu and some other tidbits hard to get going, but now they're on the way here.
Hopefully between the new power supply, cpu, and cooling fans, (crossing fingers) I'll get things up and running for a few more years before having to upgrade.

Really there's no reason for me to upgrade atm to tell the truth, the system lets me run the handful of things I need for work and my Amiga emulation is pretty zippy.. I'm looking forward to getting it running again as using this busted up laptop is rather clunky. The screen has packed it in, the keyboard is pretty rubbish, and half the USB ports are rather dodgy.
I tried to burn a CD yesterday in hopes of getting another clunker I had lying around up and running on linux (an attempt to get my A2000 using amitcp or a terminal program to give it some kind of network support on a budget) but the CD actually slipped out of its drive and is currently somewhere inside the laptop.. it was like a magic trick you see on TV.. put the CD in, close the case... abracadabra, open the case NO CD! IT'S VANISHED!

Thoughts turned to getting winuae running on it to speed up programming and make it a little more comfortable (until I pick up some wood and get to work on in the shop again I have to use my in a less than comfortable position) - and transfer the work over a null-modem as I did with my old comp, but alas, no serial port on this thing either.

I'm seriously thinking of getting a micro atx case or a book sized barebones system and putting together a dedicated, small, convenient uae dev box that also handles networked workflow to my real amiga.... but it all requires $$$, and although I'm not totally skint - I'd rather spend that money on my kids - the whole point of getting back into Ami development was to try and support the fixing and upgrading of my machine. I get my Amiga running nice and solid again, the community gets some new games. Win-win.

Always the way - you get a bunch of good ideas when you can't really effectively work on them. Still, while waiting I've been working on the CodeShell and gathering up useful routines and organizing them. Keeping in mind the pitfalls I've had in the past while trying to finish projects, and the ones that have collapsed under their own weight. I think it's coming along pretty nicely. The object isn't so much to have a bunch of routines that will 'make a game' but rather enough to streamline down the process of getting a (complete) working prototype together.
Once running and tested, I'd first get any new routines worth harvesting and roll them back into the main library, then prune out what isn't being used. Finally optimizing the core routines to accomplish their relative tasks faster for that specific project.

It can't hurt, at the moment I have 1 project on indefinite hold (EVA) and one that has hit a bit of a wall until I work out a couple of tricky problems (Scramble). I expect Scramble will get sorted out again soon once I get the new system up and running, and in the meantime I do have something in mind to test out some of the routines of the CodeShell. More details another time.

Not dead, just sleeping (ftagn)

Damn, August already!

I think my last entry pretty much summed up how things were going. The middle of the year is always hectic for me, doubly so with kids now. A lot of things work wise and home wise to look after, and it's the 'farm season' and since taking up some part time work out on the farm, spring and summer are a good chance to get some extra money as well as a workout and some sun.

Now that things are getting quiet again, I turned back to working on the Scramble Project - just like 'back in the day' I can see where things could have been done better, and perhaps smarter, but unlike in the heyday I'm not going to scrap and start over (this is probably the number one reason I never really got much finished back then) rather I'm keeping notes on what I've learned for 'the next one'. And hopefully there will be a next one.. the base Scramble game is going to be a PD release and pretty much follow the coin op gameplay/maps. I'll likely do a MAJOR reworking using all these tidbits for 'Scramble Deluxe' the shareware game.

But all that is pretty much dependent on getting things finished here, and that seems to be a sticking point.. About a month ago my computer packed it in (I've cobbled together a setup that allows me web access and little else for the moment), what I thought was a power surge from a lightning storm (I was out working when it went down) turned out to be the fan finally shuffling off it's mortal coil (and housing) and frying the processor.
This system has been pretty good to me, I hardly realized I'd built it in 2006, It's worked smoothly and like a charm forever... technology has marched on a bit though, and if the damage to it had been more I'd probably be rebuilding a new computer from scratch - however there are still processors available to replace my old one (not many, but the ones that are out there are better and now cheaper than what I had) for a paltry 60 bucks.
Maybe I can nurse another 6 years out of it! At the moment it still does everything I need it to quite well.

Of course the downside is all my work on Scramble was on that machine. I was working through an emulator and testing on the Amiga via AmiExplorer. The bad news is that for the last 2 months of working on it, I'd only transferred executables (boneheaded thing I know, especially when I learned that lesson doing the reverse - working on the Amiga and not sending the files back to the PC). So the Scamble code I have on the Amiga isn't the latest versions - not by a long shot.

Still , things are not 100% lost - time is coming back for these projects and I'm not letting it pass by. The last several days I've fired up the Ami and have been going over the 'core' routines that are tried and true. I'm optimizing, organizing and, more importantly, commenting a lot of these and putting them into a framework where they can be reused with as little effort as possible.

Hopefully this can be used later as the base to build Scramble Deluxe and eventually EVA.

End of the month...already?

In like a lion, and out like a lamb. Guess that sums this months dev pretty well.

Exactly the opposite for everything else in the home. As the month went on I found less and less time for programming, and more and more time for the things I need doing around the house. General handyman type stuff - the twins requiring more attention - and spring arriving, so I have to start whipping the lawn (very unkempt from it's last owner) into shape and a brand new garden started.

I managed to get a bunch of the groundwork stuff done for a couple of things on the to-do list, I've decided to follow the original game on reset - have it go for 2 screens warm up before restarting the level, and I'm glad I did as a lot of the older code had the original test map hardcoded in - I never got around to making it use the map structures (which when setup right, would make changing maps for stages very simple). This still needs completing, but it's close.

While thumbing through the code to address this, there were several old placeholders for things that needed doing/fixing for bullets, bombs, and their explosions on reset - so I got that cleaned up and tidied up somewhat, and started tying a lot of the common functions for updating/drawing/erasing/background saving together. This also needs finishing, but it's cleaning the code up and making it a bit tighter.

Once it's written down it seems like a bit more - but not as much *visible* progress as I'd have liked to see.

Fuelbar Start

Slow progress this five days. Winter gives way to Spring, and projects in the yard need starting.

I've managed to tweak the fuelbar graphics slightly - using a copperbar on color 4 to do the fuelbar.. it's a bit of a dated effect, but it lets me get to the important thing - an increasing/decreasing horizontal fuelbar - without having to worry too much about the graphics. I'll probably put my head to making it a bit better, but more than likely that will happen on the shareware rewrite of the game.

Hopefully screenshots next update, but with the yardwork, garden planting, and looking after the kids, I'm thinking the 5 day update will be the order of the day.

Cheers!

Sig.

Bombs Away!

Not the best shot, but you can see one bomb has blown up a missile and another is dropping.

2 bombs can be dropped just like in the arcade game, and although I'm not 100% satisfied with the look of the launch, it doesn't look half bad - so for now I'm keeping it as is (until the polish stage of things - or I find myself with only enough time to do small tinkering projects).

Bombs hitting the ground do a little explosions (like bullets) , and if they hit the main objects they do the bigger explosions - it looks pretty nice.

I fired up MAME the other day to have a play and make some notes on the original (mainly to look at the missile firing sequences) and found another interesting point worth noting - when you start the game, or any time you have to restart a stage due to being killed, the game puts you at a screen long 'lead up' that I originally thought was part of the first map.
I intend on keeping this trend, mainly as it lets me shorten my stage setup routines by quite a bit, and extends the first part of the map by some 20 tiles. Also, from a playability standpoint, it gives you a slight break to get back into the groove after being killed - which is a good thing.

With the addition of the bomb code (which needs a little dialing in on the collision side) most of the engine work is behind me.. or so it seems (until I list it out - then it seems like it never ends).

Before tackling the map reading issues I'm going to try and put the rest of the ship stuff behind me - so still to do for this milestone:

• Add 10 points every second on score
• Setup the fuel bar properly (remove placeholder graphics)
• Decrease fuel every second and crash if you run out
• Increase fuel when you blow up a tank
• mystery score on a module blow up

After than it's going to be map and missiles - then it's down to map out the rest of the first level.

Cheers!

Sig.

No Screenshots

Ok no screenshots today, and it's been 5 days since the last update. It's been a pretty long week around the home trying to catch up on mundane chores and keeping the kiddys happy.
I spent the precious downtime I had on working on some graphics for a mock up of the Retroromicon splash screen - nothing worth showing yet, and some split off code projects that I'll need, not only for Scramble, but for everything - sound and music.
Not my forte, and not something I've done much of in the past (apart from the obligatory protracker music include).

I managed to get some PT Replay source going using the CIA timer rather than vbl - took a bit of futzing and some reading (the source I had was pretty vague in the instruction area), making it case sensitive to fit in with my own code, making some changes to play nice with my includes. So far it SHOULD slot into my framework pretty well.

I also played around some waveforms and playback code - I was always partial to the Fairlight demo group low 'thrumm' sound effect on their splash screens - so I think I'll do something similar for my own Retroromicon screen before the music kicks in for the main splash.

Today though, it's back to bomb code - when I have something a little more substantial I'll put up a screen shot.

Cheers.
Sig.

Well it seemed a few of the things on this months 'to do' were a little easier than I expected (still waiting for something to break.. it was a little TOO easy).
As you can see, the module object is in there, I'm flying over top of an explosion as one of the missiles I've shot is starting to blow.. up on the hill is the final wisp of a strafe.
I whipped up a better score font too - I figured if I'm gonna write to most the bitplanes, I may as well have it look nice.
Also note - score. Working.
Numbers are converted from hex to decimal pretty fast - faster than my earlier attempt messing around with BCD numbers.
It's looking pretty nice - there are still a couple of 'big ticket items' on the docket.

Map routines - I'll have to go over and make sure they are actually using the map object (I have suspicion they aren't entirely). Once the map is working, the top scoreboard will have to be finished to include the stages (the middle section) and maybe give it a facelift - that flat embossed blue is a little bland next to the new font.

Modules as per the original game are supposed to give a mystery score 100,200, or 300 pts - I have to do this still.

Fuel tanks are in , but so far the fuel system hasn't even been started. That will also have to be done and tied in.

Also the original game gives you 10 pts for every second you stay alive.. I'll have to add this as well.

Still - good progress for one day!

Cheers.

Sig.

Scrolling Fixed - Onward!

A couple of days later (not all spent coding, just less to TO code this week) and the scrolling is changed over and fixed!
I had a bit of a dumb moment, thinking the screen modulos didn't need changing - duh - that's what makes it work, otherwise it keeps looking for an outrageous amount of bytes to find the next bitplane, ending in what I was saying wouldn't happen: memory corruption.

So, after changing that - everything else had to change as well. Lucky for me I've stuck by my guns and continued to seek out more elegant solutions rather than having everything hardcoded.
After scratching my head over the screen mods - which has always made me scratch my head trying to work them out... It's not difficult once you get your head around it, but when you only approach that point usually once a project (in my case every year or so) you forget it's little quirks.
It ended up just changing a couple of numbers in a couple of key master objects. I was surprised how most things just came back up first or second try.

I got to look over some of the older code and revisit it - some had to be done (like ripping out half the scroll routine) - and in the process I put in a few things I wished I'd thought of earlier. Some routines got a much needed facelift and optimization. Many routines now run off a pointer and have eliminated a bunch of X Y coord conversions... Scramble is running much leaner on screen time now... which is good because I think I'm pushing the home stretch (so far as bare bones GAME goes).

Still to do, and my focus on this month:

- Score board routine. Now that explosions are done and objects get erased, time to tackle this
- Add new static objects Module and Fuel Tank
- Rework some graphics (mainly ship explosions)
- Start expanding the map framework to jump to the next map section

At the moment the map is really giving me pause... I'm pretty much doing it by hand as the Amos map editor didn't really work out - and I haven't really worked on a Blitz one. Devpac is limiting my text file lines - so the maps for this version will be done in stages.

If I get these things done by the end of the month, I'll start working on the Moving Objects (the missiles that fire up) and start on the Fuel handling code.

February is looking to be busy with a pretty big list of goals...

Cheers,
Sig.

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.

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.