Side Scrolling Games on the A800

[TMR]

Using 6 enemies.... to get flicker... 5 without flicker...

 

The engine handles six without flicker (it does happen for fleeting moments in the video) and i could add a seventh to the object pool without compromising stability at least for PAL.

 

And the whole thing is currently single buffer (sprites and backgrounds) but if i went over to double buffering and 25FPS movement it'd handle upwards of ten enemies with no problem - that just doesn't appeal to me as a developer though.

 

On NTSC machines less than 10% CPU left.

 

That's not a worry to me really, i don't tend to target NTSC on the A8 and Energy Arc works more from luck than judgement!

 

If a "beginner" of coding isn't aware of things like that, the game will never get finished.

 

Most beginners aren't aware of anything really, they just try things and then find themselves wondering why it's all flickery when the CPU load for one refresh takes longer than a frame. i've never met a programmer who didn't do engine tests or spend time working out rough cycle counts because they had those moments as a beginner where they'd dive in headfirst and have the project fall over - i'm the same and for everything i've shown there's usually three or four prototypes in my work folders that are stable but not quite what i wanted.

 

But anyone with even a little A8 experience under their belt has usually done the classic lda table,x / sta wsync / sta register loop during DLI and a more basic version of what Energy Arc does without colour changes or sneaky inline table reset can be done like that over a character-based screen as long as it doesn't go over 40 bytes wide (so 32 bytes wide with hardware scrolling or 40 bytes without) so getting something halfway working is pretty easy - then it's a matter of trying to figure out how to work around the one scanline in eight hiccups.

[TMR]

what about asking Exin? He can do original gfx and he knows the limits of the machine very well.

 

i've been chatting to someone in the background (s'cuse the pun) about it already... =-)

 

To do the map you/he can use Charpad. I am pretty sure you know how to use its output, buf ig not I can help

 

i've always used the old version of Char Pad for the A8 and i've got a dedicated tool i wrote a while back for extracting CTM files that i fudged for it - it checks the attribute RAM in a tile and, when it finds a specific colour, it adds 128 to the relevant character so it's using the extra playfield colour. =-)

[Heaven/TQA]

TMR what is the single LMS all about? Similar to MCS analmux described? (and I never went into it?)

[TMR]

TMR what is the single LMS all about?

 

S'just a matter of bumping the LMS once every X frames and drawing a new column in at whatever column of screen RAM is about to arrive at the right. =-)

 

Similar to MCS analmux described? (and I never went into it?)

 

Dunno, never understood it either!

[analmux]

TMR what is the single LMS all about? Similar to MCS analmux described? (and I never went into it?)

 

I didn't invent MCS (Multi Coloured Screen: ask emkay). I assume you mean MWP (Minimal Wrapping Principle), related to scrolling. Search for MWP on the AA-forum. If you need files (demos / code), then you can ask me, by PM.

 

By the way, I've got just a toy-idea about PAL vs NTSC. I'm thinking of some kind of standard rule. When using PAL, use ANTIC4 gfx & when using NTSC, use ANTIC5 gfx. But, in both cases you could use appr. 240 scanlines. Or, maybe it's not that ideal yet. Doing this all in gfx-mode would really be better, i.e. graphics 15 (PAL) vs graphics 7 (NTSC), as then the internal ANTIC gfx-buffer would really help. (Unfortunately not in font-modes.)

[Heaven/TQA]

I mean MWP of course

[snicklin]

@TMR / Jason,

 

Here's a decent link for an explanation of the technique.

 

http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=Ironman%20Atari#section-Ironman+Atari-MWP

 

I've never played with it, but I can imagine that some pretty good possibilities come from it.

[TMR]

Here's a decent link for an explanation of the technique.

 

http://atariwiki.strotmann.de/wiki/Wiki.jsp?page=Ironman%20Atari#section-Ironman+Atari-MWP

 

I've never played with it, but I can imagine that some pretty good possibilities come from it.

 

Ah, that makes more sense... but nah, that's overcomplicating things for something like a fixed speed shooter! If i throw 2K at the screen RAM at my single LMS engine it can scroll a distance of twenty screens without needing any stops for a buffer swap.

 

That's an interesting page generally... i wrote a high resolution scroller similar to the one mentioned but in bitmap already; it's not very efficient since i didn't even start on optimising, but it scrolls a 256 by 160 pixel area at one pixel every frame with two buffers offset by a pixel! =-)

[snicklin]

I think that the MWP technique would be excellent for something like 'Alex Kidd in Miracle World' which scrolls down first and then later goes onto scroll horizontally in a large world. This is something that we don't really see in many Atari games (if any).

 

I'd like to implement a character based MWP system in a huge world based around large tiles (4x4 or 8x8). Those tiles then would indexed according to their location to different character sets and where there is an overlap, I'd have some blander tiles which can be used in more than one character set. Plus, the colour schemes would be indexed according to where they are in the world. Some huge worlds could then be made in a relatively low amount of RAM potentially.

 

This is all in theory, I don't have the time to do this. If I win the EuroMillions jackpot, I'll employ you Jason to do it for me!!

[+Stephen]

@TMR / Jason,

 

Here's a decent link for an explanation of the technique.

 

http://atariwiki.str...onman Atari-MWP

 

I've never played with it, but I can imagine that some pretty good possibilities come from it.

I must be really stupid because no matter how many times I read this, I can't make sense of it

[Heaven/TQA]

never got into benefit of MWP... ok... I am fanboy of the gameboy approach (having 2 screens for scrolling in x-direction and building the screen "behind" the visible screen by collums or having 2 screens in y-direction. so for a x-y-multidirection screen my approach would be 4x 1000 bytes for a 40x25 visible screen.

 

ok... 4k vs 1000+/- is a point to look into it again.

 

but still would need an easy explanation to be honest.

[Creature XL]

never got into benefit of MWP... ok... I am fanboy of the gameboy approach (having 2 screens for scrolling in x-direction and building the screen "behind" the visible screen by collums or having 2 screens in y-direction. so for a x-y-multidirection screen my approach would be 4x 1000 bytes for a 40x25 visible screen.

 

ok... 4k vs 1000+/- is a point to look into it again.

 

but still would need an easy explanation to be honest.

 

I didn't understand teh MWP explaination as well.

However, I think I had something planned like you describe above for MJO, however, when you scroll down AND up its not easy - at least on the memory.

So, i guess I developed something similar to MWP. I use two line buffers and have an LMS in every line. Works wonderful and if you ever completed MJO, you would see its really big map. Think it has 1082 lines with 2x2 char tiles. So around 2060 ANTIC 4 lines

 

For a horizontal scrolling my approach would not work, AFAIK.

[TMR]

The description is a bit arcane but it seems to be similar to what i'm already doing for horizontal with that second LMS forcing a wrap around to make it efficient for vertical - i still can't help seeing it as overly complicated just to get that low screen RAM count but that's probably just me...

[Creature XL]

The description is a bit arcane but it seems to be similar to what i'm already doing for horizontal with that second LMS forcing a wrap around to make it efficient for vertical - i still can't help seeing it as overly complicated just to get that low screen RAM count but that's probably just me...

 

Have you read the Minter-Article just before you wrote that?

Its the 2nd time in my live that I have read/heard the word "arcane"

First time was, when reading the article 5 minutes ago.

[TMR]

The description is a bit arcane...

 

Have you read the Minter-Article just before you wrote that?

Its the 2nd time in my live that I have read/heard the word "arcane"

First time was, when reading the article 5 minutes ago.

 

Now you're asking... i did look at it but can't remember if i posted to this thread first or not! It wouldn't be the first time though... =-)

[snicklin]

I must be really stupid because no matter how many times I read this, I can't make sense of it

 

I must admit, I had to read it a few times.

[Heaven/TQA]

thx TMR... it is really so damned easy that I thought it is far more complicated....

 

;1 LMS scroller

vram	equ $7000

	org $4000
start	
	jsr wait_vbl
	
	lda #<dlist
	sta 560
	lda #>dlist
	sta 561
	
loop	jsr wait_vbl
	jsr set_collum
	inc lms
	jmp loop
	
wait_vbl	lda #12
	sta 540
wait0	lda 540
	bne wait0
	rts
			
set_collum
	ldx lms
	txa
	and #1
:24		sta vram+#*40,x
	rts
	
	
	.align $100
dlist	.byte $70,$70,$70
	.byte $42
lms		.word vram
:23		.byte 2
	.byte $41
	.word dlist
	
	run start

mwp1.zip

Edited May 31, 2012 by Heaven/TQA

[MaPa]

But this is not MWP

[Heaven/TQA]

I know... but it will envolve... and that's why it has MWP as filename

 

MaPa. can you explain again the MWP?

 

had a conversation with TMR yesterday and to be honest... as far as I know most games use for scrolling maps LMS per line? but why if you could handle that via the simple way?

 

all my books have scrolling tile maps examples with "scrolling windows" done via LMSs/line.

[MaPa]

I'm not the right person to explain MWP technique. I just once took an example and modified it for my purpose.. It was really pain to get it working.

 

You can imagine it as you can point LMS instructions only to a fixed video RAM window i.e. $1000 - $13FF. Then DLIST in MWP uses two LMS instructions. First at the beginning of course which points to location of actual begin of displayed screen and then second LMS which is dynamically positioned within DLIST as it needs at the end of "fixed" window to point back at the start of it.

 

Example: you have fixed window $1000-$13FF, you already scrolled somewhere so your first LMS points at $1300. So you have to after 6 lines insert another LMS instruction which will point at $1000 again. If your fisrt LMS will point at $1200, then the second is needed after 12 lines etc. All you do is to wrap the continual video ram back at the beginning when the next line would exceed the the "fixed" window.

[TMR]

had a conversation with TMR yesterday and to be honest... as far as I know most games use for scrolling maps LMS per line? but why if you could handle that via the simple way?

 

all my books have scrolling tile maps examples with "scrolling windows" done via LMSs/line.

 

i suspect that's the reason really, the books all say "here's a way to make it work" and, since it does work most people'll just keep using it. That's just human nature and fair enough as far as i'm concerned, if it does the job there's no point in doing something more complicated/copnvoluted unless the gain is worthwhile.

 

i only wandered off to do silly things like trying to get everything handled by one LMS because it's a challenge really, i got the idea from some of the CRTC-based 8-bits.

[analmux]

@ Heaven & MaPa,

 

As far as I remember, someone told me that the MWP engine should be easily understandable for average coders.

 

the source of the scroll engine was published by analmux and is available... but it seems that it'S far too advanced for the average coder

 

Are you joking? Even an average coder could finish this "engine" if he really wants to. But why? If I want to play SMB I take my NES or SNES or an emulator. Ok, I cannot play it on Atari - but who really cares? ...

 

 

See here:

 

http://www.atariage.com/forums/topic/35280-super-mario-clone-being-written-now/page__st__250?do=findComment&comment=946073

 

Apparently Chrodegang had no problems understanding my fully working scrolling engine.

[Heaven/TQA]

but I am not Chrodegang.

[kenjennings]

. . .as far as I know most games use for scrolling maps LMS per line? but why if you could handle that via the simple way?

 

all my books have scrolling tile maps examples with "scrolling windows" done via LMSs/line.

 

The LMS-per-line is the simple way starting from De Re Atari and everything after. This way the entire screen is always in memory. All the published tutorials from back in the 80s that I recall only expected to scroll around a limited map a couple screens in each direction. I don't remember any scrolling tutorial that presented the scroll-forever problem. (Though, I can think of a couple games from the 80s that did this effect, but never dissected the code to figure out how it was being accomplished.) The one-LMS solution is a non-obvious, head-slap moment. It seems like anarchy to think about it, but in the end it works almost like magic.

[analmux]

but I am not Chrodegang.

Pfff....forget it, I was just joking. His comments were a bit nonsense.