Blue Angel 69 (CPC version)

[arnoldemu]

It is time to do some talking:

I am working on a CPC conversion of Blue Angel.

There is a 64K cassette version. This version has 1 CDT per side, each side has 5 out of the 10 pictures from the original. Lack of memory has forced me to make it this way.

I am coding the game using C and cpcrslib with extra library functions of my own.

The disc version is 64k compatible and loads the backgrounds from disc.

The game is about 90% complete. I am currently bug fixing and tweaking some things.

The game will be free to download and I will also release the full source, tools, build scripts and graphics.

Markus has helped me with converting the graphics and Mr. Lou has helped with some music.

EDIT: This is my first project writing in C for CPC and first time using cpcrslib.

[Gryzor]

Disk! Please consider offering physical distribution....

[Leonie]

This is my first project writing in C for CPC and first time using cpcrslib.

Some kind of beforehand-excuse?
Be that as it may, I look forward to the CPC-version of BlueAngel. 
 

[arnoldemu]

Some kind of beforehand-excuse?

indeed. I am saying, "please do not put your expectations too high.".

The z80 code that the c compiler makes is not great. Also I am limited with ram because of the backgrounds taking lots of ram space.
This also means no double buffer, so some flicker will happen.

Be that as it may, I look forward to the CPC-version of BlueAngel. 

I hope it will be fun to play and comparable to the other versions.

Update: I fixed some more bugs, loading backgrounds from disc now works.
But playing music by interrupt causes crashes.. so I need to fix this.
It took me some time to add support for interrupts correctly to "morelib" my extension of "cpcrslib".

[arnoldemu]

I've done loads of fixes.

All the music works now, loading backgrounds works, added extra bits for disc version.

A few more bugs remaining to fix.

1.4K free on cassette version!!!!! 
I know I'm going to be working hard to find some spare bytes somewhere

[fano]

Great workd, i can not wait to see the result 

1.4K free on cassette version!!!!!

That's what i like , full usage of ressources 

[arnoldemu]

Great workd, i can not wait to see the result 
That's what i like , full usage of ressources 

I fixed some more things, lots more left to fix. Tape version has 95 bytes free now but I need to add some other things in... so.. I will need to take some time counting bytes in the code and fitting it all in.

Disc version has "lots" of ram free (because it only loads 1 background at a time).

This bug fixing and fitting it all in takes time....

[fano]

I fixed some more things, lots more left to fix. Tape version has 95 bytes free now but I need to add some other things in... so.. I will need to take some time counting bytes in the code and fitting it all in.

nice count lol what cruncher do you use ?

[arnoldemu]

nice count lol what cruncher do you use ?

for disc version no cruncher.
for tape version I use pucrunch for the backgrounds only.

the byte remaining count is easy for me to calculate:

&c000-&ffff is screen (although some unseen bytes could be used)

game loads at &200. Stack grows down from &200.
code/gfx/music can go all the way up to &c000 on tape version.
Some bytes are free below &200 but not many (I don't really use the rsts much).
also a few bytes are free in parts of the screen that are not used 48 bytes per line over 8 lines.
So in theory I do have more than 95 bytes free.

95 is the number of bytes from the end of the file to &c000.

Looking at the generated asm code (from the c compiler) I can save some bytes by making a lot of library functions "callee" so that they clear up the stack themselves.
also, I can remove some chars from the font, and alter some gfx a little.
I could even use some of the unused screen memory for some data.

for the backgrounds I have to keep a buffer in memory to decompress to, but also this is used as you reveal each square.
but generally the game is graphics heavy because of the backgrounds... but slowly I am fixing bugs, filling the ram, and soon I will have to try and claim back as much bytes as I can by re-working the code.

cassette is worst because it is a single load.
disc is no problem because it loads each background as needed. in addition disc version has extra graphics as a "thanks" for using disc version
disc version also needs firmware active for loading because it uses cas in open/cas direct/cas close, but thankfully there is lots of free main ram for this.

game doesn't need extra 64k from 128k machines.
And no, i will not be adding extras for 128k users or cpc+ users.

So, wait until a future game from me to get these things.
I am already at the stage where I just want the game done

[mr_lou]

Would it really hurt if the tape version had to load the remaining levels after a few completed levels? I remember other games doing this, like R-type (I think)... and Arkanoid II (I also think).

[fano]

You may try exomizer , i use it and it gives good results (i use it to keep in memory little chunks of data like maps and larger like music or graphics).I don't know about the size of the decruncher but exomizer source is avaible too.For sure , decruncher may seem a bit slow but i don't care.
Here is a little article (in french) that make comparaison about it : http://cpcrulez.fr/applications_tools_cruncher_COMPARATIF.htm

[MacDeath]

Well, as this game don't feature stuff like scrollings... it must run well.

Of course the problem is that the "skins" are pictures, so can easily become heavy on Datas as we know the CPC is well membered graphically.

To aim at a 64K RAM version is always a shame in that you don't use the best potential of a CPC (the 6128 modl) yet it's good because it can of course run on Every CPC models.

It's also nice because you have to really do a proper code, optimize a lot and so on...
But Tapes are somewhat archaic...
Hope you'll release a MP3 version too.


So some questions :

--I suppose it's gonna be a mode0 game ?
From what I saw, the PC dos version was in EGA and CGA. CGA was in monochrome high resolution (Mode2 on a CPC) so I don't think you will use this.
But the EGA version should be quite close to a Mode0 version or even a Mode1...
The C64 is somewhat...grey and ugly. yet it uses the large pixels mode too. So with the superior blue palette from CPC and a bit of rework on the ditherings, this can only be superior.
Just got to see if the AY will be sweet enough compared to SID.

--Will there be some extra fan service (A sexy sexier version ? with naked pictures of Leonie ? ) or a straight port from existing versions ?
--Would you do as for ColourLine : a skin contest with many members of the Amstrad Community working on it ?

(the CPCsceners edition)

Also : What about the Amstrad PLUS ?
Perhaps a ROM/cartridge version may be sweet too in that optic...

Of course puting DMA samples may be heavier so better with a 6128+ version or even a ROM edition...
but concerning the Hardwired sprites, you may load the 16 slots as they have their own memory inside the ASIC...It may just take a bit longer to load...
Yet for this kind of game, the Hardwired sprites may be usefull (as a pointer in a mouse-like interface...or some special effects...) and are perhaps easier to move or manage than soft wared stuff (code-wise or even Data-wise...).

But of course, doing the 464 CPC version first is better.


Tomorow, my brother comes to my house to check if we can programm some microcontrolers to emulate ACID properly...


Whatever : THX for developping "new" games.



Commodork64 version.
Notice how they miserably failed to display the Gynoïd's busty breasts...



IBM PC and compatible (Amstrad PC is just fine then) in EGA (16colours) and CGA (Highres monocolour : exact equivalent of Mode2 on a CPC).

CGA looks like a speccy stuff actually.


Needless to say, such kind of game if the stuff where the CPC shines compared to Atari 8 bits, C64 and Speccys... Or even earlier MSX : few animations and colourfull graphics in blue.

[fano]

Well, as this game don't feature stuff like scrollings... it must run well.

this one is nice... ...Without doublebuffer with heavy stuff ,you must choose between flickering or slowdowns 

[MacDeath]

Technical matters... (Vader Voice) " I am not concerned with an interrupoïd problem!...cough... "

But seriously, even a 464 is beyond Tapes nowaday... You know ? MP3 players and shit like this ..?
IMHO it's a limitation that may not serve well the game (Datas and Loadings limitations...).

But yeah being Hardcore Retro to the core is nice.

[arnoldemu]

Technical matters... (Vader Voice) " I am not concerned with an interrupoïd problem!...cough... "

But seriously, even a 464 is beyond Tapes nowaday... You know ? MP3 players and shit like this ..?
IMHO it's a limitation that may not serve well the game (Datas and Loadings limitations...).

But yeah being Hardcore Retro to the core is nice.

Ok, I am sure when it is released many people will say "this is nice" and others will say "what is this shit?".
Well.. pictures will come in a few days.


The technical:

Same to both:
- Mode 0
- 160x200 screen.
- no double buffering (so a little flicker and you can see screen drawing ) - I didn't have ram for double buffer
- uses cpcrslib and z88dk
- main logic code written in C
- I added extra asm functions
- screens: they look much more like Amiga version than C64 version
- Nice music
- playable on green screen, but no special green screen version

Tape version:

- 2 sides (2xcdt).
- Each side has 5 out of the 10 pictures.
- This version runs in 64k with 1 load
- 1 music only at this time

Disc version:

- 1 dsk.
- All 10 pictures
- More music (2 large and 2 small)
- different score font (more like amiga)
- nice blue angel 69 logo in game (on menu screens)
- Also runs with 64k ram.

If you play disc version then you get more. If you play tape version, then it is not so nice. Less graphics and music, but same gameplay.

I will not make a cpc+ version. Wait for another of my games for this.
I will not upgrade for 128k.

So.. well I think some screen shots will answer more, so wait a day or two.