SUB HUNTER on C64, now ported to CPC... When A8 version?

[popmilo]

Its only three layers of background scroll in C64 version, so only 6 changes of Hscroll are needed per frame.

 

And double buffering bitmap screen shouldn't be a problem unless pre-shifted sprites take away lots of ram ?

[simonl]

Its only three layers of background scroll in C64 version, so only 6 changes of Hscroll are needed per frame.

 

And double buffering bitmap screen shouldn't be a problem unless pre-shifted sprites take away lots of ram ?

 

If you're smooth scrolling a bitmap on a 48 byte wide screen I reckon you'd need about this much of each strip uncompressed (the black line at the top shows 48 bytes width).

 

 

So approx 88 bytes width x 32 lines for this strip, haven't looked at the others in detail to see if they all wrap at the same length, but this means you're looking at ∼5k for this strip when double buffering, and it might be more convenient to pad the lines to a power of 2 to avoid LMS wraparound problems or to simplify the pointer maths required. Obviously you can't use LMS to mirror lines above and below, as any soft sprites would also be mirrored. It's probably doable but might be more painful than using the sorting/vcount approach. Of course in char mode it would be a different kettle of fish but then doing the soft sprites becomes significantly more difficult.

 

Cheers,

 

Simon

[Rybags]

Character mode would be the way to go.

 

In bitmap, you have to save/restore all of the data involved. In char mode, only need to save the character values then use a reserved range of characters for softsprites.

 

Either way is more complicated than standard because an object can overlay 2 areas with entirely different scroll/offset values, but it's not a game-stopper.

 

Some saving could be realised due to smaller double-buffering size although of course most of that is offset by the need for multiple charsets.

 

Additional saving can be had in that certain parts of the softsprite mightn't need to be merged, e.g. in a largish object the stuff in the middle is almost always opaque, so in charmode you just put the character there without needing to do masking.

 

 

BTW, Simon - how's "Downfall" coming along?

[simonl]

BTW, Simon - how's "Downfall" coming along?

 

Hey, first rule of Downfall club is you don't talk about Downfall club!

 

No, really well at the moment thanks, I must fire up the PC and make a video at some point so I can show the progress (the Mac emulator I'm using doesn't support video capture). I'd say it's about 70% complete now. Here's a couple of screenshots but they don't convey much of an impression of movement:

 

 

Cheers,

 

Simon

[José Pereira]

 

José, can you post the sizes in pixels of the repeating bands of background and I can try some calculations to see whether it's easy to fit in 64k with two buffers? They look like they'd be good candidates for RLE for the ones that aren't displayed currently, so they could be uncompressed to the buffers at the start of each stage.

 

Cheers,

 

Simon

 

-> 4 ANTIC4 CharLines in 40bytes wide

-> 152scanlines in Playing Area Height 48bytes wide: 32+24+16+( 8 )+16+24+32

 

Original C64 have 40bytes wide, is that any problem for an A8 48bytes wide?

Edited September 7, 2011 by José Pereira

[simonl]

 

José, can you post the sizes in pixels of the repeating bands of background and I can try some calculations to see whether it's easy to fit in 64k with two buffers? They look like they'd be good candidates for RLE for the ones that aren't displayed currently, so they could be uncompressed to the buffers at the start of each stage.

 

Cheers,

 

Simon

 

-> 4 ANTIC4 CharLines in 40bytes wide

-> 152scanlines in Playing Area Height 48bytes wide: 32+24+16+( 8 )+16+24+32

 

Original C64 have 40bytes wide, is that any problem for an A8 48bytes wide?

 

Assuming they all wrap to the same length as the example I tried, you're looking at about 13kb per buffer, so having two of those on an unexpanded machine might not leave a lot for code etc., especially as you need four shifted versions of each frame of animation for the parallax, so that indicates that using VCOUNT and vertical sorting on a single buffer would probably be the way to go if you want hires.

 

Personally I would use the 130XE extended CPU/extended ANTIC modes and double buffer but that would restrict the audience somewhat - still, it would be nice to have some software that actually used those modes as they were intended, there's only one or two demos I can think of.

 

The other option would be to make it a cart and switch in data as needed but then you're reserving another 8kb for special purposes which would make writing the code even more painful. As Rybags suggests you could use a char mode instead (no need to use PF3 with the graphics you've produced) but that makes the soft sprites more complex - still, you could use the endless vistas of RAM it frees up for a lot of tables or unrolled code to speed the process up.

 

Cheers,

 

Simon

[Heaven/TQA]

two things...

 

regarding 48 bytes.

 

I guess that this would be possible but most of the time TMR asked the right question regarding 40 vs 48... does it affect game play? you would spot enemies "earlier" than initially "designed".

 

regarding gfx modes.

 

I guess that I would try bitmap mode which makes the sprite routine simpler as bitmap mode would make sprite routine simpler (?) but if faster I don't know. I am thinking about handling the splitting scrolling zones which might be more complicated because of the crossing zones.

 

Jose I asked you already but what is the max amount if the sprites per frame?

[Rybags]

It's scrolling so there's 48 characters regardless.

 

I think character mode would be quicker overall because the Restore operation is so much simpler. No need to buffer all that bitmap data, just the 9, 12, 16, whatever characters that get changed.

[José Pereira]

two things...

 

regarding 48 bytes.

 

I guess that this would be possible but most of the time TMR asked the right question regarding 40 vs 48... does it affect game play? you would spot enemies "earlier" than initially "designed".

 

regarding gfx modes.

 

I guess that I would try bitmap mode which makes the sprite routine simpler as bitmap mode would make sprite routine simpler (?) but if faster I don't know. I am thinking about handling the splitting scrolling zones which might be more complicated because of the crossing zones.

 

Jose I asked you already but what is the max amount if the sprites per frame?

 

Sprites Normal C64 width 3bytes+1byte shifting.

They are from 13->21scanlines tall but mostly less than 16scanlines.

 

Maximum on screen are 10.

 

Submarine and Shoot and then 2or3Enemys each scanline, never more than 5each scanline/10 on all screen.

 

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

But the 10Enemys Maximum are in 'No scrolling' Levels: see this at 0:26

On the others there are only the traditional 8sprites of C64 on all screen maximum, most of the times there are only 6.

 

 

--------------------------------------

SCROLLING ZONES:

They are totally 'independent' from the others, I think you just need to scroll them at different scroll nºs.

Edited September 8, 2011 by José Pereira

[José Pereira]

To see if I understand:

"Why it would be best in Char-Mode?"

In Bitmap we wouldn't waste scanlines cycles in the soft sprites vertical shifting...

 

Sprites 4byte (with shifting) x 16scanlines (most of them) would need more 8scanlines of shifting.

8 x 4 = 32bytes (something like 16cycles x 32 = 512cycles waste in each soft sprite?

 

And the Bad Lines?

 

 

 

In Char Mode I check and the game would need 3Charsets:

-> Nº1: Top and Bottom Status Area

-> Nº2: Top Parallax

-> Nº3: Bottom Parallax.

(Cycles wouldn't be many more cycles, just 4x48cycles of the first Charset scanlines, right?

Or we need to have the 48bytes 'wasted' in all the screen 1st char scanline, even if not a Charset begin there? Probably we need to 'waste' that's why they are all considered Bad Lines in the Char Modes...)

Like:

-> TOP STATUS: Charset

-> TOP PARALLAX: Charset

-> BOTTOM PARALLAX: Charset

-> BOTTOM STATUS: Charset (Load and display the same Charset used on Top Status Area)

 

 

For the Top and bottom Parallax chars there's free space for soft sprites...

Edited September 8, 2011 by José Pereira

[simonl]

The primary advantage is that you need a lot less memory - the backgrounds are very repetitive so wouldn't take that many chars, and a 96 x 19 scrolling buffer takes a lot less memory than a 96 x 156 scrolling buffer. As far as vertical shifting is concerned if you arrange the chars dedicated to, say a 3 x 3 softsprite in the char set as:

 

a d g

b e h

c f i

 

etc.

 

Then this is not so much of an issue, however it takes a lot of cycles to copy a background char, apply a mask and then write the sprite data unless you use unrolled code in immediate mode.

 

btw, can someone explain to me what a "bad line" is in the context of a char mode? Do you just mean "one where there's an LMS instruction"? Not a term I'm familiar with.

 

Cheers,

 

Simon

[ANTIQ]

ANTIC uses more cycles on the first line of each character row as it fetches the character codes.

[simonl]

ANTIC uses more cycles on the first line of each character row as it fetches the character codes.

 

More than, say, a mode E line with an LMS? Or is it just "bad" compared to the other seven scan lines of the character row?

 

Sounds like Commodore talk to me

 

Cheers,

 

Simon

[José Pereira]

ANTIC uses more cycles on the first line of each character row as it fetches the character codes.

 

More than, say, a mode E line with an LMS? Or is it just "bad" compared to the other seven scan lines of the character row?

 

Sounds like Commodore talk to me

 

Cheers,

 

Simon

 

 

Bad because you have, for example here, in 48bytes wide, in Char-Mode 1st Line large waste of cycles:

48(bytes wide) + 48 (ANTIC Chaset) + 1 + 1 (refresh)

Lost something 98 out of 114cycles.

 

In Bitmap you would have what? Only (48+1)cycles without DLIs.?

[simonl]

Bad because you have, for example here, in 48bytes wide, in Char-Mode 1st Line large waste of cycles:

48(bytes wide) + 48 (ANTIC Chaset) + 1 + 1 (refresh)

Lost something 98 out of 114cycles.

 

In Bitmap you would have what? Only (48+1)cycles without DLIs.?

 

Oh, I see what you mean now, just hadn't heard it called that before. Still, it's only about 900 more cycles of DMA for the screen so shouldn't affect the overall result much either way. Personally I say go for hires, double buffering and extended antic/extended cpu bank switching, but then... I'm a bad person

 

Cheers,

 

Simon

[Heaven/TQA]

bad lines is a c64 wording...

 

of course soft sprites might be good using char mode... but my gutt feeling tells me that bitmap mode would be easier esp if you are crossing zones for the parallax.

 

no badlines, too... ok... maybe for the LMS lines but well... not as much as in char mode. and... if using bitmap mode... in a potential plus version game can be improved by using not zone based parallax but scanline based parallax like in Street Fighter 2...

[Heaven/TQA]

and again my question... will "fullscreen" affect gameplay? 32 pixel on each side of the screen you could see enemies earlier than intended...

[José Pereira]

and again my question... will "fullscreen" affect gameplay? 32 pixel on each side of the screen you could see enemies earlier than intended...

 

If that's a question then C64 38bytes and CPC 32bytes would be what? Less space then intended for the Enemys?

 

If we think in Normal/Older T.Vs. then 38 to 42bytes seen on A8 isn't all that much...

[José Pereira]

It's scrolling so there's 48 characters regardless.

 

I think character mode would be quicker overall because the Restore operation is so much simpler. No need to buffer all that bitmap data, just the 9, 12, 16, whatever characters that get changed.

 

 

If I am understanding this, or probably not...

 

I have char "A' that is one ANTIC4 char that is 1byte wide and 8scanlines tall.

That would be something like this:

-> Bitmap Mode: I must do 'LDA,AND,OR,STA' to put it over the Gfx. and then move 'A' to the next Gfx. char, restore the previous Gfx., and so on...

This 'A' will move Horizontal and need 1byte more for shifting.

Then I would have <two 'LDA,AND,OR,STA' each scanline> x 8scanlines x 21cycles (Bitmap Masking per each byte) = 336cycles.

 

-> Char-Mode: what's the difference?

Don't you have to do the same for all the bytes like in Bitmap Mode?

(and even more 8scanlines shifting for the 'empty' scanlines if the soft sprite also move vertically? On a Bitmap Mode there's no need for vertical shifting)

 

 

(P.s.- I know that 2ways of doing:

-> <LDA,AND,OR,STA>, <LDA,AND,OR,STA> for each byte... More cycles waste but less Memory waste

OR

-> Like a Basic Looping 'For, Next, Return'... I think it's what you call 'BRUTE FORCE'... More Memory needed but less cycles

 

 

Or Am I mess this and one More cycles is another and vice-versa.

Read this somewhere but don't remember where...

 

 

 

Anybody helps?

Or at least explain the real reason why 'waste more cycles for chars scanlines shifting in ANTIC4' and not use 'Bitmap that waste less cycles per soft sprite, as there isn't need vertical scanlines shifting on soft sprites'?

 

 

Edited September 9, 2011 by José Pereira

[José Pereira]

and again my question... will "fullscreen" affect gameplay? 32 pixel on each side of the screen you could see enemies earlier than intended...

 

 

But C64 moves one Hi-Resolution pixel and Atari will move 2Hi-Resolution pixels/colour clock.

If it will be at 50fps then what you see first on screen on A8 wouldn't be 'reset' because the Enemys would move at one colour clock?

 

Probably the bad would be that horizontal 1colour clock/2Hi-Resolution pixels and vertical movement would be the same 1scanline in C64 and also on A8...

But that the problem also on CPC and it seems a good version.

(By the way, the CPC seems the opposite as there are sometimes many Enemys on screen and just 32bytes wide... for me it seems more Bad than we are thinking in 48bytes wides, that trully would be 42bytes wide seen on Normal TVs./A8 old displays...)

Edited September 9, 2011 by José Pereira

[Heaven/TQA]

ah, ok... c64 in highres movements? ok... hmmm... and the cpc is 32 charscreen? ok... so don't care... go for fullscreen...

[José Pereira]

ah, ok... c64 in highres movements? ok... hmmm... and the cpc is 32 charscreen? ok... so don't care... go for fullscreen...

 

 

Really?

Because we so 'Emkayed by ' that I sometimes stop just watching the to see what's the meaning...

 

 

-> C64 38bytes wide and Hi-resolution movement (size of screen with Enemys)

 

<A8 42bytes,or some TVs. 48bytes wide would go into a middle between these two according to (nº of Enemys)vs(screen width)>

 

-> CPC 32bytes wide and like our 2:1/colour clock (when there's lots of Enemys they are very close to eachother)

[José Pereira]

C64

A8

ENTERPRISE (yes, just a straight port of CPC... These Z80s. can get direct ports of all the other Z80s., almost the same, Enterprise can Emulate 4colours in 320wide, I think but also 160 16colours, amazing (there's a ZX/CPC port of Last Ninja 2). seems a complete/total copy of a CPC and it isn't a Schneider officially Amstrad release in Germany.)

 

C64 have the Enemys with something like 14bytes between the Enemys on a 38bytes wide screen

The Enemys on A8 aren't really centered but they have 15bytes between them (but would need something like 18or19bytes between them...) and moving at 2:1 pixels in a 48wide screen.

CPC/ENTERPRISE have only 12bytes between Enemys moving at the same 2:1 ratio and on a small size screen of 32bytes only.

Edited September 9, 2011 by José Pereira

[popmilo]

...

Personally I would use the 130XE extended CPU/extended ANTIC modes and double buffer but that would restrict the audience somewhat - still, it would be nice to have some software that actually used those modes as they were intended, there's only one or two demos I can think of.

...

What do you mean by '130xe extended modes' ?

I do not know about any other difference beside additional 64k ram.

 

------------------------

On scrolling and sprites:

 

What ever method is used (hscroll for zones or multiple charsets for shifted positions of background), soft sprite routine would have to handle "transition" of vertical zones.

 

What is different is that if hscroll is used - shift value for sprites also changes when crossing zones.

 

So maybe it is simpler to use multiple charsets instead of hardware scrolling.

Plus screen doesn't have to be 48 wide then - more cpu cycles available.

 

Only question is what is the maximum number of unique characters in one zone ?

 

---------------------------

Bitmap mode would be simpler, but I'm not sure cpu can handle all that data with decent speed

 

---------------------------

On CPC version:

 

How did CPC handle scrolling +sprites ?

Is background shifted every frame ?

It is amazing how Z80 can handle 16kb of graphics on amstrad ...

[José Pereira]

You have 3Parallax on Top and more 3Parallax on Bottom.

In these kind of screens:

 

If you have one Charset for each Parallax you'll have just these chars Gfxs. in each Charset:

-> TOP Higher: 16chars

-> TOP Middle: 12chars

-> TOP Bottom: 5chars

 

-> BOTTOM Higher: 16chars

-> BOTTOM Middle: 11chars

-> BOTTOM Bottom: 26chars

--------------------------------------------------------------------------------------------------------------------------

If you get the Playing Area divided into 2zones, like:

-> TOP 3Parallax: 33chars

-> BOTTOM Parallax: 53chars

 

___________________________________________________________________________________________________________________________

 

If we think that all the soft sprites move in 4direction, and then need shifting 1byte Horiz. more 8scanlines shifting height it would be 1soft sprite=4x4 (maximum, mostly would go in just 4x3).

 

Four maximum by Line (my Planning) would be 64chars for the soft sprites.

This fits in all Charsets combinations but if you go into Horizontal Fine Scrolling values.

If you go into having 'copies' of each moving char (something, probably like CPC) then you would need what? More Three copies? Then, probably you would need to go to each Parallax=1Charset and Bottom Parallax isn't possible this way, because there's only, probably space for the Submarine soft sprite...

Edited September 9, 2011 by José Pereira