WIP - Horizontal Scroller

[MaPa]

 

Hi, indeed it isn't.

But Joystick or the KeyPad on an Emulator. It moves in the 8directions smoothly...

 

 

José Pereira.

 

I got myself again, of course I tried joystick, cursor keys, console keys, remaped joystick control to numpad but nothing worked. Just to realize that I had scroll lock switched on all the time and therefore the joystick didn't work

Edited November 9, 2010 by MaPa

[José Pereira]

Hello,

 

I've decided to attempt write a game for my beloved Atari 800XL. The intention is to write a horizontal scrolling game in the vein of R-Type and Section-Z, that makes user of the Atari 8 bit strengths/weaknesses.

 

I intend to post xex files of my progress and welcome advice any of you may have. Once complete I might post the source code for all to see.

 

I'll start by setting up a display list using Antic mode 4 lines and run a continuous scroll between two screens (Updating graphics as I go) i.e. (screen A, Screen B, Screen A (A copy)). A DLI routine or 2 will change the character set on each line (24 in total) and each will use the 80 characters for the screen area.

 

A software sprite routine will write to the character set area and using a character screen opens up the possibility of coarse character based sprites, which will be probably be used for weapons fire.

 

 

 

R6502A

 

Hi, don't know if this helps, but I am with an A8 8way scrolling Game in Hands and was for all ways trying to get space for SoftSprites and stil uses real ANTIC4 CharMode with less Memory/Charsets I could get.

And I discouver (seeing the game Maps) that Scroll them horizontally The Font of Line0 are different from Lines 1and2.

 

And because the Sprites moves 1pixel horiz. and 4vertical a time (Isometric) I change the C64 sprites 21pixels high into 20pixels.

The Charsets are "interleaved", like:

CharLine0: CharSet0

CharLine1: CharSet1

CharLine2: CharSet2

CharLine3: Charset0

CharLine4: Charset1

CharLine5: Charset2

(and so on...)

 

now each SoftSprite when moves Horizontal have 3+1Char(Shifting)

and Vertical only 3Chars, because moving 4pixels done, when he enters in the next Charset0, he is already out the firs Line CharSet0.

This is the same as saying that the same SoftSprite cannot be in different Lines and 2Times/Lines in the same Charset.

And now I can, for ex. have more SoftSprites and less Chars space needed in each CharSet.

 

 

 

 

 

For an Horizontal Scrolling, and I have many Maps from many ones (Gradius, Salamander, R-Type, Armalyte (by hand...),...) or even your own new, you have possible to design Backgr. Gfxs. Horizontally and that:

-> SoftSprite:20->24pixels High need are 3+1 (shifting) Chars needed vertically

-> Like this using my Method you would need:

CharLine0: CharSet0

CharLine1: CharSet1

CharLine2: Charset2

CharLine3: CharSet3

 

When moving Horizontal you need 3+1(Shifting), Vertical same 3+1(Shifting).

When he goes to the next CharLine0, he already leaves the last Carset0 CharLine.

Now a SoftSprite only needs 4Chars each.

In my case 8SoftSprites needed are 32Chars. and have 96free for the Backgr. Gfxs. They are even more than I need!...

You probably can design Gfxs. with just 96Chars for each CharLine... and 4Charsets/4Kb needed.

 

 

 

See, instead you go into place Tiles in a pseudo-BitMap you probably will have less Memory needed and just Chars, moving and placing real Chars/Tiles.

 

 

 

Hope you understand and it helps you in some way...

Greets.

José Pereira.

[R6502A]

... Where can I find them please?

 

Here

 

Thank you.

[R6502A]

Hello,

 

I've decided to attempt write a game for my beloved Atari 800XL. The intention is to write a horizontal scrolling game in the vein of R-Type and Section-Z, that makes user of the Atari 8 bit strengths/weaknesses.

 

I intend to post xex files of my progress and welcome advice any of you may have. Once complete I might post the source code for all to see.

 

I'll start by setting up a display list using Antic mode 4 lines and run a continuous scroll between two screens (Updating graphics as I go) i.e. (screen A, Screen B, Screen A (A copy)). A DLI routine or 2 will change the character set on each line (24 in total) and each will use the 80 characters for the screen area.

 

A software sprite routine will write to the character set area and using a character screen opens up the possibility of coarse character based sprites, which will be probably be used for weapons fire.

 

 

 

R6502A

 

Hi, don't know if this helps, but I am with an A8 8way scrolling Game in Hands and was for all ways trying to get space for SoftSprites and stil uses real ANTIC4 CharMode with less Memory/Charsets I could get.

And I discouver (seeing the game Maps) that Scroll them horizontally The Font of Line0 are different from Lines 1and2.

 

And because the Sprites moves 1pixel horiz. and 4vertical a time (Isometric) I change the C64 sprites 21pixels high into 20pixels.

The Charsets are "interleaved", like:

CharLine0: CharSet0

CharLine1: CharSet1

CharLine2: CharSet2

CharLine3: Charset0

CharLine4: Charset1

CharLine5: Charset2

(and so on...)

 

 now each SoftSprite when moves Horizontal have 3+1Char(Shifting)

and Vertical only 3Chars, because moving 4pixels done, when he enters in the next Charset0, he is already out the firs Line CharSet0.

This is the same as saying that the same SoftSprite cannot be in different Lines and 2Times/Lines in the same Charset.

And now I can, for ex. have more SoftSprites and less Chars space needed in each CharSet.

 

 

 

 

 

For an Horizontal Scrolling, and I have many Maps from many ones (Gradius, Salamander, R-Type, Armalyte (by hand...),...) or even your own new, you have possible to design Backgr. Gfxs. Horizontally and that:

-> SoftSprite:20->24pixels High need are 3+1 (shifting) Chars needed vertically

-> Like this using my Method you would need:

CharLine0: CharSet0

CharLine1: CharSet1

CharLine2: Charset2

CharLine3: CharSet3

 

When moving Horizontal you need 3+1(Shifting), Vertical same 3+1(Shifting).

When he goes to the next CharLine0, he already leaves the last Carset0 CharLine.

Now a SoftSprite only needs 4Chars each.

In my case 8SoftSprites needed are 32Chars. and have 96free for the Backgr. Gfxs. They are even more than I need!...

You probably can design Gfxs. with just 96Chars for each CharLine... and 4Charsets/4Kb needed.

 

 

 

See, instead you go into place Tiles in a pseudo-BitMap you probably will have less Memory needed and just Chars, moving and placing real Chars/Tiles.

 

 

 

Hope you understand and it helps you in some way...

Greets.

José Pereira.

 

Hi there, thank you for your input. I think I understand. Do you mean repeating charsets so that the soft sprite bitmap area does not have occupy the entire screen? I suppose the programmer is in control of where the soft sprites go so he/she could have bitmap zones in the areas where the soft sprites will be.

[MaPa]

My attempt to use MWP scroll technique is here http://www.atariage.com/forums/topic/172266-wip-frozen-8way-platform-scroller-mwp-technique/.

[José Pereira]

Hi there, thank you for your input. I think I understand. Do you mean repeating charsets so that the soft sprite bitmap area does not have occupy the entire screen? I suppose the programmer is in control of where the soft sprites go so he/she could have bitmap zones in the areas where the soft sprites will be.

 

O.k., lets see if some Pictures...

 

This simple, less Enemys C64 Armalyte example:

 

Forget colours, PMs, DLIs, verything by now.

Just focus on Charsets:

 

Now what I was trying to say:

 

 

 

 

See, the cycles lost are the almost the same.

Great number of cycles lost and now space for SoftSprites are soo little, but there are ways of turning this, I hope (is this I am trying to get in my yesterday Scrolling Thread)!...

 

 

Greets.

José Pereira.

[José Pereira]

Hi there, thank you for your input. I think I understand. Do you mean repeating charsets so that the soft sprite bitmap area does not have occupy the entire screen? I suppose the programmer is in control of where the soft sprites go so he/she could have bitmap zones in the areas where the soft sprites will be.

 

O.k., lets see if some Pictures...

 

This simple, less Enemys C64 Armalyte example:

 

Forget colours, PMs, DLIs, verything by now.

Just focus on Charsets:

CYCLES weren't on this Image, sorry.

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

 

 

Now what I was trying to say:

 

 

 

 

See, the cycles lost are the almost the same.

Great number of cycles lost and now space for SoftSprites are soo little, but there are ways of turning this, I hope (is this I am trying to get in my yesterday Scrolling Thread)!...

 

 

Greets.

José Pereira.

[popmilo]

@R6502: Any news about your project ?

 

If you are interested (or missing graphics for your horizontal scrolling shooter) there is an ongoing multi-platform project called "Edge-grinder" on:

 

http://formatwar.net/view_article.php?art=collabortition_1

 

 

And lots of development related (A8 also) discussion on:

http://formatwar.net/forums/viewtopic.php?f=5&t=28

[emkay]

Why do threads like this start to hurt?

[José Pereira]

Why do threads like this start to hurt?

 

Probably because there isn't untill the 21st century a good Horizontal scrolling shoot'em'up for A8...

It can't be possible that I and others accept this situation...

 

José Pereira.

Edited May 29, 2011 by José Pereira

[R6502A]

@R6502: Any news about your project ? If you are interested (or missing graphics for your horizontal scrolling shooter) there is an ongoing multi-platform project called "Edge-grinder" on: http://formatwar.net/view_article.php?art=collabortition_1 And lots of development related (A8 also) discussion on: http://formatwar.net/forums/viewtopic.php?f=5&t=28

 

Hi there popmilo,

 

Now this is a late reply!

 

Thanks for the link.

 

I'm still working on this but progress is very slow due to lack of time.

I've done some background work on the background draw routines, software sprites and PM graphics for the main ship (all in different test programs). Trying to bring it all together now.

 

Screens are built using a made up scripting language that calls subroutines such as:

PLOT_SHAPE ; Plot background graphics to character set memory (screen)

PLOT_SHAPE_ON_TOP ; plot shape to character set memory and copy chars to screen so that software sprites (when I finish the routine) appear to go behind.

SETBAK ; set the background (Using it to debug code. e.g. background is changed to a particular colour when a specific piece of code is executed)

REQUESTDEBRIEFING ; This is the end level sequence

STARTSCROLL ; The horizontal scroll from right to left is triggered when this is encountered

STOPSCROLL ; Scrolling is suspended when this is encountered

RESETSCRIPT ; Points to the beginning of the script (Will causes the game to run endlessly)

RESETSCRIPTCOUNTER ; This counter is rest to 0,0 here. It's a 16 bit number that is incremented during VBI.

START_SCRIPTCOUNTER ; The counter is incremented every VBI when this is encountered.

STOP_SCRIPTCOUNTER ; The counter incrementation is paused (allows for long running routines to finish executing before script execution continues. Mainly used for initialiising large areas.)

JUDDER_SCREEN ; Shakes the screen

 

The screen buffer is big enough for 2 screens and is looped to create a continuous scroll. Updates happen in the off screen areas and If left alone, the buffer will just loop and display whatever it contains. This is ideal for repetitive things like starfields.

 

I'm concentrating on the game engine rather than any graphics at the moment, but I know I'll need help with that (I'm no great artist) and sound is a dream at the moment (I'm no great musician.) I'm reserving $2200 and below for all sounds so DOS will be wiped out after this game loads. A lot of the graphics will be held under the OS and will be copied there from the screen buffer after loading. Similarly, the sound routines/data will be copied to memory below $2200 after loading.

 

Oh did I say that my target machine is the 800XL (The one I had as a kid) so It'll definitely work on a PAL machine. Not sure about NTSC. A few of the test routines I have developed simply did not run when I tried NTSC emulation, but the consolidated code I have so far works under NTSC. So an NTSC version might be possible.

 

Hopefully I'll finish this game this year.

[popmilo]

It's never to late for 8bit code, look at us - It's 2012 and we are still messing with it

 

I'm still working on this but progress is very slow due to lack of time....

I'll need help with that (I'm no great artist) and sound is a dream at the moment (I'm no great musician.)...

DOS will be wiped out after this game loads....

my target machine is the 800XL...

Hopefully I'll finish this game this year...

 

You mention so many things that are same at my end that it's scary

 

Screens are built using a made up scripting language that calls subroutines such as:

...

The screen buffer is big enough for 2 screens and is looped to create a continuous scroll. Updates happen in the off screen areas and If left alone, the buffer will just loop and display whatever it contains. This is ideal for repetitive things like starfields.

 

Love your scripting idea (when ever game gets any bigger that should be used...).

 

That looping screens buffer sounds like a very good idea. That way you know scrolling just works and you can separate code for "incoming graphics" from actual scrolling.

Thinking about it - you can even distribute background drawing over multiple frames easily... I like it even more now!

 

Atari's problem is 128 characters per charset limit. Severely limits softsprite count and background quality.

One way to overcome this is virtual characters and "realtime" change of characters that are off screen at that moment.

 

There is a very good discussion that went on FormatWar recently (with very good code by Andy included)

http://formatwar.net/forums/viewtopic.php?f=5&t=245

 

Ideas like this and softsprites in multiple charsets can work miracles on A8 (imho).

 

In order to see it, one can either wait for someone else to make it, or code it themselves

[José Pereira]

 

Atari's problem is 128 characters per charset limit. Severely limits softsprite count and background quality.

One way to overcome this is virtual characters and "realtime" change of characters that are off screen at that moment.

 

There is a very good discussion that went on FormatWar recently (with very good code by Andy included)

http://formatwar.net/forums/viewtopic.php?f=5&t=245

 

Ideas like this and softsprites in multiple charsets can work miracles on A8 (imho).

 

In order to see it, one can either wait for someone else to make it, or code it themselves

 

Was thinking in EG last Night.

Just posted something at FormatWar...

Is Andy's work about the chars 'pick-up on the fly' on Flimbo's working?

And is it with the 'Interleaved' Charsets?

 

[popmilo]

...Is Andy's work about the chars 'pick-up on the fly' on Flimbo's working?

And is it with the 'Interleaved' Charsets?

Yes it does work very well.

It can work with interleaved or normal order charsets.

It is not like "there is no limit" but it is pretty powerfull

And best thing about it is that it uses little cpu.

[R6502A]

 

You mention so many things that are same at my end that it's scary

 

That looping screens buffer sounds like a very good idea. That way you know scrolling just works and you can separate code for "incoming graphics" from actual scrolling.

Thinking about it - you can even distribute background drawing over multiple frames easily... I like it even more now!

 

Atari's problem is 128 characters per charset limit. Severely limits softsprite count and background quality.

One way to overcome this is virtual characters and "realtime" change of characters that are off screen at that moment.

 

There is a very good discussion that went on FormatWar recently (with very good code by Andy included)

http://formatwar.net...c.php?f=5&t=245

 

Ideas like this and softsprites in multiple charsets can work miracles on A8 (imho).

 

With my method I don't find the 128 character limit a problem at all.

My screen format is just like this: I have 24 character sets in one contiguous block of memory, one for each character line. I plot background graphics and software sprites in the character set memory. Each character line consists of the first 80 characters of the character set (2 screens wide) and another 40, which are a repeat of the first 40 to create the loop. When the scroll routine fully displays the last screen it's jumps back to the first screen and continues scrolling. This arrangement makes draw routines easy to implement and allows them to be faster since there are less boundary calculations going on. e.g. to point to the next line of chars I add #$4 to the MSB, effectively incrementing by 1024 bytes. I'm effectively creating my own bit mapped display, but by using character screens I have the advantage of the extra colour by setting the high bit of the appropriate character.

 

In order to see it, one can either wait for someone else to make it, or code it themselves

 

I say code it. It's the only way to be sure that you know what's going on.

Edited February 9, 2012 by R6502A

[popmilo]

24K is little too much for me... But it is a proven method and if you use it properly it can look awesome.

Looking forward to seeing it in action!

 

I say code it. It's the only way to be sure that you know what's going on.

True!

[Heaven/TQA]

24k? respect... on a 56k machine...

[Heaven/TQA]

aehm. 60k machine.

[MaPa]

ehm... 62k machine?

[R6502A]

24K is little too much for me... But it is a proven method and if you use it properly it can look awesome. Looking forward to seeing it in action!

24k? respect... on a 56k machine...

 

Well not quite 24k.

The screen/buffer size is 80 x 8 = 640 leaving 384 bytes of the character set free to store other data.

 

Some of the characters in the 640+ region are to be used for areas that will be on top, in this case I'll be copying characters after updating the relevent character set memory, but mostly data will be stored there. Generally the actual background graphics are stored outside the character sets and copied to the off screen areas as the game scrolls. So the real memory hit for the screen and buffer is 640 x 24 = 15360 + (40+40+40 = 120 actual screen characters per line, giving a total of 120 * 24 = 2880 for the screen)

 

Total memory hit to support this screen/buffer is 15360 + 2880 = 18240. So for one screen/buffer we have 18240/2 = 9120.

 

For graphics mode 8 (320 x 192) we require 7680 bytes and to double buffer it you'd need 15360. Therefore there's a 18240 - 15360 (1856) byte overhead to building a screen this way.

 

The memory requirement of the screen is the main reason why the OS will be stripped to the bare minimum and DOS will be wiped out when the game runs.

Edited February 10, 2012 by R6502A