A short note to reassure you that the project is walking forward day by day, and that soon you'll know about what who where and why.

It's that genre of time in which the mountain moves but you can't spot its movement. Despite of it, trust and have faith.

Really annoying, why this flu captured my nose and my head? That's a real mess, a mess of 38°C unfortunately.

Before the flu manifested, I had the time to build a test level.
The main idea would be: release a working beta of the first level, in order to allow all the people to test the game, in an alternative environment (a different level map), with one type of baddie only, and no mid level or end level bosses. The test level must have a simpler graphics assembling, and different pathways, in order to don't reveal the 1st level's original gameplay

So, all of you, be prepared to test the tangible gameplay, on the level I put below in order to zoom into. It will be around when the pickup/weapons system will be fully implemented, of course.

Still no time and, most of all, no inspiration to face the frontend tune.
I'm currently scared: I have to come back to a SID editor after one year since my last composing, and I have to decide while composing that tune, which instruments can be commonly used and which have to be kept off. I also would like to keep the motif of 1st level, hence rewriting it using the new instruments.

Mike played a bit with the frontend, adding stars, subtracting stars, adding again and so on. He's moving so much, on several battlefronts: frontend, hiscore saver (with some precious help from TNT), and many other details. And my shame inflates...

Today, we had a fruitful brainstorming about a thorny part of the game: the pickup/weapons system.
Mike and I began our chatting with very distant ideas, and in the very end we got out with a very solid grub of the weapon system as it will be. Apart of some minor accomodations, this would be the XeO3's weapons system, roughly.
Picking weapons makes your weapon advance in level, than means more bullets and more power; but you have to pay to keep that level: a powerbar continuosly decreases, until it reaches zero and you regress one level, but you can refuel it collecting coins all around.
Yeah, you just figured it: one of the two twin energy bars, exactly the bar on the right, will be used as power indicator.

Next stop: weapons!

Heeey, some days ago Mike has written a post on some far c64 forum about his almost average skill about shoot'em'ups. But no, you cheated, I saw you gettin'coins in a row!
Allow me to introduce you our brave space warrior Mike, fighting in the Galaxy of Current Work in Progress.

Not bad the dude, uh?
Yeah, don't care the older sprite version you'd seen inside, like the ancient 3 frame animated meatballs. You just spotted one of the two most garish features we added: a 95% complete frontend. The remaining 5% is for options and a certain margin of uncertainty about my XeO3 logo (do you like it, though the limited memory Mike allowed me to use?). Yeah, because when Mike popped up with the starfield (greytone at that early time), we virtually calculated no memory left to spend for anything else. Though this, he didn't limited me so much eventually. And, don't ask me because of which miracle, he managed to keep the logo without cutting it. Guys, hope you're close to value the effort!

Well I expect now you to tell me which is the second bbbbbbbigger feature. The bu...the bulll...oh, no spanish folklore here, be serious. The bullets, yeah!
Yes, Mike used the same technique he implemented for the turrets'bullets too, and now the coarse and lame black box that usually surrounds character based shots is gone forever, allowing a professional bullet's gfx overlapping on the whole background. And, useless to say, I love it!

Bad news for my musician's side: having an unexpectedly cool frontend, now we really need a frontend music. Needing a frontend music would mean I have to cut tunes of minor importance in order to make space for the former. Cutting tunes would mean a global rearranging of the whole instruments'pack in the music file that will take me to...omg I have to rewrite all the music! Panic!
No panic at all, I'll try to keep the music theme, at least. But I'm almost sure that some of my prefer features (the Pan's flute in the 2nd level's ingame tune, for example), can be considered gone forever. But I don't wanna give up on the jingles front, saving a bit of both game over and end level jingle, in a brand new shorter composition.
I'm sharpening my blades, yyaarrrrr!

It was so clear that the pod I'd drawn few days ago were lacking shadowing/lightning effects on the core ball, our mate Chicken too has pointed out this in the comments. He commented when I was just at work in order to drop some shadows on that milled sphere I loved so much, and of which I was so proud.

Once animated (and it was cool!), I'd shown it to Mike, and Mike told me it's odd, especially in that "milling"; he suggested me to draw a simpler shape.
Ok ok, glass or metal? Ah, you said it's up to me? Ok glass then. I'd drawn a nice pod with a central glass ball, and I was very proud of it too. Once Mike saw it, he told me there still was so much black, and black is the devil, and the devil uses to subvert our project's karma, and that's bad; he then suggested me to draw a simple ball.

Ok ok, metal, metal then, solid metal. Hence, I'd drawn a wonderful core of metallic sphere, that works so good in the glorious PAL video blurring, especially the light pixel in the bottom because it's surrounded by darker ones, and the overall effect is perfect. Mike saw it, then he sent back a .png image (one of those humiliations that can kill a graphician's heart in a finger's snap) that would show me his idea: a simple ball. A ball, done like a ball, a ball, a ball, actually a ball , a ball for true.

Ok...ok... I did two versions of the...the very simple shape: one with shadows, and one with no light effects, and this time, Mike told me he may be pleased by the former, but he also told me it has to be up to me, in order to choose a definitive one.
And when I was almost mentally prepared to hardly freeze in my position, he said "Oops now I see them on the real PAL video machine, yeah both glass and metal are cool.".

The question is: would he probably love the very first one with the milling, if he used to see it on the real iron, from the beginning?
Nobody will know. And I wanna die today.
But first, lemme put all the music into my blog.radio.

You can find the complete and exhaustive explication on Mike's blog, he knows exactly how this carousel works. But allow me to follow the cascade process of the events, that's actually interesting in order to explain the way this stuff belongs to work.

Mike quickly achieved a merciful collision detection, a routine that will steal your ship's energy only when you penetrate in the bulk of background graphics 4 pixel deep. This will recall into question all the considerations about collisions at the character's boundary and background graphics'shape, and I'm gonna test it for several shapes.
After all the discussions, crumbled turrets'gfx has been turned out from the project since the very few days the stuff has run, a very short existence for that discussed piece of art. Then, 4 chars has been freed, and I was ready to use them in the background, in order to fix all the pinnacles that have half character high tips at their edge. But the merciful collision nullified this needing!

So, what with those 4 exiled chars?
Well, for those who'd seen the teaser, it's clear we accepted some approximations in moving turrets'bullets, cause we use 4 characters for the non sprite bullets, with that ugly black box when the bullet reaches the background. 4 freed chars are perfect to make the bullet overlap on the graphics, but what with screentime?
Mike gave it a chance, and the results are surprising: at a cost of balancing the quantity of sprites and turrets on the screen in the same time, we can manage our 9+1 sprites with sprite bullets too, limitating the slots for seeking active turrets.

A fruitful friday, don't you think so?

First of all, THE news: Russell Kay has started talking about a XeO3 version on the Spectrum, and, believe me, listening about a multiplatform release would make me scream:"Any Zzap!64 around where to send our game? Where is one when you need it?". His blog is here, and is now in the XeO3 gateway, I will root for him!

From the coding side, several bugfixes had been performed by Mike: a ghost sprite that occurred when (and where) you collect a coin has been overcome, anda makor bug involving the whole starfield affair will come back no more!
But the main interest goes to the editor: Mike's projects about it are simply inflating more. The first idea was to have a good PC editor in order to manage all-in-one +4 sprites, level graphics and mapping. But with the dread advent of a C64 version, so many useful option has enriched the whole project. Currently, having into the editor all the tools for Spectrum too, is a temptation that a coder can't despise!

So, you could say, Luca's sleeping while the whole XeO3 armada slowly moves to the final achievement. But noooo, of course, on the countrary: I'm so close to finish the sprites for 1st level, 22 sprites left and a whole big boss to invent from zero.
But let me show my waste of the last days'sprites.
I managed to shrink and compress walkers in the little 8x16 area we have, and the result doesn't look so bad! We will swap different walkers level per level, choosing which when and where. Hope I will be able to move them correctly, with no mismatch between animation and scrolling...

Another sprite I needed is the pod, a non-directional baddie of general use, it could be either grouped in menacious attack waves and set it orbiting around the big boss. First, I tried a full moving version of this, with the core ball rotating too, afterward me and Mike thought that the simpler the better. Then, the result.

Ok, what is the best object to make a sprite collide? Yes, caught it: another sprite!
The middle boss has a huge bazooka, and this last toy looks like it can shoot big bullets. And that bullet will be a sprite. I used 7 frames to animate it, 4 frames for the flying trajectory and 3 frames in the shooting itself. A well spend single hour of working, have to say... The animated gif below is a guess, not to take so seriously, but it can let you imagine how it really plays. Hey, something you must see in the game only, right? ;)

A little but neat retouch in the panel. Why don't use much color when you can? Let's enrich the little logo with some more colours, look. Little touches, preparing mind and body to challenge against the big boss'drawing. I'll do it, don't worry, I'll do it!

So long, poor little cute pulsating piston down sprite, succumbed to let its "upper" twin survive. Mike evenly said that one piston would be enough, so I've chosen the upper pulsating one, much more Metropolis-like.
Your sacrifice won't be in vain, brave piston down sprite. You'll become the empty sprite, the number 167, key of in-game mysterious background corners in which you can spot fountains of coins. Yeah, that's the way, an empty sprite is a phantom one that lies in a place impossible to detect, it has NoCollision flag on, and it drops a coin when shot.

Oh, I had had little time only to spend in drawing sprites today, but in half a hour I managed to change the ball into something much more bubble-looking. I could keep both new and old ball sprites, cause the older has a solid look that works quite good in DNA-shaped attack waves, and the newer is catchy, but their purpose is exactly the same, and I shouldn't waste memory that way.

Allow me to introduce our new 8 frame sprite. It looks like big wheel, it seems to be the bad bouncer of your prefer pub.
Oops I did it again, I'm the Britney of fatty pixels'manufacturing, I am not able to draw simple shapes, basic molds, then animate them, and in the last instance only I have to add details. I saw so many simple sprites in the best c64 games, why I have to hit my head against complicated casts, furthermore with 8x16 pixels instead of 12x21? Bah, mysteries of the human mind...

The graphician's work is like a fattened pig: once killed, that's used in every part and nothing really has to be castaway.
Do you remember the old side cannons pickups? They're so grossy, coarse, hence I decided to chage them with the "rotating arrow". Now, I picture they could be quite good as floating obstacle, some stuff that slowly moves to reach the narrow path where you're flying throught.
The idea could work fine, but they need a biblic multiplication of coherent frames. Once said, then done: you can see the new look of our brute "pistons", differently animated due to their movement direction. Compare both with the correspondent older versions.

I'm still busy with the sprite fixing, animating, redrawing and, generally, all the words that end in -ing and that would mean tricky lenghty dull.

Oh well, probably I'm overacting: do graphics on our beloved machines is basically lot of fun. But let imagine: in the beginning, you don't know about how many space you should take for animating the sprites, hence you begin to draw cheap but quite good stuff; months after, due to your better knowledge of the game's data, you have to keep those sprites, but make them smoother in order to reach the right quality standard you need.
When you have to face this genre of work, you must know that the dirty job doubles: while you're creating new frames for your jelly sprite, you also must retouch the old ones in order to change, for example, a rotation angle between frames. In a two words sentence: it sucks.

The coins had been redraw. Simpler, with no milling on the border, and no shines: the simpler the better, the PAL's colour blurring on TV sets and monitor respond very well to this new stile. Compare the two different versions by yourself.

Do you remember the round ship and the meatball? They were respectively 4 and 3 frames animated. I had to take their frames to 6: Mike expressly asked to me about ssssmmmoootttthheeerr sprites, so I did my job.
The ship's animation has been surprisingly easier than the meatball's: once the two bonus frames were added, the sprite's rotation looked almost neat.
Almost. Most of the time, I had to fight against that "almost" thing. You can't imagine how much a sprite can change, simply using one coloured pixel instead of another. I would remind you that we're talking about 8x16 MCM sprites, and that with this graphic area available, most of the movement spotted by your eye is a fake, another part is PAL blurring, and a little one is real pixel animation.
In the end, I had my satisfactory result. You can compare it with the previous version.

The same we asked for the baddie I called "the meatball". My usual mistake is the same again: I should start from easier shapes, and keep them simple simple simple until the last pixel set, instead of inserting light, shadows, shines, dithering, antialiasing with those fatty MCM pixels!
A decisive step has been brought by Mike, when he suggested me to delete all the antialiasing with the darkest colour ariund the core ball: again, the simpler, the cleaner, the better.
It has been a hard fight against fat pixel and nutty video blurring, but I can say I'm quite happy of the overall result.

Plus, I added a 4 frames animated ball.
The pulsating ball is a classic in the cheap 8bit shmups world, do you remember the 8 frames balls in Armalyte, for example. If you use the animated ball "as is", bah, you're mastah lamer in person! But let the collision occur only against the largest ball's frame, and you can run impressive DNA-like paths in the cheapest way ever.