Because of the recent chatter about gamedev and Lisp, I've decided to
start putting together a little 3D engine for LispWorks (my environment
of choice). It is also just a side project for me to do in my spare
time.
I've finished the first two parts: a CPW and OpenGL FLI interface for
each. Both are independant of each other, and anyone should feel free
to download them off my website (see .sig). They work nicely, and there
is example code with the CPW package (tutorial.lisp) showing how to put
together a small application.
Over the next couple weeks I'll be putting a little engine together to
handle scene creation, camera movement, 3D model loading, OpenAL, etc.
Nothing super fancy (I do enough of this at work), but should be simple
enough to use for newbie Lisp-ers that are interested in gamedev to
whip something up. Hell, I might even add some shader support :)
Note: this is only on Windows. I don't have the energy (or machines) to
make sure this works or runs on Mac/Linux. If anyone is willing to put
forth a little effort, though, I'd be happy to host the files, etc.
Let me know if you have any comments/suggestions on the code -- and
especially bug reports. :)
Enjoy,
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> Because of the recent chatter about gamedev and Lisp, I've decided to
> start putting together a little 3D engine for LispWorks (my environment
> of choice). It is also just a side project for me to do in my spare
> time.
Awesome. But how do you load it? gl.lisp has the defpackage and defines
functions which use types deined in types.lisp, which does not have an
in-package form but expects to be in a package using FLI.
Also, was there some reason you did not use UFFI? No callback support? I
am thinking about forking UFFI and adding that and CLisp and...
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Jeff wrote:
>
>> Because of the recent chatter about gamedev and Lisp, I've decided to
>> start putting together a little 3D engine for LispWorks (my environment
>> of choice). It is also just a side project for me to do in my spare
>> time.
>
>
> Awesome. But how do you load it?
Oops, just found the defsystem. never mind. :)
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> Also, was there some reason you did not use UFFI? No callback
> support? I am thinking about forking UFFI and adding that and CLisp
> and...
Callback support for CPW is a must. I haven't looked at UFFI, though.
Googling now :)
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> Kenny Tilton wrote:
>
>
>>Also, was there some reason you did not use UFFI? No callback
>>support? I am thinking about forking UFFI and adding that and CLisp
>>and...
>
>
> Callback support for CPW is a must. I haven't looked at UFFI, though.
> Googling now :)
I use UFFI then tack on my own hacks in ffi-extender (FFX) package:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/ffi-extender/?cvsroot=cells
Cello runs with a Glut as its interface to the OS, which as you know CPW
took its inspiration from. Anyway, FFX supports callbacks from C into Lisp.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Jeff wrote:
>
>> Kenny Tilton wrote:
>>
>>
>>> Also, was there some reason you did not use UFFI? No callback
>>> support? I am thinking about forking UFFI and adding that and CLisp
>>> and...
>>
>>
>>
>> Callback support for CPW is a must. I haven't looked at UFFI, though.
>> Googling now :)
>
>
> I use UFFI then tack on my own hacks in ffi-extender (FFX) package:
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/ffi-extender/?cvsroot=cells
>
>
> Cello runs with a Glut as its interface to the OS, which as you know CPW
> took its inspiration from. Anyway, FFX supports callbacks from C into Lisp.
I should mention FFX supports callbacks for AllegroCl and Lispworks,
CLisp and OpenMCL RSN.
also, while you are googling, mk::defsystem or ASDF would make your work
even more portable.
what are you going to use for a physics engine?
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Kenny Tilton wrote:
>
>>
>>
>> Jeff wrote:
>>
>>> Kenny Tilton wrote:
>>>
>>>
>>>> Also, was there some reason you did not use UFFI? No callback
>>>> support? I am thinking about forking UFFI and adding that and CLisp
>>>> and...
>>>
>>>
>>>
>>>
>>> Callback support for CPW is a must. I haven't looked at UFFI, though.
>>> Googling now :)
>>
>>
>>
>> I use UFFI then tack on my own hacks in ffi-extender (FFX) package:
>>
>> http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/ffi-extender/?cvsroot=cells
>>
>>
>> Cello runs with a Glut as its interface to the OS, which as you know
>> CPW took its inspiration from. Anyway, FFX supports callbacks from C
>> into Lisp.
>
>
> I should mention FFX supports callbacks for AllegroCl and Lispworks,
Ooops. While trying to get cells-gtk running under Lispworks I
discovered some shortcomings in the callback support. I will try to fix
it, but I am dodging the trial version heap limit with variable success
so no promises.
I passed thru unaltered an argument type of (* :void).. that must be
(:pointer :void) in LW. Not sure what else remains...
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
> also, while you are googling, mk::defsystem or ASDF would make your
> work even more portable.
I haven't looked too hard at ASDF (although I have thought about it).
Perhaps I'll take a closer look.
> what are you going to use for a physics engine?
I'm planning on just using Tokamak. Simple, free, etc...
http://www.tokamakphysics.com/
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> I'm planning on just using Tokamak. Simple, free, etc...
I should add, though, that I don't enjoy the C wrapper (to the classes)
I'll have to write for it. :(
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> Jeff wrote:
>
>
>>I'm planning on just using Tokamak. Simple, free, etc...
I have looked at that a couple of times. Nice to know a hardcore gamer
considers that the way to go.
>
>
> I should add, though, that I don't enjoy the C wrapper (to the classes)
> I'll have to write for it. :(
>
Both my Celtic and Vasilis's cells-gtk use Cells to simplify "life with
a shadowed instance". basically the output function of a cell propagates
across the ffi to the shadowed C "instance", keeping them in synch
somewhat automatically. (Some DEF-TOKAMAK-CLASS macro takes a list of
slot names to keep synched and expands into the necessary output
definitions.)
You know, maybe it is time to break out GCC-XML and really try to nail
this Lisp-to-C++ thing once and for all.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
>
> Jeff wrote:
> >
> > I'm planning on just using Tokamak. Simple, free, etc...
>
> I have looked at that a couple of times. Nice to know a hardcore
> gamer considers that the way to go.
>
Well, I'd use Havok if I could :) but for free, nothing beats Tokamak
right now.
> You know, maybe it is time to break out GCC-XML and really try to
> nail this Lisp-to-C++ thing once and for all.
That has to be (right now) the biggest drawback to any FFI right now.
Once I have to pull out my C compiler to use Lisp, I feel like it's a
loss. Also, I might be in the minority, but it feels stupid to have a
tokamak.dll file there with a tokamakc.dll (or similar filename). I'm
hoping someone else already did a C port of tokamak for another non-C
language (like Python).
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> Well, I'd use Havok if I could :) but for free, nothing beats Tokamak
> right now.
Have you looked at Newton Game Dynamics ?
(www.newtondynamics.com/index.html)
I am currently split between making the FFI to Corman Lisp for Tokamak
or Newton.
>
>
>>You know, maybe it is time to break out GCC-XML and really try to
>>nail this Lisp-to-C++ thing once and for all.
>
>
> That has to be (right now) the biggest drawback to any FFI right now.
> Once I have to pull out my C compiler to use Lisp, I feel like it's a
> loss. Also, I might be in the minority, but it feels stupid to have a
> tokamak.dll file there with a tokamakc.dll (or similar filename). I'm
> hoping someone else already did a C port of tokamak for another non-C
> language (like Python).
>
> Jeff M.
>
I have not yet needed to break out the C compiler when working with the
Corman Lisp FFI.
-Luke
Open Dynamics Engine might also be worth a look. It has a simple C API
and works on both Linux and Windows (and OS X?). Don't know how it
compares to Tokamak or Newton though.
tkneste wrote:
> Open Dynamics Engine might also be worth a look. It has a simple C API
> and works on both Linux and Windows (and OS X?). Don't know how it
> compares to Tokamak or Newton though.
Good to have more options available. Thanks for the links, guys!
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> Kenny Tilton wrote:
>
>
>>
>>Jeff wrote:
>>
>>>I'm planning on just using Tokamak. Simple, free, etc...
>>
>>I have looked at that a couple of times. Nice to know a hardcore
>>gamer considers that the way to go.
>>
>
>
> Well, I'd use Havok if I could :) but for free, nothing beats Tokamak
> right now.
>
>
>>You know, maybe it is time to break out GCC-XML and really try to
>>nail this Lisp-to-C++ thing once and for all.
>
>
> That has to be (right now) the biggest drawback to any FFI right now.
> Once I have to pull out my C compiler to use Lisp, I feel like it's a
> loss. Also, I might be in the minority, but it feels stupid to have a
> tokamak.dll file there with a tokamakc.dll (or similar filename). I'm
> hoping someone else already did a C port of tokamak for another non-C
> language (like Python).
I do not think that is necessary: "The Tokamak API exposes two different
types of classes. The Interface classes are classes of objects which
must be created and freed through a Tokamak API function or a member
function of a Tokamak class. The other group, Peripheral classes,
consists of ordinary C++ classes which are managed by the API user."
Sounds to me as if the need for "tokamakc" was anticipated by producing
the interface classes. I /think/ this provides a purely functional
interface to Tokamak. ie, we call "makeWidget" and get back a pointer.
We read and modify the widget via interface accessor functions. We
dispose of the widget via a call. So we keep C++ at arms length.
Even if not, my thought in re GCC-XML was to run it against Tokamak to
get an XML description, parse that in Lisp to create both Lisp FFI and
the C source for "TokamakC". ie, lights-out bindings to C++. It could
all go in a make script.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
How are you doing the main loop and external interfaces? If you are
using OpenGL directly, what are you using for your event system? When i
hooked up to OpenGL under X11 on Linux i ran the main loop myself and
therefore had no need for callbacks into lisp as all the event handling
would originate from the lisp code...the same could be done under
Windows unless you already have an external library driving that.
Jeff wrote:
> Kenny Tilton wrote:
>
> > Also, was there some reason you did not use UFFI? No callback
> > support? I am thinking about forking UFFI and adding that and CLisp
> > and...
>
> Callback support for CPW is a must. I haven't looked at UFFI, though.
> Googling now :)
>
> Jeff M.
>
> --
> http://www.retrobyte.org
> ··············@gmail.com
Brad Might wrote:
> How are you doing the main loop and external interfaces?
CPW offers two styles of main loops. You can either just call
cpw-main-loop to have it take care of everything or you can call
cpw-main-loop-update to execute the render loop for a short period of
time and then move onto more game code.
Neither one is very ideal, but both are good enough for what I am
hoping to do.
> what are you using for your event system?
Everything is wrapped up in CPW for event capturing (window resizing,
drawing, creating window, mouse, joystick, keyboard, etc). Or perhaps
you are referring to other events? If so, which ones.
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
The question i was asking is, how are you interfacing to the host
system for the window events...are you using some pre-defined library
(SDL?) kind of thing which needs to call back into lisp or are you
driving the main loop directly from lisp?
If the former, then you need ffi callback into your lisp, if the
latter, then you don't need it (for this purpose) because you own the
main loop and can do your own dispatching.. This is independent of your
answer which is how does 'client' code hook into your main loop
assuming it (the main loop) is a black box.
e.g.
(defun init-system (...)
(graphic-library::register-main-loop-callback #'please-call-this))
or
(defun main-loop (...)
(loop
until done
do (let ((event (system-interface get-event-from-system)))
(call-my-event-dispatching event))))
sorry if i'm being dense here, but i still don't see the external
interface. I'm talking about the code that cpw-main-loop uses to get
the events, not what my cpw client does to handle them. You example
applies to both my scenarios.
I want to know how CPW gets events from the operating system. You
example which uses my first case actually seems to imply under the
covers you are actually doing my second example.
does CPW get the event by receiving a callback from the OS or by
calling something equivalent to "getNextEvent" ? If you are calling
getNextEvent (or windows equivalent, don't recall that right now) then
there is no need for c->lisp calling
CPW is getting events from the OS and calling your callback functions
with appropriate parameters (window id, keys, mouse position, etc).
While there is functionality in CPW to see what the next event will be
(and skip it, repeat it, do something special, etc), there is no method
of getting the event data before the callback is executed.
Jeff M.
Jeff M. wrote:
> CPW is getting events from the OS and calling your callback functions
> with appropriate parameters (window id, keys, mouse position, etc).
And if I may offer a little help here, Get/WaitNextEvent is a Mac thing.
Certainly under OS9, no idea about OS/X.
In windows, every application has to register one callback (Lisp
function set up to be callable from C) with Windows when putting up a
window--that is how one gets messages (aka events in Mac-ese). In
environments such as AllegroCL and Lispworks, the Lisp developer can
never actually have to do this callback because the Common Graphics
(ACL) or CAPI (LW) code does that, gets the raw win32, um, "messages",
and then doles them out via GF calls one specializes on the subclass one
created of the generic framework window class. That is if you want to
see the messages. A lot can be done just by supplying hooks for
framework widgets, hooks such as on-click or on-key or whatever.
With products such as CormanCL or CLisp, one goes out and buys a copy of
Petzold or some other C win32 tome and simply pretends they are a C
programmer. CormanCL, btw, has a pretty solid set of win32 bindings all
ready to go, IIRC.
Anyway, with CPW or Glut, those C libraries register their own one C
callback with win32, then make dozens of different callbacks to the
application, dispatching different messages via different callbacks. But
in win32 there is no getting around registering one or two callbacks
(one gets raw messages, the other the same message as an "application"
message.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Brad Might wrote:
> The question i was asking is, how are you interfacing to the host
> system for the window events...are you using some pre-defined library
> (SDL?) kind of thing which needs to call back into lisp or are you
> driving the main loop directly from lisp?
I use SDL for handling events. In the raw form, the Lisp code for
managing the events returned by SDL looks like
(do ()
((eql quit t))
(do ((poll-event 1 (sdl:SDL_PollEvent sdl-event)))
((eql poll-event 0) 'done)
(cond
((eql sdl:SDL_QUIT (ct:cref sdl:SDL_Event sdl-event sdl::type))
(setf quit t))))
(move-stuff)
(update-screen))
I wrote a macro (using the general syntax from cl-sdl) to clean up the
above code so that event handling now looks like this:
(sdl:with-events
(:quit t)
(:keydown (state scancode key mod unicode)
(when (= key sdl:SDLK_ESCAPE)
(sdl:quit)))
(:idle
(move-stuff)
(update-screen)))
-Luke
Jeff wrote:
> Because of the recent chatter about gamedev and Lisp, I've decided to
> start putting together a little 3D engine for LispWorks (my environment
> of choice). It is also just a side project for me to do in my spare
> time.
>
> I've finished the first two parts: a CPW and OpenGL FLI interface for
> each. Both are independant of each other, and anyone should feel free
> to download them off my website (see .sig). They work nicely, and there
> is example code with the CPW package (tutorial.lisp) showing how to put
> together a small application.
Not for Lispworks; But if anyone is interested in Corman Lisp, I have
available the Corman FFI bindings for the following packages on my site:
http://www.balooga.com/lisp.php3
- SDL (www.libsdl.org)
- SDL_mixer (http://jcatki.no-ip.org/SDL_mixer/)
- OpenGL
- OpenRM (www.openrm.org) - Scene graph manager
- Cal3D (http://cal3d.sourceforge.net/) - Character Animation library
(I have not yet had the chance to upload the bindings for Cal3D)
-Luke
Luke J Crook wrote:
> Jeff wrote:
>
>> Because of the recent chatter about gamedev and Lisp, I've decided to
>> start putting together a little 3D engine for LispWorks (my environment
>> of choice). It is also just a side project for me to do in my spare
>> time.
>>
>> I've finished the first two parts: a CPW and OpenGL FLI interface for
>> each. Both are independant of each other, and anyone should feel free
>> to download them off my website (see .sig). They work nicely, and there
>> is example code with the CPW package (tutorial.lisp) showing how to put
>> together a small application.
>
>
> Not for Lispworks; But if anyone is interested in Corman Lisp, I have
> available the Corman FFI bindings for the following packages on my site:
> http://www.balooga.com/lisp.php3
>
> - SDL (www.libsdl.org)
> - SDL_mixer (http://jcatki.no-ip.org/SDL_mixer/)
> - OpenGL
> - OpenRM (www.openrm.org) - Scene graph manager
> - Cal3D (http://cal3d.sourceforge.net/) - Character Animation library
Nice. Any cool demos yet?
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Kenny Tilton wrote:
>
> Nice. Any cool demos yet?
>
> kenny
>
I suppose the OpenGL Gears demo and the one OpenRM demo I ported to Lisp
qualify. But nothing quite as good as CPW.
-Luke
Luke J Crook wrote:
> Kenny Tilton wrote:
>
>>
>> Nice. Any cool demos yet?
>>
>> kenny
>>
>
> I suppose the OpenGL Gears demo and the one OpenRM demo I ported to Lisp
> qualify. But nothing quite as good as CPW.
i saw the character animation library in your list and was hoping for
something including that.
glad to hear openrm is working out for you, I might want to pull in that
or opensg in in the future.
kenny
--
Cells? Cello? Celtik?: http://www.common-lisp.net/project/cells/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Jeff wrote:
> Because of the recent chatter about gamedev and Lisp, I've decided to
> start putting together a little 3D engine for LispWorks (my environment
> of choice). It is also just a side project for me to do in my spare
> time.
As your engine is written in C, is your intent to prove that Lisp may be
used as a replacement for Lua or Python with regards to controlling an
external engine using scripts?
-Luke
Luke J Crook wrote:
> Jeff wrote:
> > Because of the recent chatter about gamedev and Lisp, I've decided
> > to start putting together a little 3D engine for LispWorks (my
> > environment of choice). It is also just a side project for me to do
> > in my spare time.
>
> As your engine is written in C, is your intent to prove that Lisp may
> be used as a replacement for Lua or Python with regards to
> controlling an external engine using scripts?
>
The engine isn't written in C. The 3D rendering is done by OpenGL. The
interface to the operating system for events and windowing is handled
by CPW. If I add physics, that will probably be a third party C package
(as I don't have the time or energy to do this). However, everything
else will be done 100% in Lisp:
- math (vectors, matrices, quaternions, AABB, ...)
- entity code (cameras, lights, models, ...)
- animations (keyframes, bones, ...)
- scene management (objects, buildings, terrain, ...)
Once the above is done, there is also the possibility of adding
additional support for other features, such as vertex and pixel shaders
(once I get OpenGL 2.0), physics, among some other ideas that I've been
toying with.
The "intent" isn't to *prove* anything. If I was attempting to do much
of anything beyond having fun and giving myself something to play with
at home, it would be to "back up" the essay I wrote recently and
posted. I'm just not concerned with doing that, as I've been doing this
(programming games and engines) for a while now. This truely is just
brain stimulation. And perhaps it will be useful to others as well. :)
Jeff M.
--
http://www.retrobyte.org
··············@gmail.com
Jeff wrote:
> The engine isn't written in C. The 3D rendering is done by OpenGL. The
> interface to the operating system for events and windowing is handled
> by CPW.
Oops. I should have looked at the cpw.h header file before I posted.
If I add physics, that will probably be a third party C package
> (as I don't have the time or energy to do this). However, everything
> else will be done 100% in Lisp:
>
> - math (vectors, matrices, quaternions, AABB, ...)
> - entity code (cameras, lights, models, ...)
> - animations (keyframes, bones, ...)
> - scene management (objects, buildings, terrain, ...)
Take a look at the links in my earlier post. OpenRM is a good scene
graph manager. And OpenRM + Chromium have the capability to render
OpenGL scenes over multiple distributed machines.
http://www.r3vis.com/Gallery/index.html
>
> The "intent" isn't to *prove* anything. If I was attempting to do much
> of anything beyond having fun and giving myself something to play with
> at home, it would be to "back up" the essay I wrote recently and
> posted.
Fair enough. Those are basically my goals for my bindings.
Was there a reason why you Lispified your OpenGL bindings, for example
using gl-clear-depth instead of "glClearDepth"? I would be interested in
getting whatever you do to work in Corman Lisp, but it would be a pain
to have to manually add the necessary '-' to each OpenGL function in the
Corman OpenGL FFI. Corman has a C header to Lisp translator that is able
to convert the OpenGL header files with almost no programmer massaging
required.
PS. I'm using your regex package right now, thanks.