[fpc-pascal]SDL Based Graph Unit - Was Contributing to FPC

[ddt at headrush.co.za]

>> 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 
>list. 
True, but as I said I wasn't trying to mail the list. 
 
>No? The current graph unit is quite flexible. It's almost 
>completely  
>independent of the underlying system, it can even work if 
>you only  
>implement putpixel(), getpixel() and mode 
>.detection/setting (though  
>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 
surface. 
 
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 
immense. 
 
I have two basic approaches to solving this, both have 
problems (this is the reaso
d yet) 
 
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 
BMP. 
 
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  
>> -the 
>> 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 
>>and open-source 
>> library. 
>> 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 
handling.  
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. 
 
 
Ciao 
A.J. 
 
 
 
 
 
 
 
 

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .