Hello!

I tried to use freepascal' graph module based on svgalib but from my point of view it's not comfortable: I need root prevelege or to remember what to do with *ids (uid and so on). Also I have a problems with konsole after starting programm with graph module: there is an error with input and I get much garbage inside it.
I realize a test module with a few graph functions (for my needs) via SDLlib. I wrote it on C, but some code may be written on pascal. It's not bad and fully compotable with traditional graph module code. I have some problems, but I will solve them (SDL don't want to return 'keydowns'). If you like it I may realize a full and normal graph module. Test programm need to be started in the terminal (console). You need to push the key only after setting up the terminal window active. I start in in konsole. If you start it from GUI in will run and then the window will close its self. In the tar there is linux binary.

Here the test ptogramm and simple graph module:
http://itmo.vingrad.ru/testGraph.tar.bz2

Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:

It is in the planning to rewrite Graph on top of PTCPas. I hope to do this before 2.2 it released. In the meantime ggigraph might suit your needs.

Implementing graph on top of SDL might also be an idea, but it should then be built on top of JEDI-SDL, and reuse the existing graph code. Implementing graph in C seems like a bad idea to me.

Daniël Mantione

It is in the planning to rewrite Graph on top of PTCPas. I hope to do this before 2.2 it released. In the meantime ggigraph might suit your needs.

Then you've to hurry ;)

Daniël Mantione wrote

Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:

Hi Evgeniy,

I'd say that having Graph built on top of SDL would be quite useful. I agree with Daniel that implementation in Pascal would be much better choice - among others, one could use it on various platforms without having to compile C libraries on those platforms (SDL is available on quite a few of them). I believe that Daniel intended to rewrite Graph to use a "driver" system (similarly to what we use for threading, keyboard/video/mouse units, heap management etc.), which would allow people to use the same Graph functionalities supported by different back-ends and choose either at compile time or possibly even at run time which back-end should be used (as an example, svgalib could be used as backup option for systems not running X11, etc.).

I personally wouldn't necessarily wait for PTCPas based implementation - if Daniel wants to use the driver system, it should be enough to agree on the driver interface, anything else can be done completely independently.

If you implement Graph as a completely independent implementation, you could add it to contributed units (see our WWW pages), so anybody else can use it.

If you do it using the driver system and want to contribute this work to FPC, I can imagine it could even become part of our SVN repository and future official FPC releases under some conditions (however, this last sentence is my personal view, not necessarily shared by the whole FPC core team).

Tomas

On Fri, 09 Mar 2007 15:46:34 +0300, Tomas Hajny
wrote:

Hi Tomas,

As far as I've understood Daniel is working only on driver system, isn't it? He doesn't touch such things like line and circle for example (It should be based on PutPixel as I thing) but he is implementing only the things that using back-end libs (like PTCPas), in my example such thing is PutPixel. Am I right?

It would be great for me to realize a small small part of FPC. And I find that it is much more useful to build a piece for something than create own little project.
I will do it using driver system with pleasure, but you've written that it is only your own opinion.
And there are several questions about libraries and programme languages.

I agree that the most part must be in pascal, but I think that such things like SDL initialization, loading images need to be implemented in C (if use native SDL headers). From my point of view usage of C parts is less dangerous then usage converters and other wrappers stuff. I have no experience with JEDI_SDL, but the last release was 2 years ago... And it's only the headers, so it uses "native" SDL libraries. I'm just beginner in software development so, please, be patient.

The graph unit is pretty generic in this respect. You indeed only need to implement putpixel, getpixel, graphics mode detection, setting a graphic mode, setting and getting colour palette entries for indexed modes, and closing down the graphic system again. But it's perfectly possible to also intercept line, elipse, rectangle etc and to implement them directly in the "driver".

I will do it using driver system with pleasure, but you've written that it is only your own opinion.

It's the way the whole graphics unit is designed to work. Note that "driver" is just used in the figurative sense here. In practice, you simply write your code and set some procedure variables inside the graph unit so it calls your code.

If you write your code in C, then you need to write Pascal headers for your code. In the end, you will always have to convert some headers.

I have no experience with JEDI_SDL, but the last release was 2 years ago... And it's only the headers, so it uses "native" SDL libraries.

That's true, and it's the case for most libraries out there. Converting all libraries from C to Pascal rather than the headers would be a huge and never-ending duplication of effort. There's nothing wrong with using Pascal interfaces for libraries which are written in another language.

Jonas

So, I may implement only putpixel and etc, but then if I wish I may implement line and othe stuff inside my part of code (or somewhere)?

So will be there different ways of using different back-ends directly from graph unit like to have some variables like sdlgraph=1?

So if I will implement it in C with pascal headers it have a chance to be a part of freepascal?

Yes, inside your code.

No, this is done by creating differently named graph units. All common graph unit code is in some include files, and to create a new graph unit for a different platform/library, you create a new unit with code needed for this platform library, and which includes all those generic include files.

See e.g. the graph.pp and ggigraph.pp files at
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/unix/

The include files are in
http://svn.freepascal.org/svn/fpc/trunk/packages/base/graph/inc/

Very little. We do this to reuse work done and maintained by others, not for new code which we support and maintain (since we ourselves are Pascal programmers, not C programmers).

Jonas

No, since it would increase the requirements of FPC with a C compiler, for something that could also be done in Pascal.

Jonas meant that it's no problem to use C libs for SDL using the Pascal headers to interface to Pascal main code.

Op Fri, 9 Mar 2007, schreef Evgeniy Ivanov:

As far as I've understood Daniel is working only on driver system, isn't it?

It already exists.

He doesn't touch such things like line and circle for example (It should be based on PutPixel as I thing) but he is implementing only the things that using back-end libs (like PTCPas), in my example such thing is PutPixel. Am I right?

Yes. The back-end can be implemented by whatever, but there seems to be no need to reinvent the Pascal core.

Well, Graph maintenance is more than welcome.

Many people @ Pascal Game Development. Domique Louis (Savage) is also still maintaining it. Writing all the imports yourself seems a bit like reinventing the wheel.

Daniël Mantione

while you can implement just putpixel and such doing so is a surefire way to get terrible performance.

to keep overhead down the conversion of shapes into pixels should be pushed as close to the framebuffer as possible, preferablly into the graphics card.

Thanks, I wanted to ask about it but you prevented my question.

I meant that I want to implement "dangerous" parts in C (driver core) and other things in pascal. But other developers are right that it is bad idea to write on C for pascal project.

Daniël Mantione wrote

Well, Graph maintenance is more than welcome.

I will try to work in this way. It is interesting.

Reinventing the wheel is to write all SDL imports, for graph I need only few.

So you think that it is not bad to use JEDI SDL instead writing some initialization code on C and make pascal headers for it? I haven't used JEDI SDL before but it is beta. I need your advise.

Evgeniy Ivanov wrote

On Fri, 09 Mar 2007 18:36:40 +0300, Jonas Maebe wrote: On Fri, 09 Mar 2007 18:39:10 +0300, DaniĂŤl Mantione wrote:

.
.

I don't know what heder conversions are available for SDL. However, I believe there are basically two options:

1) Have full SDL headers added as another package in repository (either existing like JEDI SDL or possibly a new one, although that would probably make little sense). I don't know what the size and complexity of these headers is and whether there might be somebody who could maintain such a package in our repository.

2) Include highly limited set of imports necessary for SDL purposes directly in the new sdlgraph (or whatever is the name). This might make sense if we don't have somebody who'd maintain the full headers, whereas maintaining just a highly limited set needed for sdlgraph purposes might be still acceptable (possibly just copied from the existing headers if the licence for those headers allows it).

Tomas

Op Fri, 9 Mar 2007, schreef Tomas Hajny:

JEDI-SDL is rather large. It contains import libraries for many SDL sattelite libraries, many examples and documentation. It is under somewhat active development by Dominique Louis.

2) Include highly limited set of imports necessary for SDL purposes directly in the new sdlgraph (or whatever is the name).

We could limit ourselves to sdl.pas. This is the main library. All graphics formats stuff, 3D stuff etc. is of less importance to graph.

SDL is LGPL, so is JEDI-SDL. We would need ask Dominique for permission of the FPC static linking exception to just JEDI-SDL (we do not distribute SDL itself). I don't think this will be a problem.

Daniël

Sorry, but you are wrong. JEDI-SDL is Mozilla Public License 1.1 (MPL 1.1). I don't know all refinements of licences, but JEDI-SDL is based on SDL libraries and they are LGPL version 2, so if we want to use JEDI-SDL headers they will bring us MPL 1.1 and it's requirements. But linking with SDL library will bring LGPL 2. If you mean static linking (ld job and static libraries) then we need permissions not from Dominique but from Sam Lantinga. As far as I know JEDI-SDL haven't its own libraries.

Daniel was talking about staticallu linking the interface, not the libraries themselves. Since we do not distribute the libraries, what license they are distributed under is irrelevant. The interface can be used to both link the dynamic and static library versions of SDL.

Jonas

OK, the conclusion is to implement sdlgraph in pascal on top of JEDI-SDL. So, I will work with it. I will finish my study activities (I was ill 2 weeks so this week (after Sunday) I will clear my debts) and then will implement it.
Daniël was talking about 2.2 FPC release, what is date in team's plans?

Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?)

Ales

Do you mean http://svn.freepascal.org/svn/fpc/trunk/packages/extra/sdl/ ? Yes, I will use this, as team wish.

Aleš Katona wrote

Just so you know, I just added modified SDL units from JEDI-SDL into packages/extra but only to trunk (2.3.1). I think it's best you use those and not copy your own, but we might need to merge into 2.2 later then (there's a freeze in effect now I think?)

Are the licensing issues sorted out for it? If not, there may be a problem since standard MPL is incompatible with GPL (so people can't release GPL programs using those bindings). I don't know about the LGPL (and how our static linking exception affects this).

Jonas

As far as I know if somebody uses MPL the product based on MPL must be only MPL.

MPL is incompatible with LGPL too.

http://www.mozilla.org/MPL/relicensing-faq.html

There is a way to use a triple license. But as I understood we need to make all FPC code licenced as MPL/LGPL because one module uses MPL code. It is not the way.
So, if we want to have sdlgraph there are 3 ways:
- rewrite needed SDL headers
- write SDL initialization and few base function for SDL in C and then make headers for pascal
- speak with JEDI-SDL developer. But I don't know if he relized it under MPL has he right to give such permission

Where exactly? I see "perceived incompability" in the header, but afaik FSF only names GPL.

http://www.mozilla.org/MPL/relicensing-faq.html#why-relicensing

=========================================================================================================================================================== (The LGPL allows code released under LGPL terms to be combined in certain specified ways with code released under non-LGPL terms, as for example when releasing an application using a library consisting of code released under the LGPL. However the relevant LGPL provisions do not address all possible ways in which code released under the MPL and code released under the LGPL could be combined to form a larger work. In particular, when linking Mozilla source files directly into a library released under the LGPL, e.g., to extend the functionality of that library, the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) ===========================================================================================================================================================

This is why we have the exception.

Micha

Sorry, I don't understand what you mean.

For example, look at the RTL license:

http://www.freepascal.org/cgi-bin/viewcvs.cgi/trunk/rtl/COPYING.FPC?rev=1&view=markup

It specifies the exception. Lazarus' LCL has the same exception in COPYING.modifiedLGPL IIRC.

Micha

Sorry, but we still don't understand each other. I was talking not about first part of sentence (you mark it red), but about ending: ==================================================================================================================================================== the effect of the LGPL terms, and any potential license incompatibilities that might arise, appear to be similar to those associated with the GPL.) ====================================================================================================================================================

And we were talking about linking MPL code to fpc, but not about fpc to some MPL.
Daniël have written to Dominique, so we are waiting the answer.

I've begun working. Haven't much time so it may be not a very short story. But I will try to do my best in such conditions.