[fpc-devel] sdlgraph, pre-alpha

[Evgeniy Ivanov]

2007/8/22, Jonas Maebe <jonas.maebe at elis.ugent.be>:
>
>
> Congratulations! Just one note: please do not make it GPL, because
> that would mean anyone using that unit would have to make their
> program also GPL. Instead, please change the text at the top to
> something like this:
>
> ***
>      Copyright (c) 2007 Evgeniy Ivanov
>
>      This file implements the sdl support for the graph unit
>
>      See the file COPYING.FPC, included in this distribution,
>      for details about the copyright.
>
>      This program is distributed in the hope that it will be useful,
>      but WITHOUT ANY WARRANTY; without even the implied warranty of
>      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> ***
>
> You're of course free to also include your email address and a link
> to your website, like you have done in the version you put on the web.


Ok, no problem. I will do it in the way you have told. I'm waiting when they
will register the project (there is sdlgraph on sf.net, but it's old and
empty, they need to check it).

> I need to do some hooks to speed up the module (Bar3d). But I have
> > network
> > problems and my dial up doesn't me allow to google much (I don't
> > know how to
> > hook functions/procedures).
>
> Bar3D is indeed one of the few routines which cannot be hooked
> currently. As long as you hook the line drawing it should be plenty
> fast though.


No, I tryed. It is in the test.pas. It works very very slow.
I may patch graph.inc, graphh.inc and modes.inc to add ability to hook such
routines (Shapes/Lines) like Bar3D. It will not take any effect on currently
written modules (Current Bad3d may be Bar3Ddefault and to  be added to Bar3D
proc if it's not assigned).  Of course if you will approve it (I don't see
any reason to make it just for my needs).

> Also readln function need to be hooked too (It works when alt+tab
> > to console
> > from which app was executed).
>
> This will indeed be difficult. It's probably best to create a generic
> "wincrt"-like unit (sdlcrt?) which can be used together with the sdl
> graph unit. Full input/output support can also be added to it over
> time, similarly to how the regular crt unit also takes over all input/
> output.


Nice idea. I may do it. I think that the best way for this is to use
SDL-terminal (I have never used it, but it must be pretty nice).
But it isn't in JEDI-SDL (so, it must be wrapped to .pp).
But I prefer to use readln to give user a chance to see the screen created
by graph (and close after any key was pressed). There are many old
programmes with it. The "+" of SDLgraph is that it may be used with old code
and you may add any JEDI-SDL routine (timer or SDL_mixer and so on) using
global screen variable. Sorry for my poor English, but I think you will get
the idea.

> If you remember we were talking about it in April (or May). I've
> > created
> > sf.net project, but it is in Processing Queue. So, here are the
> > temp links:
> >
> > Unit: http://itmo.vingrad.ru/files/sdlgraph.pas.txt
> >
> > Example: http://itmo.vingrad.ru/files/test.pas.txt
> >
> > Build script (you need to fix paths):
> > http://itmo.vingrad.ru/files/build.sh.txt
>
> Very nice!


Thanks a lot! :)

> P.S. Thanks you for your answers about the graph modules and to
> > authers of
> > graph*.inc and *Go32* module - the code is very nice.
>
> Carl will be happy to hear this :)
>
>
>
> No, it doesn't do the same: the lowNewMode..highNewMode case uses
> IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's
> to transparently support both the old and new mode selection logic.
>
> > TODO: in modes.inc 181: Overloaded procedure initmode(var mode:
> > TModeInfo);
> > isn't used. I've looked only in modes.inc, so it may be my mistake
>
> It is used by all platform-specific graph units (also by your
> sdlgraph unit) to initialise a new mode.


Thanks, sorry my inattention.

> TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode =
> > Init640x480x32k
> > }
>
> Fixed, thanks.


You're welcome :)


-- 
E.I.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20070822/fc3eda30/attachment.html>