CPCWiki forum

General Category => Programming => Topic started by: cpc4eva on 10:30, 26 January 11

Title: screens and modes
Post by: cpc4eva on 10:30, 26 January 11
is it possible to utilise the full cpc screen in games ?


i always feel jaded that the three screen size modes- mode 0, mode 1, mode 2 limited the cpc
Title: Re: screens and modes
Post by: arnoldemu on 10:42, 26 January 11
Quote from: cpc4eva on 10:30, 26 January 11
is it possible to utilise the full cpc screen in games ?


i always feel jaded that the three screen size modes- mode 0, mode 1, mode 2 limited the cpc
in terms of removing the visible border?

Yes.

For static screens the type of overscan that uses a 22k (approx) screen can be used.
You reduce the amount of ram available for the game and graphics, but it's still possible and some games use the extra 64k of the 6128 to compensate. With this sized screen you can do double buffering, but then you've got almost no main ram free.

For scrolling screens you need to use demo techniques to split the screen into two parts which then cover the display.
You can then scroll these. Same problems as the static screen in terms of amount of ram lost.

So yes, it is possible.

I choose not to use this sized screen at this time because I like to make all my games run in 64k minimum.
But perhaps in the future I will use this size screen.

EDIT: Some games that use this overscan display:

Sudoku master
Return of the sisters
Groops

There are others but I don't remember them at this time.
Title: Re: screens and modes
Post by: AMSDOS on 06:56, 27 January 11
I remember mentioning the Public Domain games Axys and I think Plumpy before which in the case of Axys has an overscan screen during the loading phases along with Scrolling Text at the bottom. Plumpy has a Titled Screen which also has scrolling text and some Rasters at the top and bottom, both quite neat. The games themselves I'm not so sure it's full screen overscan, though for me the effect is still quite stunning and just as good (even if some memory is being spared), because Axys is scrolling from top to bottom (since it's basically a PD version of Light Force), the top/bottom effect looks quite good. Plumpy likewise does the same, though doesn't involve any scrolling, each level though fills the screen top/bottom, though both don't cover the left/right side of the screen, though they don't really need to!  ;D
Title: Re: screens and modes
Post by: fano on 22:03, 27 January 11
Another game in fullscreen/overscan : Red&Blue (http://www.cpc-power.com/index.php?page=detail&num=3405)
Title: Re: screens and modes
Post by: TFM on 22:58, 27 January 11
Quote from: cpc4eva on 10:30, 26 January 11
is it possible to utilise the full cpc screen in games ?

Yes, look here:

http://www.youtube.com/watch?v=6_RbO0Vm-AA (http://www.youtube.com/watch?v=6_RbO0Vm-AA)

and here:

http://www.youtube.com/watch?v=MavWmgzr2P8 (http://www.youtube.com/watch?v=MavWmgzr2P8)

and probaby much more ;-)
Title: Re: screens and modes
Post by: eliot on 23:03, 27 January 11
Some other examples for this usual topic:  
Inferno : http://www.cpc-power.com/index.php?page=detail&num=3876 (http://www.cpc-power.com/index.php?page=detail&num=3876)

Xyphoes Fantasy : http://www.cpc-power.com/index.php?page=detail&num=1433 (http://www.cpc-power.com/index.php?page=detail&num=1433)

Karatian : http://www.cpc-power.com/index.php?page=detail&num=3625 (http://www.cpc-power.com/index.php?page=detail&num=3625)
Les Mondes Parallèles: http://www.cpc-power.com/index.php?page=detail&num=76 (http://www.cpc-power.com/index.php?page=detail&num=76)

Burger Party : http://www.cpc-power.com/index.php?page=detail&num=3668 (http://www.cpc-power.com/index.php?page=detail&num=3668)
Cyborgs : http://www.cpc-power.com/index.php?page=detail&num=3586 (http://www.cpc-power.com/index.php?page=detail&num=3586)
And a prototype called Killing Fist we have already debated about in this Forum : http://www.cpc-power.com/index.php?page=detail&onglet=goodies&num=1248 (http://www.cpc-power.com/index.php?page=detail&onglet=goodies&num=1248)
Title: Re: screens and modes
Post by: MacDeath on 08:09, 28 January 11
Get a fullfullscreen is not always suitable for a game.

As told, this may use something like 22-32K or Ram... and then the CPU is seriously limited in power.

Was on the other hand a common feature in Demos of course.

to get this with a scrolling game may be some sort of nightmare.

A solution is more like to get horizontal fullscreen or vertical fullscreen.
So you still have a border but it is limited to only 2 borders..

Some commercial games in almost full screen ?

-Arkanoid 1&2 (best exemples of this done right...)
-Donkey kong
-Ghoul's and Ghost (almost scrolling...)
-Titan (from Titus)

PrehistorikII is horizontal if I remember well  (so may be superCauldron then...)

Shinobi actually display a few text pages in vertical fullscreen.

Cartridges games also feature fullscreen still pictures (Wild street or Fire and forget2 per exemple)

This technic can be great for non scrolling games with simple graphical content...
Tetris like games or various puzzle games per exemple.

Also it is quite "common" for craked games to get cracktros or intropicture in Fullscreen.

the main advantage with "limited fullscreen" (lol) or redimensionned screen sizes is that it may enable to get a "VideoRAM" weighting the same as normal one...
And it gets the Demo flavour or removethe reduced screen feeeling.

An exemple is the underused 256x256 resolution...
Most speccy ports were 256x192 but they should/could have been 256x256 with a real CPC code.
Title: Re: screens and modes
Post by: cpc4eva on 13:25, 28 January 11

for example say it was a basic game like the link ive posted below for misslie command atari 2600


http://www.youtube.com/watch?v=Z4zF790DzyQ (http://www.youtube.com/watch?v=Z4zF790DzyQ)


would it be possible to display full screen and have the game area include the borders so in affect there was no border at all ?




would it be possible to alter the cpc motherboard to develop a new screen or mode or is that just way out of the question ?
Title: Re: screens and modes
Post by: cpc4eva on 13:31, 28 January 11
Quote from: eliot on 23:03, 27 January 11
Some other examples for this usual topic:   
Inferno : http://www.cpc-power.com/index.php?page=detail&num=3876 (http://www.cpc-power.com/index.php?page=detail&num=3876)

Xyphoes Fantasy : http://www.cpc-power.com/index.php?page=detail&num=1433 (http://www.cpc-power.com/index.php?page=detail&num=1433)

Karatian : http://www.cpc-power.com/index.php?page=detail&num=3625 (http://www.cpc-power.com/index.php?page=detail&num=3625)
Les Mondes Parallèles: http://www.cpc-power.com/index.php?page=detail&num=76 (http://www.cpc-power.com/index.php?page=detail&num=76)

Burger Party : http://www.cpc-power.com/index.php?page=detail&num=3668 (http://www.cpc-power.com/index.php?page=detail&num=3668)
Cyborgs : http://www.cpc-power.com/index.php?page=detail&num=3586 (http://www.cpc-power.com/index.php?page=detail&num=3586)
And a prototype called Killing Fist we have already debated about in this Forum : http://www.cpc-power.com/index.php?page=detail&onglet=goodies&num=1248 (http://www.cpc-power.com/index.php?page=detail&onglet=goodies&num=1248)






what can i say but WOW :)  cpc looks so much more improved with full screen in use.


full screen and colour some really impressive work for cpc are they all cpc or cpc+ ??


is killing fist released / going to be released ?
Title: Re: screens and modes
Post by: arnoldemu on 13:31, 28 January 11
Quote from: cpc4eva on 13:25, 28 January 11
for example say it was a basic game like the link ive posted below for misslie command atari 2600


http://www.youtube.com/watch?v=Z4zF790DzyQ (http://www.youtube.com/watch?v=Z4zF790DzyQ)


would it be possible to display full screen and have the game area include the borders so in affect there was no border at all ?
Yes.

If you also mean "can I write a game in basic using this mode?" then the answer is not easily, and then you would need some firmware functions patched so that they could take into account the new dimensions.
The best place to locate this screen and keep firmware happy is around &0000-&7ffff! Just where basic likes to be ;)

Quote from: cpc4eva on 13:25, 28 January 11
would it be possible to alter the cpc motherboard to develop a new screen or mode or is that just way out of the question ?
Well the aleste does something like this.

The possibilities are to take the existing colour modes, and just increase or decrease the resolution, to do that you need to change the clock of the gate-array, and perhaps the whole system.
I'm not sure how possible this is with the cpc design.
Title: Re: screens and modes
Post by: eliot on 15:58, 28 January 11
Quote from: cpc4eva

what can i say but WOW :)  cpc looks so much more improved with full screen in use.

full screen and colour some really impressive work for cpc are they all cpc or cpc+ ??

is killing fist released / going to be released ?

Only Burger Party is for PLUS only. Others are for CPC and PLUS. 

Killing Fist won't be released, it's an old  (1992?) german-french cooperation project. We have already discussed about it here or on the old CPC zone forum... I can't remember.

A lot of games could be (have) done in fullscreen, especially the numerous board games!!! Adding rasters or mode-changes on a screen could be more frequent, like these recent releases :  http://www.cpc-power.com/index.php?page=detail&num=4567 (http://www.cpc-power.com/index.php?page=detail&num=4567) or http://www.cpc-power.com/index.php?page=detail&num=4970 (http://www.cpc-power.com/index.php?page=detail&num=4970)

I like the idea that a CPC game uses the specific CPC features... 

Eliot
Title: Re: screens and modes
Post by: MacDeath on 17:39, 28 January 11
Quotewould it be possible to alter the cpc motherboard to develop a new screen or mode or is that just way out of the question ?
If you alter the motherboard you can even turn a CPC into a Sega MegaDrive... (using a Z80 too... sort of...)
:laugh:


But yeah a game like the coldwar panic on Atari2600... there is no scrolling, so yeah this may run in fullscreen with no border...
Would look better in 128K Ram though... or Cartridge perhaps.

But it's not like there are a lot of graphics to be used... oh ok it is an Atari2600...

The full screen is great in mode0 as the wide pixels are dwarfed by the extended screensize... you can get a less blocky feeling...because you have more space to display your graphics and can make them bigger.


But a non-tile based full screen picture is a lot of RAM for a CPC464 per exemple.

Another aspect to watch is the monitor...
the maximum of displayed pixels may depend wether your is hot or not, or from monitor to monitor
Title: Re: screens and modes
Post by: TFM on 19:46, 28 January 11
Quote from: MacDeath on 08:09, 28 January 11
Get a fullfullscreen is not always suitable for a game.

As told, this may use something like 22-32K or Ram... and then the CPU is seriously limited in power.

No, if you use two 16 KB screens for example (32 K V-RAM) then this uses not even 0.1% of the cpu power. Twice a second some OUT commands, that's all you have to do.

I don't know why people are afraid of fullscreen? Probably programmers are to lazy to use it. Or it's all about that speccy conversions...  :'(
Title: Re: screens and modes
Post by: fano on 20:04, 28 January 11
Quote from: TFM/FS on 19:46, 28 January 11No, if you use two 16 KB screens for example (32 K V-RAM) then this uses not even 0.1% of the cpu power. Twice a second some OUT commands, that's all you have to do. 
I don't know why people are afraid of fullscreen? Probably programmers are to lazy to use it. Or it's all about that speccy conversions...  :'(
For sure , on a 128K machine , it is interesting to use hard scroll.If it takes too much memory , it is possible to use lower values than 7 on R9 to save 2*2K per line.
One problem is it needs to be a 1 or 2 byte scroll , not 1 pixel scroll.
Another reason is you need to fully master CRTC adressing to feed the scroll and to draw sprites , thing that is not obvious.
Title: Re: screens and modes
Post by: redbox on 20:10, 28 January 11
Quote from: fano on 20:04, 28 January 11
Another reason is you need to fully master CRTC adressing to feed the scroll and to draw sprites , thing that is not obvious.

It's been said before and you're right again fano, the real b*tch is not scrolling it (yes TFM, it's easy) but calculating everything again once you've scrolled it.
Title: Re: screens and modes
Post by: fano on 20:32, 28 January 11
Exactly , i noticed a lot of people got problems to understand that (including myself until Longshot explained it and made things clear as crystal for me) and i think we lack of documentation about this.I'd like to write an article on wiki about this (and some other things about tile based rendering) when i'll have more free time.
Title: Re: screens and modes
Post by: cpc4eva on 20:47, 28 January 11
thanks for the link eliot - that colour lines loading screen is so detailed the resolution and colour palette reminds me of purple saturn day loading screen c64 resolution and colour palette nowhere near the cpc's but thats off topic and being discussed elsewhere...




skweek, 1942, flying shark, 1943, are just a few of the cpc games that come to mind that use a very small playing area and to see the links people have posted with cpc full screen being used is remarkable as it is very capable of doing it with or without scrolling. expecially with detailed sprite games like xyphoes fantasy and prehistorik II


macdeath your a funny man just want to see if its possible for the cpc motherboard to be moded in any way not turn it into a sega  mega drive :)
Title: Re: screens and modes
Post by: cpc4eva on 20:48, 28 January 11
Quote from: fano on 20:32, 28 January 11
Exactly , i noticed a lot of people got problems to understand that (including myself until Longshot explained it and made things clear as crystal for me) and i think we lack of documentation about this.I'd like to write an article on wiki about this (and some other things about tile based rendering) when i'll have more free time.




that would be really helpful :)
Title: Re: screens and modes
Post by: redbox on 21:26, 28 January 11
Quote from: fano on 20:32, 28 January 11
I'd like to write an article on wiki about this (and some other things about tile based rendering) when i'll have more free time.

That would be great!

But please finish R-Type first (some things are more important  ;) ).
Title: Re: screens and modes
Post by: TFM on 21:42, 28 January 11
Maybe the biggest problem here is indeed a lack of docs. However, it may make some sense to use a piece of paper and write down your strategy before you start coding...

Introduce a bunch of pointers and offset variables. Finally they also can be adjusted pretty easy.

However, it's not that easy to provide a general solution, since every kind of overscan and / or fullscreen needs slightly different formulas.
Title: Re: screens and modes
Post by: AMSDOS on 22:58, 28 January 11
arnoldemu wrote:

Yes.

If you also mean "can I write a game in basic using this mode?" then the answer is not easily, and then you would need some firmware functions patched so that they could take into account the new dimensions.
The best place to locate this screen and keep firmware happy is around &0000-&7ffff! Just where basic likes to be ;)


From memory I think there was something in AA98 which had all sorts of tricks and tips and an assortment of useful pokes and there were a few to poke where BASIC programs were situated in memory. I think the problem you would run into once you've done that, is the Overscan screen is situated at &0000 to &7fff and it's overwriting that Low-ROM area - based at 0 to &3F. Disabling Interrupts would resolve this, but then your firmware routines have just been disabled, though to be dealing with Overscan stuff you'll probably need specific routines anyway. It maybe just possible to pull it off in BASIC, though it's not really well suited for it!  ???
Title: Re: screens and modes
Post by: sigh on 03:35, 29 January 11
I was thinking about screens in regards to modes and colours earlier today. I'm wondering that if you were only to use 8 colours in mode 0 instead of the full 16 colours I assume this would result in less ram being used.  I also assume that the use of ram would be only slightly bigger than using a 4 colour mode 1.

Please correct me if I'm wrong.

It's just that I've been thinking recently that creating games in 4 colours only leaves   3 for sprites as you need one for transparency. If you had 5 colours   instead it would have to use mode 0 - but how much difference in ram   would it make compared to using 4 in mode 0?


 
Title: Re: screens and modes
Post by: AMSDOS on 05:28, 29 January 11
The screen memory is around 16Kb whichever way you look at it. With the colours though they are represented as bits and each byte can consist of a number of colours.

I can demonstrate this better in this little program:


org &8000

ld hl,&c000
ld de,&4000
ld bc,&004f
ldir
ret


Assemble that into memory, Lets say for example I poke &C000 with &FF type this in:


10 poke &c000,&ff
20 call &8000
30 print hex$(peek(&4000),2)


Obviously it will return FF in hexidecimal. But if I do something like this:

10 MODE 1:PLOT 0,399,3:CALL &8000:CALL &BB18
20 print hex$(peek(&4000),2)


All of a sudden the value returned is 88 in hexidecimal. How it works in that example above is merely one little pixel is a fraction of a whole byte. In mode 1 a byte is represented as 8 pixels, that byte consists all the information as to what's being displayed, in the case of saving memory by not using all the colours you wouldn't be significantly reducing it, reducing the size of visible screen would definitely cut down on more RAM. On the other hand taking something in a certain mode and compressing it may cut down on the amount of RAM being used. As a rule, a compressor will cut down the amount of memory being used on a screen if there's a lot of consistancy to it, images which tend to alternatate between colours will ultimately use more memory.

So the difference between the number of colours being used on an Amstrad is minimal cause it's coded in as Bytes anyway. Uncompressing images as I mentioned above is more for Displaying Screens, not ideal for within games, though I've heard of people using compressed sprites in Minigame productions - obviously one would uncompress the image and have it as uncompressed in their game.
Title: Re: screens and modes
Post by: fano on 07:49, 29 January 11
Quote from: sigh on 03:35, 29 January 11
I was thinking about screens in regards to modes and colours earlier today. I'm wondering that if you were only to use 8 colours in mode 0 instead of the full 16 colours I assume this would result in less ram being used.  I also assume that the use of ram would be only slightly bigger than using a 4 colour mode 1.

Please correct me if I'm wrong.
Yes , that would be smaller but that would be an infamous mess.As your data would be 3 bits , you'll need to stream bits to rebuild color indices on 4 bits.That would be a slow process as your data would not be aligned on 8bits boundary (only every 8 bytes and 4bits aligned every 4 bytes)
3bits mode 0 graphics would be 1/4 lighter than 4bits mode 0 or mode 1.There are no differences in size between modes because if you use twice pixels , you'll have half colors so the result is the same.

Quote from: sigh on 03:35, 29 January 11It's just that I've been thinking recently that creating games in 4 colours only leaves   3 for sprites as you need one for transparency. If you had 5 colours   instead it would have to use mode 0 - but how much difference in ram   would it make compared to using 4 in mode 0?
This is a game that uses 4 colors graphics on a full 16 colors (and more?) display , internal gfx takes half size than 16 colors graphics : http://www.cpc-power.com/index.php?page=detail&num=143 (http://www.cpc-power.com/index.php?page=detail&num=143)
It is not possible to store only 5 colors because each bit mutiply by 2 the amount of possibles colors like 2,4,8,16,32 and so on.
Title: Re: screens and modes
Post by: sigh on 12:52, 29 January 11
Quote from: CP/M User on 05:28, 29 January 11
As a rule, a compressor will cut down the amount of memory being used on a screen if there's a lot of consistancy to it, images which tend to alternatate between colours will ultimately use more memory.

Okay - I'll remember this. Thanks.

Quote from: fano on 07:49, 29 January 11
Yes , that would be smaller but that would be an infamous mess.As your data would be 3 bits , you'll need to stream bits to rebuild color indices on 4 bits.That would be a slow process as your data would not be aligned on 8bits boundary (only every 8 bytes and 4bits aligned every 4 bytes)
3bits mode 0 graphics would be 1/4 lighter than 4bits mode 0 or mode 1.There are no differences in size between modes because if you use twice pixels , you'll have half colors so the result is the same.

So even though using 8 colours would be less ram, it would actually be slower to use than 16 mode 0 or 4 mode 1?
Damn. I seem to be constantly failing every single time to find ways of reducing the amount of ram and cpu when handling modes.
Thanks for the info.
Title: Re: screens and modes
Post by: fano on 13:04, 29 January 11
Quote from: sigh on 12:52, 29 January 11
Okay - I'll remember this. Thanks.

So even though using 8 colours would be less ram, it would actually be slower to use than 16 mode 0 or 4 mode 1?
Damn. I seem to be constantly failing every single time to find ways of reducing the amount of ram and cpu when handling modes.
Thanks for the info.
I think.4 colors would divide per 2 the size of graphics.If 3+transparent colors is not acceptable , a solution could be to split sprites in 4*8 mode 0 tiles and to use a 512 bytes aligned and interlaced table to convert bytes on the fly to 16 colors.You could take advantage of non masked parts and mask only when it is needed.
Anyway , closer is your rendering code from native CPC render format , faster it is.
Title: Re: screens and modes
Post by: sigh on 13:33, 29 January 11
Quote from: fano on 13:04, 29 January 11
I think.4 colors would divide per 2 the size of graphics.If 3+transparent colors is not acceptable , a solution could be to split sprites in 4*8 mode 0 tiles and to use a 512 bytes aligned and interlaced table to convert bytes on the fly to 16 colors.You could take advantage of non masked parts and mask only when it is needed.
Anyway , closer is your rendering code from native CPC render format , faster it is.

That seems like an incredible amount of programming hassle :laugh: !

Thanks
Title: Re: screens and modes
Post by: fano on 14:00, 29 January 11
Why doing simple when you can make it complicated (this is my motto)  :laugh:

To help you a bit :
(http://pharmacie-clemenceau.com/images/ASPIRINE.jpg)
Powered by SMFPacks Menu Editor Mod