288 pixels horizontal resolution

[HornBeamSoft]

Few days ago I play Agony.
I made screen shot under uae and get that screen is 288 pixels wide.
I was almost sure that Amiga resolution in lores is 320 pixels?
I found in some sites that 320 pixels horizontal resolution is often reduced to 288 pixels wide to provide the game more time to process sprites, color changes object blitting etc.
I don't found how to change Amiga horizontal resolution to 288 pixels.
How to do this?

[alexh]

I don't think you can but I am far from an expert.

I think you use a lowres 320x256 buffer and render fewer pixels into it?

[ross]

Originally Posted by HornBeamSoft

I found in some sites that 320 pixels horizontal resolution is often reduced to 288 pixels wide to provide the game more time to process sprites, color changes object blitting etc.

In Amiga you cannot change the base pixel clock.
So it means that if you want to display less than 320 pixels you have to narrow the view (the pixel is the same size).
Basically less data fetched for the screen, more time for other stuff.

[Thomas Richter]

Originally Posted by HornBeamSoft

Few days ago I play Agony.
I made screen shot under uae and get that screen is 288 pixels wide.
I was almost sure that Amiga resolution in lores is 320 pixels?

The horizontal resolution is whatever you make it to be. The DIWSTART and DIWSTOP registers allow you to position and size the playfield window, the DDFSTART and DDFSTOP registers allow you to control the playfield DMA.

Originally Posted by HornBeamSoft

I found in some sites that 320 pixels horizontal resolution is often reduced to 288 pixels wide to provide the game more time to process sprites, color changes object blitting etc.

Indeed, you need to move DDFSTART to the right (i.e. the playfield to the right) to free more slots for sprite DMA.


Or, from the operating point of view, adjust the overscan preferences, which is pretty much doing the same, but in an Os-friendly way.


That it's 320 pixels is more a convention, one can change that within limits. You cannot change the pixel clock (i.e. the speed by which pixels are delivered), but you can adjust the width and height of the playfield.

[Rock'n Roll]

Agony Level 1

0005e9ce: 008e 2d90 ; DIWSTRT := 0x2d90
0005e9d2: 0090 00a0 ; DIWSTOP := 0x00a0
0005e9d6: 0092 0038 ; DDFSTRT := 0x0038
0005e9da: 0094 00c8 ; DDFSTOP := 0x00c8
BPLCON0 6600 ; lowres, 6 bitplanes, dual playfield

That is:
DDFSTRT = 0x0038 DDFSTOP = 0x00B8 (calculated)
top left_y =002D (=45) , top left_x =0090 (=144)
bottom right_y =0100 (=256), bottom right_x =01A0 (=416)
width=272 height=211 screensize 7174 bytes

[Rotareneg]

You could get 160 pixel wide screen modes on AGA, but I'm not sure about ECS.

[HornBeamSoft]

Now is clear hot to do it to me. Thank You All.

[aros-sg]

Originally Posted by Thomas Richter

You cannot change the pixel clock

Btw, how do modes like "EURO72:160 x 200" (a standard mode/monitor coming with the OS) manage to get 160 horizontal pixel resolution (it really does, I remember trying it on Microvitec Monitor in the 90s) if there's only 35, 70, 140 ns pixel clocks?

[ross]

Originally Posted by aros-sg

Btw, how do modes like "EURO72:160 x 200" (a standard mode/monitor coming with the OS) manage to get 160 horizontal pixel resolution (it really does, I remember trying it on Microvitec Monitor in the 90s) if there's only 35, 70, 140 ns pixel clocks?

It just double the horizontal frequency (using 140ns pixel clock).

[aros-sg]

Originally Posted by ross

It just double the horizontal frequency (using 140ns pixel clock).

So could you have something like a ~ 256x250 (multiply 160 x 200 by 1.25) screenmode with not double but only ~ 1.25 higher horizontal frequency?

[ross]

Originally Posted by aros-sg

So could you have something like a ~ 256x250 (multiply 160 x 200 by 1.25) screenmode with not double but only ~ 1.25 higher horizontal frequency?

It's the opposite, you have to lower the frequency (both horizontal and vertical), if you are using EURO72.
But anyway yes, the concept is that

EDIT:
in fact in ECS and AGA you can vary the video frequencies as you like and create any resolution you want with the base clock of 35ns and multiples (x1, x2 and x4).
The problem is a devices that can support it.
Also with the clock of 35.24ns (in PAL machines) you can not reach very high resolutions, that is something more than the VGA which have a pixel clock of 39.72ns.

EDIT2:
an example with ECS/OSSC:
https://eab.abime.net/showpost.php?p...2&postcount=11


To tell the truth for some technical issues it would be better to use less pixels in x and the two lower lines have the 'mark' of central synchronism, but let's say that 400x300 works great. And the frequency is the pure standard PAL one.
No problem on AGA and you can also double or quadruple the x resolution without any particular restrictions.

[Rock'n Roll]

Agony DIWSTRT is not optimal, or?
DIWSTRT: 0x2D90 is DDFSTRT 0x38, but
DIWSTRT: 0x2D91 would be DDFSTRT 0x40 (ok, one px lose)
or they could take DIWSTRT: 0x2d81 for a bigger view

if I make the screen narrower with diwstrt and diwstop and leave ddfstrt and ddfstop as it is,
do I lose cycles for the cpu or does it not matter?
(of course, optimal would be to calculate the values for ddfstrt and ddfstop, or?)

[Rock'n Roll]

0005e9ce: 008e 2d90 ; DIWSTRT := 0x2d90
0005e9d2: 0090 00a0 ; DIWSTOP := 0x00a0
0005e9d6: 0092 0038 ; DDFSTRT := 0x0038
0005e9da: 0094 00c8 ; DDFSTOP := 0x00c8

in my opinion better would be:
DIWSTRT := 0x2d91 with DDFSTRT := 0x0040
DIWSTOP := 0x00a1 with DDFSTRT := 0x00C0
because alignment with DDF-borders
screenwidth is 272px (17*16Bit)

[ross]

But aren't Agony' video DIW values set that way due to fine scroll? You need a larger DDF for it...

[VladR]

Originally Posted by Rotareneg

You could get 160 pixel wide screen modes on AGA, but I'm not sure about ECS.

Would that be a native mode ? This is very interesting!
I always thought 160x200 would be very practical for a SW rasterizer on Amiga, and not just 3D flatshading, but racing games in particular would really benefit from this.

Like, you could have a really nice racing game at 160x200 and EHB. This resolution would halve the amount of bitplane fetches, so EHB there should be faster than 320x200x4 BPL, right ?

320x200x4 BPL : 8,000 (40 x 200) x 4 = 32,000
160x200x6 BPL : 4,000 (20 x 200) x 6 = 24,000

This also means there's enough time for Copper to switch palette 2-3 times across the screen and allow for both additional 64 colors for the skybox and some additional shading (say, for fog into distance).
Lock the framerate to 20 fps (but do not allow for single framedrop, so must account for all spiked) and it's a very colorful game.

[ross]

Originally Posted by VladR

Would that be a native mode ?

http://eab.abime.net/showpost.php?p=1549622&postcount=9

[VladR]

Originally Posted by ross

EDIT:
in fact in ECS and AGA you can vary the video frequencies as you like and create any resolution you want with the base clock of 35ns and multiples (x1, x2 and x4).

Do I get that right that ECS is the lowest config capable of native 160x200 then ? Meaning, you can't adjust the frequencies same way on OCS ?

[ross]

Originally Posted by VladR

Do I get that right that ECS is the lowest config capable of native 160x200 then ? Meaning, you can't adjust the frequencies same way on OCS ?

Right.
And also there is the problem that a device that supports the frequency is required (no longer a PAL or NTSC standard).

[VladR]

Originally Posted by ross

Right.
And also there is the problem that a device that supports the frequency is required (no longer a PAL or NTSC standard).

Thanks.

I imagine CRT monitors to be finicky about the required frequency, that was quite fun back in the day...

But these days with LCD, this shouldn't be an issue, I reckon ?

160x200 on AGA would be probably quite ridiculed, but on ECS it just might be acceptable...

[rothers]

How would sprites behave in such a resolution?