Amiga Screen Resolutions, Modes & Overscan

[EDanaII]

Greetings All,

I posted this earlier, but it looks like I accidentally posted it in a News Forum. I'm guessing the moderator hasn't approved it yet. Yo, Mod? Don't bother, my bad, or if you do, by chance, approve it, remove it instead.

Anywho... for some time now, I've been playing with various Amiga C++ Frameworks with little or no success. So, just for giggles, I decided to experiment with my own. First I created a prototype meant simply to open a window and communicate with it. Next, also just for giggles, since we're talkin' Amiga here, I created a class for Displays (Screens). At present, using it looks something like this:

Code: [Select]


IntuitionBase = IntuitionLibrary.GetIntuitionBase( );

Display screen = Display(320, 200);
screen.SetLocation(0, 120);
screen.DisplayMode = DisplayModeId::LoRes;
screen.OverscanMode = OverscanModeId::Text;
screen.SetTitle("Low Res Screen.");
screen.open( );
Delay(50 * 5);

screen.close( );
IntuitionLibrary.close( );


Now, the DisplayMode and it's associated enum, DisplayModeId derive their values from the C header file, graphics/modeid.h, and what I'm wondering is this: doesn't the modeid effectively determine the resolution? If I specify LORES_KEY (from modeid.h) isn't that the same as declaring a screen resolution of 320x200? And specifying it as HIRES_KEY would be the same as declaring a 640x200 resolution, while declaring HIRESLACE_KEY is the same as 640x400?

I ask because, at present, I'm declaring a screen as "Display screen = Display(320, 200)" when it seems to me this should be the same as "Display(DisplayModeId::LoRes)".

Of course, this then begs the question, what about Overscan? How does it further affect the resolution? If the developer declares LOWRES_KEY and an overscan of OSCAN_MAX, how does this increase the display area? Does know where I might look to further define how these two modes interact?

Thoughts welcome.

[Zac67]

Don't know if I got you right but screen dimensions and display mode are somewhat independent on the Amiga. You can e.g. open a 320 wide screen in Hires, filling only part of the screen. The overscan settings define the maximum visible size within a certain mode. Overscan just widens the window in which screen data is displayed. It doesn't do anything to the pixels themselves.

[EDanaII]

Ah... you're right. It's been so long that I'd forgot about the fact that the Amiga would scroll if you defined an area too large for the screen. So, since they are independent, the current method for screen creation seems fine.

Thanks for the response.

[EDanaII]

OK, next question for any who care to answer.

I walked through the intuition_protos.h file looking for routines I need to incorporate into a C++ Screen class and I found these:

Code: [Select]

BOOL CloseScreen( struct Screen *screen );
VOID DisplayBeep( struct Screen *screen );
VOID MoveScreen( struct Screen *screen, LONG dx, LONG dy );
VOID ScreenToBack( struct Screen *screen );
VOID ScreenToFront( struct Screen *screen );
VOID ShowTitle( struct Screen *screen, LONG showIt );
LONG MakeScreen( struct Screen *screen );
? LONG RemakeDisplay( VOID );
? LONG RethinkDisplay( VOID );
LONG GetScreenData( APTR buffer, ULONG size, ULONG type, CONST struct Screen *screen );
struct Screen *LockPubScreen( CONST_STRPTR name );
VOID UnlockPubScreen( CONST_STRPTR name, struct Screen *screen );
struct List *LockPubScreenList( VOID );
VOID UnlockPubScreenList( VOID );
STRPTR NextPubScreen( CONST struct Screen *screen, STRPTR namebuf );
VOID SetDefaultPubScreen( CONST_STRPTR name );
UWORD SetPubScreenModes( ULONG modes );
UWORD PubScreenStatus( struct Screen *screen, ULONG statusFlags );
struct Screen *OpenScreenTagList( CONST struct NewScreen *newScreen, CONST struct TagItem *tagList );
struct Screen *OpenScreenTags( CONST struct NewScreen *newScreen, ULONG tag1Type, ... );
struct ScreenBuffer *AllocScreenBuffer( struct Screen *sc, struct BitMap *bm, ULONG flags );
VOID FreeScreenBuffer( struct Screen *sc, struct ScreenBuffer *sb );
ULONG ChangeScreenBuffer( struct Screen *sc, struct ScreenBuffer *sb );
VOID ScreenDepth( struct Screen *screen, ULONG flags, APTR reserved );
VOID ScreenPosition( struct Screen *screen, ULONG flags, LONG x1, LONG y1, LONG x2, LONG y2 );

The two routines with the ? in front of them I'm assuming affect screens and may need to be incorporated somehow into my Display class, but I'm not sure and there wasn't much in the way of comments regarding them, so clues there would be appreciated.

I basically assumed anything with screen in it was something I needed to focus on. Is there anything I'm missing here? Someplace else I need to look? Again, clues appreciated.

Finally, I need to add events to such a class. Obvious events would be ones like: OnOpen(), OnClose(), OnRaiseLower(), OnMove, etc... Does anyone have any thoughts on these?

Thanks again.

[Zac67]

AFAIR RemakeDisplay() and RethinkDisplay() are only necessary when you're working with custom Copper lists.

[...]
Yes, here it is:

RethinkDisplay()

RethinkDisplay() reworks Intuition's internal state data, rethinks the relationship of all of the
screen ViewPorts to each other and reconstructs the entire Intuition display by calling the
graphics primitives MrgCop() and LoadView(). This includes all the screens in the display, not
just the ones controlled by your program. It is especially handy if you are creating custom
screens and want to make up your own lists of Copper instructions for handling the display.
For more information about the Copper, see the Amiga ROM Kernel Manual and Amiga
Hardware Reference Manual.

RethinkDisplay() makes calls to the graphics primitives MrgCop() and LoadView(), which causes
the display of Intuition's screens to be reconstructed. MrgCop() merges all the various Copper
instructions for different ViewPorts of the display into a single instruction stream. This creates
a complete set of instructions for each display field (complete scanning of the video beam from
top to bottom of the video display). LoadView() uses this merged Copper instruction list to
create the display. Before calling RethinkDisplay(), you may wish to call MakeScreen() to create
the Copper instruction list for your own custom screens.
Note that RethinkDisplay() can take several milliseconds to run, and it locks out all other tasks
while it runs. This can seriously degrade the performance of the multi-tasking Executive, so
don't use this routine lightly.

RemakeDisplay()

The function RemakeDisplay reconstructs the entire Intuition display. It calls MakeScreen() for
every screen in the system and then calls RethinkDisplay(). As with RethinkDisplay(), RemakeDisplay()
can take several milliseconds to run, and it locks out all other tasks while it runs.
This can seriously degrade the performance of the multi-tasking Executive, so do not use this
routine lightly.