Those Arcade scrolling beat'em'ups that we never had on A8

[José Pereira]

From many of my tries and watching again this Vega's MIKIE conversion:

And also talked sometime ago with the Author it was possible to get the guys sprite routine to build a Double Dragon type.

 

 

Problem to direct port was that Vega is using Bitmap Mode and I think he really need the 5th colour.

Char-Mode get us with the traditional problem of 128chars only per charset and more cycles to get the guys soft sprites.

 

 

In Mikie you have the guys using skin and Black as the PFs colours and then each guy is using one Player with a change across the body to get re-use of Player and have hair, then shirt then throusers diferent colours.

What I get is that if we have PF0 and PF1 as Black and skin colour and use PRIOR4 we have the hair,clothes,... overlaying BACKGROUND register colour then we only need to do the Masking between the soft sprites.

In a 'C64 way' top guy it's P0 and untill the bottom one P3 then evrytime they change yPos you do the PFs Bitmap Masking only (PMGs can be changed, like P0->P1, P1->P2, P2->P3 and P3->P0).

It seems the simpliest way to get this on A8... Or is it simple to Mask also between the PMGs and not change their Players number?

 

 

I get sometime ago DOUBLEDRAGON 2 from C64 and it may not look good if we need the 32Bytes wide (or the 40Bytes)screen but if we have then at 48bytes it really look good.

So we have:

PF0- Black

PF1- Skin colour

------------------

PF2 and PF3 simulate C64 ColourMap and have some DLIs to get diferentbuildinds and objects colours.

----------------------------------------------------------------------------------------------------

BACKR.- would be the same all screen high if in 32Bytes wide screen (if 48bytes wide then one or two DLIs even more screen diferent colours on the gfxs)

 

 

 

 

This seems the only and best way to get something this type on A8 but:

-> That size soft sprites can we get the screen at 48Bytes wide (or really need to 'squeeze it to 32Bytes wide?)?

-> Is it really need that we have the Area where the guys move using the same charset or can we have it like I said sometime ago using that Interleaved charsets?

-> And the guys using just 1Player each or if needed to have 10pixels wide then adding the correspondant one Missile on each guy would turn the things more complicated concerning the guys priorities/changing it yPos (and best to not use them)?

 

 

 

 

 

 

Or if we get GameBoy version and using ANTIC5?

It seems less scanlines on the guys but indeed they are almost the same and the guys are now double wide/double chars each.

All the things are the same as PF0 and PF1 are still Black and skin colour where PF2 and PF3 gets the diferent/DLis colours.

It is also possible to squeeze the screen to 32Bytes wide but with the guys so large width the screen probably not the aprropriate size to battle/moving/see the incoming guys...

Here's the 48Bytes wide screen:

 

 

 

 

 

 

 

 

 

_____________________________________________________________________________________________

 

From these two, wich one beter/possible to get something on A8, the 2x1 or the 2x2 (or the two possible?)

[Magic Knight]

I cant see much wrong with this version of Mikie (speaking as a player and not a programmer)

 

Would love to see Mikie completed or even a few levels at least! Up there with Space Harrier and Bomb Jack (or Jake)

 

Wonder how your Barbarian is getting on.........?

[Synthpopalooza]

here's a technique I came up with ... how to use Antic 4/5 as a bitmap (not char) mode.

 

What you need is to set character set DLI every 3 lines (in normal mode, or 4 lines in narrow), put ATASCII 0-119 to the screen sequentially 8 times (0-255 when using narrow mode). You would be POKEing to the character set memory instead of the screen memory. What this means is that the bitmap layout in this mode would be like low-res multicolor mode on the C-64 ... it's read one char cell at a time.

 

So you would get 160x192 (or 160x96 in Antic 5), 5 colors ... Every 4x8 char cell can use either PF2 or PF3, but you inverse the character on the screen map where you want to use PF3 ... so the screenmap acts like the color map on the C-64 in lo-res.

[Tezz]

here's a technique I came up with ... how to use Antic 4/5 as a bitmap (not char) mode.

 

What you need is to set character set DLI every 3 lines (in normal mode, or 4 lines in narrow), put ATASCII 0-119 to the screen sequentially 8 times (0-255 when using narrow mode). You would be POKEing to the character set memory instead of the screen memory. What this means is that the bitmap layout in this mode would be like low-res multicolor mode on the C-64 ... it's read one char cell at a time.

 

So you would get 160x192 (or 160x96 in Antic 5), 5 colors ... Every 4x8 char cell can use either PF2 or PF3, but you inverse the character on the screen map where you want to use PF3 ... so the screenmap acts like the color map on the C-64 in lo-res.

That's a common technique. This is the method used when we did Bomb Jack and how I'm doing Barbarian at the moment.

[Tezz]

There's several options: A true linear layout of the font for bitmap style writes is what you've described. Another option is to have the font sequentially between alternate rows. The number of rows depending on screen width and number of background chars/software sprites required. I often have one font per two rows with a standard 40 byte wide display for example. This leaves plenty of chars for the soft sprites.

[TheNameOfTheGame]

This is very interesting topic. I would like to know more.

 

Are there any good tutorials to learn more about the various A8 tricks and techniques like soft sprites, character sets, DLIs, etc?

[Synthpopalooza]

I know De Re Atari has lots of good stuff in regards to DLI's and using character sets ,,, search http://www.atariarchives.org/dere/ .. atariarchives.org has a lot of interesting material from other sources as well.

 

I would like to learn more about softsprites though, how to create and use them.

[TheNameOfTheGame]

I know De Re Atari has lots of good stuff in regards to DLI's and using character sets ,,, search http://www.atariarchives.org/dere/ .. atariarchives.org has a lot of interesting material from other sources as well.

 

I would like to learn more about softsprites though, how to create and use them.

 

Oh good link. Sorry to interrupt this thread. I'll read up a bit.

[popmilo]

I would like to learn more about softsprites though, how to create and use them.

There is really no easy to find comprehensive soft-sprites tutorial out there... Lots of information scattered around, but no one place-to-go-to for soft sprites...

 

Best bet is to look in world of spectrum forum or cpc forums...

 

Or just say so and I'll write a tutorial for Atari

[snicklin]

Or just say so and I'll write a tutorial for Atari

 

And put it on the Atari wiki!

[Magic Knight]

There is really no easy to find comprehensive soft-sprites tutorial out there... Lots of information scattered around, but no one place-to-go-to for soft sprites...

 

Best bet is to look in world of spectrum forum or cpc forums...

 

Or just say so and I'll write a tutorial for Atari

 

Yes - please do, i would appreciate it and im sure others would too!

[popmilo]

And put it on the Atari wiki!

Which wiki are you refering to ?

 

Yes - please do, i would appreciate it and im sure others would too!

Ok. As I'm working on new routine anyway, I'll just document it as it goes ...

[Tin_Lunchbox]

It wasn't scrolling but we did have a version the head-chopping Barbarian duel game.

[Creature XL]

Another possible ANTIC-4 layout is using 4 fonts and alternate them every modeline. It was proposed to me the first time by Jose.

In my current engine I am using that. First workable version you can see in my NYD 2013 contribution

 

You lose some cycles because of a DLI in each modeline, but this 20 cycles are more of an academic nature.

The advantage of this layout is, that you only "lose" 3 chars per soft-sprite (considering a 2 char wide sprite). So Having 8 of those and some bullets should fit nicely.

You even have some advantages when writing the gfx data into the chars.

A problem I have encountered so far, is that it is not straight forward to use the same mapping tools (like CharPad). But a bit planing and some Python script will cope with that problem

 

Soft-sprites aren't that hard to do, however, a good tutorial helps a lot I guess. Doing those in a bitmapped mode is rather simple, but the char-mode based ones are faster i guess. At least when you consider all needed routines.

For example, collision detection is much easier in some cases. And saving the background as well.

 

Two things I learned rather late: you have one horizontal pixel extra (8 instead of 9) and when using char-based sprites, the "vertical layout" is easier and faster to handle.

the part which sucks teh most, are the routines to pre-shift the sprites and to calculate the AND-tables. If you do not know what that means, wait till someone makes a tutorial

And that is why I post my routines here, so a beginner must not deal with that non-sense

 

;-------------------------------------------------------------------------------
;
; Preshift soft sprites
;
;    zp4:    gfx data
;    zp0:    0 pixel shift
;    zp1:    1 pixel shift
;    zp2:    2 pixel shift
;    zp3:    3 pixel shift
;-------------------------------------------------------------------------------
css0816_pre:
       movei    2,charline
@ll:
       ldx    #7
@charloop:
   ; init shift buffer with gfx

   ; 3rd char in line
       ldy    #2*16
       lda    (zp4),y
       sta    (zp0),y
       sta    buf+2

   ; 2nd char in line
       ldy    #1*16
       lda    (zp4),y
       sta    (zp0),y
       sta    buf+1

   ; 1st char in line
       ldy    #0*16
       lda    (zp4),y
       sta    (zp0),y

   ; shift line one pixel to the right
       lsr
       ror    buf+1
       ror    buf+2
       lsr
       ror    buf+1
       ror    buf+2

   ; copy to shift-1 buffer
       pha                ; save value (@buf+0)
       ldy    #0*16
       sta    (zp1),y   
       ldy    #1*16
       lda    buf+1
       sta    (zp1),y
       ldy    #2*16
       lda    buf+2
       sta    (zp1),y
       pla

   ; shift line one pixel to the right
       lsr
       ror    buf+1
       ror    buf+2
       lsr
       ror    buf+1
       ror    buf+2

   ; copy to shift-2 buffer
       pha
       ldy    #0*16
       sta    (zp2),y
       ldy    #1*16
       lda    buf+1
       sta    (zp2),y
       ldy    #2*16
       lda    buf+2
       sta    (zp2),y
       pla                ; shift a last time one pixel
      
   ; shift line one pixel to the right
       lsr
       ror    buf+1
       ror    buf+2
       lsr
       ror    buf+1
       ror    buf+2

   ; copy to shift-3 buffer
       ldy    #0*16
       sta    (zp3),y
       ldy    #1*16
       lda    buf+1
       sta    (zp3),y
       ldy    #2*16
       lda    buf+2
       sta    (zp3),y
      
   ; next line (byte) in char
       inc_w    zp4
       inc_w    zp0
       inc_w    zp1
       inc_w    zp2
       inc_w    zp3

   ; 8 lines done?
       dex
       bmi    @next_charline
       jmp    @charloop
@next_charline:
       dec    charline
       beq    @done
       jmp    @ll
@done:
       rts

 

The used macros should be obvious.

Calculating the AND-tables. Here i consider COLBK as transparent.

If you want to have black (or what every your background color is) you cannot build the AND-tables so easy

 

 

 

;------------------------------------------------------------
;
; Generate AND-tables for the pre-shifted SS.
;
; Parameter:
;    zp0:    ss-gfx addr
;    zp1:    AND-data addr
;------------------------------------------------------------
css0816_and:
       movei    3,@count        ; 3*128 = 384
@loop:
       ldy    #0
@l:
       movei    0,@tmp
       lda    (zp0),y
       tax
       and    #%11000000
       bne    @n1
       lda    @tmp
       ora    #%11000000
       sta    @tmp
@n1:
       txa
       and    #%00110000
       bne    @n2
       lda    @tmp
       ora    #%00110000
       sta    @tmp
@n2:
       txa
       and    #%00001100
       bne    @n3
       lda    @tmp
       ora    #%00001100
       sta    @tmp
@n3:
       txa
       and    #%00000011
       bne    @n4
       lda    @tmp
       ora    #%00000011
       sta    @tmp
@n4:
       lda    @tmp
       sta    (zp1),y
       iny
       bpl    @l
       addq_w    128,zp0
       addq_w    128,zp1
       dec    @count
       bne    @loop
       rts
@tmp:        .byte    0
@count:        .byte    0

 

I haven't measured these routes yet. However, I plan on calling them in-game in my current project and not at the beginning.

These routs aren't coded fro optimal speed. More for readability.

[popmilo]

...Soft-sprites aren't that hard to do, however, a good tutorial helps a lot I guess. Doing those in a bitmapped mode is rather simple, but the char-mode based ones are faster i guess. At least when you consider all needed routines.

Started thinking on how would one approach complex subject like this... Software sprites sound easy (draw shapes on screen), but they include lots of other things...

 

First of all it all depends on kind of screen you are handling (Character screen, Multiple character sets screen, Bitmap mode...).

 

Masking - are sprites 'flying' over empty space, or are should they 'watch' what is under them and restore background as they move around ?

 

Priorities - in what order to draw sprites ?

 

'Color clash'. On A8, 5th color in multicolor character mode.

 

Sprite animation, double buffering, calculating sprite positions, thinking about hardware scrolling of background and its influence on software sprites, what if sprites are part outside screen area, etc ...

 

Guess, I'll start from beginning: bitmap mode, simple drawing, no masking, no preserving background ...

 

 

the part which sucks teh most, are the routines to pre-shift the sprites and to calculate the AND-tables. If you do not know what that means, wait till someone makes a tutorial

Two ways you can fight with that.

 

Use sprite cache (keep limited number of most used shifted sprite frames in a reasonably sized cache). Mike Daily used it in Xeo3 on Plus 4. (http://dailly.blogsp...arch/label/Xeo3).

 

Second way I like is 'on the fly shifting' with self modifying code, more complex to set up, but you save lots of memory and don't loose much of speed.

 

And yeah - masking is a pain in the but

[Creature XL]

Started thinking on how would one approach complex subject like this... Software sprites sound easy (draw shapes on screen), but they include lots of other things...

 

First of all it all depends on kind of screen you are handling (Character screen, Multiple character sets screen, Bitmap mode...).

 

Masking - are sprites 'flying' over empty space, or are should they 'watch' what is under them and restore background as they move around ?

 

Priorities - in what order to draw sprites ?

 

'Color clash'. On A8, 5th color in multicolor character mode.

 

Sprite animation, double buffering, calculating sprite positions, thinking about hardware scrolling of background and its influence on software sprites, what if sprites are part outside screen area, etc ...

 

Guess, I'll start from beginning: bitmap mode, simple drawing, no masking, no preserving background ...

 

 

 

Two ways you can fight with that.

 

Use sprite cache (keep limited number of most used shifted sprite frames in a reasonably sized cache). Mike Daily used it in Xeo3 on Plus 4. (http://dailly.blogsp...arch/label/Xeo3).

 

Second way I like is 'on the fly shifting' with self modifying code, more complex to set up, but you save lots of memory and don't loose much of speed.

 

And yeah - masking is a pain in the but

 

Selfe-modifying code? You mean "compiled sprites"? That's an are I have just touched the surface. Did a "compiler" in C on the PC to use it on the A8.

It worked, however, it uses more RAM. So for sure only useful when you compile them JIT. I think Andy posted code to do this in AA. i am not yet convinced that it is faster.

So I keep to my current approach I am currently testing. Allow only 2/3 different enemies and pre-shift them when the level starts. We'll see. I am still learning stuff

 

 

For your write-up. Starting with bitmap is correct. I am not sure if it useful to start with "blank background". The overhead explaining the AND/ORA stuff is not much. I guess.

If that is understood, the next step (using normal char screen) is something one has to think about. But basicaly it's the same, with the difference that the screen data is in the chars and that saving the background is easier .

Well, the more advanced char-layouts are a bitch. Took me some hours to find a nice and fast routine to use the alternating 0-1-2-3-charsets.

 

Oh and let the reader for himself figure out the special cases when "ypos mod 8 = 0" in the charmode

 

Possible, someone else (me?) will join you adding more info to the post/wiki what ever you do when you want it. But someone has to start it

[Creature XL]

I haven't measured these routes yet. However, I plan on calling them in-game in my current project and not at the beginning.

These routs aren't coded fro optimal speed. More for readability.

 

i just had a quick peek with Altirra's debugger (profiler)

 

pre-shifting: 4700 cycles (e.g. 32 shapes => 150000 cycles)

pre-ANDing:31600 cylces (e.g. 32 shapes =>1011000 cycles)

 

This is less then one second (with DMA off) for 32 shapes. So I guess not a problem in level/room transitions.

 

EDIT:

The ANDing can be optimized a lot with a 256 byte look-up table I guess.

Edited January 27, 2013 by Creature XL

[MaPa]

Second way I like is 'on the fly shifting' with self modifying code, more complex to set up, but you save lots of memory and don't loose much of speed.

You mean shifting sprites as you draw them? I would like to see some example as I can't imagine that you will not loose much of speed. IMHO drawing one sprite with on fly shifting will be like 4x-5x slower then preshifted sprites.

[popmilo]

Self-modifying code? You mean "compiled sprites"?

I wasn't referring to 'compiled sprites'... Those belong with large cartridge games and lots of memory...

 

Self modifying code = unrolled (to a reasonable degree) routine where you can adjust (absolute) addresses of mask, sprite data and screen before you start drawing one sprite frame. Unroll code so you eliminate at least 'one dimension' of sprite drawing procedure (be it vertical or horizontal, depending on screen format). Makes a lot of difference for larger sprites where setup code doesn't overcome benefits of unrolled loop ...

 

... So I keep to my current approach I am currently testing. Allow only 2/3 different enemies and pre-shift them when the level starts.

This is less then one second (with DMA off) for 32 shapes. So I guess not a problem in level/room transitions.

It's a reasonable method for certain type of games. My game is slower paced rpg type with lots of unpredictable sprite frames at once on screen so I can not use that approach...

 

For your write-up. Starting with bitmap is correct. I am not sure if it useful to start with "blank background". The overhead explaining the AND/ORA stuff is not much. I guess.

 

...Possible, someone else (me?) will join you adding more info to the post/wiki what ever you do when you want it. But someone has to start it

Any kind of help is much appreciated

You are right about masking being simple to explain once you have the base explained.

 

Any ideas about existing wiki platform for collaborative editing or maybe a shared repo on Github or Bitbucket is enough ?

 

Drawings seem to be toughest to produce, but I don't see sprite drawing tutorial without them, so I'll be drawing more than usual these days

[popmilo]

You mean shifting sprites as you draw them? I would like to see some example as I can't imagine that you will not loose much of speed. IMHO drawing one sprite with on fly shifting will be like 4x-5x slower then preshifted sprites.

Yes. Every byte of sprite and mask is shifted right before it is used for drawing.

That is why I emphasized 'absolute' addressing in my previous reply. Absolute addressing allows using of both index registers, so you can make sprite drawing core code like this:

 

Use X for getting shifted representation of sprite and mask bytes.

Use Y for indexing sprite data and screen byte rows.

 

Here is code for 'C64 sized' sprites (3 columns, 21 bytes high), 4 bytes wide on screen)

spriteplot_main ldy #20

spriteplot_01 ldx $1000,y ;x=m0
spriteplot_02 lda $1000,x ;a=shl_mask(m0)
spriteplot_03 and $1000,y ;a=m0 and ch0
spriteplot_04 ldx $1000,y ;x=s0
spriteplot_05 ora $1000,x ;a=a or shl(s0)
spriteplot_06 sta $1000,y ;left byte

spriteplot_11 ldx $1000,y ;x=m0
spriteplot_12 lda $1000,x ;a=shr_mask(m0)
spriteplot_13 ldx $1000,y ;x=m1
spriteplot_14 ora $1000,x ;a=a or shl_mask(m1)
spriteplot_15 and $1000,y ;a=a and ch1
spriteplot_16 ldx $1000,y ;x=s0
spriteplot_17 ora $1000,x ;a=shr(s0)
spriteplot_18 ldx $1000,y ;x=s1
spriteplot_19 ora $1000,x ;a=shl(s1)
spriteplot_10 sta $1000,y ;middle byte 1

spriteplot_21 ldx $1000,y ;x=m1
spriteplot_22 lda $1000,x ;a=shr_mask(m1)
spriteplot_23 ldx $1000,y ;x=m2
spriteplot_24 ora $1000,x ;a=a or shl_mask(m2)
spriteplot_25 and $1000,y ;a=a and ch2
spriteplot_26 ldx $1000,y ;x=s1
spriteplot_27 ora $1000,x ;a=shr(s1)
spriteplot_28 ldx $1000,y ;x=s2
spriteplot_29 ora $1000,x ;a=shl(s2)
spriteplot_20 sta $1000,y ;middle byte 2

spriteplot_31 ldx $1000,y ;x=m2
spriteplot_32 lda $1000,x ;a=shr_mask(m2)
spriteplot_33 and $1000,y ;a=m2 and ch3
spriteplot_34 ldx $1000,y ;x=s2
spriteplot_35 ora $1000,x ;a=a or shr(s2)
spriteplot_36 sta $1000,y ;right byte

dey
bpl spriteplot_01

 

Non-masked sprites are much simpler. All 'spriteplot' addresses need to be setup in advance based on value of (sprite_x and 7).

 

Here is an example of that type of sprites on C64 (this is 6-7 years old code ).

http://www.youtube.com/watch?v=3Utg2RfTPHU

 

These are 8 full masked, free to move over background, 24x21 software sprites with hardware sprites underlay (in double buffered character screen mode). Background in video is simple chequered 2x2 grid of pixels, but can be anything else in character mode. Each sprite uses 16 characters, so 128 are left for background.

 

I wouldn't call them speedy, but considering this is running on 1MHz C64 with charmode badlines while also manipulating hardware sprites, I think on A8 this type of routine could be better.

[Synthpopalooza]

One question: Would such a softsprite routine be feasible, using Super IRG?

 

You'd need to select your colors carefully, rely mainly on the solid PF colors where possible, make sure you checkerboard-dither the other colors, and watch out for PF2-PF3 inverse conflicts, but 14 colors at 160 resolution would be almost as good as the C-64. You wouldn't need to double up on the softsprite processing, just double overhead for the font data.

 

I did a mockup of Rainbow Islands in Super IRG, in this thread:

 

http://www.atariage.com/forums/topic/202803-anyone-ever-thought-in-ways-to-get-rainbow-islands-on-a8/page__st__25#entry2600221

 

Would Rainbow Islands in this mode benefit from softsprites?

[popmilo]

One question: Would such a softsprite routine be feasible, using Super IRG?

If I understood IRG correctly, you are right... They wouldn't require more cpu time, but they would require twice the memory compared to simple character screen.

We would have to draw one frame into one charset and another frame into other charset... Wouldn't be hard to convert routine to work like that.

 

Hmmm.... Could be a problem if drawing wouldn't fit in one frame time... Double buffering means more memory, and slower animation... Wouldn't be too bad I guess...

 

Bigger problem is 128 character limit... If you split charset roughly in two, something like seven 2x2 sprites would require 7x3x3=63 chars. 65 chars left for background... Would that be enough for something like rainbow islands ?

 

ps. We still have PMs of course...

[MaPa]

Yes. Every byte of sprite and mask is shifted right before it is used for drawing.

That is why I emphasized 'absolute' addressing in my previous reply. Absolute addressing allows using of both index registers, so you can make sprite drawing core code like this:

 

If I understand the code properly, that routine is only for one specific sprite shape. It's not "universal" and for different shapes you need different tables? And even then this approach seems to me like more than 2x slower than lda,and,ora,sta per byte and I wouldn't call that you don't lose much of speed.

Edited January 28, 2013 by MaPa

[popmilo]

If I understand the code properly, that routine is only for one specific sprite shape. It's not "universal" and for different shapes you need different tables?

Yes. For each sprite width you need separate code... Doesn't look like a big problem to me... My game has 4x4 and 1x1 sprites... 'Only' two routines...

 

And even then this approach seems to me like more than 2x slower than lda,and,ora,sta per byte and I wouldn't call that you don't lose much of speed.

Also yes, no doubt about it... Nothing beats LDA STA

 

This one is at least 2xslower, 32 instructions in the main loop compared to 16 (4 x lda,and,ora,sta).

 

But... For preshifted graphics I would need 4 times more ram for sprite images... With dozen Kbs of sprite frames (plus left-right mirrored sprite frames that I forgot about... ), there is simply not enough space in ordinary 800xl for that.

 

As I said, sprite cache is another option I'm thinking about.... We'll see...

[Synthpopalooza]

If I understood IRG correctly, you are right... They wouldn't require more cpu time, but they would require twice the memory compared to simple character screen.

We would have to draw one frame into one charset and another frame into other charset... Wouldn't be hard to convert routine to work like that.

 

Hmmm.... Could be a problem if drawing wouldn't fit in one frame time... Double buffering means more memory, and slower animation... Wouldn't be too bad I guess...

 

You would only need the normal 960 bytes for an Antic 4 screen. It's only the character set memory which is doubled (2K vs 1K).

 

Bigger problem is 128 character limit... If you split charset roughly in two, something like seven 2x2 sprites would require 7x3x3=63 chars. 65 chars left for background... Would that be enough for something like rainbow islands ?

 

ps. We still have PMs of course...

 

It might work. I was able to fit my sample screen into 128 chars with some to spare.