Screens frComputer Games:

[PeteD]

 

I really think you can do this (in PAL at least) with a fairly conventional character based sprite system and a nice PM multiplexer

 

Agreed, as I said there are lots of cases for non-masking drawing which saves a fair bit per sprite. Even on that snakey thing I posted a YT link to earlier you can draw 1/2 the sprites without masking and the other 1/2 on top of them.

 

 

Pete

[José Pereira]

Hello people.

 

I've been wondering in this:

O.K., possible Underlays but I think you're forgetting something:

Underlays would be great with same sprite square size, like 9Horiz.(in Double)x21 Vertical.

But they change sizes accordind to movement. And now you'll have to probably create something like 8/10 diferent squares for each EnemyShip:

 

Here you see different types of Enemys, but if they were just one type you'll get more or less this nº of shapes/sizes.

Create Undrelays in DoubleSize but 3,4,5,6Horiz. and many different vertical. What would you do here?

 

 

Thanks.

Greetings.

José Pereira.

[PeteD]

The vertical size isn't a problem, in fact depending on how the PM code is written the smaller they are the faster the code will be. Horizontal size changes are also possible. What would be needed is a width/height table for each frame, something that can be automated either with some PC code or when the game runs. The width is just a case of deciding what byte to write into the PM so only needs to be done once per sprite, the height is how many lines of that byte to write to the PM.

 

There are more subtleties to it depending on how the clear/draw routine is written or if ignoring the width, does the code do a clear/draw at all or a timer based X move or dma change. There are quite a few ways to do it but everything like that depends on how far/fast the sprites move in Y.

 

*edit*

Just to make it clear to José. It's not "creating" the squares as much as them basically being a byte for the width and an "amount" of bytes for the height. It can all be done with code as the PMs are being drawn.

 

 

Pete

Edited March 18, 2010 by PeteD

[José Pereira]

The vertical size isn't a problem, in fact depending on how the PM code is written the smaller they are the faster the code will be. Horizontal size changes are also possible. What would be needed is a width/height table for each frame, something that can be automated either with some PC code or when the game runs. The width is just a case of deciding what byte to write into the PM so only needs to be done once per sprite, the height is how many lines of that byte to write to the PM.

 

There are more subtleties to it depending on how the clear/draw routine is written or if ignoring the width, does the code do a clear/draw at all or a timer based X move or dma change. There are quite a few ways to do it but everything like that depends on how far/fast the sprites move in Y.

 

*edit*

Just to make it clear to José. It's not "creating" the squares as much as them basically being a byte for the width and an "amount" of bytes for the height. It can all be done with code as the PMs are being drawn.

 

 

Pete

 

 

Thanks, but a little/many technical explanation. I understand some things, but by now, just answer this:

 

"Start with a Underlay of 6Double Horiz. x 21 Vertical and what follows? 3Doublex21->4x21->12x6 and so on... according to the movement of the SoftSprite?"

 

Thanks.

José Pereira.

[José Pereira]

Like I said yesterday I've center the Screen on A8 and add PF3 on the StatusPanel (just add to 48Wide on the end).

But I also said that I was trying diffrent colour/Lumin. that can look good on the Large SpaceShip but also with Ored colours on the Enemys.

And because of Todays Posts, I think I also get some solution to the different shapes of PMs.

I decided (and would look better and can work, untill now) that when having two different type of Enemys, one type as SoftSprite only and the other as SoftSprite+PMs. underlays. With this you would get less nº. of shapes of each PM.

In this case only for the Circles:

 

I also play with some PF3 adding on the Backgr.

I am using PF3 only on Enemys because they don't overlap Backr. graphics.

Our two Ships will come later, but will only have PF0-Black and PF1-LighestGray with PM0&1 Ored PF1 (I'll get 4colours) and they can go over the Backgr. (and above) without colour clash.

About our two Ships I'll have to create diffrent shapes, but they probably wouldn't have many (I think...)

 

Greetings.

José Pereira.

[PeteD]

 

Thanks, but a little/many technical explanation. I understand some things, but by now, just answer this:

 

"Start with a Underlay of 6Double Horiz. x 21 Vertical and what follows? 3Doublex21->4x21->12x6 and so on... according to the movement of the SoftSprite?"

 

Thanks.

José Pereira.

 

Basically, yes The maximum size of 1 unexpanded C64 sprite can be covered with 1 6 pixel 2x expanded player. So you can basically have sizes of player of the equivalent of 6,5,4,3,2,1 expanded 2x and then 8,7,6,5,4,3,2,1 unexpanded (obviously some of those are the same). Of course with the expanded player it isn't as accurate as the c64 sprite can be because you're limited to 12 then 10 then 8 etc multicolour "pixels" or "clocks" where the c64 can do 12,11,10,etc but I don't think that's too bad and is only a problem while the c64 sprite is wider than 8 pixels/clocks.

 

Ignore the "movement" of the software sprite, it's the size/width of it that's important.

 

 

Pete

Edited March 18, 2010 by PeteD

[TMR]

Ignore the "movement" of the software sprite, it's the size/width of it that's important.

 

i believe i'm obliged to go "fnarr fnarr" at this point.

[José Pereira]

Ignore the "movement" of the software sprite, it's the size/width of it that's important.

 

i believe i'm obliged to go "fnarr fnarr" at this point.

 

 

[PeteD]

http://en.wikipedia.org/wiki/Finbarr_Saunders

 

 

Pete

[José Pereira]

From this example you'll see some of Overlap and of Pfs. using Underlays.

One Snake it's PF2-Green and the other PF3. They can move without "clashing eachother, soo, no problem here.

 

I put P2Undrelay on one and P3 on the others Heads.

I've also trying something at PM0&1 in our two Space Ships.

 

See C64 and A8 (to better see that overlapping pixels):

 

 

Yeah, probably not noticable (it's only 2squares underlay on the two Heads and only inside their limits).

 

 

Suggestions/ideas?

 

 

Thanks and greetings.

José Pereira.

[José Pereira]

Hello people.

 

Just take the Sprites from C64 (ours and Level2), soo that you can see the number of each shapes (not many):

 

José Pereira.

[José Pereira]

It's a long, long way.

 

 

With the "Ripping" Sprites from each Level I am choosing the colours of each Large SpaceShip so that can be good IMHO in Enemy Ships using PRIOR0.

Even if some would be only SoftSprites I must have the colours that can match with the backgr. graphics and also on the PMs. underlays using PRIOR0.

Many, many Large Spaceships and colours/Luminances to try on all Game, but possible!...

 

 

This example Screen is from a Level2 and all the Enemys differnt shapes.

At the Top Left and Right are the SoftSprites with PMs underlays.

At the bottom the same shapes, but only Backgr./PF1&PF3.

This is because sometimes they could be SoftSprites and other times with PMs. Underlays. This is another great trouble, as they have to look good IMHo on screen when are side-by-side and With or without PMs. Undrelays.

But they can as, Soft Sprites (or Underlays have diffrent colours, if they are in changing DLI Lines, and again another trouble PMs./PFs. DLIs. only when the last is off the Screen. But later, when all Sprites are remaked I'll do a Map, like for Ex. OpenSpace with Attacking Wave and go off the screen in Lines that I can now change the colours of PFs. to in-coming Large SpaceShip, or if possible, tottally off the Screen. Difficult to explain but not very different from what C64 does...):

 

Comments/Suggestions/ideas always welcome.

 

 

 

Greetings.

José Pereira.

[José Pereira]

Here I am again.

 

I've re-paint the same Enemys with the colours/Luminances of another Level2 ground graphics (the same way as before):

(probably not the best colour matches this time )

 

 

But what am trying to show here is something I tried on the last Post but in my bad English is always difficult.

Here you see the two screens joined (like if was one after the other when you play the Game...):

 

In middle of the two creens you see that large Black Area. was this I was talking about... I must have first a free OpenSpace (like on C64) untill all the last Ground graphics goes off the Screen.

In this Space empty I can add some DLI to the PFs and/or the Enemys that can be place there, but at the ending the PFs. must be the same in the same Lines as the Entering new Ground Complex.

But the Lines that haven't new Ground can still have the old colour/Luminances so that the last Enemys go off the Screen (with the old Colours/Luminances) in this Lines and start with new Enemys in the new Ground colours.

 

 

Yeah, a little difficult to explain, but I think you see what I am trying to...

 

Greetings.

José Pereira.

[José Pereira]

Ah! Just one more thing that you can see better on the Second Level2 screen example:

Using PF2 on the Ground graphics with just some small PF3 shown (that "pale Green) and than using PF3 in mostly (or even all) the Enemy Ships gives you a feeling of totally differnt colours when they are only Softsprites.

Just see the inside the Red circles (the ones that are only SoftSprites)and also the add of PF3 (Green circles) in the Ground graphics (look good in Ground weapons/XRays/Metalic,...):

 

José Pereira.

[PeteD]

The pale green things on the background are actually hardware sprites on the C64 anyway it's just because they're stationary in relation to the background they look like they shouldn't be.

 

 

Pete

[PeteD]

I think if it's a choice between lots of different DLIs and stuff or changing the game slightly so the enemy sprite waves stop THEN the new screen scrolls on I'd go for the latter. It doesn't really change the dynamic of the game much and makes it a lot easier when refactoring the levels to work on A8.

 

 

Pete

[José Pereira]

The pale green things on the background are actually hardware sprites on the C64 anyway it's just because they're stationary in relation to the background they look like they shouldn't be.

 

 

Pete

 

 

 

The Pale Green on my G2F A8.

José Pereira.

[PeteD]

The pale green things on the background are actually hardware sprites on the C64 anyway it's just because they're stationary in relation to the background they look like they shouldn't be.

 

 

Pete

 

 

 

The Pale Green on my G2F A8.

José Pereira.

 

uh? Those "turret" things.. with the green circles round them.

 

 

Pete

[José Pereira]

I think if it's a choice between lots of different DLIs and stuff or changing the game slightly so the enemy sprite waves stop THEN the new screen scrolls on I'd go for the latter. It doesn't really change the dynamic of the game much and makes it a lot easier when refactoring the levels to work on A8.

 

 

Pete

 

But you don't see the things very clear here.

Even if you stop the Sprites you still need to changing DLIs. because you forgot that the Enemys are SoftSprites and have a different colour when Underlay (PF3) and Backgr.&PF3 if they are just SoftSprites (just see this in my Pictures).

 

You have to be very clever.

The first thing will be: Old Ground Complex off the Screen but left some Sprites of it.

Second: for Ex. move them off the Screen in the Middle.

Third: change DLIs. to new colours at the Top and at the Bottom.

Fourth: enter new Enemys in the Top and Bottom with the new DLI colours.

Fifth: Middle ones are off, now you can have all screen high colours changed to new ones.

 

 

 

This is an example, and it depends. You can do this Top/bottom and Middle DLI diffrent. You can even do that more that one time when they are in OpenSpace Battle.

Just clever movement choose of the Attacking waves.

But as you see you have to doing DLIs. "in progress". Just Stopping SoftSprites it's not the only solution.

 

 

Something like the "Snake(s)", they normally move in Ground Complex(s) that have a large free place on the Middle of the Screen. But you cannot do like C64, they enter in not many, but 1Char Lines of the Ground Complex. You have just to not move 8Pixels there in A8 so that you can change DLIs. at the Middle of the Screen and the Snake have Body colours different. Here you can see that you'll have "going with" many DLIs. changes allong the Game.

In the Snakes it's even one more trick to add. All SoftSprite and only the Head as P2 Underlay. But sometimes it goes off the Screen at the Top. And hgere you have diffrent colours (the Ground). You go with the Head first (P2) and then put P3 (underlay, because Black it's PF0 masks it) in the place it goes off the Screen. With a correct choose of colour/Luminance the SoftSprite Body Snake (Backg./PF1/PF3 or PF2) still have the same colours as before.

 

 

As you can see, the things are my head, join this is a...

 

 

 

Thanks and greetings.

José Pereira.

[José Pereira]

Google "no translation" to Portuguese:

" uh? Those "turret" things.. with the green circles round them. "

 

 

Help translation needed

José Pereira.

[PeteD]

I haven't "forgot" anything

 

If you mean there are fixed areas like 4 chars at the top then 4 at the bottom then that's fine and I understand what you're saying but the levels tend not to be like that and there's no way the sprites don't go into the same areas (char lines) as the background graphics so you can't really do anything extra with DLIs there which is what I'm worried you're attempting to do, like every time there's a clear char line in the background, put a DLI there. That would be bad

 

 

Pete

[PeteD]

Google "no translation" to Portuguese:

" uh? Those "turret" things.. with the green circles round them. "

 

 

Help translation needed

José Pereira.

 

The last image you posted, the "green" circles, you do know green?

 

 

Pete

[Heaven/TQA]

Jose... I love your passion... but you really have a lot of free tme???

[andym00]

Quantify fairly reasonable and simple

 

I don't think it's possible to get anywhere near it with say a PM plexer for the enemy ships, 2 per line hmmm very doubtful so you're still down to how many software sprites you'd need to draw (ignoring any PM under/overlays) and once that's written then it's simple, but fast? There are a fair few "cheat" possibilities for keeping the speed of the sofsprite routine up. It looks like most of the time the enemy sprites don't go over the background so as long as they also don't cross each other you haven't got a lot of masking to do, when they do cross you can at least draw the lower ones first and save a round of masking.

 

If there's going to be any changes in attack waves or numbers of sprites etc then I say forget Armalyte and José should design a game using what he's learned from all this G2F stuff. Use armalyte or whatever graphics for now, they can always be changed later but do something the A8 can handle without having to think about it for a month.

 

 

Pete

 

 

 

I didn't mean using PMs only, but with software sprites and PM underlays..

 

What I meant was one that's viable for game use, that doesn't trade massive of memory (either code-wise or graphics-wise) for performance..

 

For my Galaga & Galaga'88 hybrid stuff I eventually settled on a a nice system based on this method which works really well.. Performance is nice, not the fastest, but offers width and height flexibility without too much setup cost (in fact very low compared to some of the other techinques I played with).. restore cost is very fast using code stubs for each virtual sprite which self modifies, and also makes redundant moving around of variable quite low as well.. And a few other bonuses fell out of the system as well that I didn't expect.. Things like being able to mark regions of the character set as having a foreground mask, so it allows things like the PoP going behind pillars stuff for free, well okay, a few extra cycles per byte when it occurs, but no additional handling required.. And I can see a lot of uses for that in other things, cool things, nothing really practical

 

I tried umpteen other character set attempts, and just settled on this as it seemed to be a nice balance, especially given in for what I want, and what Armalyte would want most of the chars aren't going ot be masked.. I still maintain that Armalyte is very doable with such a simple sprite methodolgy.. The PM multiplexor isn't an issue in this case

 

Anyway, code dump straight from the last working code of this stuff.. Comments might be out of date, but you get the gist

 

It's textbook stuff, nothing clever, just for what I wanted, with variable sizes gave me a nice tradeoff and would work simply with scrolling the screen as well, and a sprite core that only eats ~4K of code, when unrolled vertically.. I even binned the idea of treating the unused lines at the top and bottom of it specially since I just found it wasn't paying off enough when compared against the code size, so just used sprites arranged in column style with padding between and just masking/copying the zero data.. It made life simple, and didn't make that much difference when all thrown into a real situation..

 

Hell, there's even optimisations in this to be had, but as I said, it's from a testbed where I was playing with even more software sprite ideas, and in it state it was last left in..

 

		!macro cs6_line .x, .width, .screen, .zone_char_base{
.do:
		ldy .x
		lda (.screen),y
		bne .not_empty
		
		;	Character is zero, just allocate and copy..
.empty:
		txa
		sta (.screen),y
		lda char_mul_8_lo,x
		sta Dest_Char+0
		lda char_mul_8_hi,x
		clc
		adc .zone_char_base
		sta Dest_Char+1
		inx

		ldy #0
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	
		iny
		lda (data),y
		sta (Dest_Char),y	

		jmp .next
	
.not_empty:
		cmp #33			; +1!
		bcs .no_alloc

		;	Copy base character into new and mask data onto it..	
.mask
		tay
		lda char_mul_8_lo,y
		sta Src_Char+0
		lda char_mul_8_hi,y
		clc
		adc .zone_char_base
		sta Src_Char+1

		txa
		ldy .x
		sta (.screen),y
		lda char_mul_8_lo,x
		sta Dest_Char+0
		lda char_mul_8_hi,x
		clc
		adc .zone_char_base
		sta Dest_Char+1
		inx
.mask_go:
		ldy #0
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y
		iny
		lda (Src_Char),y
		and (mask),y
		ora (data),y
		sta (Dest_Char),y

		jmp .next

		;	Character is already a created one, so merge into it in place..
.no_alloc:
		;	This is special, because we modify the existing character in place..
		;	And to reduce code size we share the normal mask code..
		;	It would be faster to only use Src_Char, but it costs too much memory for the extra code bloat..
		tay
		lda char_mul_8_lo,y
		sta Src_Char+0
		sta Dest_Char+0
		lda char_mul_8_hi,y
		clc
		adc .zone_char_base
		sta Src_Char+1
		sta Dest_Char+1
		jmp .mask_go
.next
		lda data+0	; We can set these up in advance.. The old each column seperate
		clc			; pointer since we can reduce the loading cost on each..
		adc .height    ;	So that will save 9*lda abs per 3x3.. Also will save carry 
		sta data+0	;	set cost as well..
		sta mask+0

		inc .x
		ldy .x
		cpy .width
		beq .exit
		jmp .do
.exit
		}

CS6_MEM_START	=	*

 

 

lol, and no comes the signing away of my life.. If I find sometime I'll put something together with Armalyte'esque sprite counts just to prove the point And it's something I've been meaning to do for a while actually, and will make a change from bloody stupidly complex alien logic in my Galaga gubbins

 

But in crunch mode for the next week and a bit, so don't expect anything before then..

[Heaven/TQA]

I thought crunch modes in software industry have gone? I am in one, too... damned release schedule and the iPad release...