12-Color Tile/Character mode?

[PacManPlus]

Hi Guys:

 

I wanted to start on a game with more colors in the background so I was thinking about 160B (12-color mode), but quickly realized that you cannot fill the screen with this mode... The bit setting in the control register is either one or two bytes for each character read, which would not be enough for a tile in 160B mode (you would need 4).

 

Am I correct in assuming that I have to use 160A for background/tile/character mode and can only use 160B for sprites? Or am I missing something?

 

Thanks for the help,

Bob

[GroovyBee]

Dungeon!, Apple Snaffle, Wasp! and Worm! all use 160B for the backgrounds. Dungeon! is an 8 way scrolling engine, Apple Snaffle 4 ways and Worm 2 ways, so its possible to scroll too.

[PacManPlus]

Nevermind - I think I was getting confused with the number of characters read in character mode with the number of bytes needed per pixel in 160B mode.

I have some experimenting to do.

 

Thanks anyway,

Bob

[kenfused]

Beef Drop and b*nq both use 32 character wide 160B double character mode. Beef Drop uses 160A for all sprites, b*nQ uses 160A for most sprites and 160B for b*nq and Snakey.

[PacManPlus]

OK, then I am confused. How do I get a full screen Character Mode, in 160B, using double character mode in the CTRL?

 

This is my CTRL:

GRAPHON   =	 $50					;CTL VALUE FOR 160 MODE GRAPHICS. TWO CHAR MODE WIDTH

 

This is my DL:

DLISTS
	 .byte	 $00,$E0,			 $00,$40+$00,#LEFTSIDE ;SCREEN - PLAY FIELD
	 .byte	<(STAMPS), $C0,>(STAMPS), $00+$1C,OFFSCRN   ;PLAYER 1
	 .byte	<(STAMPS), $C0,>(STAMPS), $00+$1C,OFFSCRN   ;ENEMY OR OBJECT, DEPENDING ON TYPE
	 .byte	<(STAMPS), $C0,>(STAMPS), $00+$1C,OFFSCRN   ;ENEMY OR OBJECT, DEPENDING ON TYPE
	 .byte	<(STAMPS), $C0,>(STAMPS), $00+$1C,OFFSCRN   ;ENEMY OR OBJECT, DEPENDING ON TYPE
	 .byte	<(STAMPS), $C0,>(STAMPS), $00+$1C,OFFSCRN   ;ENEMY OR OBJECT, DEPENDING ON TYPE
	 .byte	$00,$00,$00,$00,$00
SDLIST
	 .byte	 <(SCRSCOR),$60,>(SCRSCOR),$20+$00,#$10	   ;SCORE DLIST
	 .byte	 $00,$00,$00,$00,$00

 

This is the screen I get:

 

So, GB, you are saying you get a Character Mode that fills the screen, that you can scroll in any direction? I don't think that is even possible with the constraints of the display list.

Even if you only use the 32 Characters that you are allowed (again, in 12-color Character Mode), that means you have to waste a sprite on either side to hide the scrolling. That leaves you with, what, three 12-color objects on the screen at once before you max out Maria?

 

I just don't see how it's possible. Is there any kind of example that you are able to show?

Thanks,

Bob

[GroovyBee]

I just don't see how it's possible. Is there any kind of example that you are able to show?

 

Its certainly possible. Worm! has near full screen 160B character based scrolling left/right. Apple Snaffle has one 160B area that is 32 characters wide with up/down/left/right scrolling, masked at the left/right edges with multiple sprites per zone layered on top. Dungeon! has 8 direction scrolling with near full screen 160B too.

[PacManPlus]

I see.

 

Being that it looks like I have to guess, you consider "near full screen" 32 characters, and you keep your sprites zone separated... So I wasn't wrong that it isn't possible to have more that three 160B sprites *in the same zone* against a 160B background, while keeping two sprites to hide the scrolling on either side.

 

Thanks for your help.

[GroovyBee]

Being that it looks like I have to guess, you consider "near full screen" 32 characters,

 

Nope! In the case of Worm! "near full screen" is the whole screen (41 characters wide) apart from the 8 pixel high status line at the bottom. Whereas "near full screen" on Dungeon! is the whole screen apart from 16 pixels at the bottom for a status area.

 

So I wasn't wrong that it isn't possible to have more that three 160B sprites *in the same zone* against a 160B background, while keeping two sprites to hide the scrolling on either side.

 

Cycles get pretty tight in character mode in 160B.

[PacManPlus]

Does someone else who might also know the answer and who is actually *willing* to help let me know how to accomplish this instead of just reading a repeat of "my game can do it"?

 

Thanks,

Bob

Edited February 5, 2012 by PacManPlus

[kenfused]

Nope! In the case of Worm! "near full screen" is the whole screen (41 characters wide) apart from the 8 pixel high status line at the bottom. Whereas "near full screen" on Dungeon! is the whole screen apart from 16 pixels at the bottom for a status area.

 

So with a 320B, 41 total character wide character mode (or are you using a bitmap mode), how many 320A or 320B sprites say 8 pixels wide can you get?

[GroovyBee]

So with a 320B, 41 total character wide character mode (or are you using a bitmap mode), how many 320A or 320B sprites say 8 pixels wide can you get?

 

In terms of MARIA cycles.

 

For 320B fetching 41 characters in dual character mode will take :-

 

2x8 - 4 byte DL headers (one for 20 bytes and another for 21).

41x3 - read the indexes for the graphics data.

82x3 - read the graphics data.

 

385 MARIA cycles to get the background. I tend to work to a safety net upper limit of of 417 MARIA cycles so that would leave 32 cycles for sprites. For 8 pixel wide sprites you'd need :-

 

1x8 - 4 byte DL header

2x3 - read graphics data

 

14 cycles per sprite

 

So you'd be able to display 2 eight pixel wide sprites per zone.

 

That is pretty much what it comes out to when I did some experiments in 320B a couple of years ago.

Edited February 5, 2012 by GroovyBee

[kenfused]

Doh. I meant 160B but guessing it would be the same since it just trades resolution for color and we are fetching the same number of bytes.

 

 

And bitmap would need another header (since we can't do the double wide thing) but get rid of the character fetches?

 

3x8 - 4 byte DL headers (three for 27 bytes). Maybe could use 3 bytes headers?

82x3 - read the graphics data.

 

270 MARIA cycles to get the background?

Edited February 5, 2012 by kenfused