TMR

Heaven/TQA, on Sun May 27, 2012 2:25 PM, said:

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. =-)

Heaven/TQA, on Sun May 27, 2012 2:25 PM, said:

Dunno, never understood it either!

Creature XL, on Sun May 27, 2012 12:43 PM, said:

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

Creature XL, on Sun May 27, 2012 12:43 PM, said:

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. =-)

emkay, on Sun May 27, 2012 12:21 PM, said:

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.

emkay, on Sun May 27, 2012 12:21 PM, said:

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!

emkay, on Sun May 27, 2012 12:21 PM, said:

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.

emkay, on Sun May 27, 2012 5:45 AM, said:

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, on Sun May 27, 2012 5:27 AM, said:

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.

emkay, on Sun May 27, 2012 5:27 AM, said:

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.

emkay, on Sun May 27, 2012 5:27 AM, said:

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.

emkay, on Sun May 27, 2012 5:27 AM, said:

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.