<br><br><div><span class="gmail_quote">2007/8/22, Jonas Maebe <<a href="mailto:jonas.maebe@elis.ugent.be">jonas.maebe@elis.ugent.be</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>Congratulations! Just one note: please do not make it GPL, because<br>that would mean anyone using that unit would have to make their<br>program also GPL. Instead, please change the text at the top to<br>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.

<br><br>     This program is distributed in the hope that it will be useful,<br>     but WITHOUT ANY WARRANTY; without even the implied warranty of<br>     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.<br>***<br><br>

You're of course free to also include your email address and a link<br>to your website, like you have done in the version you put on the web.</blockquote><div><br>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 

<a href="http://sf.net">sf.net</a>, but it's old and empty, they need to check it).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> I need to do some hooks to speed up the module (Bar3d). But I have<br>> network<br>> problems and my dial up doesn't me allow to google much (I don't<br>> know how to<br>> hook functions/procedures).

<br><br>Bar3D is indeed one of the few routines which cannot be hooked<br>currently. As long as you hook the line drawing it should be plenty<br>fast though.</blockquote><div><br>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).

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Also readln function need to be hooked too (It works when alt+tab<br>> to console

<br>> from which app was executed).<br><br>This will indeed be difficult. It's probably best to create a generic<br>"wincrt"-like unit (sdlcrt?) which can be used together with the sdl<br>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.</blockquote><div> 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.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> If you remember we were talking about it in April (or May). I've<br>> created

<br>> <a href="http://sf.net">sf.net</a> project, but it is in Processing Queue. So, here are the<br>> temp links:<br>><br>> Unit: <a href="http://itmo.vingrad.ru/files/sdlgraph.pas.txt">http://itmo.vingrad.ru/files/sdlgraph.pas.txt

</a><br>><br>> Example: <a href="http://itmo.vingrad.ru/files/test.pas.txt">http://itmo.vingrad.ru/files/test.pas.txt</a><br>><br>> Build script (you need to fix paths):<br>> <a href="http://itmo.vingrad.ru/files/build.sh.txt">

http://itmo.vingrad.ru/files/build.sh.txt</a><br><br>Very nice!</blockquote><div><br>Thanks a lot! :) <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

> P.S. Thanks you for your answers about the graph modules and to<br>> authers of<br>> graph*.inc and *Go32* module - the code is very nice.<br><br>Carl will be happy to hear this :)<br><br><br><br>No, it doesn't do the same: the lowNewMode..highNewMode case uses

<br>IntcurrentNewDriver, while the else case uses IntcurrentDriver. It's<br>to transparently support both the old and new mode selection logic.<br><br>> TODO: in modes.inc 181: Overloaded procedure initmode(var mode:

<br>> TModeInfo);<br>> isn't used. I've looked only in modes.inc, so it may be my mistake<br><br>It is used by all platform-specific graph units (also by your<br>sdlgraph unit) to initialise a new mode.</blockquote>

<div><br>Thanks, sorry my inattention. </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> TODO: Go32 mistake 2740: modenumber is m1024x768x32k, but initmode =

<br>> Init640x480x32k<br>> }<br><br>Fixed, thanks.</blockquote><div><br>You're welcome :) <br></div><br><br></div>-- <br>E.I.