Easy to port?

[Heaven/TQA]

would something like this nice for us A8? we could at least use multicolour PMs for the ship...

 

http://www.xeo3.org/

[Tezz]

That looks pretty cool Heaven. That's interesting that you are thinking about this. I have been looking through some of the c-16 titles since TMR mentioned the other day that the porting path would be more logical from this platform. Thrust as we mentioned in that thread is 16k.. This Plus/4 project seems good too as it too is a more logical source with less hardware specific

[emkay]

You have to keep in mind that the single scanline modes on the A8 take heavy cycle stealing, while double scanline modes can give a real speed up.

I guess, on the Plus 4 this detail level is possible, because this "used mode" doesn't do cycle stealing.

(fulll colour text mode has two lines of cycle stealing on the plus 4).

On the other hand.... the bus of the C64 is double of cpu clocking? Not sure about the plus4.

[Heaven/TQA]

oh... but i have forgotten that the plus 4 has 256 chars... but going for antic e would be the way to go maybe...

[gauntman]

I have watched that project on and off. It has some interesting ideas, and very nice pixel artist(s).

 

BTW, 256 characters are definitely useful for cacheing soft-sprites. I think in one of the blogs, a discussion of the cache system is made.

 

It would be interesting to see if an ANTIC e version could be made. (Perhaps with MWP scrolling? This could help minimize the background drawing, but double buffering would be trickier).

[TMR]

I guess, on the Plus 4 this detail level is possible, because this "used mode" doesn't do cycle stealing.

(fulll colour text mode has two lines of cycle stealing on the plus 4).

 

The Plus/4 (like the C64) doesn't have the option of disabling it's colour fetches and they're still happening as usual and taking the cycles from the CPU; the colour RAM has been washed with a single value to avoid having to scroll that extra data.

 

On the other hand.... the bus of the C64 is double of cpu clocking? Not sure about the plus4.

 

The C64 loses 40 cycles on a badline, the Plus/4 loses the same so 80 per badline pair.

[Rybags]

I don't see why not - there is a distinct lack of scrolling games on the A8 which employ software sprites.

 

Software sprites and multiplexed PMGs could be used. Doing software sprites against a fine-scrolling background isn't really much extra work vs a static bg.

 

Of course, only having 128 characters available becomes a liability at times, but there is always the option to use multiple charsets.

 

The "normal" background graphics could use (e.g.) 80 characters (which are replicated in each charset), leaving the remainder to be dynamically allocated for softsprites which are generated as needed.

 

A well written softsprite character generator can do 10 or more 8x16 characters in a frame, although you of course need to leave cycles free for generating new screen data.

[TMR]

Of course, only having 128 characters available becomes a liability at times, but there is always the option to use multiple charsets.

 

The main problem is that, currently, Xeo3 uses around 128 characters for a level background alone, that's before the software sprite rendering space and the fixed chars for bullets are allowed for; i can't see any way that using multiple fonts will help because the background character use is pretty much arbitary.

 

So the short answer to the original question is "no, it's not easy to port" because it'll need either a radical paring down of the background graphics or conversion to use bitmap and either way that's a fairly substantial recoding.

[Rybags]

Well, there's always the option of a character set for every second line, or even every line.

 

90 or so chrs for BG data, the remainder redefinable.

 

Problem is, that would almost definately make it a 128K only game.

 

 

Alternatively, a bit of trickery swapping certain characters in and out of the charsets as needed could be done, to free up more for sprites.

[Tezz]

Well, there's always the option of a character set for every second line, or even every line.

 

90 or so chrs for BG data, the remainder redefinable.

Indeed, such an engine has already been created by Tebe. The 128 Char set size of the A8 is always a stumbling block particularly with the use of software sprites but as we know there's not much other option aside from multiplexing the hardware sprites, perhaps the resourceful programmers can find a clever solution, many such limitation problems have been overcome on other platforms.

[TMR]

Alternatively, a bit of trickery swapping certain characters in and out of the charsets as needed could be done, to free up more for sprites.

 

So lots of work, a major recoding of the graphics handling and not an easy port then...?

[carmel_andrews]

I do recall that there was a type in listing in 'Atari User' magazine (August or September 1987 edition) by Richard Vanner as part of the 'Special FX' Series (or was it vanier) apparently the listing produced over 80 PMG's on a screen

 

BY PMG's, I'm assuming that means Hardware Sprites (PMG's)

Edited January 4, 2008 by carmel_andrews

[TMR]

I do recall that there was a type in listing in 'Atari User' magazine (August or September 1987 edition) by Richard Vanner as part of the 'Special FX' Series (or was it vanier) apparently the listing produced over 80 PMG's on a screen

 

That doesn't help, they're all locked on "rails" and can't be used arbitarily like Xeo3 does with it's software sprites. The same sort of technique can put 120 sprites on the C64 screen but it's utterly useless for games.

[Rybags]

In the meantime, some Galaga backdrop to keep you occupied...

 

pmg1.zip

 

Closer to 1,000 there... but leaves near zero time for anything else.

[+Philsan]

In the meantime, some Galaga backdrop to keep you occupied...

Beautiful!

Can you remove the cursor?

[Rybags]

pmg2.zip

 

Proper direction this time too.

[GameEngine]

Someone has to make bank-switching RAM cartridge with bank of 256 (128?) bytes first.

[TMR]

Someone has to make bank-switching RAM cartridge with bank of 256 (128?) bytes first.

 

Erm... why?

[Rybags]

One way of swapping out part of a chset, I guess.

 

I think whether or not the source code for this game becomes available might have more bearing on if it gets ported to other 6502 systems than any technical hurdles that have to be bypassed.

 

It may well pass that a lot of games, be they ports or not, in future might require 128K due to massive inline coding being required to obtain the desired performance.

[GameEngine]

Someone has to make bank-switching RAM cartridge with bank of 256 (128?) bytes first.

 

Erm... why?

One way of swapping out part of a chset, I guess.

 

Yes. Other then this I do not see how it can be improvement over the original. If it is ported from weaker system and in the end same or inferior on Atari then why to do this (plenty of work and nothing really to show - it would be like Yoomp! on C64).

 

PS

I know it would be a bit of cheating but I consider it less then putting SID in Plus/4 case.

[Rybags]

How could it possibly be inferior if done correctly?

 

128 characters, and lack of a SID is the only limitation.

 

More than made up for by PM graphics, one extra sound voice, and around 40% faster net CPU speed. Not to mention much more powerful scrolling abilities.

 

And, as the authors said, they only use the basic MC mode without attribute RAM.

[GameEngine]

The game is not yet ready (at least last time I checked it was not ready) so we need to make some assumptions first. Let's say they need 64 characters for sprites and 32 for animated backgrounds. Lets assume Atari conversion needs 3 character sets and it takes twice as much time to update all of them so we have 64+(32*2). So we need 33 more CPU time on Atari. Fortunately we have few cycles left so we can handle character set exceptions. We unroll playfield so we are able to drive Pokey so music is as good as generated by SID. We end up with PMG not being used but we do not have resources to drive them … or we are lucky and we use them to create colorful / interlaced / interleaved underlays for software sprites. Which proves one thing: I am a pessimist

Edited January 5, 2008 by GameEngine

[Rybags]

Atari could use PMGs for either/both player's ship and weaponry in addition to softsprites.

 

For softsprites of 8x16 dimension, typically you'll need 9 characters allocated for each, except for cases when they are on certain pixel boundaries which might drop it down to 6 or 4 (which can also bring CPU cycle savings).

You also gain savings if the target character is a blank, or the character which will overlay is completely opaque (no masking needed).

 

But, regardless of that, you only create a definition for each character in the one target chset.

 

It could well become a programming juggling act, but not impossible.

Edited January 5, 2008 by Rybags

[GameEngine]

Ok, I agree. If anyone attempts this do please put level editor in scope - just to raise the bar a bit

[Rybags]

According to the Wiki article, the Plus4 runs at about the same speed as the Atari.

 

That raises the bar a bit more... but Atari can play catchup by implementing much more efficient scrolling methods.

 

I've also read some of the 'blog - seems to infer that the game runs at 25 FPS - looking at the video, the sprites seem to be single frame but the scrolling may well be every second frame.