Reinforcement Learning and
Artificial
Intelligence (RLAI) |
|
G,
a 2D graphics standard for multiple platforms and languages |
from G.g import *
import G.g
as gg.gDrawLine(...)
gStartEventLoop()
to make your windows
visible and
interactive. G
folder (gtests1,
gtests2,
etc). You can use these as examples. python
>>>from G.g import *
>>>w = Gwindow()
>>>gdFillRect(w, 0, 0, 30, 30, 'red')
>>>gStartEventLoop()
G as described herein can be obtained by downloading the file g.lisp. To install G, first load the
MCL quickdraw interface, e.g., by
(load "ccl:library;quickdraw")
(if necessary), and then load the G source file, e.g., by (load
"g.lisp")
. If you then "use" the newly created package, e.g., by
(use-package :g)
, you will have access to all the G
routines.
To avoid continual refocusing, each routine checks when it runs
whether or not the view is focused properly. It is refocused only if
necessary. The check is by checking if MCL's
*current-view*
is the same as the view. Refocusing is
done by calling focus-view
. (This trick has been disabled
for the moment because of an incompletely understood interaction with
MCL's dialog-view functions.)
A similar trick is done to prevent unneeded calls to set-fore-color
.
The last foreground color
set on each view is stored with the view. It is set again only if a new
color is
asked for. This assumes color-codes are never changed, i.e., that they
are used
only with G routines. It also assumes no other processes are changing
the
foreground color of the views without changing it back when they are
done!
These tricks result in an efficient graphics system. G is about 5
times faster than calling quickdraw routines through the normal
interface provided in MCL (this is based
on drawing random line segments within a 200 by 200 pixel window).
Compared to the fastest possible interface from MCL, undercutting the
quickdraw interface, G loses by only about 10%. All these comparisons
are for gd-
routines of course. g-
routines
are slower (by about a factor of 3) because they require floating
point calculation. Whereas gd-
routines make no garbage
during normal drawing, g-
routines make garbage because
normal floating point operations generate garbage in MCL. If desired,
this can be avoided by using MCL's short-float
data type.
If the coordinate system is set using short floats then calls to
g-
routines using coordinates that are also short-floats
will generate no garbage (speed is unaffected). A good future project
might be to convert G internally to use Eran Gat's floating point
compiler, which can speed up floating point calculations significantly,
but may require some care to be used successfully.
G as described herein can be obtained by downloading the file here. Included are the
C and Lisp implementations, as well as documentation, which can be
found in the Docs/ folder.
This version of G is in early beta. Please report problems
with it to butcher at cs dot ualberta dot ca.
To avoid continual calls to set the OpenGL context, each routine
checks when it runs
whether or not the OpenGL context of the view is the current context.
It is modified only if
necessary. The check is by checking if the the current
views context is the same as the view to be drawn in. Setting the
context is
done by calling gUtil_SetCurrentContext
.
A similar trick is done to prevent unneeded calls to gSetColor
.
The last foreground color
set on each view is stored with the view. It is set again only if a new
color is
asked for. This assumes color-codes are never changed, i.e., that they
are used
only with G routines. It also assumes no other processes are changing
the
foreground color of the views without changing it back when they are
done!