[fpc-pascal]SDL Based Graph Unit - Was Contributing to FPC
ddt at headrush.co.za
ddt at headrush.co.za
Tue Sep 10 14:53:16 CEST 2002
>> According to the freepascal website, you are the
maintainer of the Linux
>> port, hence this mail.
>It seems you wrote to the wrong address :)
Oops, this was meant to go to Michael, my mail client
replied to the group instead -aarch.
>fpc-devel would be a slightly better place than this
True, but as I said I wasn't trying to mail the list.
>No? The current graph unit is quite flexible. It's almost
>independent of the underlying system, it can even work if
>implement putpixel(), getpixel() and mode
>quite slowly, as demonstrated by the current win32 graph
.unit). You can
.override almost all procedures (they're all procvars)
>though and in
>general, the more you override, the fast things become
>(most banked VESA
>routines are quite fast). A graph unit based on SDL would
>be really nice
>though, since it's available on many platforms.
This true, in fact my plan for such an SDL-Graph unit was
almost completely based on put/get pixel with standard
vector maths (e.g. putpixel plus rotation give elipse)
The trouble lies in these areas:
Initialization - SDL uses a very different initialization
technique that essentially returns a pointer to a segment
of video ram.
To create a graph like initialization one would have:
Uses a pointer variable in the unit itself,
Transparently do all graphics functions to this SDL
It could work but is a very big abstraction of the SDL
method - the wisdomn of that is debatable.
PutImage and GetImage:
SDL was designed for displaying and manipulating images
from files. And all the documentation asumes this method.
PutImage and GetImage is a much older approach, in
practise it requires using a vector approach of drawing,
then copying the result into memory as a bitmap (Which is
not BMP compatible)
The overlaying in creating an exact version will be
I have two basic approaches to solving this, both have
problems (this is the reaso
Recreate the graph like method - and use get and put
pixels to pull it off - but SDL was not designed for this
at all - in other words it would require a dirty hack
which may have less than wonderfull results.
Fack the graph method with the SDL method - blit to and
from a temporary BMP file - the only trouble is that this
will not work for graph images stored in code - so one
would yet again need to write code to convert that into
Essentially which ever way you go about it, you end up
needing to convert between MS bmp and graph bitmap formats
- if someone was to contribute this code to me, I would
start on it tomorrow.
>> Once that is finished I would create
>> CRT'ish mouse and keyboard access using SDL's event
>>manager behind it
>> result will be a graph unit that is portable to more
>>platforms and OS's
>> than FPC and depends only on a highly available, stable
>> Please let me know your feelings on this one.
>This sounds really nice, but it would be even better if
>you could keep
>the mouse/keyboard stuff separate so that we can have the
>cake and eat
>it too: a (hopefully) BP compatible graph unit and all
>the advantages of
>using SDL in some other units. We already have
>keyboard/mouse units in
>the RTL though, maybe it would be best to implement those
>on top of sdl
>as well instead of creating completely new ones?
The kb/mouse units I mentioned are needed for the same
reason you need wincrt and winmouse on windows - SDL runs
it's graphics in sepperate thread so you need SDL input
handling to catch clicks etc from it.
This is also why the RTL units don't work with SDL :-)
Actually to create them would be even more of a serious
hack since SDL completely abstracts keyboard and mouse
Using readkey as an example:
It would need to get ONLY the last KEYBOARD event on the
cue. Then one would need to use a lot of constants in
order to be able to return the scan
as SDLK_Escape then we would
need to know to return 27.
All this is still ok, the trouble is that SDL has no
keyboard repeat, an event occurs only once for a keypress
-and a new event occurs at key release.
In other words we would need to keep returning the last
event until a new one occurs - but not everytime - to be
able to work with programs that rely on keyboard repeats.
Thoughts and suggestions are very wellcome here.
mail2web - Check your email from the web at
More information about the fpc-pascal