What New Game do you want developed for the Amstrad if the option was there?

[Puresox]

There really ought to be a version of Beamrider on the Amstrad , great but simple game versions' are on Intelivision and 2600 (So what size are we looking 4k?) ,It  is on everyother platform but our's??This doesn't seem right, this also goes for River Raid although slightly larger programme I'd think.

[pacomix]

I would like to see:

- Toki
- Joe & Mac
- A decent version of Pang/Super Pang for the CPC (and not Zapt'n'balls... the movement and the splitting of the balls really sucks!!!)
- Worms
- RPG like games.
- Ghost'n'goblins reloaded.
- Snow Bros

   With regards to some previous posts about targeting 64k/128k/512k etc... what motivates me personally is the challenge of squeezing up to the last bit whilst giving the best possible results. Personally I love loading from tape (yes... some games have a quite personal loading feeling and are nice to see). Apart from that it always give me time to prepare my Nutella (nocilla) bread slice and my ColaCao while it finishes loading.

   But yes... 128k always give you more freedom specially at having more space for putting there those nice graphics that most of the CPC games lack. It might be not practical targeting 64k but it's more of a challenge for lots of people I guess...

[VincentGR]

I would like to see:

- Toki
- Joe & Mac
- A decent version of Pang/Super Pang for the CPC (and not Zapt'n'balls... the movement and the splitting of the balls really sucks!!!)
- Worms
- RPG like games.
- Ghost'n'goblins reloaded.
- Snow Bros

Thanks for typing this for me 

[STE86]

I would have thought that GnG arcade/reloaded in 160x200 in 16 colours would be an awesome addition the cpc.

based on the experience of doing the c64 one, an amstrad one would have to be disk and 128k tho. the c64 one is BIG, it fills the whole ram and loads too.
therefore an amstrad one by virtue of the screen memory size will be an order of magnitude bigger.

It could however look bloody lovely and the lack of 50hz scroll would be of minimal impact because GnG is a very "stop/start" scrolling game anyway so you wouldnt notice.

pretty much all the c64 graphics assets would work "as is" (then tweaked for additional colour) except the progress map because that uses mixed hi res/mc mode and would need amended to just 160/200. and the score area would probably have to be redone in 4 colour hires mode for the text to be readable. All attainable tho really.

[TotO]

cheated poll, it was previously 13 votes for a 512K memory game! 

[TFM]

cheated poll, it was previously 13 votes for a 512K memory game! 

Well, like my old math teacher always told back the day: Never thrust a poll which you didn't manipulate by yourself. 

[TFM]

... and the lack of 50hz scroll would be of minimal impact because ....

Why not 50 fps scroll?

[Puresox]

Sod the poll , we need some project leaders in the CPC Zone . The production rate for the Amstrad is a bit lacking of late .

[TFM]

I volunteer for project leader and helping hand for any kind of game which will be made for FutureOS. 

[Puresox]

I volunteer for project leader and helping hand for any kind of game which will be made for FutureOS. 

Are there any good threads or is there any info to explain what FutureOS is all about? Sorry if this is a dumb question , but I haven't a clue what the In's and Outs are of FutureOS?

[TFM]

Are there any good threads or is there any info to explain what FutureOS is all about? Sorry if this is a dumb question , but I haven't a clue what the In's and Outs are of FutureOS?

Thanks for asking. Well in this forum we have a dedicated thread about it here:
FutureOS corner

The CPCWiki has a page about it:
FutureOS - CPCWiki

Software and the handbook are available here:
http://www.FutureOS.de


The advantages for making a game are:
- Use nearly all memory (OS needs a minimum of 2 KB RAM)
- Use all 2nd registers of the Z80, significant speedup
- Use all RST's and IM 2 if needed, 2 screens possible
- Quick loading & saving
- Use different screen formats (64 x 32, 80 x 25 etc)
- Memory management
- direct access to hardware is ok
- TFM is eager to provide help for it 

Disadvantages are:
- It need some kind of Flash or ROM card. like an X-MEM

[Puresox]

Great stuff

[STE86]

Why not 50 fps scroll?

because the the c64 version scrolls at 1px (thats 1 square pixel)/frame because its hardware can do that regardless of the actual pixel size on screen.
AFAIK the amstrad cant do this and would therefore scroll 1doublepx/2 frames to keep the same scroll rate for gameplay.

also I think its VERY optimistic to think that any old computer running sw spriting and scrolling on such a big screen is going to stay within 50hz enough to make it worthwhile.
we could never get the spectrum,bbc or atari ST to do it and have yet to see anything worthwhile do it on the amstrad to make me think otherwise.

[Puresox]

Just spotted Skool Daze has been converted to the CPC ! Genius, I imagine it is just an early version , but great to see

[Joseman]

Just spotted Skool Daze has been converted to the CPC ! Genius, I imagine it is just an early version , but great to see

Well I had a lot of plans with skool daze, but the 2 jobs this 2 months previous and that things changed  on my mind and now i've another plans with my life and some other projects (not exactly cpc related).

I want to finish Skool Daze in a way that the game can be completed, and nothing more right now.

I don't want to let the project unfinished.

in the next months i will try to finish the conversion this way

[TFM]

because the the c64 version scrolls at 1px (thats 1 square pixel)/frame because its hardware can do that regardless of the actual pixel size on screen.
AFAIK the amstrad cant do this and would therefore scroll 1doublepx/2 frames to keep the same scroll rate for gameplay.

also I think its VERY optimistic to think that any old computer running sw spriting and scrolling on such a big screen is going to stay within 50hz enough to make it worthwhile.
we could never get the spectrum,bbc or atari ST to do it and have yet to see anything worthwhile do it on the amstrad to make me think otherwise.

Hi! Yes the usual CPC scroll is two MODE 0 pixel per 'move'. But if you use two screens, then you can move one pixel per 'move'. I say move here, but I mean per frame.

We have quite some games on CPC scrolling at 50 fps, I have two games in WIP which actually scroll in 50 fps in Overscan. When using not more than 16 KB V-RAM then things are 50% more easy anyway.

Now you can use two screens and have 50 fps with 1 pixel scrolling, or save one screen and scroll with 2 pixel at 50 fps. But please don't go for 2 pixel at 25 fps - that looks jerky. 


EDIT: If somebody is seriously going to make a game, I will gladly share my scrolling engine. However, what ever one needs to make proper scrolling can be found at Arnoldemus homepage. 

[TMR]

Hi! Yes the usual CPC scroll is two MODE 0 pixel per 'move'. But if you use two screens, then you can move one pixel per 'move'. I say move here, but I mean per frame.

He's saying the C64 game is doing half a mode 0 pixel per move/frame...

[Optimus]

Hi! Yes the usual CPC scroll is two MODE 0 pixel per 'move'. But if you use two screens, then you can move one pixel per 'move'. I say move here, but I mean per frame.

My CRTC knowledge might be clumsy, but isn't the HW registers 12 and 13 scrolling at two bytes per time? (&C000, &C002, &C004, etc)
That would mean 4 Mode 0 pixels, or 8 mode 1 pixels, literally the character's width in basic, so we are more screwed.
Then with double buffering you can have shifted backgrounds as you say, thus 2 Mode 0 pixels scroll, which I think would be fine for specific games but maybe too fast for others.
To get to 1 pixel Mode 0 scrolling you'd have to go four framebuffers, which is a no-no for memory, unless maybe you do split screen for scoreboard and have 4 framebuffers of smaller in height screens, still a reduced 12kb multiplied by 4 would fill 48k and leave 16k for code and data.


I still love the C64 model of scrolling. 8x shifter on both X and Y and char based video mode helps with moving the small amount of data one char right or up after the shift loops. Also ideal for tiled based backgrounds, which are a norm in oldschool consoles and help save memory and move data faster. Now, CPC+ has those shifters too, but still you have to complete bytes at the edges of the screen, no hw charmode. It helps a lot, but I would still have an easier time making pixel perfect scrolling on C64 in all directions.

[Axelay]

My CRTC knowledge might be clumsy, but isn't the HW registers 12 and 13 scrolling at two bytes per time? (&C000, &C002, &C004, etc)
That would mean 4 Mode 0 pixels, or 8 mode 1 pixels, literally the character's width in basic, so we are more screwed.
Then with double buffering you can have shifted backgrounds as you say, thus 2 Mode 0 pixels scroll, which I think would be fine for specific games but maybe too fast for others.
To get to 1 pixel Mode 0 scrolling you'd have to go four framebuffers, which is a no-no for memory, unless maybe you do split screen for scoreboard and have 4 framebuffers of smaller in height screens, still a reduced 12kb multiplied by 4 would fill 48k and leave 16k for code and data.

TFM is talking about using CRTC R3 as well, so you could have 1 mode 0 pixel scrolling with two screens.  I am not convinced myself how effective it would be to use offset screens in a game requiring a push scroll though.  It means you need to cope with sprites updating on the visible screen if no scrolling is required, and managing that potential flicker issue will cost time.

[seanb]

If we're talking scrolling then I vote for a sonic game.
Let's show that c64 lot how you do fast scrolling.

[TFM]

TFM is talking about using CRTC R3 as well, so you could have 1 mode 0 pixel scrolling with two screens.  I am not convinced myself how effective it would be to use offset screens in a game requiring a push scroll though.  It means you need to cope with sprites updating on the visible screen if no scrolling is required, and managing that potential flicker issue will cost time.

You are exactly right Sir. An example for 1 Pixel MODE 0 scrolling (multidirectional) is Burnin Wheels, let me see if I find a link [nb](except that one on my homepage, because that's for FutureOS only).[/nb]


Found:
burning wheels &copy _public_domain_ (1987)

[Puresox]

On Scrolling Note, Hopping Mad by Elite has a nice scrolling style that graduates well , it would have been nice to have been implemented in Uridium in stead of the two stage scrolling that is too fast or too slow.

[TFM]

On Scrolling Note, Hopping Mad by Elite has a nice scrolling style that graduates well , it would have been nice to have been implemented in Uridium in stead of the two stage scrolling that is too fast or too slow.

Ja, that's very true. 4 speed wouldn't have been a problem for the CPC. But it was a speccy port. Would be nice to see an Easter Egg 128 KB Uridium one day.

[Puresox]

Have you seen Hopping Mads scrolling? Btw

[TFM]

Honestly not, but let me just walk over to CPC-Power and take a look... will be back in a minute 


Looks like it hat 25 fps and 1 Pixel MODE 1 scrolling, but this is just by eyeballing it.