...and we are back again!
You surely realized we had a project's freezing winter, but spring's sunrays are coming to thaw us.

Though we're not completely on the keys, due to several other projects to finish, Mike is fighting against the major bugs that affected the main code, before facing the weapon system, which continues to be the next milestone to reach. But, you know how it can happens, when you fix a routine, another can breaks: Mike is filling all the holes, preexistent and new ones.
In the end, I would finally know the destiny for the background animation engine.

My own milestones are now: buildin'up a level2 map (nevermind animations can be performed continuos or not), 2nd level's middle boss drawing/animating and, finally, more sprites when inspired.
Follow us.

I love this feature! I love it so much, I wanna be the Mike's blog echo and publish the image here too!

Mike is hitting the code again with a target to reach: find spare memory for the second time. In the meantime, he's trying and trying several little solutions here and there. One of those, will cost about 200 bytes and a bit of speed, but that's so cool and useful!
When you hit an enemy, it flashes. Apart of the big improve in player's satisfaction, it looks pretty nice, and allows us in the usage of weak point for larger enemies: the player will know about a possible damage to the enemy when he'll shoot at the weak point, hence a whole slice of changes has been added to the big bosses'build up.
Apropos, I may picture how to roughly draw a big boss for level 1, but at the moment we're deciding how they're done: yes, initially we said:"Chars!", after some time we said "Sprites!", and now...well, we will see.

Ah I wanna tell ya, music has been composed! I can't pillory it yet for several reasons you will know soon, but I could start describing it.
The game will load one music file per level. Mike is deeply persuaded about the needing of let the player starts to play immediately, once the game is loaded. This means, in the available 4 Kbytes for it, I have to squeeze both frontend and level music, without too much loose in quality for both.
Once said, then done. I squeezed in a decent main tune, two jingles for end level and game over (obtained from the main theme itself), and the 1st level tune. The latter is the older 1st level tune you can hear in the radio, converted to the new instruments'set.
Believe me, I had to fight a lot against lack of memory, I had to reduce some instruments'quality and to cut the tune's length. But in the end: success! Soon, you'll listen at all the 4 tunes.

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!

It's time to let your mummy scream:"Jeez, your room is so dusty! Confess, did you blast some turrets and mines here?".

The latest version of XeO3 allows to destroy al the frantically shooting turrets, and to make a breach thru the clusters of pulsating mines. All this movement, added to sprite waves, background animations and turrets'bullets, reaches that dynamic visual performance that a shoot'em'up game can't miss: now you have the feeling of a menace from the deep unknown space, who knows how many enemies will jump out from the darkest corner?

Soon, next issues: shooting enemies, collision with background, and finally the first big boss will scare you in the terrific hugeness of its own 9 composed sprites shape!
I feel the fragrance of a public demo, stay with us!

In every project, we may detect a rare magic point, during which time the destiny of the project itself is determined. It happens several times, this moment extends in a very short but golden time, few dozen minutes only.
Well, probably Mike experienced something very similar, today.

The question is: why getting busy in sprite managing, when actually the target sprite is not overlapping other than the empty space? Why don't let the sprite routine check for special cases, in order to save precious cpu time when the sprite doesn't need to be manipulated cause the background under it? We have to consider that a sprite flies in the empty space for the bigger slice of its own flight path, and that means you can move more that 7 sprites with no slowdown, if almost one of them is not undergoing a disadvantageous circumstance.

Lemme show the actual screen in the current beta:

You are watching to a real world record on our beloved +4: 10 fully masked sprites moving around at good framerate, with SID music and 21 chars high scrolling background. Be honest: have you ever seen something similar on a +4?
When the deep space begins to spread on the screen, the biggest hordes come out from their hoards! Then, we only have to modulate baddies'waves and background's fillup, in order to obtain a furious battlefield to play with.

This important result needs some changes in the level graphics supply, like a little reduction for the available chars. Due to this complex change, we used the occasion to come to an understanding about some dedicated placements in the level's charset. But we also took some important decisions about level's item: 2x2 turrets are in, and I must draw something in order to display hit turrets too; 3x2 bins had been totally removed, if we'll have bins that open and set free some baddies, they will be 2x2 and sprites in turn. All the little animation that have to be displayed, is located outside the charset, where they will be copied from.

Heyhey, I said that we'd lost some chars to make space for the new sprites, but in the end I have a bit more chars per level, due to the new project's guidelines! Ok, let's complete the level's graphics, while Mike will work on background's collision.

"Now it begins to look like a real game", Mike said.
And he has good reasons to talk that way: now his lovable piece of code features a dynamic joystick driven player's ship, and the panel in the bottom now works 100%, counting ships left, shield level, money gain and score.

In order to test it, Mike attempted a real heroic act, desperately trying to persuade the ship to move softly via the worst joystick we can remind. Yes, if you're here, you know what a 264 series Commodore machine is, consequently you surely know how problematic can be the normal use of a terrific Commodore 1341 joystick!

The 1341 joystick (apart of the special Könix Speedking with round connector) was a fir's branch, badly sticked on the worst patchy imitation of a black Venice's gondola. You know, a joystick has the right to vaunt a decent balance, whereas the 1341 offers you the thrill of imaginary playing on board ship.
I hope that people will play XeO3 with a most decent joystick, instead of  this rare example of technological crock.

Waiting for the Mike's global editor, I try to save time drawing some backdrop elements, refreshing level 1 graphics.
At the moment, 22 characters has to be assigned. Part of these 22 must become non collidable background. In the case we're able to put little animation in the background's graphics, I wanna open the 3x2 turrets in order to use them as baddies'bin (9 chars for a decent animation), hence I need another 4 chars in order to draw an equivalent 2x2 shooting turret.
Mmm.. In the closer future, I see challenges in order to save memory...mmm...

Mike vs. screentime!
That's the result when you try saving cpu from bullets'allocation consumption. Let me introduce Mike's explication about the routine, keys to you Mike!

In the old days (when I was doing C64 stuff), my allocation routines tended to be bog standard, and very simple, like this....(in fact...I still tend to do this now...).

Alloc:      ldx   #MAX_OBJECTS
CheckAll:
               lda   InUse,x
               beq GotOne
               dex
               bpl  CheckAll
               rts

GotOne:
               lda #$ff
               sta BullInUse,x
               rts

Now this is all very well and good, but the more "slots" you have the worse it'll get. The easy answer is a simple linked list or something... but this requires you to link and unlink, and setup is't as simple either, not to mention the overhead of the links themselves.

So, while I was struggling to find a solution, I stated thinking of some sort of "stack" method... and stumbled into this method- timings were based on 16 slots. (hope the code comes out readable).

***************************************************************************
;
; Allocate/Free a bullet.
; Out: X=spare slot or -1 for error
;
; Alloc - BEST/WORST - 12/25
; Free - Best/Worst - 24 (constant)
;
;***************************************************************************
FreeList db 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,$ff
;
; Usage:- AllocBullet [x|y]  Specify the X or Y register that hold the bullet to free
;AllocBullet macro \0
           ld\0   FreeIndex                    ; 3       ldx  FreeIndex
           lda    FreeList,\0                    ; 4      lda  FreeList
           bmi   !NoneFree                    ; 2     bmi  !NoneFree
           in\0                                     ; 2           inx
           st\0   FreeIndex                    ; 3       stx  FreeIndex
           ta\0                                     ; 2           tax
           dec   BullInUse,\0                  ; 7    dec  BullInUse,x
!NoneFree:                                      ;           tax
           ta\0                                     ; 2           get next free bullet (or $ff for none left)
           endm
;
; Usage:- FreeBullet [x|y]  Specify the X or Y register that hold the bullet to free
;FreeBullet   macro
            t\0a                                       ; 2        txa
            ld\0  FreeIndex                        ; 3   ldx FreeIndex
            de\0                                      ; 2        dex
            st\0  FreeIndex                       ; 3    stx FreeIndex
            sta   FreeList,\0                       ; 5   sta FreeList,x
            ta\0                                      ; 2         tax                - restore index
            lda   #0                                 ; 2        lda #0
            sta   BullInUse,\0                    ; 5   sta BullInUse,x 
            endm

Now, the best thing about it is that it doesn't matter how many you have, its aconstant speed, and all you need to do is setup an array with the freelist in it. You can type it in here as I've done, or calculate it at runtime... In effect its a simple stack, but it never occured to me to use a stack as an allocator before, its very quick and thanks to macros, you can use X or Y to allocate depending on your needs....

I used this for bullet allocation, and when firing many at once, I took a huge hit... now allocation is virtually invisible... which is nice.

At first sight, Mike said we probably have to resize the turrets shape from 3x2 chars to 2x2, a less expensive dimension to manage.
Instead of this,although he's saving any single precious timeslice, it seems that we probably will be able to keep 3x2 turrets, probably adding a little animation somewhere.

The ancestral idea of a "turret" in this project, was a simple 3x2 shaped stuff, built in simple chars, from which sprite bullets pop out occasionally. The turret would show explosion made by a single 4 frames animated character, of course we need 6 of it.
In the new view the project gained, a turret may shoot at you or simply acts as an obstacle, could have a little animation, could become a bunch of smoking crap when shot down.

New winds on the project also take the difference between collidable and noncollidable backdrops elements. This second feature should be used in the way of having a dark counterbackground (usually in one color only, see Denaris as a good example, Menace as a bad one). A destroyed turret, hence, can be an animated noncollidable element, and I'll attend to draw it in order to instantly say to the player that there's no collision moving with the ship on it.
Hence, we passed from a simple 6 chars inanimate large stuff, to a pretty nice 4 or 6 chars turret that can show a little animation when working, and another little animation as noncollidable once shot down.

We'll see if the CPU will tolerate this too.

Since from the very first attempts about the software sprites, Mike formulates the Big Question: full sprites or not?

He talked very clear. 10 baddies can be easily moved around if we don't need to manage their own graphic interation; that way, a black box appears between two baddies, and they have to run under the backdrops, but at that point you can use all the colors you want! Looking the first picture, please don't care the colour clashes. Instead, look where the ships are moving, and the black box of the red one overlapping the grey one.
The other choice is to have 6 sprites, that  your CPU will move with effort over a 3 colors world. I said over, in fact. Looking the lower screenshot , you can see full sprites in their chromeless glory.

We decided.
It would be great to have a screen pullulating of enemies to blast, but it's not a necessity when you also have turrets, bosses, narrow passages and more. On the other side, I can't remember other C16 or +4 titles supporting a graphic core like this...mmm...GWNN? Yeah maybe, but it moves a 12 chars high screen, not a 21 chars high one!
I don't care about lack of colours, if my eyes are delighted by the vision of real softsprites floating over a backdrop. We choose the second option.

Mike also tried to mask the sprites.
You can see on the right how much definition on the backdrops a sprite gains when masked
The result was quite pretty, but his 8501 CPU popped out from his +4 screaming to him:"Heeey are you a damn sadic brainless? It's HOT into the case!". Masking the sprites seems to be really CPU consumptive, unfortunately, and we won't have into the game.