Discussion: Rygar AGA Edition - Page 11

roondar · 31 August 2018, 14:07

Quote:

Originally Posted by ross

Yes, you are right, I've oversimplified.
My intention was to specify that it is not as simple as in the dual playfield where even and odd bitplanes scroll registers can move fields freely without interactions between them.

Method 2 colors interaction are terrible..

I know, I implemented something like this this once and it was indeed a major headache. Setting up the palette meant sprite colours ended up all messed up as a result and the whole thing ended up being complicated to use and maintain.

Must have drawn diagrams on how it should work at least a dozen times before I got it right!

Not to mention that blitting that extra bitplane in the correct place turned out to be surprisingly fiddly for something that should be the easy part of the whole thing.

mcgeezer · 31 August 2018, 14:09

Quote:

Originally Posted by roondar

I know, I implemented something like this this once and it was indeed a major headache. Setting up the palette meant sprite colours ended up all messed up as a result and the whole thing ended up being complicated to use and maintain.

Must have drawn diagrams on how it should work at least a dozen times before I got it right!

Not to mention that blitting that extra bitplane in the correct place turned out to be surprisingly fiddly for something that should be the easy part of the whole thing.

^^^ THIS ^^^
Completely Concur - An absolute nightmare to implement with marginal gains in time.

ross · 31 August 2018, 14:32

I've written a 'method 2 like' for OCS on late '80 and the collateral effects (and limited planes usable) were so heavy that I never used it.

So opted for [odd/even scroll=same] and blit (method1) or better, if possible, DPF.

But sure a way to use it can be found, especially on AGA.

Tigerskunk · 31 August 2018, 15:40

Quote:

Originally Posted by mcgeezer

I'm pleased it isn't just me who gets like this, really that took it out of me so you'll notice there hasn't been many updates as I've been having a rest.

I'd be interested to see details on your sprite multiplexer... Ross really helped me massively with the one I have for Rygar but I'm always looking for improvements.

re. method 2 - here is a link to post 175 earlier in the thread that hurt my brain. http://eab.abime.net/showpost.php?p=...&postcount=175

Well, on the multiplexer, basically:

step 1) you create a y-sorted list of all objects
step 2) you generate a dynamic copperlist where you write all that stuff into

I have to admit, coding the sorted list in asm almost ended up in me pulling my hair out.

Step 2 wasn't that hard then anymore, though.

If you have any further questions, feel free to ask..

mcgeezer · 31 August 2018, 15:44

Quote:

Originally Posted by Steril707

Well, on the multiplexer, basically:

step 1) you make a y-sorted list of all objects
step 2) you generate a dynamic copperlist where you write all that stuff into

I have to admit, coding the sorted list in asm almost ended up in me pulling my hair out.

Step 2 wasn't that hard then anymore, though.

If you have any further questions, feel free to ask..

Did you do any X axis multiplexing?

Tigerskunk · 31 August 2018, 15:56

Quote:

Originally Posted by mcgeezer

Did you do any X axis multiplexing?

No, since coding that that would be a whole other magnitude of pain (a.k.a. the "GOING SUPER GOLLUM"

) and wasn't necessary for my engine.

I used the sprites only in addition to my BOBs, and for certain enemy formations which didn't need more than 2 in any line.

I have done horizontal multiplexing of sprite channels on my sprite background, but that's a static list.

Tackling an engine like that might be a nice project in the future, but at the moment I want to concentrate to finish my game, and as it is there is enough other stuff left to do at the moment...

ross · 31 August 2018, 16:11

Well Geezer, you've 32bit sprites so the only possibility for x multiplex is for some background (with static list)
[SPRDAT is CPU/Copper usable only on 1x sprite fetch mode].

Or you have the same object pattern on the very same line?

mcgeezer · 31 August 2018, 16:43

Quote:

Originally Posted by ross

Well Geezer, you've 32bit sprites so the only possibility for x multiplex is for some background (with static list)
[SPRDAT is CPU/Copper usable only on 1x sprite fetch mode].

Or you have the same object pattern on the very same line?

Yeah if you think about rygar, enemies in the mid and low zones repeat across the x axis quite alot so i was thinking about trying repeating sprites with 1 channel.

roondar · 31 August 2018, 17:22

Not wanting to dissuade you here, but that might difficult to pull of in a useful way

Not only do these sprites need to be on the exact same vertical position, but there can not any difference in image. Which means that they will all animate the same, even when you kill one and the other lives. This in turn means you need to dynamically choose sprites vs blitter use etc.

But it gets even worse

Even if you manage to fix all that, reusing sprites like this will probably need a dynamic copperlist which updates as you go along to keep all sprites in the right places. To be honest, I considered stuff like this and concluded that it's best to not try to move the copperlists entries around much if at all.

I'm not saying it's definitely not possible, but I see some real challenges on the road to freely relocated sprites using the copperlist I'm afraid.

mcgeezer · 31 August 2018, 17:46

Dont worry, i’m sticking with what i have.

I need to get a silly bob bug fixed tonight and thrn onto collision detection.

aros-sg · 01 September 2018, 09:51

Quote:

Originally Posted by mcgeezer

The palette in method 1 is simple. Each of the 8 palette banks has the same palette repeating except for each register except the first register after bank 5.

Registers 0,32,64,96,128,160,192 & 224 all make up the background colour registers.

The palette in method 2 isn't, but I documented how to do in a previous post, a real brain teaser.

untested pseudo code:

Code:

palette[256];

fg_palette[32];
bg_palette[8];

FG_TRANSP_COLOR = 0;

#define FG_PLANE_1 1
#define FG_PLANE_2 3
#define FG_PLANE_3 5
#define FG_PLANE_4 7
#define FG_PLANE_5 6

#define BG_PLANE_1 0
#define BG_PLANE_2 2
#define BG_PLANE_3 4

/* return 1 or 0 depending on whether bit x in i is set or not */
#define BIT(x) ((i & (1 << x)) ? 1 : 0)

int get_fg_col(int i)
{
    int r = BIT(FG_PLANE_1) * 1 +
            BIT(FG_PLANE_2) * 2 +
            BIT(FG_PLANE_3) * 4 +
            BIT(FG_PLANE_4) * 8 +
            BIT(FG_PLANE_5) * 16;
    
    return r;
}

int get_bg_col(int i)
{
    int r = BIT(BG_PLANE_1) * 1 +
            BIT(BG_PLANE_2) * 2 +
            BIT(BG_PLANE_3) * 4;
    
    return r;
}

for(i = 0; i < 256; i++)
{
    fg_col = get_fg_col(i);
    bg_col = get_bg_col(i);
    
    if (fg_col == FG_TRANSP_COLOR)
    {
        palette[i] = bg_palette[bg_col];
    }
    else
    {
        palette[i] = fg_palette[fg_col];
    }    
}

mcgeezer · 01 September 2018, 10:39

Quote:

Originally Posted by aros-sg

untested pseudo code:

Code:

palette[256];

fg_palette[32];
bg_palette[8];

FG_TRANSP_COLOR = 0;

#define FG_PLANE_1 1
#define FG_PLANE_2 3
#define FG_PLANE_3 5
#define FG_PLANE_4 7
#define FG_PLANE_5 6

#define BG_PLANE_1 0
#define BG_PLANE_2 2
#define BG_PLANE_3 4

/* return 1 or 0 depending on whether bit x in i is set or not */
#define BIT(x) ((i & (1 << x)) ? 1 : 0)

int get_fg_col(int i)
{
    int r = BIT(FG_PLANE_1) * 1 +
            BIT(FG_PLANE_2) * 2 +
            BIT(FG_PLANE_3) * 4 +
            BIT(FG_PLANE_4) * 8 +
            BIT(FG_PLANE_5) * 16;
    
    return r;
}

int get_bg_col(int i)
{
    int r = BIT(BG_PLANE_1) * 1 +
            BIT(BG_PLANE_2) * 2 +
            BIT(BG_PLANE_3) * 4;
    
    return r;
}

for(i = 0; i < 256; i++)
{
    fg_col = get_fg_col(i);
    bg_col = get_bg_col(i);
    
    if (fg_col == FG_TRANSP_COLOR)
    {
        palette[i] = bg_palette[bg_col];
    }
    else
    {
        palette[i] = fg_palette[fg_col];
    }    
}

Errrr... yeah sorta looks right for method 1

My actual code for method 2 palette is below.

Code:

CREATE_PALETTE_MASK:
	moveq	#0,d0
	moveq	#0,d1
	moveq	#0,d2
	moveq	#0,d3
	move.l	#255,d7			; 256 colour registers

	lea	PALETTE_MASK-data(a4),a3

.loop:	move.b	d3,d0
	
	and.b	#87,d0		; Remove bits 8,6 & 4
	move.b	d0,d1
	move.b	d0,d2
	and.b	#7,d0

	lsr.b	#4,d1		; Move bit 5 into bit position 1
	and.b	#1,d1		
	lsl.b	#3,d1		; then shift it up to bit position 4
	or.b	d1,d0

	lsr.b	#6,d2		; Move bit 7 into bit position 1
	and.b	#1,d2	
	lsl.b	#4,d2		; then shift it up to bit position 4
	or.b	d2,d0
; 5 bit colour bank now in d0...  colour to select from paletee
;
	move.b	d3,d1		; get current colour number.
	lsr.b	#5,d1		; divide by 32 to get bank number

	move.b	d1,(a3)+	; d1 has bank number
	move.b	d0,(a3)+	; d0 has source colour
	addq.w	#1,d3
	dbf	d7,.loop
	rts

Hewitson · 01 September 2018, 14:58

What would you say if I said I was seriously considering making a YM card and I'd love this to be the first game to support it?

Don_Adan · 01 September 2018, 15:23

Quote:

Originally Posted by mcgeezer

Errrr... yeah sorta looks right for method 1

My actual code for method 2 palette is below.

Code:

CREATE_PALETTE_MASK:
	moveq	#0,d0
	moveq	#0,d1
	moveq	#0,d2
	moveq	#0,d3
	move.l	#255,d7			; 256 colour registers

	lea	PALETTE_MASK-data(a4),a3

.loop:	move.b	d3,d0
	
	and.b	#87,d0		; Remove bits 8,6 & 4
	move.b	d0,d1
	move.b	d0,d2
	and.b	#7,d0

	lsr.b	#4,d1		; Move bit 5 into bit position 1
	and.b	#1,d1		
	lsl.b	#3,d1		; then shift it up to bit position 4
	or.b	d1,d0

	lsr.b	#6,d2		; Move bit 7 into bit position 1
	and.b	#1,d2	
	lsl.b	#4,d2		; then shift it up to bit position 4
	or.b	d2,d0
; 5 bit colour bank now in d0...  colour to select from paletee
;
	move.b	d3,d1		; get current colour number.
	lsr.b	#5,d1		; divide by 32 to get bank number

	move.b	d1,(a3)+	; d1 has bank number
	move.b	d0,(a3)+	; d0 has source colour
	addq.w	#1,d3
	dbf	d7,.loop
	rts

I dont know, if you like if someone will be try to optimised your code, but this code:
lsr.b #6,d2 ; Move bit 7 into bit position 1
and.b #1,d2
lsl.b #4,d2 ; then shift it up to bit position 4
can be replaced by and.b and lsr.b only, you dont need to use first shift. Same for d1 register. 2 instructions left x 256 times.

mcgeezer · 01 September 2018, 16:18

Quote:

Originally Posted by Hewitson

What would you say if I said I was seriously considering making a YM card and I'd love this to be the first game to support it?

Sorry I don't know what one of those is? Happy to look into it though.

Quote:

Originally Posted by Don_Adan

I dont know, if you like if someone will be try to optimised your code, but this code:
lsr.b #6,d2 ; Move bit 7 into bit position 1
and.b #1,d2
lsl.b #4,d2 ; then shift it up to bit position 4
can be replaced by and.b and lsr.b only, you dont need to use first shift. Same for d1 register. 2 instructions left x 256 times.

The code is only ever called once so isn't time critical. I never went back to optimise it so that's why it is like it is.

mcgeezer · 01 September 2018, 16:22

Another quick update here.

Last night I worked on fixing some things up like the background scrolling and doing bits of optimsations here and there.

This morning I've worked on integrating the hardware sprite animations.

Doing this has resulted in me losing a sprite or two though so I need to optimise some more.

There are factors in the scrolling which although look correct are not really doing what they are supposed to be, this is causing me to blit more words into the background than I should be... so I'm looking into it.

Another thing I plan on doing is some sort of blitter queue system so I can do all the blits in one go, this will hopefully enable me to mutli-thread the CPU to do other things.... all trial and error really.

[ Show youtube player ]

vulture · 01 September 2018, 18:08

@mcgeezer

Have you decided against using copper skies? Personally, I think they were beautiful.

Tigerskunk · 01 September 2018, 18:27

Looks mighty fine...

mcgeezer · 01 September 2018, 18:34

Quote:

Originally Posted by vulture

@mcgeezer

Have you decided against using copper skies? Personally, I think they were beautiful.

No, they're going back in. It is just I had to remove the temporarilly due to the sprite multiplexing. They'll be going back soon.

Quote:

Originally Posted by Steril707

Looks mighty fine...

Cheers buddy. Give me a shout if you need a hand with anything (your game entry) and I'll be happy to take a look and help if I can.

mcgeezer · 01 September 2018, 21:23

I know I'm pedantic with my videos but here's another one and it's a good milestone as I fixed lots of performance bugs... 20 animated sprites scrolling through all levels!!!!!

I even added a bit Lazerhawk for you to enjoy on the journey.

[ Show youtube player ]

PS. Why Youtube does a shit encoding job on my videos I will never know.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Entry: Rygar AGA Edition	mcgeezer	Coders. Entries	75	28 February 2019 20:41
On the Ball - World Cup Edition AGA	djcasey	request.Old Rare Games	4	25 January 2013 12:39
On The Ball League Edition AGA , Player Manager 2	StarEye	Games images which need to be WHDified	11	22 January 2010 18:21
The Vague #1 AGA-RTG edition is released !	kas1e	Amiga scene	12	30 October 2007 00:27
On The Ball: World Cup Edition AGA	CodyJarrett	request.Old Rare Games	11	27 May 2003 06:14

31 August 2018, 14:32	#203
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	I've written a 'method 2 like' for OCS on late '80 and the collateral effects (and limited planes usable) were so heavy that I never used it. So opted for [odd/even scroll=same] and blit (method1) or better, if possible, DPF. But sure a way to use it can be found, especially on AGA.

31 August 2018, 16:11	#207
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Well Geezer, you've 32bit sprites so the only possibility for x multiplex is for some background (with static list) [SPRDAT is CPU/Copper usable only on 1x sprite fetch mode]. Or you have the same object pattern on the very same line?

31 August 2018, 17:22	#209
roondar Registered User Join Date: Jul 2015 Location: The Netherlands Posts: 3,406	Not wanting to dissuade you here, but that might difficult to pull of in a useful way Not only do these sprites need to be on the exact same vertical position, but there can not any difference in image. Which means that they will all animate the same, even when you kill one and the other lives. This in turn means you need to dynamically choose sprites vs blitter use etc. But it gets even worse Even if you manage to fix all that, reusing sprites like this will probably need a dynamic copperlist which updates as you go along to keep all sprites in the right places. To be honest, I considered stuff like this and concluded that it's best to not try to move the copperlists entries around much if at all. I'm not saying it's definitely not possible, but I see some real challenges on the road to freely relocated sprites using the copperlist I'm afraid.

31 August 2018, 17:46	#210
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 2,702	Dont worry, i’m sticking with what i have. I need to get a silly bob bug fixed tonight and thrn onto collision detection.

01 September 2018, 14:58	#213
Hewitson Registered User Join Date: Feb 2007 Location: Melbourne, Australia Age: 41 Posts: 3,771	What would you say if I said I was seriously considering making a YM card and I'd love this to be the first game to support it?

01 September 2018, 16:22	#216
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 2,702	Another quick update here. Last night I worked on fixing some things up like the background scrolling and doing bits of optimsations here and there. This morning I've worked on integrating the hardware sprite animations. Doing this has resulted in me losing a sprite or two though so I need to optimise some more. There are factors in the scrolling which although look correct are not really doing what they are supposed to be, this is causing me to blit more words into the background than I should be... so I'm looking into it. Another thing I plan on doing is some sort of blitter queue system so I can do all the blits in one go, this will hopefully enable me to mutli-thread the CPU to do other things.... all trial and error really. [ Show youtube player ]

01 September 2018, 18:08	#217
vulture Registered User Join Date: Oct 2007 Location: Athens , Greece Posts: 1,840	@mcgeezer Have you decided against using copper skies? Personally, I think they were beautiful.

01 September 2018, 18:27	#218
Tigerskunk Inviyya Dude! Join Date: Sep 2016 Location: Amiga Island Posts: 2,770	Looks mighty fine...

01 September 2018, 21:23	#220
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 2,702	I know I'm pedantic with my videos but here's another one and it's a good milestone as I fixed lots of performance bugs... 20 animated sprites scrolling through all levels!!!!! I even added a bit Lazerhawk for you to enjoy on the journey. [ Show youtube player ] PS. Why Youtube does a shit encoding job on my videos I will never know.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)