Can overscan and parallax scrolling live together on Amiga?

[Bruce Abbott]

Originally Posted by pandy71

So if even PC doesn't use overscan in VGA by default then it was uncommon HW functionality.

Correct. Some systems even reduced the width in text mode to ensure that all the characters could be seen.

VGA can theoretically display an extra 24 lores pixels on the left and 8 pixels on the right to make a screen width of 352, but this intrudes into the front and back porches which will probably upset the black level, as well as offsetting the screen by 8 pixels. Many VGA CRTs didn't overscan the beam so you would still get a border anyway.

[pandy71]

If i recall correctly VGA granularity for display window was 4 pixels - and in Mode 13h video mode limit of video buffer size was 64KiB so 320x200 use exactly 64000 bytes i.e. leaving 1536 bytes. To overcome 64KiB limit famous Mode X need to be activated - it was quite popular later in 90's but large amount of software before Mode X "invention" (1991) was limited by standard BIOS 13h so no overscan...

[lmimmfn]

@ross, sorry, I find it hard to understand your explanation, in summary are you saying overscan steals so many DMA slots as to make sprites unusable? Could you perhaps present a diagram to show this or via one of your videos?

Sorry, I know it's complex, but intriguing all the same.

[ross]

Originally Posted by lmimmfn

.. in summary are you saying overscan steals so many DMA slots as to make sprites unusable?

I'll try to explain it simply so I'll overlook many tech details (maybe it's better to post more detailed requests in the appropriate sections, I don't want to weigh down this thread discussion too much ).

Yes, in practice with overscan (for the left side of the video line) the DMA fetches for the bitplane data can 'steal' the slots reserved for the DMA fetches for sprite data (that are in fixed time slot positions).
The sprites data are fetched in numerical order, therefore the first one that will become unusable if you 'enlarge' the view will be the number 7, then 6 and so on.

The DMA slot from which to start the video data fetch is programmable, the lower the value, the sooner the data appears on the screen.
If you also need to perform a hardware scroll you must further decrease the start value to 'mask' the 16 pixels related to the fine 'delay' in the display.

So it's always a question of compromise: do I give up on sprites or do I give up on a larger video window? How many hw sprites I really need? Do I use hardware scrolling or do I use the blitter to scroll and/or static bitmaps?

In OCS just using the hw scroll and a standard video position and already you have to give up on a couple of sprites..

Could you perhaps present a diagram to show this..

It's in the HRM.
Although in fact slightly imprecise it can give you a rough idea of how DMA slot allocation on the video line works.

You can find it online at: http://amigadev.elowar.com/read/ADCD.../node02D4.html

[mr.spiv]

Originally Posted by ross

As mentioned by DanScott there is a (small) problem on the far right black area, fixable in a convoluted way (but requiring effort and resources).

I used to fix this "far right" scrolling garbage with an attached sprite. Blitted the proper gfx into that sprite to make right edge look nice (some old crap)

[ross]

Originally Posted by mr.spiv

I used to fix this "far right" scrolling garbage with an attached sprite. Blitted the proper gfx into that sprite to make right edge look nice

Nice



[OFF-TOPIC]

(some old crap)

The link didn't open for me, but then I realized that it's simply because there is no pouet entry in Cloudflare's DNS!

Can be checked by anyone by going to:
https://www.nslookup.io/domains/www....ds/#cloudflare

Of course it can be solved by changing DNS server, but maybe better notify those responsible.
[/OFF-TOPIC]

[Jobbo]

Originally Posted by mr.spiv

I used to fix this "far right" scrolling garbage with an attached sprite. Blitted the proper gfx into that sprite to make right edge look nice (some old crap)

I fixed it with a well time bplcon1 change at the end of each line.

It’s a real pain having to do that and that otherwise you only get an extra 4 pixels on the right or something small like that.

That dma diagram does explain the sprites getting dropped. But is it just me or was that diagram always terrible! Most of it is unexplained.

[ross]

Originally Posted by Jobbo

I fixed it with a well time bplcon1 change at the end of each line.

Yep, another valid method (used in Seven Seas).

It’s a real pain having to do that and that otherwise you only get an extra 4 pixels on the right or something small like that.

They are not "extra pixels", they are normal bitmap pixels from the Denise shifter, but emitted when the comparison between the beam counter and BPLCON1 overflows (it happens misaligned "in the next line").
Unfortunately it is a side effect of having lines with 227CCK, a non-divisible value with the bit granularity of BPLCON1.

EDIT: maybe Jobbo was talking about the "extra pixels" referring to the normal ones seen using an extra fetch to the right and some defined values for BPLCON1, and I replied referring to the wrong "extra pixels" when using a 'large' BPLCON1 in addition.
Oh well, I hope we understood each other

But is it just me or was that diagram always terrible! Most of it is unexplained.

True..
Fortunately there is the DMA debugger on WinUAE, which is perfect

[kremiso]

thank you for the very detailed explain ross ++

atm im just browsing into the hol database, searching for some maybe closer matches

[mr.spiv]

Originally Posted by Jobbo

I fixed it with a well time bplcon1 change at the end of each line.

Care to explain in more detail how bplcon1 need to be changed on every possible shift?

[ross]

Originally Posted by mr.spiv

Care to explain in more detail how bplcon1 need to be changed on every possible shift?

The trick is to change to a valid BPLCON1 "for the next line" (see my previous message).

Basically the counters (both Agnus and Denise) reset a few cycles before the beam reaches the end-of-line of the display device
(you can easily notice this by changing COLOR00 at the 'beginning' of the copper line).

This however requires understanding how BPLCON1 actually works (see my post https://eab.abime.net/showpost.php?p...3&postcount=17).
And also require a cycle exact setup for BPLCON1 where the 'new' value is written exactly after the strobe that reset Denise counter (usually an exact CWAIT followed by a CMOVE).
Followed by a rewrite of the correct value for BPLCON1 for the 'real' new line.

Yes, not exactly a pleasant thing

[hooverphonique]

Originally Posted by ross

And also require a cycle exact setup for BPLCON1 where the 'new' value is written exactly after the strobe that reset Denise counter (usually an exact CWAIT followed by a CMOVE).
Followed by a rewrite of the correct value for BPLCON1 for the 'real' new line.

So you're "undoing" the scroll at end of line, then re-establishing your (new) scroll immediately after?

[ross]

Originally Posted by hooverphonique

So you're "undoing" the scroll at end of line, ..

Perhaps the word "undoing" is not exact, I would use "redo".
It is true that the CWAIT is at the end of the line, but the setting of BPLCON1 'falls' on the new line, for the correct 'different' value to compare with Denise's counter.

.. then re-establishing your (new) scroll immediately after?

Yes, but rather than 'new' I would call it 'natural' .

Then there are several ways to quickly set all the 'column' in the copper list with the right values (which are constant per frame), for example you can use the blitter.


EDIT: gah..
It seemed to me that I had already talked about this topic, but I didn't even remember when and with whom...
Finally after a search I found it and was talking about it with the very same good old Jobbo
https://eab.abime.net/showthread.php?t=108314
But the fact remains, I can’t remember a damn thing... nice..

[kremiso]

so far, this is the title with the larger area used (horizontally), and some parallax too?

ok not a platform, but its just about the idea behind

Fire! (1989)

https://hol.abime.net/556

EDIT the whdload install does contain the asm source code too, nice

[Jobbo]

Originally Posted by mr.spiv

Care to explain in more detail how bplcon1 need to be changed on every possible shift?

I'll have to go check the code if you need exact specifics but in my particular use case I have something like:


- a wait roughly before the end of the right edge.
- a move to bplcon1 with a value to patch the weirdness.
- more moves for bplxmod
- another move to bplcon1 with the value for the next line.


The value for the patched bplcon1 move is based on whatever the bplcon1 was for that line, this worked for me:

u16 patchcon1 = (bplcon1 + 0x0a) & 0x0f;
patchcon1 |= patchcon1 << 4;

[Jobbo]

It seemed to me that I had already talked about this topic, but I didn't even remember when and with whom...
Finally after a search I found it and was talking about it with the very same good old Jobbo
https://eab.abime.net/showthread.php?t=108314
But the fact remains, I can’t remember a damn thing... nice..

Haha, I also barely remember that thread, all the extra details are all in there!

[ross]

Originally Posted by Jobbo

The value for the patched bplcon1 move is based on whatever the bplcon1 was for that line, this worked for me:

u16 patchcon1 = (bplcon1 + 0x0a) & 0x0f;
patchcon1 |= patchcon1 << 4;

About the 0x0a constant: it's not a magic value.
Denise counter counts from 2 to 2*(HTOTAL+2)-1 (Agnus counts 0 to HTOTAL; Agnus granularity is CCK, Denise CCK/2).

In PAL this give a maximum possible value = 0x1c7 then a strobe reset it and restart from 0x02 (so .. 0x1c6 -> 0x1c7 -> (0x1c8) 0x02 -> 0x03 ..).
Now you can see that the masked 0x0f 'distance' from 0x1c8 and 0x002 is -6 or 0x0a.
With 227CCK per line a misalignment is unavoidable.

[mr.spiv]

Originally Posted by ross

About the 0x0a constant: it's not a magic value.

Right.. it is wichcraft

[saimon69]

Originally Posted by mr.spiv

Right.. it is wichcraft

Or, considered Amiga is a temperamental gal, B17chcraft :P

[Photon]

With a DDFSTRT / STOP of $30 / $d8, you get 16px of horizontal overscan on the right, and can use the scroll register. (Not all parallax scrolling requires the scroll register.)

Maximum horizontal overscan is 384, but there are some monitor and gameplay limitations to consider:

You might be wasting time on rendering graphics many don't see, perhaps enemies or bullets that you'd very much like to see.

If you use a 5:4 or 4:3 flatscreen monitor for display, horizontal overscan will likely be stripped.

The game's programmer must also know a little bit about the Copper. Most OCS games did very little with the Copper, and perhaps they were conservative, or it made the port quicker. Maybe it's as rare as Amiga-First games, but probably it's rarer. The reason being: it's not just the play area that should be bigger. Panels etc. graphics must also be drawn for it, and you would have noticed quite clearly if e.g. the score or number of lives were cut off by your TV (which was the most common display during the OCS game explosion).

Sprites:
As you move the left border farther out, more and more sprites are lost. This is by design: you are asking DMA slots near the left border to transfer bitplane data instead of sprite data. At the maximum overscan the first sprite is still displaying, also by design: to still be able to point and click in Workbench.