Wildfire

[Misel982001]

Does anyone knows anything about a plus game called
Wildfire?

[fano]

This is protoype i made some time ago (Wildfire - CPCWiki) but it is on hold because Easter Egg's projects have priority on my own projects.
This is funny as i added some things to the game design last month, maybe that will be an 'official' EE project in the future    (i hope)

[Gryzor]

Just loaded the preview (thanks for providing that!), it looks really nice and scrolling is awesome. I'd suggest scaling sprites down a bit though, everything seems too large and doesn't leave too much space...?

[TFM]

No, BIG sprites are wonderful!

[mr_lou]

I haven't tried Wildfire yet. I downloaded it some time back, and put it in my "TO BE CONVERTED TO HFE" folder, but haven't had to the time to look at it yet.

But I'm gonna have to side with Gryzor regarding big sprites.

Better to have small sprites + smooth movement + more overview of the play-field, than to have big sprites + chunky movement + limited space to move in.

Of course, it depends on the game too. Cyberhuhn obviously needs big sprites.

[fano]

Just loaded the preview (thanks for providing that!), it looks really nice and scrolling is awesome. I'd suggest scaling sprites down a bit though, everything seems too large and doesn't leave too much space...?

Thanks to ygdrazil who created page from CPCrulez thread (http://cpcrulez.fr/forum/viewtopic.php?f=6&t=3683).


One problem is screen format, i wanted to make an horizontal overscan and limit playfield to 160 (20 chars) , this way player's ship height is 10% and enemies are 20%.You're right , that may be a bit big , i think i'll use a 192 (24 chars) playfield height to increase player space and reduce objects size to something like 2/3 (32*16=>24*16 , 32*32=>24*24)


Another problem is obviously the sprite count , a poor 7 standard enemies wave would eat all avaible sprites, that's too why screen space is reduced to 160 and why sprites are so big.In a vertical shooter , multiplexing using PRI interrupts (or better use AY lists to generate positional interrupts) would be very usefull but with an horizontal shooter, even it is possible, it would be to CPU intensive.


Btw, due to the project specifications , i think cartridge support would be the best way, especially with the CTC-AY cartriges (only as mass support and maybe AY because other features are already covered by ASIC)

[Misel982001]

Where can I see this game? When it is going to be ready?Is it a plus game?

[Axelay]

Another problem is obviously the sprite count , a poor 7 standard enemies wave would eat all avaible sprites, that's too why screen space is reduced to 160 and why sprites are so big.In a vertical shooter , multiplexing using PRI interrupts (or better use AY lists to generate positional interrupts) would be very usefull but with an horizontal shooter, even it is possible, it would be to CPU intensive.

Wouldn't it be perfectly adequate to use the Plus sprites mostly individually as 16 pixel high enemies?  Even without multiplexing, I think 16 sprites at 16 pixels high, with bullets handled in software would give plenty of scope for a Plus horizontal shooter.  I had worried that 16 pixels high on a large play area might look a bit small myself, as Relentless used 16 pixel high sprites on a 24 char high screen (and there was just 5 of them!), but they didnt end up feeling small to me.  But of course it could be a different story, depending on the style and pace of the game you have in mind. 

[Trebmint]

Wouldn't it be perfectly adequate to use the Plus sprites mostly individually as 16 pixel high enemies?  Even without multiplexing, I think 16 sprites at 16 pixels high, with bullets handled in software would give plenty of scope for a Plus horizontal shooter.  I had worried that 16 pixels high on a large play area might look a bit small myself, as Relentless used 16 pixel high sprites on a 24 char high screen (and there was just 5 of them!), but they didnt end up feeling small to me.  But of course it could be a different story, depending on the style and pace of the game you have in mind.

Why not use the Y multiply to make the sprites double height. If they are animating I dont think you'd notice, and they are already blocky in MODE 0 X wise, so why not. C64 games use this all the time, why not Gx4000 too

[Axelay]

Why not use the Y multiply to make the sprites double height. If they are animating I dont think you'd notice, and they are already blocky in MODE 0 X wise, so why not. C64 games use this all the time, why not Gx4000 too

Personally I'd probably only be inclined to Y multiply in special cases like boss 'superstructure' or something, but I'm not looking to prescribe a particular way!     My point really was that if you have the sort of game where you've got to fly between background you can collide with, you really dont need sprites to be all that big.  By the time you have a dozen bullets and as many again in enemy sprites, plus perhaps turrets protruding in from that background in there, it would feel plenty cramped enough - I think.

[fano]

Where can I see this game? When it is going to be ready?Is it a plus game?

There is a link to the .dsk file at the bottom of the wiki page 
Impossible to say when it will be ready , the one on wiki page is just a prototype to see how the real project could be done but misses a lot features.

Wouldn't it be perfectly adequate to use the Plus sprites mostly individually as 16 pixel high enemies?  Even without multiplexing, I think 16 sprites at 16 pixels high, with bullets handled in software would give plenty of scope for a Plus horizontal shooter.  I had worried that 16 pixels high on a large play area might look a bit small myself, as Relentless used 16 pixel high sprites on a 24 char high screen (and there was just 5 of them!), but they didnt end up feeling small to me.  But of course it could be a different story, depending on the style and pace of the game you have in mind.

I'd say , R-Type (again!) is a reference so i am trying to keep the same proportions between player , enemies and level as i'd like to get a similar gameplay, mainly based on the good handle of the game space .16 pixels height would not fit here.On Relentless , 16 pixels height matches perfectly with game style as it is a fast shooter (as opposite with R-Type where speed is lower)
About software handled objects , in the lastest prototype , i used them for fixed enemies like turrets.For bullets and player shots the main problem is to handle discontinuity in screen address caused by multiples zones with differents speeds  and address wrap involved in hardware scrolling (but i'd say the one who would be able to handle this at 50Hz would be able to make the code of a technical demential game)

Why not use the Y multiply to make the sprites double height. If they are animating I dont think you'd notice, and they are already blocky in MODE 0 X wise, so why not. C64 games use this all the time, why not Gx4000 too

I always found that doesn't deserve graphic artist work, i used this only for explosions as you can see because they vanish fast.