60 replies to this topic

[emkay]

Tempest, on Fri May 25, 2012 7:19 PM, said:

Knock it off everyone.

I'm only responding to the title of the thread. Those games - like Thunderfox - took place at the weakest point of the A8. Unexperienced coders hit fast the direct limits of the A8 there and release the "unfinished" game.
The difference of work between such game, and to have it all moving freely, is immense. like a factor of 10. So people who wanted to earn money swapped over to other machines where their work was better payed.

[TMR]

emkay, on Sat May 26, 2012 2:51 AM, said:

I'm only responding to the title of the thread. Those games - like Thunderfox - took place at the weakest point of the A8. Unexperienced coders hit fast the direct limits of the A8 there and release the "unfinished" game.

They can still be playable games though, shoot 'em ups don't need much to make them fun, just a player craft, enemies, bullets and off we go! Since i lump Thunderfox in with Mirax Force, Humanoid and other games that use similar sprite handling, i'm always going to prefer Humanoid because i like fixed speed scrollers more than multi-directional - i'd pick Humanoid over Dropzone most of the time for the same reason.

emkay, on Sat May 26, 2012 2:51 AM, said:

The difference of work between such game, and to have it all moving freely, is immense. like a factor of 10. So people who wanted to earn money swapped over to other machines where their work was better payed.

Free vertical movement for enemies using a similar technique to Thunderfox is actually pretty easy; the only issue is that when objects cross on the player 3/4 "stack" and it'll be the last one drawn that gets priority on the scanlines they're both using (for the other scanlines, both objects are visible) so if the draw order is reversed every other frame, objects'll "time share" those crossed spaces (one object getting priority on odd frames, the other on even) and both remain at least partially visible. YouTube pretty much nukes that flickering and there's only a couple of test enemies, but this engine test uses that method.[1]

Going further from that... well, i wouldn't have said it was more difficult by a factor of ten but that next step involves using similar techniques for sort-based multiplexing as Armalyte uses on the C64 so yes, it is harder to do. =-)

[1] i say "engine test" but it's pretty much a full game that just lacks cosmetic code and, importantly, level data...

[therealbountybob]

To be honest I've just found possbily the best A8 scrolling shooter (ok I've not played the fantastic Aquatron for ages) and it's name is Vanguard - yes, really. I thought it was only an average game with poor controls but after playing it for 2 weeks (moonlighting and kicking butt ) in the 5200 HSC, the game is superb once you work out how to play (use the games Rapid fire setting with bursts of manual fire). Read my comments on Post 43 and others. Don't be put off by holding in fire and wondering why you can't move - the first round is much slower and the game just gets better and better. The game has varied game play, exhilarating scrolling, progressive difficulty (I'm up to the 5th round so far) superb sounds, good graphics, very addictive 10/10

p.s. if you NTSC guys do get a PAL working setup checout Zone X another great game

[emkay]

TMR, on Sat May 26, 2012 6:16 AM, said:

Going further from that... well, i wouldn't have said it was more difficult by a factor of ten but that next step involves using similar techniques for sort-based multiplexing as Armalyte uses on the C64 so yes, it is harder to do. =-)

For such games you don't even get bothered with the limitations of the C64, so you can start thinking of a working game , without writing a "flickering multiplexer" first.
btw: 10 times....
A sprite on the C64 takes one "LDA / STA" command for the vertical position. A 10 line high 3 colour PM object needs an "LDA/STA" 20 times plus clearing routines.... plus the multiplexer.... plus the sorting....
At least, you can save cycles by disabling the PM DMA, when doing this multiplexing, where the sprites on the C64 always take their cycles.
Using no DMA there, also saves cpu cycles from "clearing data", and it makes it possible to re use the PMg in a scanline aswell....
So it depends on the complexity of an engine , how much expense is needed for such a game.

10 times is a good approximation there...

Edited by emkay, Sat May 26, 2012 8:12 AM.

[Mclaneinc]

Jesus, someone rename Emkays avatar to 'Thread stopper'....

Never have i seen a person debate so much based upon 'perceived knowledge' as opposed to hands on quality coding time..

Its like going to the hospital (as i do a lot) and hearing the opinion of an F1 about your condition, sorry but I trust only the consultant every time..(F1 only watchy & leany , consultant done learny and do'ey many times)

Edited by Mclaneinc, Sat May 26, 2012 8:34 AM.

[Tempest]

Last warning to everyone to cut it out.

[emkay]

According to the title of the thread....

If it's for the cause of collecting A800 software, it is worth to purchase the game.

[TMR]

emkay, on Sat May 26, 2012 8:09 AM, said:

For such games you don't even get bothered with the limitations of the C64, so you can start thinking of a working game , without writing a "flickering multiplexer" first.

And that's what i said when you said that the same knowledge used to produce Thunderfox could translate to code "games like Armalyte". If you just write something without being bothered with the C64's limitations you get a game like Radius and that's leagues away from what Armalyte does on pretty much any level. If you write something on the C64 with Thunderfox-style sprite recycling you get Delta or perhaps Danger Zone with scrolling and, again, not in the same ballpark as Armalyte technically.

emkay, on Sat May 26, 2012 8:09 AM, said:

btw: 10 times....
A sprite on the C64 takes one "LDA / STA" command for the vertical position. A 10 line high 3 colour PM object needs an "LDA/STA" 20 times plus clearing routines.... plus the multiplexer.... plus the sorting....

That's not what you were challenged over; to remind you, i was responding to your statement in post #51 that "Those games - like Thunderfox - took place at the weakest point of the A8. Unexperienced coders hit fast the direct limits of the A8 there and release the "unfinished" game. The difference of work between such game, and to have it all moving freely, is immense. like a factor of 10" (my emphasis) so how the C64 handles things is irrelevant because we're just talking A8. i'll ask again though because i'm intrigued and what you said doesn't tally with my own experiences; going from Thunderfox to something with free vertical motion on objects, where are you getting that factor of ten from?

For reference, my solution in that video has flicker, yes, but only when two objects co-exist on the same scanline - the wave data in use was modified to deliberately make those conflicts happen because i was talking about what it does under those circumstances and wanted a visual demonstration. If the enemies are scripted to avoid conflicts (as in this second video with the original test waves restored but no sound because i'd left the mute on in A8Win... oops =-) it handles six enemies with occasional flicker at the extremities and only then if an object event is mistimed in the script (that isn't happening in the video, by the way). It still has free vertical motion in the sense that it doesn't matter which object slot is assigned to an enemy at spawn (in fact they change slot order if enemies are shot, the engine always grabs the lowest-numbered available one) and the wave manager can be told to make objects cross and cause flicker if i ask it to but i'll always try to avoid that in a working game.

(Callisto is similar in some respects, it has totally free vertical placement of objects but via a sorting multiplexer and i've scripted them to within an inch of their lives to prevent overloading of sprites on a scanline.)

[TMR]

Since this thread is "responsible" for me spending an evening prodding at the source code i might as well post this... objects now use a dark grey for low light but have two shades of a colour each, the background colour has been changed, lots of behind-the-scenes code tidying has taken place and end of level detection enabled. For a project i've been calling "stalled" that's quite a bit of work! =-)

[Gunstar]

TMR, on Sat May 26, 2012 7:23 PM, said:

Since this thread is "responsible" for me spending an evening prodding at the source code i might as well post this... objects now use a dark grey for low light but have two shades of a colour each, the background colour has been changed, lots of behind-the-scenes code tidying has taken place and end of level detection enabled. For a project i've been calling "stalled" that's quite a bit of work! =-)

it looks frickin' awsome, but then I'd rather play it than watch it...

[Mclaneinc]

Top stuff TMR....Looks great.....

Won't please Emkay but who cares