Me and Mike ripened different ideas about level's graphics, and we'd encountered the very first tough idea's divergence.
At the moment, we don't know the way we'll choose, but a solution will be find for sure.

That's the dilemma. Look the picture below.

I drew, at last, non collidable backdrop elements: some menhirs in the dark, 8 chars used only, blank one included. I used a bit of white only, but Mike had suggested me to keep white off, so I cutted off the white pixels and only dark and mid colors are used. Your ship should move on menhirs without collision, while they scroll with the whole background, overlapping the fixed stars, in order to give the player a sense of depth.

Mike's side: though the white pixels had been cutted off, the player won't believe the menhirs don't collide with his ship. I pictured in my mind the non collidable elements as ruins at the ground and so on, but now I think that we should spend those chars  toward a more various background's graphics, and variety means: to have as many different background characters as possible.

Luca's side: menhirs are cool, cheap (8 chars only!) and they're enough in the dark to suggest to the player they won't collide with the ship. Background doesn't need another 8 chars sacrifice, also because I tried in the past to make the most from the 200 3x3 blocks we use to build up a level, and they run out very quickly, voiding the necessity of having so many elements.

What is your opinion about this?

The discussion continues here too. The old scrolling demo will help you too.

"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.

The most important tool in the making of XeO3 is the paper, no doubt about.

Ideas about graphics or music pop out from your mind in the most unpredictable occasions, especially when your emulator and your original machine are distant: in the bathtub, at workplace, when driving, on the toilet bowl. The last one, particularly...
In those instances, a paper sheet represents your salvation, either if you are quite good in handdrawing or not. Mine is the second, of course. A chequered notebook can simulate video matrix as well, predicting the 4x8 partition and the global look.

This is exactly the way the new graphics for level 1 began its very first steps, and a piece of paper saved my day.

As you can see, there will be glass balls everywhere, combined with metallic tubes; and platforms versatile enough to be 3 or 4 or 5 chars long, in order to underpin both 3x2 and 2x2 turrets. Apropos, I hope that 3x2 turrets will open and release baddies, instead of shooting around. I'm also able to have a DNA shaped column, due to the balls. Moreover, I added some more pipe chars.
Now the level 1 charset, keeping into count the system stuff (bullets, chars explosion etc...) has 50 chars left, to be used in more backgroud elements, non collidable background and, maybe, few little animation.

I achieved this easy improvement for level 1 graphics using the older XeO3 levels'editor kindly coded for me by FatMan, but I had to switch off DirectX to make it work good. Because of this, Mike is still sweating hard on a bug free and much extensive editor, as you can wonder watching the following rare snapshot.

A little offtopic note.
I received a pretty and very heartening email from James McKay. I just had the taste about his retro project: he's working on Klass of '99, a Spectrum 128 porting of a PC stuff, in turn inspired by the cult classic Skool Daze. No need to say I root for James'project like a drunk hooligan.
But our and James'projects are not alone, 8bit life's out there! Do we need a button banner recognizable ring, that keeps all us linked?

Sometimes, the simpler act can do miracles.

Mike had suggested me to change a bit the "pipeline" characters used in the current level 1 graphics. A black pixel row points out that light comes from the upper border, giving a very metallic look to the whole pipeline. I guess I changed...uhmm...a dozen pixels in all.

Though we can't predict yet the look that level 1 will put on, this minimal change proves to be enough to improve the overall result. And how cheaper it had been! Thanks Mike!

Look at these two little animation of a rocket.
They are composed by two sprites (I would remember you that here, a "sprite" must be intended as a 16x16 software sprite); the chequered one has a 6 frames animation, and the second, simpler, has 4 only.
Well, whereas the second will be used in the game, the chequered one has been discarded, 'coz it suffers the inner black syndrome.

As you know, several times the black color is used as transparent color for the sprites, and the background can be seen throught it.
But the black color also represents a great resource for the graphician, especially if he can't wallow in a most comfortable 24x21 area: if you manage to draw a darkened part of the sprite, the player's eyes and brain will see it complete. And this is only one trick you usually can do with black!
Back to missile's case, the rotation of a chequered cylindric shape needs the black, when you're in 3 colours + black mode, no other solutions available!
But the problem is: if you have background graphics, they will bitch up your chequered effect, cause the transparency.

A lesson for the future, the inner black theory says that:"No inner black areas are allowed drawing sprites".

What about compare this golden rule with C64 classic games?
Surprise: many times this rule had been forgotten. Let's take IO, for eample,
Well, let's take IO: the stars in the background move into the ship's sphere. "Because probably it's made of glass!", a friend of mine said. LOL! Ok, so let's take an incontrovertible specimen: let's look at this Enforcer big boss, as you can see this laaaarge ship needs a black background, in order to looks metallic as it had been thought to be!

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.

Do you remember?
The little green pickup had no assignment yet: smart bomb, or shield recovery?
Well, the clearest solution is to draw another pickup, no?

And this is the result. A 7 frames (2x2, you know) sprite, with a 22 steps animation, so the system sprites now count 48 overall, leaving 119 available for any new level. Yeah I know, so many frames and steps for a pickup. But, hey, I think it looks nice, doesn't it?

In this period, Mike is challenging bullets'management in the game, one of the worse beasts we have to fight against. And he has to save any single rasterline, 'coz the whole code had begun to suffer seriously due to the softsprites math's big load.
I'm in a pause state, waiting for the best moment in which I'll redraw the early level's graphics I did, taking advantage of the larger space we saved for after we found memory to move final bosses'gfx.
Good, I'll use this time in order to draw some attempts for the mid bosses.

XeO3 will have 167 sprites per level.
Some of them must be considered fixed system sprites: player's ship, explosion, coins and pickups. Counting their frames, the overall consumption is 41 sprites.
But please, first of all, let me introduce 3 new baddies I drew in the last days.

126 remaining sprites are a good number of them considered per level. Hence, Mike began to code something able to manage a 6 sprites built mid boss. Yes, we will have considerably large big baddies in the middle of the level, and that's nice.
The best thing to do in this case, is to utilize the 6 sprites in the laaaargest displacement possible. Armalyte teaches how to implement this theory: W-shaped ships everywhere! Player's eye will make his brain considering included empty space into the W as part of the enemy's shape.
"Good!" - I thought - "In order to allow Mike developing his piece of code, I'll draw one of those ships!". And actually, I did not, of course. You know I'm essentially brain damaged.

I drew a 6 sprites armoured warrior instead. His helmet is intended to pulse continuously. It should shoot laser with integrated cannon, and when it happens, a gun recoil occurs, and an empty bullet's cartridge pops out to be removed. All the little animations had been finished, though here you can see the warrior in a motionless stage.

And something suggests me that the 2nd level midboss too won't be a W-shaped stuff...

Maybe, the 6 full sprites choice begins to weigh against gameplay.
Mike said me that he can't move on the screen weapons larger than 2x1 chars: they become a real mess if some would stay on screen in the same time.
That's a real pity, I liked so much those biiiiiig bullets, I wondered about take away big slices of wreckable backdrops in one single shot!

I drew them anew with tears on my eyes, and in spite of this limitation I raised their ranks in quantity. Now you can boost up your prefer weapon 6 times. They're different in power, shape (a bit), and shot rate.
In the picture below, you can look at: normal shot, both sideshots, rear, laser, energy blade and plasma ball.