About
Docs
Files
Support
Index

Essentials
AutoDocs
Library functions
Cooperate
Process mastering
Debug
Own debugging kit
FGE
Smart modeid pick
Loader
Shared lib. loader
Macros
Helper macros
Structs
All the structures
Logs
Library changelogs
Tools
Progs baked inside



F
G
E

 qdev_findgfxentry.txt
-----------------------


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
users!

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
at first:

   "<[modeid] | [XxY[xD]]> [[rlow] [rhigh] | [monname]] [flag] [...]"
      ^^^^^^     ^^^ ^^      ^^^^^^^^^^^^     ^^^^^^^    ^^^^
      1          2   3       4                5          6



 1. ModeID
###############

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.



 2. Resolution
###############

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.



 3. Depth
###############

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
           graphics board.


   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
           yet do.

   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.



 4. Ranges
###############

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
                               avoid duplicates.

   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.



 5. Monitor
###############

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
monitor! 

If  you  want  to request some resolution within current monitor then
use virtual monitor called 'ACTIVE'.



 6. Flags
###############

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.

   lace
   dualpf
   pf2pri
   ham
   ecs
   aa
   pal
   sprites
   genlock
   wb
   draggable
   panelled
   beamsync 
   extrahalfbrite
   sprites_att
   sprites_chng_res
   sprites_border
   scandbl
   sprites_chng_base
   sprites_chng_pri
   dbuffer
   progbeam
   foreign


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.

---
megacz

  


No more fear cus pure HTML is here!
Copyright (C) 2013-2014 by Burnt Chip Dominators