Side Scrolling Games on the A800

[emkay]

Because it hits the weakest point of the A8, many side scrolling shooters weren't really fun...

 

Let's have a look what some "over decades experienced" 8 bit coder can do with the A8.....

 

 

http://www.atariage.com/forums/topic/198204-is-thunderfox-worth-purchasing/page__st__50?do=findComment&comment=2530019

 

 

http://www.youtube.com/watch?v=Mi5U75PXMvs

 

Actually, it looks very interesting.

 

It would be interesting to see the CPU usage.... on PAL and NTSC machines.

 

Depending on the limits, just like the 128 chars .... it would be interesting to know ways for making a final game out of it.

[Rybags]

"Weakest point" - PMSL.

 

A8 can H-scroll using less CPU than practically anything. The generall crappiness of such games was more a case of lazy programmers than inadequate hardware.

[emkay]

"Weakest point" - PMSL.

 

A8 can H-scroll using less CPU than practically anything. The generall crappiness of such games was more a case of lazy programmers than inadequate hardware.

 

And hit your brain when "PxxL" ?

After 128 characters the scrolling has to be set new. Not to forget the DMA cycles that get lost, using the 48 bytes width and the lms reads...

The handling of the PMg is immense and can waste up to 80% of the CPU, if you want updates every screen at 50Hz.

Huge RAM banks help there, and, ofcourse some "advanced" experience in coding.

 

"Lazy" programmers, hit the point where people want to earn money.From their aspect, the A8 wasn't lucrative enough.

[Rybags]

Not putting effort to overcome technical barriers can fall into the "lazy" category.

 

Whether the game gets done is up to TMR. If he pulls the plug due to negativity then I can't really blame him.

[emkay]

Not sure where is the "negative" point, when someone wants to make things clear.

[Mclaneinc]

Jeebs, TMR says its a WIP that's been stalled for ages and you want to pick holes?

 

All I see here is a personal issue which is beyond the forums and one that Tempest needs to have a wee chat about imho.

 

TMR, WE appreciate the work old man, as said by a certain British person, "don't let the bas***ds grind you down"

[emkay]

Jeebs, TMR says its a WIP that's been stalled for ages and you want to pick holes?

 

All I see here is a personal issue which is beyond the forums and one that Tempest needs to have a wee chat about imho.

 

TMR, WE appreciate the work old man, as said by a certain British person, "don't let the bas***ds grind you down"

 

You are able to read or even to think?

 

I'm not writing, TMR is doing bad here. You guys really have problems.

 

Keep in the thread or keep out and don't write crap.

 

It's about - what the A8 can do - and to make it clear to people who want to write software for it.

 

Have you read and understood?

[TMR]

It would be interesting to see the CPU usage.... on PAL and NTSC machines.

 

Generally speaking, there's a small burst of CPU time taken at the VBL to update my sound effect driver, then the DLI kicks in at the top of the screen and locks it up for 160 scanlines of sprite manager, followed by about twenty scanlines of waiting and splitting for the status bar colours. Then four pixels before the end of the status after the last colour split, the interrupts are done and send a sync command to the runtime code which actually does all the game management stuff - that can take from that point to halfway down the top border under load on NTSC and stops just after the VBL at full tilt on PAL.

 

All sprite draw/clear routines are unrolled loops for speed (with the bullet being hardwired lda # / sta so it's the only object that can't animate) with live software-based X clipping and the sprite manager during the screen takes care of Y clip and scrubs the X offset table as it goes so there's no need to clear enemy objects from the player data at any point. That management loop also splits one of the enemy sprite colours every scanline (bar those with DMA fetch and there's a work-around to prevent off-colour lines at the top of objects if they're sat on those lines which means that a scanline gap needs to be left between objects to avoid conflicts now) and one of the playfield colours is updated from a table every eight scanlines with that table constantly modified during play from a script so one block of landscape using that register set to, say, reds will scroll off at the left and the next block will arrive at the right using greens - timing these changes is a scumbag for something people hardly ever comment on or even seem to notice unless i mention it... =-)

 

Depending on the limits, just like the 128 chars .... it would be interesting to know ways for making a final game out of it.

 

The current level takes about 85 characters (not all of which are used yet and some might be optimised out later) so there's still space for a little more detail and new character sets can be shunted in for each stage as well - 128 is ample space for a decent scrolling background if you're not having to worry about drawing software sprites into it. Looking at the data this morning, the only concerns i've got about space are is that the first level gobbles up 95 of the 256 tiles and the sprite data is a bit of a mess and could do with optimising. Right now all that unrolled code and fast access sprite data is crammed into 11.5K but there's another 4K given over to the scroll buffer, a couple of K for the hardware sprites and relevant tables and a few buffers for tile decoding and so on.

 

As to making a final game, what it needs right now is someone i feel i can work with who fancies making level data, sprites and backgrounds to specification - that's a regular stalling point for me and, since i still have level 4 of Callisto to add enemies to so i'm not keen on sitting down and populating a second game right now.

[Mclaneinc]

And that rather rude response actually proved every word I wrote...

 

You have picked holes in just about every subject..The word negativity is your strong point.

 

As for what I write, sorry old man, that's down to me and not some control freak, I write where and when I like as long as its re the topic or in keeping with the thread contents..

 

Have you read and understood?

Edited May 27, 2012 by Mclaneinc

[Rybags]

Jose would probably jump onboard.

 

I think an original project would be good for him.

[TMR]

After 128 characters the scrolling has to be set new. Not to forget the DMA cycles that get lost, using the 48 bytes width and the lms reads...

 

The scroller in Energy Arc uses a single LMS command and can travel up to 65 screens without any special allowances (Callisto uses the same engine but slightly more optimised to remove some of the bursts). The DMA loss is an issue because it means a consistent loop can't be used during the play area, but that just requires a partial unroll to get around.

 

Edit: the single LMS thing was a phase i went through a couple of years back, i've also got a prototype Zybex-style engine (with a

) that uses a 128x96 pixel play area and a single LMS with nine EORed software sprites over the top.

 

"Lazy" programmers, hit the point where people want to earn money.From their aspect, the A8 wasn't lucrative enough.

 

As an aside... i still don't understand why fan programmers didn't carry on where the commercially-minded people who went to other formats left off. Honestly, what Energy Arc is doing really isn't taxing if you've got perhaps a year or two with the A8 hardware (it was written a couple of years ago now before i did any really serious cycle timing on the A8) and, whilst it relies on demo coding techniques like scanline-by-scanline splitting or unrolled loops, none of this stuff was undiscovered territory - some of it is in Warhawk, other bits in a crack intro for Thrust i remember seeing, more in various demos and so on. Yeah, it's a little tricksy to time initially but it really isn't that hard and is just a logical progression from the sprite handlers in games like Mirax Force.

Edited May 27, 2012 by TMR

[TMR]

Jose would probably jump onboard.

 

I think an original project would be good for him.

 

i believe he's said previously that he can't produce original graphics...? He'd be the kind of person i'd want working on it though, because it's going to need quite a bit of attention to detail to get the landscape colour splitting thing working.

[Mclaneinc]

Come on Jose, give it a crack...

 

Looking a bit Last V8 at the mo...

[TMR]

Looking a bit Last V8 at the mo...

 

i was going for more Red Max at the time... =-)

[Mclaneinc]

Looking a bit Last V8 at the mo...

 

i was going for more Red Max at the time... =-)

 

That's the one I meant....Damn, old and senile...

 

I can't be a super stud AND intelligent..

Edited May 27, 2012 by Mclaneinc

[emkay]

After 128 characters the scrolling has to be set new. Not to forget the DMA cycles that get lost, using the 48 bytes width and the lms reads...

 

The scroller in Energy Arc uses a single LMS command and can travel up to 65 screens without any special allowances (Callisto uses the same engine but slightly more optimised to remove some of the bursts). The DMA loss is an issue because it means a consistent loop can't be used during the play area, but that just requires a partial unroll to get around.

 

As long as you keep the style of "Mirax Force" and 5 moving objects do well, it seems to work.

Btw: 160 scanlines of 240 are used, just for the handling of the moving objects. On NTSC machines this means approx. 1/3 of cpu is left in the current state.

 

Edit: the single LMS thing was a phase i went through a couple of years back, i've also got a prototype Zybex-style engine (with a

) that uses a 128x96 pixel play area and a single LMS with nine EORed software sprites over the top.

 

Half amount of screen content and 50% faster cpu...

 

 

"Lazy" programmers, hit the point where people want to earn money.From their aspect, the A8 wasn't lucrative enough.

 

As an aside... i still don't understand why fan programmers didn't carry on where the commercially-minded people who went to other formats left off. Honestly, what Energy Arc is doing really isn't taxing if you've got perhaps a year or two with the A8 hardware (it was written a couple of years ago now before i did any really serious cycle timing on the A8) and, whilst it relies on demo coding techniques like scanline-by-scanline splitting or unrolled loops, none of this stuff was undiscovered territory - some of it is in Warhawk, other bits in a crack intro for Thrust i remember seeing, more in various demos and so on. Yeah, it's a little tricksy to time initially but it really isn't that hard and is just a logical progression from the sprite handlers in games like Mirax Force.

 

One explanation is the variation of the available sources, that vary to an "unsolvable" solution, if someone presumed the availabel CPU cycles and what is available when Antic si active.

[Rybags]

Ahem... Antic 5 gives a negligible CPU saving. About 450 less DMA cycles per frame vs Antic 4.

[emkay]

Ahem... Antic 5 gives a negligible CPU saving. About 450 less DMA cycles per frame vs Antic 4.

 

Zybex is Gr.7 (mode D)... so Zybex-style to me doesn't mean charmode (5) to me .

Edited May 27, 2012 by emkay

[Rybags]

If you want a Graphics 7 game, then get programming.

[emkay]

If you want a Graphics 7 game, then get programming.

 

Unbelievable.

 

TMR mentioned the softwaresprite engine.

[TMR]

As long as you keep the style of "Mirax Force" and 5 moving objects do well, it seems to work.

 

There's actually six enemy objects in Energy Arc but the waves only use five so they can overlap a little. If i were to go PAL only (and to be honest the NTSC compatibility was a fluke, i didn't plan for it!) i could probably push it up to seven or possibly eight enemies.

 

Btw: 160 scanlines of 240 are used, just for the handling of the moving objects. On NTSC machines this means approx. 1/3 of cpu is left in the current state.

 

Nah, there's less time left than that because the code updating the game takes some of the rest. On NTSC there's probably about 20 scanlines left and possibly 40 for PAL.

 

Edit: the single LMS thing was a phase i went through a couple of years back, i've also got a prototype Zybex-style engine (with a

) that uses a 128x96 pixel play area and a single LMS with nine EORed software sprites over the top.

Half amount of screen content and 50% faster cpu...

 

More a case of wanting a contiguous screen RAM really, it removes the need for caveats in the software sprite engine without needing to force an LMS every pixel line.

 

One explanation is the variation of the available sources, that vary to an "unsolvable" solution, if someone presumed the availabel CPU cycles and what is available when Antic si active.

 

Honestly, the basic sprite recycling in Energy Arc really wouldn't be an issue without a day or perhaps two of experimentation and there's really nothing that needs serious knowledge of ANTIC timing. Forget the colour splits and it's a logical next step from something like Thunderfox or Astromeda.

[TMR]

Zybex is Gr.7 (mode D)... so Zybex-style to me doesn't mean charmode (5) to me .

 

Sorry, should've qualified that a little; when i said Zybex-style i meant it was running in bitmap mode.

 

Slight correction to what i said; the play area resolution of that engine in the video is 128x80 rather than 96, the older version had a bigger play area but i needed the extra RAM in the 4K block back for the scroller.

[emkay]

Honestly, the basic sprite recycling in Energy Arc really wouldn't be an issue without a day or perhaps two of experimentation and there's really nothing that needs serious knowledge of ANTIC timing. Forget the colour splits and it's a logical next step from something like Thunderfox or Astromeda.

 

 

 

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

 

On NTSC machines less than 10% CPU left.

 

 

Using horizontal scrolling in charmode, the 1.79MHz get wasted most. In real , less than 1.2MHz were available. The "lucky" point is that all the cycle stealing and DLI is at the "same" time.

 

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

Edited May 27, 2012 by emkay

[José Pereira]

Jose would probably jump onboard.

 

I think an original project would be good for him.

 

Thanks guys but I am not designer...

T.M.R. has good people around him to design the gfxs and sprites like in Edge Grinder.

[Creature XL]

As to making a final game, what it needs right now is someone i feel i can work with who fancies making level data, sprites and backgrounds to specification - that's a regular stalling point for me and, since i still have level 4 of Callisto to add enemies to so i'm not keen on sitting down and populating a second game right now.

 

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

For MJO he needed to "pixel inside spec" and he does. 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