Game preview:WILDFIRE

[Ygdrazil]

Posted a while ago on the German CPC forum ...

A preview of a new horizontal shooter has been released.

Beside some screenshots and a .dsk image not much info has been released about the game.

Wildfire looks really promissing. Who is making the game, will it be completed?

So many questions?

As I am involved in doing something similar for the CPC plus I am really interested in this.

link to Wildfire article on the CPCWIKI

http://cpcwiki.eu/index.php/Wildfire

/Ygdrazil

link to german forum thread: http://www.cpc-forum.de/viewtopic.php?t=692

[Gryzor]

A shooter! Me likes! Looks like a colourful R-Type... please do keep us posted...

[khisanth]

Oooo very nice. Dont think Irem would be happy about it though

[fano]

But, but , WTF ! for a surprise , this is a surprise !

I posted it some time ago on CPCRULEZ as i needed to test that on a real CPC. ( thread : http://cpcrulez.fr/forum/viewtopic.php?f=6&t=3683 )
Project Wildfire aims to be a R-TYPE clone for CPC 6128+.The final source code would be opened to share what i learned.
On first preview, it was running at 25FPS but i would to optimize code to go to 50FPS and keeping all features.For me , the bottlenecks are softs sprites and effects and collision testes.

It is currently in devellopement, some essential things are ok (like general framework, enemies plugins system or devtools) but there is still a lot of work .It progress slowly because i do not have a lot of time to have the required calm to work seriously on it.

I wanted to wait to have a very solid prototype to post it and require graphics/level/enemy designers.But as for now it is known to here from germany so if someone is interested to help for this, music (STarkos) or to optimize code , contact me 

This is the lastest screenshot.Actually color bands in the border are here to estimated time for differents parts of code.

[Gryzor]

Looks really impressive, I hope you pull it off!

Do you still need someone to test it on a real CPC?

I really don't think Irem would mind, unless they want to release more titles for the CPC

[fano]

Thx, i hope i'll be able to implement everything i want 
This topic gave me more motivation 

Do you still need someone to test it on a real CPC?

Thanks a lot but my CPC+ owns a 3"5 drive now  but i keep the offer for the beta 

I don't think Irem has something to say because all GFX and code are made from scratch (w/ grafx2 that allows to create GFX easily w/ CPC+ palette ) and i don't think they patented the shmup principle or R-Type modules 

As I am involved in doing something similar for the CPC plus I am really interested in this.

Great, you are helping for XEO3 or you are working on a another personal project too ?
This is an additional souce of motivation to see other people projects in this style like XEO3.
Thx for the wiki page too but my english (engrish ? frenglish ?) skills are not good enough to fill it in proper english, i'll add screenshots in progress.

[Gryzor]

I'll tear up that beta in no time, please do let me in

[Ygdrazil]

No personal project! I am only helping out on XeO3 which has proven to be more time consuming than first thought, but we're progressing slowly but steadily.

I really like the appearance of Wildfire, and I can't wait to see the final game in action. I agree completely with you that it serves as great motivation to see other people working on something similar.

Keep up the spirit.

/Ygdrazil

Great, you are helping for XEO3 or you are working on a another personal project too ?
This is an additional souce of motivation to see other people projects in this style like XEO3.
Thx for the wiki page too but my english (engrish ? frenglish ?) skills are not good enough to fill it in proper english, i'll add screenshots in progress.

[Gryzor]

Will it have in-game music? A DMA tune would be so out-of-this-world...

[Ygdrazil]

I think there is hope that real soon we will be able to relatively easily include DMA composed sound into programs for the Amstrad CPC plus.

Currently there is a tracker in development for the CPC plus.

Check the CPCWIKI article..

Plus tracker

Seems really promissing..

Sadly I don't really remember where I got the sna image from.

Anyone??

/Ygdrazil

Will it have in-game music? A DMA tune would be so out-of-this-world...

[Gryzor]

Heh, thanks for the heads-up. I think it'd be worth the wait if it gets possible to implement something of the sort... And with this kind of gfx, if scrolling is good, it could be the ultimate CPC shooter...

[Axelay]

I think there is hope that real soon we will be able to relatively easily include DMA composed sound into programs for the Amstrad CPC plus.

Currently there is a tracker in development for the CPC plus.

Check the CPCWIKI article..

Plus tracker

Seems really promissing..

Sadly I don't really remember where I got the sna image from.

Anyone??

/Ygdrazil

Here:

http://mrick0363.free.fr/

Though as far as I can tell it doesn't seem to have been updated since it was first put up.

[fano]

Will it have in-game music? A DMA tune would be so out-of-this-world...

On first approach i was focusing STarkos because it is a great tool , player source is avaible and could be integrated easily in the project.
Other hand, i didn't have time to think seriously to have only DMA featured sound effects but that would be very sexy 
Updated wiki page w/ some fresh content 

[Ygdrazil]

Hi Fano

Great looking stuff... Really impressed by the quality of the graphics, already planning the 'end of level' monsters! A thing we have only had a brief look at until know, particularly because the Plus/4 developers are not there either.

I had a look at the preview in Winape again. It does seem that you're not using interrupts. Is this because you are running the entire game in a big frame timed main loop. Just curious!

/Ygdrazil

On first approach i was focusing STarkos because it is a great tool , player source is avaible and could be integrated easily in the project.
Other hand, i didn't have time to think seriously to have only DMA featured sound effects but that would be very sexy 
Updated wiki page w/ some fresh content 

[fano]

Thx ! doing GFX are not usually my cup of tea but i admit theses wide pixels and theses 4K colors give me a lot of pleasure 

End level bosses are just at 'proof of concept' stage, i would like to implement a system that allow to have large bosses.As CPC+ owns only 16 sprites, the animated parts would be small (max 12 sprites) and big bosses would be a mix between hardware and software stuff.

I must admit i am not a great user of interrupts because they can affect
expected timing of part of code and they may be a pain to debug 

The 'preview' uses PRI only to synchronise main loop with refresh to avoid flickering on sprites (hard & soft) and effectively to synchronise game loop with refresh rate.
Also i made experiments with CRTC register 9 prior to this preview to allow 2k/4k/8k split screens.That works perfectly in WinApe but interrupts never come on a real CPC+ so i removed them.Now my CPC owns a 3"5 drive so i'll be able to experiment further this idea in the future 

I noticed also timing for PRI in WinApe are not exactly the same on a real CPC+, they seem to occur before and to be more precise on it.We should be aware about this because that could be terrible for some effects (imagine a raster giant lazer all messed up and flickering because synchro is bad  ) and i think i'll have to find a way to detect on which context code runs.

As i saw you are working on an utility program for sprites, what method are you planing (or using) for XEO3 to transfer sprites from memory to ASIC ?

[Ygdrazil]

Hi Fano

Sorry for late reply.. .. My brain needed some cooling off..

Interesting stuff you write.

Doing graphics is a real pain in the a.... . I have realised why pixelart is ART! Luckily when porting XeO3 we can see how the graphics are desgined for either the C64 or the PLUS/4 version, the CPC plus can easily handle the graphics without problems (It could even be improved I guess)

I think the graphics done by you looks real cool. I like the use of the very colorful mode 0.

When doing the port of XeO3 we don't really experience the CPC plus specs as a problem, it's well suited for porting stuff at least from the C64 and PLUS/4. 16 hardware sprites is enough for most effects.. (In the original XeO3 there are seldom more than 8 baddies moving on screen at the same time - but more hardware sprites would have been nicer i guess)

I am not sure I know what you mean by a PRI problem(bug?). Testing the stuff we have made so far on a real CPC Plus has proved that our stuff works allright!

And why do you want to do 2K/4K/8K splits, not sure I know what you mean!!

Because we are porting a game already running in 320x200 we don't need to change the size of the screen!

Until now porting the sprites to the ASIC has been very time consuming. I will on a later time describe the process in detail - and put it on the wiki. But in the future I think Amsprite will speed up the process by including a CPC plus sprites design option.

/Ygdrazil

Thx ! doing GFX are not usually my cup of tea but i admit theses wide pixels and theses 4K colors give me a lot of pleasure 

End level bosses are just at 'proof of concept' stage, i would like to implement a system that allow to have large bosses.As CPC  owns only 16 sprites, the animated parts would be small (max 12 sprites) and big bosses would be a mix between hardware and software stuff.

I must admit i am not a great user of interrupts because they can affect
expected timing of part of code and they may be a pain to debug 

The 'preview' uses PRI only to synchronise main loop with refresh to avoid flickering on sprites (hard & soft) and effectively to synchronise game loop with refresh rate.
Also i made experiments with CRTC register 9 prior to this preview to allow 2k/4k/8k split screens.That works perfectly in WinApe but interrupts never come on a real CPC  so i removed them.Now my CPC owns a 3"5 drive so i'll be able to experiment further this idea in the future 

I noticed also timing for PRI in WinApe are not exactly the same on a real CPC , they seem to occur before and to be more precise on it.We should be aware about this because that could be terrible for some effects (imagine a raster giant lazer all messed up and flickering because synchro is bad  ) and i think i'll have to find a way to detect on which context code runs.

As i saw you are working on an utility program for sprites, what method are you planing (or using) for XEO3 to transfer sprites from memory to ASIC ?

[fano]

Doing graphics is a real pain in the a.... . I have realised why pixelart is ART!

For sure, you may take a look to this site : http://www.pixeljoint.com/ You'll find there a lot of stuff and some wide pixels lover, i learned a lot there 

but more hardware sprites would have been nicer i guess)

That should be soo coool to have big big big big mobile bosses 

I am not sure I know what you mean by a PRI problem(bug?). Testing the stuff we have made so far on a real CPC Plus has proved that our stuff works allright!
And why do you want to do 2K/4K/8K splits, not sure I know what you mean!!

Not a CPC+ bug but as i worked first on WinApe , i noticed ASIC emulation is quite different, especially with PRI when you load R9 with different value than 7.My main playing screen use memory from #C000 to #FFFF and i wanted to add a 2 lines score panel at #4000.Problem is memory wasted for only 2 lines, one solution is to use SPLT to change address and to add an interruption with PRI to change R9 with a lower value (from 0 to 7, each increment uses 2K, as a line is 96 bytes, i can have 21 lines in 2K).
But it is not so easy, with WinApe , lines ignored with R9 changes are still counted but interruption on theses lines do not occur.With theses considerations i wrote my interruption handler that worked perfectly on WinApe but interruption never came on a real CPC+.I didn't have time to experiment this further on a real CPC+ to see how to fix that.I'll surely have to detect the context the code is running to allow compatibility w/ Winape.

Until now porting the sprites to the ASIC has been very time consuming. I will on a later time describe the process in detail - and put it on the wiki. But in the future I think Amsprite will speed up the process by including a CPC plus sprites design option.

I am using directly BMP format in Grafx2 and i wrote a toolkit that allow easily convertion for sprites and backgrounds (compatible with TileStudio) in specific formats.For example, actually there are 4 differents ways to store sprites with differents memory/cpu usage ratios (RLE/packed/standart/compiled).That may interest you and i could post here some example and source code if you want to include theses type of features for Amsprite.

[Xyphoe]

Hi guys .... Just wondering if you have an update on this project? I was very much looking forward to this one

[fano]

Actualy no real update as i am planning to put it in a 512K cartridge and i need to make some before (and need some stuff to do that).
Maybe another preview or something like this in 2010 but it is too early to speak about actually as i have already a lot of work

[MacDeath]

Also because of a R-type...lol.

[fano]

Sure m8 , i just found how to bypass the sprite rendering system with "élégance" 

[Gryzor]

512k cartridge? wow... this would be sweet. A bit expensive, but sweet!

[fano]

I just hope we'll success in creating a cartridge from scratch and to create a 512K game for GX/464+/6128+.

The only thing i don't know is time that will take so expect to have a preview version for 6128+.When ? i don't know 

[Gryzor]

When? When? WHEN?

[fano]

When? When? WHEN?

Only GOD himself knows (if he has something to do with that)