Latest gfxlib news

General FreeBASIC programming questions.
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Latest gfxlib news

Postby lillo » May 30, 2005 15:36

Hello

I just finished adding a couple of new features to gfxlib... don't worry, not much ahead :)

PALETTE now supports also the new construct:

Code: Select all

PALETTE GET index, r, g, b
PALETTE GET index, color
PALETTE GET USING pal

The first retrieves current palette color index RGB values and stores them in r, g, b, in the range 0-255.
The second gets specified color index RGB and stores it as a packed value in color.
The third allows to get the entire current palette into the pal array, in packed RGB form.
These forms are specular to the usual old PALETTE setting forms, and have been added as an easier way to get the current palette instead of using the old INP/OUT tricks (which continue to be emulated in FB anyways).

Also, I've added the new SCREENSYNC built-in routine to wait for vertical blank synchronization. This is the same as doing WAIT &h3DA,8, so you don't have to remember this arcaic form.
cha0s
Site Admin
Posts: 5317
Joined: May 27, 2005 6:42
Location: Illinois
Contact:

Postby cha0s » May 30, 2005 16:16

nice man, really nice way to make this stuff nice and clean and clear, those qb hacks and numbers were useful to memorize back then, but its nice that you see them for what they are / were: dead weight :)


btw, does packed mean...

Code: Select all

type PalType

  r as ubyte
  g as ubyte
  b as ubyte
  pad as ubyte

end type


?
jofers
Posts: 1525
Joined: May 27, 2005 17:18
Contact:

Postby jofers » May 30, 2005 18:14

I think it means packing it into a 32-bit number

e.g.

"&H520501"
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » May 30, 2005 18:25

Yep, packed in the same format as accepted by PALETTE when setting up entries...

PALETTE index, &hBBGGRR

(note the inverse order of R and B against what COLOR accepts when in truecolor modes; QB used this method for PALETTE, so I couldn't modify it to be the same as color (&hRRGGBB which seems more intuitive to me) for compatibility sake)
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » May 30, 2005 19:18

Perhaps people has missed a more important improvement you made in the past days, because we talked about it in the Linux forum, not of general interest.

SCREENLOCK and ...UNLOCK are now compatible with GFXLIB primitives as PSET, LINE,PAINT, CIRCLE and PUT. Before, locking was only garanteed to work with direct memory writes....

In fact those new functions are just easier to use aliases to existent features.

That compatible screenlock ROCKS!!!
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » May 31, 2005 10:17

Thanks Antoni :)

BTW, I also just added another new little function: SCREENLIST.
This addresses a request I've had lots of times, i.e. fetching available screen modes. Here's the new description in gfxlib.txt:
Syntax:
SCREENLIST ([depth])


Insights:

The SCREENLIST function can be used to find out at runtime which fullscreen
video modes are available on the host machine. This works like the DIR$
function: you first have to call this function once requesting the list of
supported resolutions for a given color depth (supported depths are 8, 15, 16,
24 and 32); this will return the first supported resolution for the request,
encoded in an integer result such that the screen width and height are stored
in the high and low word respectively.
Next, continue calling SCREENLIST without parameters to get the next supported
resolutions, until 0 is returned.
Resolutions are returned from lowest to highest supported ones. Also, it is
safe to call this function at any time.


Example:

DIM AS INTEGER mode, w, h
'' Find which 8bit resolutions are supported
mode = SCREENLIST(8)
WHILE (mode)
w = HIWORD(mode)
h = LOWORD(mode)
PRINT STR$(w) + "x" + STR$(h)
mode = SCREENLIST
WEND

If you're wondering why using a mechanism similar to DIR$, the reason is that I wanted to keep it as simple as possible, and I also didn't want to return allocated memory and let the user play with pointers... This way you don't have to worry about it.

Changes in CVS, even though only Linux implementation is done, under Win32 SCREENLIST will always return 0 for now. I'll implement it for Win32 later today or tomorrow.
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » May 31, 2005 14:55

The Alphabetical list of keywords in the wiki will never be finished! :D

The new function is useful to programs working fullscreen, so they can set any available mode.
For windowed programs, knowing the current video mode would be more useful (to avoid setting a window bigger than the screen, or to avoid working with a color depth gfxlib must keep converting to the actual one).
jofers
Posts: 1525
Joined: May 27, 2005 17:18
Contact:

Postby jofers » May 31, 2005 16:46

Cool. V1ctor's been ramblin' on about how cool BlitzMax is... any idea on how if/how that's going to end up in fb?
relsoft
Posts: 1767
Joined: May 27, 2005 10:34
Location: Philippines
Contact:

Postby relsoft » Jun 01, 2005 7:41

Blitzmax? I had helped a person who uses it set up TinyPtc for that Dev kit.

Hi Rel,

I've been trying to get TinyPTC working under MinGW/DevCPP with no
luck, and I know from Googling around that you've managed to get it
working, so wondered if you would mind emailing a copy of your
DevCPP-compatible version?

I enjoyed the demos on your web site, but couldn't find an email
address anywhere so I have to admit I joined this QBasic forum just to ask
you!

I'm involved with BlitzMax (www.blitzmax.com), which uses MinGW, and
would really like to be able to use TinyPTC with it, but my C skills are
pretty much non-existent, so it would be much appreciated if you would
be willing to share your version!
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » Jun 03, 2005 12:42

Ok, since the new SCREENLIST function didn't really address the problem of getting the desktop resolution/depth, I've modified the existing SCREENINFO function to be more flexible and do this task as well.

SCREENINFO is now a statement and not a function anymore. This means it does not return a pointer to an internal gfxlib structure anymore (what could be troublesome for someone, plus prone to bugs as you're dealing with pointers - at least once I found out someone what deallocating the pointer returned by this function, what was causing the app to crash...).
The new SCREENINFO stores informations on the current gfx mode in the parameters passed by reference to it, if specified; here's the syntax:

Code: Select all

SCREENINFO [width][,[height][,[depth][,[bpp][,[pitch][,driver]]]]

If SCREENINFO is called when no gfx mode is set, informations on the system desktop is returned. Here's an example:

Code: Select all

SCREEN 15, 32
' Obtain info about current mode
SCREENINFO w, h, depth,,,driver_name$
PRINT STR$(w) + "x" + STR$(h) + "x" + STR$(depth);
PRINT " using " + driver_name$ + " driver"
SLEEP
' Quit gfx mode and obtain info about desktop
SCREEN 0
SCREENINFO w, h, depth
PRINT "Desktop running at " + STR$(w) + "x" + STR$(h) + "x" + STR$(depth);

Changes in CVS.
DrV
Site Admin
Posts: 2116
Joined: May 27, 2005 18:39
Location: Midwestern USA
Contact:

Postby DrV » Jun 03, 2005 12:58

Just to let you know, I am still working on the DOS gfxlib driver. :) I managed to format the hard disk of my development machine by accident, so I lost most of my recent progress, but I think I can rewrite it without too much trouble. I did discover that hooking a timer interrupt and updating the screen during that works prettty well - faster than updating on each unlock call. I'll try to have at least minimal SCREEN 13 and 14 support for the next release and linear and banked VESA later (maybe for the next release if it's still pretty far away. :)
DrV
Site Admin
Posts: 2116
Joined: May 27, 2005 18:39
Location: Midwestern USA
Contact:

Postby DrV » Jun 03, 2005 17:38

Related to new SCREENINFO, perhaps it would be useful to be able to retrieve the actual refresh rate, because the requested refresh rate is not guaranteed.
lillo
Site Admin
Posts: 447
Joined: May 27, 2005 8:00
Location: Rome, Italy
Contact:

Postby lillo » Jun 03, 2005 18:22

Done. Now SCREENINFO syntax is this:

Code: Select all

SCREENINFO [w][,[h][,[depth][,[bpp][,[pitch][,[rate][,driver]]]]]


Where the current refresh rate in Hertz will be returned in rate, or 0 if unable to retrieve it.
Antoni
Posts: 1393
Joined: May 27, 2005 15:40
Location: Barcelona, Spain

Postby Antoni » Jun 03, 2005 19:34

Thanks, lillo!

And great news, DrV!!!

Return to “General”

Who is online

Users browsing this forum: No registered users and 5 guests