A Jaguar game with Parallax scrolling

[emkay]

a 9 color pm is not an issue... and perfect for the kernal... VBL sets the DLI bit on desired charline then waits the VSCROL scanlines to be in sync and then starts to color the players... not a big deal.

 

 

OK. Just explain pleas, how you manage the different colourisations of the protagonist crossing 8 of different scanlines depending on the DLI start.

[Heaven/TQA]

simple...

 

you know where you want to position the player? ypos

 

now calc ypos/8 then you know the charmode line where to set the DLI... ok... first you need to subtract the "border" from ypos so ypos fits to the background gfx. (first scanline = first ypos)

 

then you add the VSCROL value... and then you have the scanline corrected where to start to color the head+body...similar to 2600 technique... really nothing special. the score panel was done like this in my Boinxx example posted few days ago...

[Heaven/TQA]

in Boinxx as far as I can remember I am waiting VSCROL scanlines before I start to color the panel... otherwise it would move up with the dlist...

 

or maybe I have not understood your question?

[emkay]

simple...

 

you know where you want to position the player? ypos

 

now calc ypos/8 then you know the charmode line where to set the DLI... ok... first you need to subtract the "border" from ypos so ypos fits to the background gfx. (first scanline = first ypos)

 

then you add the VSCROL value... and then you have the scanline corrected where to start to color the head+body...similar to 2600 technique... really nothing special. the score panel was done like this in my Boinxx example posted few days ago...

 

And what is needed to set the colours at the dedicated positions?

[Heaven/TQA]

a simple color table plus a simple loop???

[emkay]

a simple color table plus a simple loop???

 

 

What is that simple loop doing ? It's the main question

 

 

 

Is it just like

wsync

wsync

wsync

wsync....

 

 

for up to the needed lines where the colourchange is needed?

Edited June 29, 2011 by emkay

[Heaven/TQA]

yup... here some pseudo-code

 

DLI

 

wait_scanlines ;compensate VSCROL

ldx shadow_vscrol ;actual vscrol value

loop

sta wsync

dex

bne loop

 

color_loop

ldx #15 ;f.e. 16 color changes

loop lda coltab_p0,x

sta wsync

sta colpm0

lda coltab_p1,x

sta colpm1

dex

bpl loop

...

 

something like this... not 100% sure if the waiting and syncing is correct. would need to look in the Boinxx source code.

Edited June 30, 2011 by Heaven/TQA

[emkay]

yup... here some pseudo-code

 

DLI

 

wait_scanlines ;compensate VSCROL

ldx shadow_vscrol ;actual vscrol value

loop

sta wsync

dex

bne loop

 

color_loop

ldx #15 ;f.e. 16 color changes

loop lda coltab_p0,x

sta wsync

sta colpm0

lda coltab_p1,x

sta colpm1

dex

bpl loop

...

 

something like this... not 100% sure if the waiting and syncing is correct. would need to look in the Boinxx source code.

 

 

That's what I thought.

 

And this makes me fuzzy

 

Wasting approx. 20 Scanlines of CPU cycles is OK. Doing stuff like PM reuse and colour change midline is wasting CPU for 20 scanlines .... hm

[Creature XL]

Available colors? doesn't it look (almost) perfectly suited for a 2600-style PMG kernel?

There should be enuff CPU time. 3 colors for the head, three for the body and three for the legs. That would be awesome!!!

 

If I find the time I try it out.

 

Interesting to see a kernel that calculates with the continous scrolling.

What has that got to do with scrolling?

Read on...

 

@Heaven (and Emkay):

I wasn't thinking about DLI (its tedious with char-mode, but could work.

What i would try is these Paddle (or Lightgun?) counters of POKEY. AFAIK (I never tested it!), you can count scan lines with them.

Of course this works best when the mainloop is doing nothing, what I think it does in this game.

 

 

PS:

If these counters doesn't work, DLIs can still be used as Heaven said. Its just a bit calculating and waiting.

[Heaven/TQA]

yup... here some pseudo-code

 

DLI

 

wait_scanlines ;compensate VSCROL

ldx shadow_vscrol ;actual vscrol value

loop

sta wsync

dex

bne loop

 

color_loop

ldx #15 ;f.e. 16 color changes

loop lda coltab_p0,x

sta wsync

sta colpm0

lda coltab_p1,x

sta colpm1

dex

bpl loop

...

 

something like this... not 100% sure if the waiting and syncing is correct. would need to look in the Boinxx source code.

 

 

That's what I thought.

 

And this makes me fuzzy

 

Wasting approx. 20 Scanlines of CPU cycles is OK. Doing stuff like PM reuse and colour change midline is wasting CPU for 20 scanlines .... hm

 

when the game is done you can spend most of the CPU for such things like midline changes... it really depends on how much is left... and you don't need to do the WSYNC stuff of course you can sync code with the beam like we have done in the HIP Bump mapping in Numen...

[Creature XL]

Wasting approx. 20 Scanlines of CPU cycles is OK. Doing stuff like PM reuse and colour change midline is wasting CPU for 20 scanlines .... hm

 

The thing with wasting is that we waste the cycles in THIS particular game ANYWAY. I Bet 10k cycles of the 30k cycles we have per frame

are spend in:

 

mainloop: jmp mainloop

 

Of course the coder of this game should say something. However, I can't imagine that he needs 30k cycles for the scrolling engine.

 

When you are considering games with 5-8 soft sprites, THEN you would waste cycles because THEN you need every cycle you can get for the soft sprites.

 

 

EDIT:

Of course it would be most awesome, if all the game fits in the vertical blank zone and we can use a kernel for the whole screen. THEN we could have different colors for every vertical stripe or just change the charset in the "void" and can use a charset for the left and one different for the right side.

Edited June 30, 2011 by Creature XL

[Rybags]

20 scanlines "wasted" - who cares?

 

The only thing that would effect is digital sound playback and even in that case a way could be devised to play the missing samples during such a DLI.

[Heaven/TQA]

first I thought that the charset rotation is done by code but when I read that it uses 16 fonts to do that... I guess that a lot of CPU cycles are free...

[sack-c0s]

 

 

Just face it - 160 x 100 would look cheap, the C64 version would be done properly and give them something to laugh at us about.

 

It would only look better on the C64 , because it would show more colours. Everything else would look cheaper on the C64. Just as the screenheigth is rather limited and the colour ram shows tearing.

Just a reminder here about the flexible graphics in YOOMP! . No chance for a stock C64 to suite it well.

 

 

Yoomp is a very different game - that makes as much sense as me saying the Atari can't run bounty bob because it doesn't have the power to run Crysis.

 

Colour RAM tearing? don't think I've ever seen it. The C64 has a blanking period just like everyone else you know

in any case I wouldn't envisage this game shifting the colour RAM around much, or most of the display for that matter.

 

2) you're saying the screen area is limited whilst discussing using 160x100? even if you double the lines you are talking 160x200 which oddly enough is identical to the C64 multicolour resolution.

 

The possibilities that I see for expanding the play area on the C64 are:

 

* open the top/bottom border and move the score into the top/bottom borders to avoid cluttering the play area and give the feel of more space. This would work on every machine and isn't

 

* open the border and exploit the $3FFF bug to continue the parallax pattern throughout the border. This would probably need the ram expansion unit to act as a basic blitter by hammering the relevant VIC address though, so I personally wouldn't bother because I like to keep things stock.

Edited June 30, 2011 by sack-c0s

[Creature XL]

* open the border and exploit the $3FFF bug to continue the parallax pattern throughout the border. This would probably need the ram expansion unit to act as a basic blitter by hammering the relevant VIC address though, so I personally wouldn't bother because I like to keep things stock.

 

Note to Simon: Use 48-byte mode. Just to show it to the C64 guys

[José Pereira]

for a vertical scrolling game I would not vote for Gr.7 game... come on... use as much resolution as possible. vertical scrolling will get faster due to the resolution. we are not talking about Yoomp here...

 

 

Never thought this:

In GR.7 or GR.13 double pixels height in Fine Vertical Scrolling we have one scanline scroll each time or two by two (A8 double) each time?

 

(And in GTIA Modes Fine Horizontal Scrolling it scrolls what? A 4:1 pixel that it's these Modes colour clock righ?)

 

Hi, can someone answer this?

About GTIA Modes and if they move in colour clock, here 4:1ratio, the PMs. at Normal width 2:1 move what 2:1 or 4:1?

 

 

 

Thanks.

José Pereira.

[Creature XL]

Here my first try with the Pots.

Looks good in atari800 (linux) but flickers from time to time on real HW.

No time to investigate now, will be done later.

 

As you may see, I use NOT the PMG color but PF2. But its the same a changing COLPM0/1

 

So, if the mainloop is completely free its no problem to use a 2600-Player-kernel

As the Pots count scanlines, it doesn't matter if the screen scrolls or not. What it needs is a DLI to restart the Pots.

And a further downside: it only works for 228 scan lines. But I think there will be ways around that limitation.

 

Emkay, if you would like to pick the colors for head, body and legs (or feet additionally?) for your freak I try to incorporate them with your gfx

kpmg.xex

Edited June 30, 2011 by Creature XL

[Rybags]

GTIA modes can't scroll horizontally like the other modes, they can only do 2 colour-clock movement, ie 1 pixel.

That's because GTIA is mixing 2 pairs of 2 bits coming from Antic, and does so without regard to what the HScrol register setting is.

Trying to use odd HScrol values will just mix up the bits between 2 pixels and make a mess.

 

Using Pots - I don't really see the point. For starters they're not accurately emulated.

Secondly, in a Kernal you tend to know where you are anyway. And if you don't you can just consult VCOUNT.

Thirdly - although XL/XE you're guaranteed that Pots 4 thru 6 will count to 228, on a 400/800 they can be any value.

 

(IIRC, 1200XL uses Pot 7 for a Jumper switch, so value not guaranteed)

Edited June 30, 2011 by Rybags

[Creature XL]

Using Pots - I don't really see the point. For starters they're not accurately emulated.

Secondly, in a Kernal you tend to know where you are anyway. And if you don't you can just consult VCOUNT.

Thirdly - although XL/XE you're guaranteed that Pots 4 thru 6 will count to 228, on a 400/800 they can be any value.

 

(IIRC, 1200XL uses Pot 7 for a Jumper switch, so value not guaranteed)

 

Firstly, I just wanted to try it out

I was of the opinion that a scanline-accurate position was needed. Of course that can be done with VCOUNT and an odd/even-test.

And I do not know where I am, as the kernel should be only active in the lines from YP to YP+16 (or something).

 

But in the end, your points are all valid. But as said, I wanted to try it out. Might as well exchange the Pots for VCOUNT...

 

EDIT:

and it is only using one Pot not all 8

Edited June 30, 2011 by Creature XL

[José Pereira]

GTIA modes can't scroll horizontally like the other modes, they can only do 2 colour-clock movement, ie 1 pixel.

That's because GTIA is mixing 2 pairs of 2 bits coming from Antic, and does so without regard to what the HScrol register setting is.

Trying to use odd HScrol values will just mix up the bits between 2 pixels and make a mess

 

 

 

If in GTIA 4:1 and scrolling you put PMs 2:1 what will happen/how the PMs would change the xPos.?

[Rybags]

If the player colour change is gone ahead with, the offset from where the DLI is to where the player starts will be an simple calculation that can be pre-determined in VBlank.

 

PMGs have nothing to do with HScrol.

[José Pereira]

If the player colour change is gone ahead with, the offset from where the DLI is to where the player starts will be an simple calculation that can be pre-determined in VBlank.

 

PMGs have nothing to do with HScrol.

This is saying that GTIA move at 4:1 but we can have/change the PMs xPos. at 2:1 abve Gfxs., right?

And if PMs. are double width (4:1) or even quadruple width (8:1) they still can be moved xPos. at 2:1 ratio?

 

(P.s.- About PMs. scanlines colour change in CharMode and Vertical scrolling: Warhawk, I think it's ANTIC4, does that.)

[Heaven/TQA]

Jose... yes...

 

you can use PMs to "mask" GTIA Pixels...

 

PMs always positioned 2:1 pixels... that's why you can not set PMs at every high-res pixel... 256 positions only... not like on c64.

[Creature XL]

Ok, here is the VCOUNT version. Its a bit more simpler to code, because it neets no "synchronization/reset DLI".

 

Works on real HW as well. However, it seems to miss a line from time to time.

I can't be arsed to check why. Its just a "proof of concept". I didn't mentioned it in the last post, but you can move it, like the other one, with STICK0

 

EDIT:

in case you wonder why it so big (almost 300 bytes) it has lots more stuff in it PMG routines and a DList.

So it wouldn't need 300 bytes in the final product.

kpmg.xex

Edited June 30, 2011 by Creature XL

[Heaven/TQA]

why using POTs... does this not sacrifice sound channels.