What can make your prog. even more powerful is 'nfo_findgfxentry()'
function that is a part of 'qdev'. If you are a programmer and you
like this kind of philosophy, then feel free to use it whenever
you need to play with screen modes as this may really help your
As to interface it may look simple, but you can construct quite
a complex queries, which does not necessarily mean it may become too
complex. No, it rather means powerful ;-) .
Lets start by explaining the query, which may be somewhat confusing
"<[modeid] | [XxY[xD]]> [[rlow] [rhigh] | [monname]] [flag] [...]"
^^^^^^ ^^^ ^^ ^^^^^^^^^^^^ ^^^^^^^ ^^^^
1 2 3 4 5 6
If you need to make sure that given 'modeid' is available on this
system then you just pass it in one of four numeral systems(decimal,
hexadecimal - $ or 0x, octal - q or 0o, binary - % or 0b). You can
additionally narrow searching to 'monname', which is a monitor name
that should be bound to this 'modeid'. Mode property flags can also
be used, but this will narrow even more.
Another way to ask for modeid is to pass just the resolution and
maybe the depth. This has many advantages, such as: no need to
know those cryptic mode identifiers who may differ from system to
system, there is a great matching probability this way and more
control over the desired display properties. While 'XxY' template
is quite obvious, the optional 'xD' requires some explanation since
it is not just the depth as you understand it.
By default depth in the resolution query is set to 2 bits. This means
specifically that the screen mode must support at least 4 colors for
you to be usable and it really does not matter what type of screen
this is, like: CMAP, HAM, EHB, etc. Anything will do. Of course you
can narrow the search to what you need by using property flags, but
there is a quicker way! You can express your color requirements
by specifying depth in full range where:
1 - The screen must really be capable of displaying 2 colors.
First matching resolution will be used.
2 - Anything will do. In the worst case you will be limited
to a colour mapped screen that supports just 4 colors.
3,4 - Anything that can display 8 and more colors(OCS/ECS/AGA).
At this point the screen will still be opened even if no
'setpatch' was started.
5 - You need at least 32 colors(ECS/AGA). May require enhanced
modes to be activated by the 'setpatch'.
6 - You require something that can display at least 64 colors,
including EHB and HAM. This could still be ECS.
7,8 - You really need 128 and more colors which will be AGA or
32-25 - You definetly want true color display, but other RGB modes
will also do.
24-17 - You want 16M color mode, but other RGB modes will also do.
16 - You want 64k color mode, but of course lower RGB mode will
15-9 - You either want 32k color mode or landed here due to lack
of better RGB mode.
I dont know if you see that already, but the strategy is as follows.
Passing at least 2 in depth allows anything to be picked which is yet
workable(lets hope so). Passing 32 will try to match RGB mode at all,
which is to say will downstep to even 15 in worst case, but will not
go any lower.
Ranges are very useful if you want to narrow the search to say chip
type or particular monitor. Range is simply modeid region in which
you search for a desired resolution. For instance:
0x00000000 - 0x0000FFFF - Is a place where startup monitor lives
(implicit) and that monitor can be
registered in another place too! By
default 'rlow' is set to 0x0000FFFF to
0x0000FFFF - 0x0002FFFF - Is a place where PAL and NTSC monitors
have their identifiers.
0x0002FFFF - 0x000AFFFF - All other native monitors(MULTISCAN,
DBLPAL, EURO72,...) can be found here.
0x000AFFFF - 0xFFFFFFFE - All non-standard maybe native monitors
are located here. But mostly this is a
place for gfx boards.
If you do not like the idea of ranges, then you can use monitor names
to resolve particular resolution. This way you can be sure that what
you seek for will stay within this very monitor. Please note that
even though you are allowed to use patterns in monitor name, you
should really only use the non-wildcard matching. This is because
monitor name will expand to the actual monitor range, where
wildcards may cause some side effects! One such case is 'NTSC'. If
you specify '#?NTSC' and you also use 'DblNTSC' then the range will
be surely bogus.
Another issue is 'PAL' monitor name. Since one of the property flags
is also 'pal' , you will have to use 'P?L' if you are asking for the
If you want to request some resolution within current monitor then
use virtual monitor called 'ACTIVE'.
Flags allow to narrow or expand search criteria. Most of them are
screen mode related, but there are also flags who have some impact on
the resolution. Below is a list of all standard flags. I will not
comment on them since they are more or less explained in
'graphics/displayinfo.h' file, besides it is easy to guess what some
of them mean.
There are also two non-standard flags who really help matching the
resolution by establishing some tolerance.
similar - By using this flag or maybe modifier you agree that the
final resolution can be smaller than what you really
look for. For instance, if you want '640x400', but this
system offers highest possible resolution of '320x400',
then it will be picked. You can combine this flag along
with 'ycofact' for better results.
ycofact - By using this modifier you tell the routine to tolerate
Y resolution skew, so that matching is non-perfect.
This in particular means that providing '640x400' on a
system that can offer only '640x480' or '640x512' will
allow these to be used.
Interesingly or not '640x400x4 similar ycofact' is the most safe
setup on every Amiga. It just cannot fail.
Despite the casing of names used in this article all the monitor and
flag names are case insensitive.