Ideas - Guidelines for Programming games

[db6128]

We should not compromise a game that uses colour by allowing it to be played on a monochrome monitor, there is no excuse for not having a colour monitor.

I know people already responded, but I don't see why you're so against the concept: all it requires is an option before the game to simply change some inks, and it has absolutely no effect upon people who want to use a colour monitor as they will simply not choose the green/mono inks, so I have no idea where this implied damaging "compromise" you mention would come from.

[steve]

I know people already responded, but I don't see why you're so against the concept: all it requires is an option before the game to simply change some inks, and it has absolutely no effect upon people who want to use a colour monitor as they will simply not choose the green/mono inks, so I have no idea where this implied damaging "compromise" you mention would come from.

If someone goes to the trouble of producing graphics using a 4096 colour pallette with sprites and pallette changes to increase the number of colours on screen, it is an insult to demand that those graphics be identifiable in shades of green.

[db6128]

Firstly, no one is "demanding" anything; this is only a set of guidelines by a few users on one website, and to act as though they're going to enforce is and like it's "an insult" seems very excessive to me.

Secondly, I was under the impression that we were not talking about Plus-specific extensions, seeing as the bulk of the conversation is looking for ways to make games accessible by all CPC owners, including those with 'just' a 464. In the context of the Plus, I guess it's up to the artists whether they want to provide amended, mono-friendly versions of their graphics. With regard to the non-Plus CPCs, however, re-mapping a few inks to ensure that all pixels are visible to appropriate degrees on a monochrome screen is so easy that I – me, personally, no nasty body of freedom-hating CPC Enforcers – can't really think of any excuse for not taking the few minutes necessary to do it, especially in this day and age where editing and programming are so much easier for all.

[arnoldemu]

Yes the information is for guidance only.

This means you can use the information if you want or choose to ignore it.

Much of it is I think fairly good information that can be used to improve a game and make it more accessible.

[arnoldemu]

As db6128 says, none of it is enforceable.

[TFM]

* If a game needs a specific configuration (e.g. 128K minimum) and it is loaded on a machine that doesn't have this configuration, it should tell the user and not allow them to continue.

The same thing should be done for different environment, but I don't like to go into detail.

[mr_lou]

Can someone set up a "Good Practice" conversion service? 

Here I thought I should play a little Rainbow Islands just now, but since I can't jump using FIRE 2 button, then it's useless with a gamepad. And I want to play using a gamepad.

Another annoying thing when the CPC is standing far away, and you're using an extension cord for the gamepad, is those intros that requires you to press SPACE or F-keys first. Get rid of those too in the process.

[TFM]

Can someone set up a "Good Practice" conversion service? 

For a conversion? That's easy! :-DDD ... ... ...

DO IT FROM SCRATCH!!!

Anything else is more or less just a lousy speccy port

[mr_lou]

Which parts of the guidelines would require doing it from scratch?

I'm personally mostly interested in the gamepad hacks. Rainbow Islands has mapped both FIRE1 and FIRE2 for the rainbows. Changing FIRE2 so that it maps to jumping shouldn't be a big job.
The game already starts by joystick, so no need to change anything there.
It's not using overscan, so no need to do anything there either.

[arnoldemu]

Which parts of the guidelines would require doing it from scratch?

I'm personally mostly interested in the gamepad hacks. Rainbow Islands has mapped both FIRE1 and FIRE2 for the rainbows. Changing FIRE2 so that it maps to jumping shouldn't be a big job.
The game already starts by joystick, so no need to change anything there.
It's not using overscan, so no need to do anything there either.

Depending on the amount of free ram, these small modifications are much easier.
I was thinking the same, but at the moment I don't have any free time and I already have some projects lined up.

[TotO]

I'm personally mostly interested in the gamepad hacks.
Rainbow Islands has mapped both FIRE1 and FIRE2 for the rainbows.
Changing FIRE2 so that it maps to jumping shouldn't be a big job.

I suggest you to learn how to do that yourself, so you can actively contribute.

[mr_lou]

I suggest you to learn how to do that yourself, so you can actively contribute.

I'm gonna stick to music. That's my contribution.

[TFM]

Which parts of the guidelines would require doing it from scratch?

Not the guidelines, the game! The guideline is: "Do the game from scratch", which means don't do a speccy port.

And to confuse you a bit more, this is the reason for the From Scratch Demo being so beautiful

[TotO]

Not posted here, but it should be interesting to take care about memory expansions for handling a double buffer and avoid flickering.
Here, an easy way to achieve that for any programmers. (supported by DK'Tronics compatible boards)

CPC 64K:
0 1 2 3 (C0, access bank1 / screen written while displayed)

CPC 64K + EXP:
0 P 2 3 (C7, write buffer2 / buffer1 displayed)
0 1 2 3 (C0, access bank1 / buffer1 displayed)
0 3 2 P (C3, write buffer1 / buffer2 displayed)
0 1 2 P (C1, access bank1 / buffer2 displayed)

Just take care to not store the GFX data to the same address range, else you can't access it for filling the buffers.