{{fbdoc item="title" value="Frequently Asked FreeBASIC Graphics Library Questions"}}----

{{anchor name="item0"}}

**""FreeBASIC"" Graphics Library questions:**
	
	==- {{anchor name="item1|How can I link/use Gfxlib?"}}==
	==- {{anchor name="item2|What about the fbgfx.bi header file?"}}==
	==- {{anchor name="item3|How are Get/Put arrays managed?"}}==
	==- {{anchor name="item4|Why is Bsave/Bload crashing?"}}==
	==- {{anchor name="item5|How can I get the red, green, blue, or alpha component of a colour?"}}==
	==- {{anchor name="item6|How can I make the 'x' button in the window header close my application?"}}==
	==- {{anchor name="item7|Can't run programs using Screen 13 or 14 in fullscreen !"}}==
	==- {{anchor name="item8|Why does Imagecreate return a NULL pointer?"}}==
	==- {{anchor name="item9|Why does a low resolution graphics screen get bigger when I maximize the window?"}}==

{{fbdoc item="back" value="DocToc|Table of Contents"}}

----

@@**""FreeBASIC"" Graphics Library questions**@@

{{anchor name="item1"}}==How can I link/use Gfxlib?==
	Gfxlib is "built in" into the language, it is not necessary to include any .bi file or to link any library explicitly. ""FreeBASIC"" detects you want to use Gfxlib when you use the [[KeyPgScreengraphics|Screen (Graphics)]] or [[KeyPgScreenres|Screenres]] statements. So to use Gfxlib, just start a graphics screen mode and use the graphics commands.

{{anchor name="item0|Back to top"}}

{{anchor name="item2"}}==What about the ##fbgfx.bi## header file?==
	The ##fbgfx.bi## header file is available for inclusion by your program, and contains constant and type definitions that may be helpful to the programmer when using Gfxlib. You do not have to explicitly include this file to use Gfxlib however; the header is only available as an aid. It contains the constants for the mode flags that can be passed to [[KeyPgScreengraphics|Screen (Graphics)]] and [[KeyPgScreenres|Screenres]], and also definitions of [[GfxScancodes|Keyboard scancodes]] and the [[GfxInternalFormats|fb.Image buffer structure]].

{{anchor name="item0|Back to top"}}

{{anchor name="item3"}}==How are Get/Put arrays managed?==
	In ""FreeBASIC"", images can be used as arrays (as in QB) or as pointers. Either way, the image data is contained in one continuous chunk. The chunk consists of an header followed by the image data. The header can be of two types (old-style and new-style) and determines the format of the following image data, for details see [[GfxInternalFormats]] .

{{anchor name="item0|Back to top"}}

{{anchor name="item4"}}==Why is Bsave/Bload crashing?==
	Bsave/Bload can only be used to load and save graphics screens in ""FreeBASIC"". It can't be used to save a text mode screen. To load and save an array check this [[FaqPgbloadworkaround|snippet using file Get/Put]] .

{{anchor name="item0|Back to top"}}

{{anchor name="item5"}}==How can I get the red, green, blue, or alpha component of a color?==

	Each byte in a color attribute corresponds with the red, green, blue, and alpha components.  The following example shows how to extract the component values from a 16, 24, or 32 bit color attribute.

{{fbdoc item="filename" value="examples/manual/faq/gfxlib2/RGB-component.bas"}}%%(freebasic)
#define rgb_a(x) ((x) Shr 24)
#define rgb_r(x) ((x) Shr 16 And 255)
#define rgb_g(x) ((x) Shr 8 And 255)
#define rgb_b(x) ((x) And 255)

dim as uinteger c
dim as integer x, y
dim as ubyte red, green, blue, alpha

'' Assume a 16, 24, or 32 bit screen mode has been set
c = Point(x, y)
red = rgb_r(c)
green = rgb_g(c)
blue = rgb_b(c)
Alpha = rgb_a(c)
%%

{{anchor name="item0|Back to top"}}

{{anchor name="item6"}}==How can I make the 'x' button in the window header close my application?==
	In windowed graphics mode you can test for the press of the window's X (close) button with ##[[KeyPgInkey|Inkey]]##, checking for the value Chr( 255 ) + "k" (which is also the code returned for Alt+F4). This applies to ""Win32"" and Linux, in DOS there is no "X" button.
	
	Here is a small example:

{{fbdoc item="filename" value="examples/manual/faq/gfxlib2/check-for-close.bas"}}%%(freebasic)
'' "X" close button example , Win32 and Linux only
Dim as String key
Screen 13
Do
  Print "Click the 'x' to close this app."
  Sleep
  key = Inkey
Loop Until key = Chr(27) Or key = Chr(255, 107) 'escape or x-button
%%

{{anchor name="item0|Back to top"}}

{{anchor name="item7"}}==Can't run programs using Screen 13 or 14 in full-screen!==
	Modern hardware and display systems often do not expose old low-resolution modes such as 320x200 directly.  On current backends this is less of a problem than it used to be: several drivers can keep the program's logical framebuffer at the requested size while presenting it centered and integer-scaled on a larger display or in a maximized window.

	This means ##Screen 13## can still behave like a ##320x200## screen to the program, while the driver presents it at a larger clean scale when possible.  If a backend cannot provide the requested mode or an integer-scaled presentation, use ##[[KeyPgScreenlist|ScreenList]]## or a safer fallback resolution such as 640x480.

{{anchor name="item0|Back to top"}}

{{anchor name="item8"}}==Why does Imagecreate return a NULL pointer?==
	[[KeyPgImagecreate|Imagecreate]] needs to create an image buffer that fits the current screen's pixel format, and it cannot do so if there is no screen mode setup yet, so it returns NULL, very likely resulting in a NULL pointer access later on that crashes the program.

	This is known to happen when Imagecreate is called //before// the graphics library was initialized with a call to [[KeyPgScreengraphics|Screen (Graphics)]] or [[KeyPgScreenres|Screenres]], as may happen when Imagecreate is called in a global constructor that is invoked before the Screen or Screenres call in the main part of the program. In such a case it is necessary to move the screen initialization into a constructor too, and have it execute before the image-creating constructors.

{{anchor name="item0|Back to top"}}

{{anchor name="item9"}}==Why does a low resolution graphics screen get bigger when I maximize the window?==
	Several GfxLib backends use centered integer scaling when the visible window or display is larger than the program's framebuffer.  For example, a ##320x200## screen on a ##1920x1080## display can be shown as a centered ##1600x1000## image at 5x scale.  The program still sees a ##320x200## framebuffer, and mouse/touch coordinates are mapped back to that logical size.

	Integer scaling is used because it keeps old pixel-art and QB-style graphics sharp.  It also avoids lying to the program about the screen size.  If you are building the runtime yourself and really want low-resolution screens to stay physically small even in a larger window or display area, build gfxlib2 with ##-DGFXLIB_NEVERSCALE##.

{{anchor name="item0|Back to top"}}

{{fbdoc item="see"}}
	- [[CompilerFAQ|Compiler FAQ]]
	- [[FaqPgrtlib|FB Runtime Library FAQ]]
	- [[FaqPggfxlib2|Frequently Asked FreeBASIC Graphics Library Questions]]

{{fbdoc item="back" value="DocToc|Table of Contents"}}
