IKARI WARRIORS (a possible new game on the way)

[Heaven/TQA]

Pete... when messing around hscrol on A8, remember it works in color clocks, too and not in highres like the c64.

 

so... 0-3 scrolls one antic 4 char...

 

and thx for the explanation. thoughts here were similar but I am not sure if the lockup and logic behind the "scroll correction" will eat the gain?

[PeteD]

Yeah, got the 4 pixels per char seriously embedded in my brain now that's why only 4 sets of char definitions.

 

Think of this scenario. The 2 guys are standing offset by 2 pixels and I only have 1 set of data so both of them have to not just have a load background, load data, load (or create) mask, mask, OR, store etc but also 4 shifts to get the bits offset to the right place. That's gonna be fairly nasty.

 

So, keep the 4 copies of the background (320 bytes per char line) * height * 4.

 

hardware scroll the screen up to the point where they're crossing (on a char height boundary of course) and change the "bank" of background definitions to the "offset by 2" . Now there's no shifting at all for the one guy. The other guy, in this case, because he's now offset by 2 pixels as well because of the hardware shift is suddenly also on a char boundary again. no shifting through data for him either APART from where his data crosses into the offset chars.

 

That's of course best case scenario but at least you only ever HAVE to shift all the data for one guy.

 

 

Pete

Edited July 28, 2009 by PeteD

[emkay]

i'm thinking we might have to spend a while working out the raster splits for the 4 player one tho Pete

 

 

 

 

but it is the same shade of green they used for gauntlet

 

 

Hehe... seeing this picture, reminds me about the solution for the buddha pic in exploding fist. A buddha is never grey. It's grey on the C64 because there are not enough "gold" or "jade" colours available. Seeing the background there "golden/yellow" it is no problem to make the buddha golden via additional PM overlays....

[Irgendwer]

i'm thinking we might have to spend a while working out the raster splits for the 4 player one tho Pete

...

Where is the problem?

 

CU

Irgendwer

Edited July 28, 2009 by Irgendwer

[+CharlieChaplin]

[completely off-topic]

 

PeteD,

 

your new Avatar gfx looks good - but nevertheless, I do not like it. It looks like a huge Commodore logo is behaving like Pacman and eating our Atari logo. Commodore eating Atari - no no no !! Or to quote a well-known (anti-Commodore) Atari Basic demo "Of course you know, this means war..." and thus Atarians may strike back with Avatars where the C-logo is treated badly... -Andreas Koch.

 

[end off-topic]

[PeteD]

Alternatively it could be seen as an Atari analy raping a C64

 

 

Pete

[+GroovyBee]

It looks like an Atari symbol scaling a building while holding a golfing umbrella to me.

[TMR]

It looks like an Atari symbol scaling a building while holding a golfing umbrella to me.

 

i was thinking Commodore logo with a Robin Hood-style arrow coming in and splitting it.

[dwhyte]

I must also chime in on the awesome avatar you have now PeteD... I like it...

[miker]

Awesome idea - both computers have somening in common.

[+Philsan]

I am developing a routine for 8 pixel wide sprites multicolor.

Peter, it would be nice if you could make this routine available for Turbo-Basic XL programmers like me!

[PeteD]

Thanks guys, of course it wasn't my intention for the avatar to be the C= eating the A8 logo. I'd thought of the idea to combine both logos last week (me being a C64 guy venturing into A8 land) but if it involves graphics manipulation my skills are that of a 5 year old I mentioned it to Ste'86 last night and 10 mins later there it was (thanks again Ste).

 

 

Pete

[popmilo]

Here is part of one of my posts in Atari v Commodore thread:

 

"Screenshot from Ikari Warriors:

 

 

There are 17 sprites on this shot. There are max 8 sprites in one horizontal line... all of them can have one unique color. Each of them is at least 8-12 multicolored pixels wide...

There are 6 more colors in background...

I think you could maybe simulate that in a static screenshot...

 

But it would be a totally different matter to make it move around ..."

 

Best game that came close to this type of game is Commando...

I guess that with character sprite reuse and with simpler backgrounds it could be done... at least the number of enemies could be achieved...

They wouldn't be so colorfull (or maybe change color using DLIs so there can be rows of differently colored soldiers )

 

So identical no,

similar with good gamplay yes.

[popmilo]

... The 2 guys are standing offset by 2 pixels and I only have 1 set of data so both of them have to not just have a load background, load data, load (or create) mask, mask, OR, store etc but also 4 shifts to get the bits offset to the right place. That's gonna be fairly nasty.....

What I did in one of my routines was:

use only one character for background (like grass, dirt, stuff like that...), so background is same for all software sprites...

and dont do shifting but lookup tables...

self modifying code to set correct lookup table addresses depending on X and 4,and then simple:

ldx sprite

lda table,x

to get correct shifted value...

same thing with masks...

it is 4 cycles per byte more but still better then shifting...

[PeteD]

... The 2 guys are standing offset by 2 pixels and I only have 1 set of data so both of them have to not just have a load background, load data, load (or create) mask, mask, OR, store etc but also 4 shifts to get the bits offset to the right place. That's gonna be fairly nasty.....

What I did in one of my routines was:

use only one character for background (like grass, dirt, stuff like that...), so background is same for all software sprites...

and dont do shifting but lookup tables...

self modifying code to set correct lookup table addresses depending on X and 4,and then simple:

ldx sprite

lda table,x

to get correct shifted value...

same thing with masks...

it is 4 cycles per byte more but still better then shifting...

 

Yeah but we were talking about exploding fist (if you read the whole thread), I know it was totally off topic in here but it started because of something José said, it's a totally different problem to handle. You can't build the background into the sprites like you could with say Gauntlet.

 

The colour lookup is something I've used before too but can get fairly complex eg ldx sprite, lda table,x is ok for sprites that are 1 byte wide (of course you also need more than 1 lda because they've crossed the char barrier) but if they're two then you lose the bits that you're "shifting out" by reading them from a table so instead you have to say ok have 2 tables so you can read 2 bytes from the x (which becomes 3 because of course you're now into using 3 chars width) but wait, what if the sprite is wider (c64 sprite 3 bytes size) etc etc It's all swings and roundabouts and of course is very useful in some situations, not so in others. I'm quite happy to write 10 softsprite routines and do a benchmark test for them all, pick whichever is fastest in that game.

 

Pete

Edited July 29, 2009 by PeteD