English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Contest (http://eab.abime.net/forumdisplay.php?f=130)
-   -   Discussion: Rygar AGA Edition (http://eab.abime.net/showthread.php?t=93545)

roondar 31 August 2018 14:07

Quote:

Originally Posted by ross (Post 1265642)
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 (Post 1265646)
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.

Steril707 31 August 2018 15:40

Quote:

Originally Posted by mcgeezer (Post 1265644)
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 (Post 1265669)
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?

Steril707 31 August 2018 15:56

Quote:

Originally Posted by mcgeezer (Post 1265670)
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" :D) 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 (Post 1265672)
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 (Post 1265631)
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 (Post 1265898)
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 (Post 1265923)
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 (Post 1265982)
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 (Post 1265991)
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.

https://youtu.be/CLXVCvcCxek

vulture 01 September 2018 18:08

@mcgeezer

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

Steril707 01 September 2018 18:27

Looks mighty fine... :)

mcgeezer 01 September 2018 18:34

Quote:

Originally Posted by vulture (Post 1266017)
@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 (Post 1266024)
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.

https://youtu.be/-mdwiljTY-A

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


All times are GMT +2. The time now is 08:14.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.14349 seconds with 11 queries