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.