Re: OpenGL and miniPicoLisp

2016-04-25 Thread Robert Herman
I'll keep you posted, thanks. I did venture into Lua for a very little
while, and I came away thinking I would just do it in C at a certain point,
or python, since it is more ubiquitous.  I am now looking at PicoLisp for
livecoding too, not just gaming.

Rob

On 25 April 2016 at 13:03, Jakob Eriksson  wrote:

> You are welcome to. I have been exploring Lua lately and have been longing
> to do some PicoLisp again. Lua is nice but it ain't no Lisp. :)
>
> 24 apr. 2016 kl. 11:31 skrev Robert Herman :
>
> I might take you up on that, Jakob! At the moment, I am exploring options
> regardless of the game jam. I would think it were easy to wrap SDL2, since
> another person I know wrapped a few functions from SDL to compile under ECL
> for a Ludum Dare Game Jam. I don't know enough of miniPicoLisp. I thought
> it wouldn't be able to handle big nums, but I'm not sure that's necessary
> for glut (floats)? I have holes in my programming knowledge in general,
> since I am self-taught, and have not programmed for a living for the most
> part. But, I did start in 1979!
>
> Rob
>
> BTW, I am currently in +7 GMT. What time zone are you guys in?
>
> On 24 April 2016 at 15:04, Jakob Eriksson  wrote:
>
>> IMHO it should be trivial to get SDL working with miniPicoLisp. I'd wrap
>> enough of SDL to get a minimal example running and extend it from there. If
>> you put it on GitHub I might help out too! :-)
>>
>> 24 apr. 2016 kl. 09:50 skrev Robert Herman :
>>
>> Well, that answers a lot, thanks. Textures are great, but not the end,
>> but X11 would have to go, since that would only work on Linux and Mac? How
>> hard do you think it would be to replace X11? If it is very hard, it would
>> be best to just interface to SDL2, and have sound, graphics, i/o, and
>> networking out of the box. Still trying to figure if it is easy to get SDL2
>> working with miniPicoLisp...sans networking.
>>
>> Rob
>>
>> On 24 April 2016 at 14:38, Alexander Burger  wrote:
>>
>>> On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
>>> > I think Java is valid, but this is for fun, and to further my PicoLisp
>>> > education. Plus I think Ersatz is slow even for Java, no?
>>>
>>> Indeed.
>>>
>>>
>>> > pure PicoLisp, the way Alex did in his RC simulator. Althought, that
>>> was
>>> > 64-bit PicoLisp, which relies on the 'native' function (where is that
>>>
>>> in @src64/main.l
>>>
>>> > defined?), and a custom lib for everything, no openGl? I know there is
>>> a
>>>
>>> Yes, all drawing is done pixel by pixel into buffers, and then copied to
>>> an XWindow.
>>>
>>>
>>> > to a limitation ;)
>>> > I will look at your rcsim code, Alex, and maybe I can grok enough to
>>> use it
>>> > for a game lib?? I find digging into the code more and more interesting
>>>
>>> It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
>>> it has a lot of limitations (e.g. no textures). On the other hand it is
>>> completely independent from any libraries except X11 (which might be
>>> replaced by some other window system).
>>>
>>> ♪♫ Alex
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>
>>
>


Re: OpenGL and miniPicoLisp

2016-04-25 Thread Jakob Eriksson
You are welcome to. I have been exploring Lua lately and have been longing to 
do some PicoLisp again. Lua is nice but it ain't no Lisp. :)

> 24 apr. 2016 kl. 11:31 skrev Robert Herman :
> 
> I might take you up on that, Jakob! At the moment, I am exploring options 
> regardless of the game jam. I would think it were easy to wrap SDL2, since 
> another person I know wrapped a few functions from SDL to compile under ECL 
> for a Ludum Dare Game Jam. I don't know enough of miniPicoLisp. I thought it 
> wouldn't be able to handle big nums, but I'm not sure that's necessary for 
> glut (floats)? I have holes in my programming knowledge in general, since I 
> am self-taught, and have not programmed for a living for the most part. But, 
> I did start in 1979!
> 
> Rob
> 
> BTW, I am currently in +7 GMT. What time zone are you guys in?
> 
>> On 24 April 2016 at 15:04, Jakob Eriksson  wrote:
>> IMHO it should be trivial to get SDL working with miniPicoLisp. I'd wrap 
>> enough of SDL to get a minimal example running and extend it from there. If 
>> you put it on GitHub I might help out too! :-)
>> 
>>> 24 apr. 2016 kl. 09:50 skrev Robert Herman :
>>> 
>>> Well, that answers a lot, thanks. Textures are great, but not the end, but 
>>> X11 would have to go, since that would only work on Linux and Mac? How hard 
>>> do you think it would be to replace X11? If it is very hard, it would be 
>>> best to just interface to SDL2, and have sound, graphics, i/o, and 
>>> networking out of the box. Still trying to figure if it is easy to get SDL2 
>>> working with miniPicoLisp...sans networking.
>>> 
>>> Rob
>>> 
 On 24 April 2016 at 14:38, Alexander Burger  wrote:
 On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
 > I think Java is valid, but this is for fun, and to further my PicoLisp
 > education. Plus I think Ersatz is slow even for Java, no?
 
 Indeed.
 
 
 > pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
 > 64-bit PicoLisp, which relies on the 'native' function (where is that
 
 in @src64/main.l
 
 > defined?), and a custom lib for everything, no openGl? I know there is a
 
 Yes, all drawing is done pixel by pixel into buffers, and then copied to
 an XWindow.
 
 
 > to a limitation ;)
 > I will look at your rcsim code, Alex, and maybe I can grok enough to use 
 > it
 > for a game lib?? I find digging into the code more and more interesting
 
 It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
 it has a lot of limitations (e.g. no textures). On the other hand it is
 completely independent from any libraries except X11 (which might be
 replaced by some other window system).
 
 ♪♫ Alex
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 


Re: OpenGL and miniPicoLisp

2016-04-24 Thread Robert Herman
I might take you up on that, Jakob! At the moment, I am exploring options
regardless of the game jam. I would think it were easy to wrap SDL2, since
another person I know wrapped a few functions from SDL to compile under ECL
for a Ludum Dare Game Jam. I don't know enough of miniPicoLisp. I thought
it wouldn't be able to handle big nums, but I'm not sure that's necessary
for glut (floats)? I have holes in my programming knowledge in general,
since I am self-taught, and have not programmed for a living for the most
part. But, I did start in 1979!

Rob

BTW, I am currently in +7 GMT. What time zone are you guys in?

On 24 April 2016 at 15:04, Jakob Eriksson  wrote:

> IMHO it should be trivial to get SDL working with miniPicoLisp. I'd wrap
> enough of SDL to get a minimal example running and extend it from there. If
> you put it on GitHub I might help out too! :-)
>
> 24 apr. 2016 kl. 09:50 skrev Robert Herman :
>
> Well, that answers a lot, thanks. Textures are great, but not the end, but
> X11 would have to go, since that would only work on Linux and Mac? How hard
> do you think it would be to replace X11? If it is very hard, it would be
> best to just interface to SDL2, and have sound, graphics, i/o, and
> networking out of the box. Still trying to figure if it is easy to get SDL2
> working with miniPicoLisp...sans networking.
>
> Rob
>
> On 24 April 2016 at 14:38, Alexander Burger  wrote:
>
>> On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
>> > I think Java is valid, but this is for fun, and to further my PicoLisp
>> > education. Plus I think Ersatz is slow even for Java, no?
>>
>> Indeed.
>>
>>
>> > pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
>> > 64-bit PicoLisp, which relies on the 'native' function (where is that
>>
>> in @src64/main.l
>>
>> > defined?), and a custom lib for everything, no openGl? I know there is a
>>
>> Yes, all drawing is done pixel by pixel into buffers, and then copied to
>> an XWindow.
>>
>>
>> > to a limitation ;)
>> > I will look at your rcsim code, Alex, and maybe I can grok enough to
>> use it
>> > for a game lib?? I find digging into the code more and more interesting
>>
>> It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
>> it has a lot of limitations (e.g. no textures). On the other hand it is
>> completely independent from any libraries except X11 (which might be
>> replaced by some other window system).
>>
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>
>


Re: OpenGL and miniPicoLisp

2016-04-24 Thread Jakob Eriksson
IMHO it should be trivial to get SDL working with miniPicoLisp. I'd wrap enough 
of SDL to get a minimal example running and extend it from there. If you put it 
on GitHub I might help out too! :-)

> 24 apr. 2016 kl. 09:50 skrev Robert Herman :
> 
> Well, that answers a lot, thanks. Textures are great, but not the end, but 
> X11 would have to go, since that would only work on Linux and Mac? How hard 
> do you think it would be to replace X11? If it is very hard, it would be best 
> to just interface to SDL2, and have sound, graphics, i/o, and networking out 
> of the box. Still trying to figure if it is easy to get SDL2 working with 
> miniPicoLisp...sans networking.
> 
> Rob
> 
>> On 24 April 2016 at 14:38, Alexander Burger  wrote:
>> On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
>> > I think Java is valid, but this is for fun, and to further my PicoLisp
>> > education. Plus I think Ersatz is slow even for Java, no?
>> 
>> Indeed.
>> 
>> 
>> > pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
>> > 64-bit PicoLisp, which relies on the 'native' function (where is that
>> 
>> in @src64/main.l
>> 
>> > defined?), and a custom lib for everything, no openGl? I know there is a
>> 
>> Yes, all drawing is done pixel by pixel into buffers, and then copied to
>> an XWindow.
>> 
>> 
>> > to a limitation ;)
>> > I will look at your rcsim code, Alex, and maybe I can grok enough to use it
>> > for a game lib?? I find digging into the code more and more interesting
>> 
>> It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
>> it has a lot of limitations (e.g. no textures). On the other hand it is
>> completely independent from any libraries except X11 (which might be
>> replaced by some other window system).
>> 
>> ♪♫ Alex
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 


Re: OpenGL and miniPicoLisp

2016-04-24 Thread Robert Herman
Well, that answers a lot, thanks. Textures are great, but not the end, but
X11 would have to go, since that would only work on Linux and Mac? How hard
do you think it would be to replace X11? If it is very hard, it would be
best to just interface to SDL2, and have sound, graphics, i/o, and
networking out of the box. Still trying to figure if it is easy to get SDL2
working with miniPicoLisp...sans networking.

Rob

On 24 April 2016 at 14:38, Alexander Burger  wrote:

> On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
> > I think Java is valid, but this is for fun, and to further my PicoLisp
> > education. Plus I think Ersatz is slow even for Java, no?
>
> Indeed.
>
>
> > pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
> > 64-bit PicoLisp, which relies on the 'native' function (where is that
>
> in @src64/main.l
>
> > defined?), and a custom lib for everything, no openGl? I know there is a
>
> Yes, all drawing is done pixel by pixel into buffers, and then copied to
> an XWindow.
>
>
> > to a limitation ;)
> > I will look at your rcsim code, Alex, and maybe I can grok enough to use
> it
> > for a game lib?? I find digging into the code more and more interesting
>
> It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
> it has a lot of limitations (e.g. no textures). On the other hand it is
> completely independent from any libraries except X11 (which might be
> replaced by some other window system).
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


Re: OpenGL and miniPicoLisp

2016-04-24 Thread Alexander Burger
On Sun, Apr 24, 2016 at 09:46:28AM +0700, Robert Herman wrote:
> I think Java is valid, but this is for fun, and to further my PicoLisp
> education. Plus I think Ersatz is slow even for Java, no?

Indeed.


> pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
> 64-bit PicoLisp, which relies on the 'native' function (where is that

in @src64/main.l

> defined?), and a custom lib for everything, no openGl? I know there is a

Yes, all drawing is done pixel by pixel into buffers, and then copied to
an XWindow.


> to a limitation ;)
> I will look at your rcsim code, Alex, and maybe I can grok enough to use it
> for a game lib?? I find digging into the code more and more interesting

It would be possible to use @lib/z3d.l in a game like misc/rcsim.l, but
it has a lot of limitations (e.g. no textures). On the other hand it is
completely independent from any libraries except X11 (which might be
replaced by some other window system).

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Robert Herman
Scratch that! I am getting senile. I went back to 7/2015, when I asked
similar questions to you, and you put an article on the site on rcsim! It's
working now...I am getting old!

Rob

On 24 April 2016 at 09:52, Robert Herman  wrote:

> I just tried to run rcsim.l on my newest PicoLisp system, and it didn't
> run. I know I have run it on another box before. What am I doing wrong?
> here's the code from load to failure. I typed '(go)' after the '-> go'
> response, and it brought up a white window though:
>>
>>
>> $ pil +
>> : (load "@misc/rcsim.l")
>> -> go
>> : (go)
>> -> (-20 0 (let R (assoc @ *Run) (sim> *Scene) (sim> *Model) (use (Yaw
>> Pitch) (dir> *Model 'Yaw 'Pitch) (z3dCamera *FocLen Yaw Pitch 0 0 *Tower
>> LightBlue DarkGreen)) (draw> *Scene) (draw> *Model) (z3dPut) (z3dText 20
>> 580 (pack *Throttle " %")) (z3dText 120 580 (pack *Speed " km/h")) (z3dText
>> 220 580 (pack *Altitude " m")) (z3dText 320 580 (case *FocLen (20
>> "(--)") (40 "(-)") (160 "(+)") (320 "(++)")))
>> (z3dSync) (let M (*/ (usec) 1000) (setq "MSec" (- M (set (cdr R) (min -2 (-
>> M "MSec" 20
>> : !? (sim> *Scene)
>> sim> -- Bad message
>> ?
>
>
> Thanks!
>
> Rob
>
> On 24 April 2016 at 09:46, Robert Herman  wrote:
>
>> I think Java is valid, but this is for fun, and to further my PicoLisp
>> education. Plus I think Ersatz is slow even for Java, no?
>> I program in C, well I used to, so I just need to get down with the io.l
>> file and see which route to take. I'd like to do somethign that has some
>> value for the PicoLisp community rather than just a means to an end,
>> meaning no sloppy fix to say I did a game in PicoLisp.
>> I am just having a mental block on whether I am just wrapping libs, since
>> SDL2 is in C, and I just need to call it, or if I want to duplicate it in
>> pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
>> 64-bit PicoLisp, which relies on the 'native' function (where is that
>> defined?), and a custom lib for everything, no openGl? I know there is a
>> 60-bit limit on loops in 64-bit PicoLisp, but that should not be even close
>> to a limitation ;)
>> I will look at your rcsim code, Alex, and maybe I can grok enough to use
>> it for a game lib?? I find digging into the code more and more interesting
>> each day! I am always amazed at what you have built.
>>
>> Rob
>>
>> On 23 April 2016 at 23:26, Jakob Eriksson  wrote:
>>
>>> I think minipicolisp is easy enough to extend. For a small game you need
>>> a dozen or so C calls. The Java route is interesting but has its
>>> distribution problems. What if there is no JVM on the target machine?
>>>
>>> > 23 apr. 2016 kl. 17:49 skrev Alexander Burger :
>>> >
>>> >> On Sat, Apr 23, 2016 at 01:06:46PM +0200, Jakob Eriksson wrote:
>>> >> That support is not going to be widely spread until
>>> >> a few years down the road.
>>> >
>>> > Oh, I see :(
>>> >
>>> > If portability is an issue, and miniPicoLisp is both too limited and
>>> > tedious to extend, then Rob should indeed also consider ErsaztLisp.
>>> >
>>> > It is by far easier to extend, with existing Java libraries. There are
>>> > some examples (in addition to what can be found on picolisp.com) on
>>> > rosettacode.org, not directly for OpenGl, but other GUI/Window stuff:
>>> >
>>> >   http://rosettacode.org/wiki/Animation#PicoLisp
>>> >  -> Java/Swing
>>> >
>>> >   http://rosettacode.org/wiki/GUI/Maximum_window_dimensions#PicoLisp
>>> >
>>> >   http://rosettacode.org/wiki/Image_Noise#PicoLisp
>>> >
>>> > ♪♫ Alex
>>> > --
>>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>>
>>
>>
>


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Robert Herman
I just tried to run rcsim.l on my newest PicoLisp system, and it didn't
run. I know I have run it on another box before. What am I doing wrong?
here's the code from load to failure. I typed '(go)' after the '-> go'
response, and it brought up a white window though:
>
>
> $ pil +
> : (load "@misc/rcsim.l")
> -> go
> : (go)
> -> (-20 0 (let R (assoc @ *Run) (sim> *Scene) (sim> *Model) (use (Yaw
> Pitch) (dir> *Model 'Yaw 'Pitch) (z3dCamera *FocLen Yaw Pitch 0 0 *Tower
> LightBlue DarkGreen)) (draw> *Scene) (draw> *Model) (z3dPut) (z3dText 20
> 580 (pack *Throttle " %")) (z3dText 120 580 (pack *Speed " km/h")) (z3dText
> 220 580 (pack *Altitude " m")) (z3dText 320 580 (case *FocLen (20
> "(--)") (40 "(-)") (160 "(+)") (320 "(++)")))
> (z3dSync) (let M (*/ (usec) 1000) (setq "MSec" (- M (set (cdr R) (min -2 (-
> M "MSec" 20
> : !? (sim> *Scene)
> sim> -- Bad message
> ?


Thanks!

Rob

On 24 April 2016 at 09:46, Robert Herman  wrote:

> I think Java is valid, but this is for fun, and to further my PicoLisp
> education. Plus I think Ersatz is slow even for Java, no?
> I program in C, well I used to, so I just need to get down with the io.l
> file and see which route to take. I'd like to do somethign that has some
> value for the PicoLisp community rather than just a means to an end,
> meaning no sloppy fix to say I did a game in PicoLisp.
> I am just having a mental block on whether I am just wrapping libs, since
> SDL2 is in C, and I just need to call it, or if I want to duplicate it in
> pure PicoLisp, the way Alex did in his RC simulator. Althought, that was
> 64-bit PicoLisp, which relies on the 'native' function (where is that
> defined?), and a custom lib for everything, no openGl? I know there is a
> 60-bit limit on loops in 64-bit PicoLisp, but that should not be even close
> to a limitation ;)
> I will look at your rcsim code, Alex, and maybe I can grok enough to use
> it for a game lib?? I find digging into the code more and more interesting
> each day! I am always amazed at what you have built.
>
> Rob
>
> On 23 April 2016 at 23:26, Jakob Eriksson  wrote:
>
>> I think minipicolisp is easy enough to extend. For a small game you need
>> a dozen or so C calls. The Java route is interesting but has its
>> distribution problems. What if there is no JVM on the target machine?
>>
>> > 23 apr. 2016 kl. 17:49 skrev Alexander Burger :
>> >
>> >> On Sat, Apr 23, 2016 at 01:06:46PM +0200, Jakob Eriksson wrote:
>> >> That support is not going to be widely spread until
>> >> a few years down the road.
>> >
>> > Oh, I see :(
>> >
>> > If portability is an issue, and miniPicoLisp is both too limited and
>> > tedious to extend, then Rob should indeed also consider ErsaztLisp.
>> >
>> > It is by far easier to extend, with existing Java libraries. There are
>> > some examples (in addition to what can be found on picolisp.com) on
>> > rosettacode.org, not directly for OpenGl, but other GUI/Window stuff:
>> >
>> >   http://rosettacode.org/wiki/Animation#PicoLisp
>> >  -> Java/Swing
>> >
>> >   http://rosettacode.org/wiki/GUI/Maximum_window_dimensions#PicoLisp
>> >
>> >   http://rosettacode.org/wiki/Image_Noise#PicoLisp
>> >
>> > ♪♫ Alex
>> > --
>> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>
>
>


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Jakob Eriksson

That support is not going to be widely spread until
a few years down the road.

Even so, I expect it (Ubuntu on Windows) to be a
downloadable server component rather than standard on all Windows client
versions.

best regards,
Jakob



On 23/04/16 12:57, Robert Herman wrote:
> Thanks, I'll have a look when I get home.
> 
> Rob
> 
> On Apr 23, 2016 14:59, "Alexander Burger"  > wrote:
> 
> On Sat, Apr 23, 2016 at 02:29:18PM +0800, Robert Herman wrote:
> > I'd love to use full PicoLisp, because it is still small, but it
> is POSIX
> > dependent so you need Cygwin to make and distribute to Windows systems
> 
> I haven't investigated, but perhaps that's no longer a problem now that
> Microsoft supports POSIX natively?
> 
> 
> > If I understand you, I would need to write an FFI for
> miniPicoLisp, like
> 
> There is an FFI for miniPicoLisp by Tomas Hlavaty, but in this case it
> isn't even needed. You can extend the core system with OpenGl functions
> just like the existing I/O functions.
> 
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de
> ?subject=Unsubscribe
> 
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Robert Herman
Thanks, I'll have a look when I get home.

Rob
On Apr 23, 2016 14:59, "Alexander Burger"  wrote:

> On Sat, Apr 23, 2016 at 02:29:18PM +0800, Robert Herman wrote:
> > I'd love to use full PicoLisp, because it is still small, but it is POSIX
> > dependent so you need Cygwin to make and distribute to Windows systems.
>
> I haven't investigated, but perhaps that's no longer a problem now that
> Microsoft supports POSIX natively?
>
>
> > If I understand you, I would need to write an FFI for miniPicoLisp, like
>
> There is an FFI for miniPicoLisp by Tomas Hlavaty, but in this case it
> isn't even needed. You can extend the core system with OpenGl functions
> just like the existing I/O functions.
>
> ♪♫ Alex
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Alexander Burger
On Sat, Apr 23, 2016 at 02:29:18PM +0800, Robert Herman wrote:
> I'd love to use full PicoLisp, because it is still small, but it is POSIX
> dependent so you need Cygwin to make and distribute to Windows systems.

I haven't investigated, but perhaps that's no longer a problem now that
Microsoft supports POSIX natively?


> If I understand you, I would need to write an FFI for miniPicoLisp, like

There is an FFI for miniPicoLisp by Tomas Hlavaty, but in this case it
isn't even needed. You can extend the core system with OpenGl functions
just like the existing I/O functions.

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: OpenGL and miniPicoLisp

2016-04-23 Thread Alexander Burger
Hi Rob,

> So what other libs and files do I need to drag into miniPicoLisp to get the
> existing lib/OpenGl.l to work other than math.l? And, how difficult is it
> to get math.l working in miniPicoLisp sufficiently to do any openGL work?

I think it is quite hard to get @lib/openGl.l to work with miniPicoLisp.

Or, to be exact, it is not possible. @lib/openGl.l is just a wrapper for
the OpenGl "glu" and "glut" libraries using the 'native' function of
pil64. And 'native' is missing from miniPicoLisp. So the whole wrapper
is meaningless, and you must call OpenGl functions from explicitly
written C glue code. Not difficult, but needs to be done.

Same with @lib/math.l, which consists also only of glue functions.

Also, I'm not sure if mini is a good idea. It lacks the database, so
more interesting games are out of reach. Why not pil64, where you can
use @lib/openGl.l right out of the box?

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe