I haven't had time lately to organize and post meaningful blog entries
(http://ptarmigangames.com/malcontent)
but came across this thread on the sweng-gamedev mailing list. It's
about all the
scary things people do to preprocess C++ for meta information.
http://thread.gmane.org/gmane.games.devel.sweng/4346
There are all kinds of crazy hand rolled schemes so that they can
annotate
their classes for things like serialization, run time typing etc.
Experienced CL people will know how simple this by wrapping a macro
around defclass.
For those new to CL, these C++ efforts are the type of pain that makes
us wonder
why people continue to think it's so great. With CL macros, this kind
of thing can easily be written in CL itself to extend the system.
For my game code i'm planning on wrapping defclass so that classes can
be marked for serializagin each field can be annotated as to whether
they are local, server side only, or client side only, as well as
generating the server and client side version of the classes, and the
serialization code to pass the info from one side to the other.
Sure beats the latest trends of either (a) using comments to specify
metaprogramming then having to preprocess the file to take care of it
or
(b) the inscrutability of C++ template abuse programming.
Too damned many Brads here! :)
I just wanted to say hello. I am also interested in games/3D graphics,
and it's good to see that someone who has more Lisp experience than me
doesn't think that it is impossible. Are you writting open or closed
source stuff? If it is open I wouldn't mind taking a look at the code
- I am a complete Lisp newbie, so some real code would be instructional
for me.
Cheers
Brad
I'm not intending to open source my code, maybe that will happen some
day, but not in the near future.
If you follow my blog, I try and put up some intertersting and
instructive cases on how the power of CL helps, along with code
examples yanked from my project.
So far I've developed the low level networking layer, and prototype rpc
layer for the server side using CMUCL/SBCL on linux and freebsd (both
x86).
I'm currently working on client side code, Lispworks for Windows,
OpenGL.
I'm desiring to have the client and server run on MacOSX as well.
I think its very possible to use CL for games of all kinds. I'm
specifically targetting MMORPGs which have high requirements on both
the client and server. I suspect doing an A level FPS would present
some speed challenges for CL, but done right, that would only be in
specific areas, and would present similar problems in the C++ world as
well, requiring specialized code (assembly, intel compiler) to maximize
speed on the chip.
In general, the tricks to maximizing OpenGL performance have nothing to
do with the language used and everything to do with maximizing data
setup and library calls.
"bradb" <··············@gmail.com> writes:
> Too damned many Brads here! :)
> I just wanted to say hello. I am also interested in games/3D graphics,
> and it's good to see that someone who has more Lisp experience than me
> doesn't think that it is impossible. Are you writting open or closed
Ingvar Mattsson is also writing a 3D game in Lisp. His blog is:
http://www.advogato.org/person/ingvar/
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- CFFI: Foreign Function Interface
"Ingvar" <······@hexapodia.net> wrote in message
···················@head.cathouse.bofh.se...
>
> I'm, on the side and not nearly as efficiently as I'd like, looking at
> getting "CLg" working (lisp-alike code that gets compiled to shaders,
> not sure if I will be targetting OpenGL shaders or DirectX shaders
> first, but I imagine once the over-arching CLg infrastructure is in
> place, it's just a question of writing another back-end). Life has a
> horrible tendency to get in the way.
>
Well, I've been looking at Win-DX + Lisp for game development and the
results I've had so far aren't encouraging, I managed to get a connection
to DirectDraw from LW Personal, FFI was a major pain, and the screen was
a different colour from the C++ version. When it comes down to it, I see
two possible configurations:
1- C++ front end, graphics engine (possibly + physics), Lisp game logic
(possibly a CLISP-style byte-code compiler), specialized public scripting
language
2- Lisp front end, C++ (DLL?) graphics engine (possibly + physics), Lisp
game
logic (full compiler), specialized public scripting language
The front end depends on the amount of control you can get over the Windows
message loop, games have a tendency to use a highly specialized loop due to
frame rate issues.
The graphics engine is due to ease of programming, C++ connects easily to
the OO DX, no really hideous FFI (you can design your own interface), no
boxing issues, you don't end up with a bunch of DX specific symbols in the
Lisp end. Lisp can then connect from a higher level of abstraction.
Specialized scripting language, as nice as Lisp is for scripting, the last
thing you want is for a script kiddie to get access to CL:WITH-OPEN-FILE,
mods should be relatively safe.
--
Geoff
For cross-platform capabilities, and because DX is so hideous, i'm
using OpenGL. LW has much of OpenGL already setup with ffi, i've had to
add some definitions for some of the later versions of OpenGL, which is
not a problem because i can add 1 or 2 new calls as I need them.
I've created FFI definitions to the win32 calls so I can run my own
main loop through the windowing system directly.
I thought this post is just another troll staff but looks like i'm
wrong.
Ok my interest is entirely on DirectX games Win platform .
I can't afford Mac and i still think that Linux is not ready for
commoners like me.
I don't have anything against OpenGl but majority of the Win games run
with DirectX and with coming of Vista OpenGL will get another strong
punch in the nose .
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=12;t=000001
So everytime we Lispers are saying that Lisp is good for games
we have nothing but aoe scripts and Noughty Dog past games to prove it.
If someone has anything to prove that i'm wrong post the game that is
written in Lisp 'couse i really want to see it.
Speaking about what might have been written and how it can be done
means nothing to anybody outside c.l.l.
So untill someone write some cool game and show the world that it can
been done with Lisp we're just running our mouth.
Nowdays C/C++ rules and Lisp sucks for games no matter we like that or
not.
slobodan
http://blazeski.blogspot.com/
I think that you have a fair point concerning the lack of actual games
written in Lisp. But I don't understand the rest of your post really.
You say that Lispers only have Naughty Dog as an example, and then you
just ask for an example... huh? Having an example is proof that
something can be done - so therefore it is already proven that it is
possible to write a PS2 game using Lisp. By extension it ought to be
possible to write a Lisp game for the PC. However, right now it is
probably very very hard to do because there are few (no?) tools that
are geared toward writing games in Lisp - so you have to write them
yourself.
Its like a learning curve thing, notepad has almost no learning curve
as an editor, while Vim and Emacs have steep curves - but which is
ultimately more powerful? Not notepad.
So, yes - right now C++ is easier to write small games in, because the
tools are there. Once Lisp has the tools (or access to the C tools)
then I suspect things may be different.
Also, I doubt that OpenGL is really going away - it is a stable, mature
API that developers like to use.
Brad
bradb wrote:
> I think that you have a fair point concerning the lack of actual games
> written in Lisp. But I don't understand the rest of your post really.
> You say that Lispers only have Naughty Dog as an example, and then you
> just ask for an example... huh?
> Having an example is proof that
> something can be done - so therefore it is already proven that it is
> possible to write a PS2 game using Lisp. By extension it ought to be
> possible to write a Lisp game for the PC. However, right now it is
> probably very very hard to do because there are few (no?) tools that
> are geared toward writing games in Lisp - so you have to write them
> yourself.
> Its like a learning curve thing, notepad has almost no learning curve
> as an editor, while Vim and Emacs have steep curves - but which is
> ultimately more powerful? Not notepad.
> So, yes - right now C++ is easier to write small games in, because the
> tools are there. Once Lisp has the tools (or access to the C tools)
> then I suspect things may be different.
>
My post was about our credibility regarding lispers position that C++
sucks for games . Allmost all of the games are written in C/C++ and now
nobody (Noughty dog left Lisp right?) doesn't have anything with Lisp .
Also concentrated on Win/DX slice the only thing i've ever heard about
Lisp is aoe scripts . Nothing else. Nil
So when C++ camp says that Lisp sucks for games and C++ rules they have
allmost every game written in it . When Lispers says vice versa what do
Lispers have to back it up? Nothing .
It possible for me to write better game than Mafia but untill i prove
it that\s just something\
i could be a Michael Jordan if i wanted to , but i prefer selling hot
dogs
So my fellow Lispers who care about Lisp in Game development lets shut
the f**k up our mouths and start writing games in it.
When we'll have some game using Lisp we could discuss this issue.
That's it from me . Untill i code something interesthing in Lisp (or
partially in Lisp like i plan to) i will not write another word about
Lisp in gameworld.
> Also, I doubt that OpenGL is really going away - it is a stable, mature
> API that developers like to use.
I'm not Nostradamus but today the majority of game development for Win
is DirectX based
with some honourable execptions like John Carmack works , call of duty
etc.
With MS freezing OpenGL at 1.4 and aero issues i believe that OpenGl
will get a major
punch . It'll probably stay but will lose market share and it could be
marginalized.
But let's wait and see 2006 is close.
fireblade wrote:
>> Also, I doubt that OpenGL is really going away - it is a stable, mature
>> API that developers like to use.
>
> I'm not Nostradamus but today the majority of game development for Win
> is DirectX based
> with some honourable execptions like John Carmack works , call of duty
> etc.
And what percentage of game development is Windows-only? IIRC I heard
that the PS2 uses OpenGL. So do all Unices, the Mac, and possibly other
game consoles (Gamecube?). Direct3D is only Windows and the XBox. To
me it's really a wonder that so many people still invest in that
technology, just because it allowed stuff like programmable shaders
maybe a couple of months before GL did...
> With MS freezing OpenGL at 1.4 and aero issues i believe that OpenGl
> will get a major
> punch . It'll probably stay but will lose market share and it could be
> marginalized.
But why? There are still lots of non-MS game consoles, there are
important 3D applications running on Unices and Macs. For new
developments especially it doesn't make sense at all to found that
development on Direct3D. Also, isn't there an OpenGL implementation
that uses Direct3D as the low-level backend?
> But let's wait and see 2006 is close.
Yes, it's gonna be interesting.
--
Do or do not. There is no try.
Yoda
Ulrich my game is a strategy like and that genre is not a console
based ,
there's some exceptions but games with many buttons are for desctops .
So i'm in the desctop kingdom where MS rules with 90%+ of the comps.
If i choose OpenGL i would be in deep shit when Vista arrives,with my
OpenGl emulated
lossing 50% performance and/or turning of aeroglass eye candies.
BTW also that is not the only reason, DX is more like indystry standard
in the gameworld the majority of the code and books are written for it.
For starter like me that is very important .Doing console it's tricky,
you must acquire the license from Sony , Nintendo ... which is
impossible for me.
The Mac is only other market but it's marginal and turbulent is Jobs
going to Intel ?
About the Linux there's just no bread in that market for games.
Fireblade,
I read an interesting article a while ago (google can't find it now)
that said developing for the Mac was actually a good idea. Some of the
points I remember
- although the market is smaller, they tend to actually like their
computers
- mac people are used to paying for software, win people download it
- the market is still more than large enough to support devs who don't
need to sell 1million copies just to recoup costs
>From a pure API point of view, the last time I looked at DX it was a
mess, where OpenGL is actually nice. I really doubt that OGL support
will be bad on Vista because there are too many developers (not just
games, CAD tools) with an interest it OGL on Win being good. And if it
is bad, either
1) The OGL consortium + others will kick up a stink (lawsuit?)
2) A third party will offer decent OS support
Still, do what you feel is best - but everyone I know who tinkers with
games has chosen OGL.
Brad
"bradb" <··············@gmail.com> writes:
> Fireblade,
> I read an interesting article a while ago (google can't find it now)
> that said developing for the Mac was actually a good idea. Some of the
> points I remember
Probably this:
<http://wilshipley.com/blog/WWDC_Student_Talk.pdf>
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
That's the one, thanks. By the way, I really like your book. I am
currently trying to implement/understand your binary file parsers so I
can easily load 3D data files. It is slow going (I've started from
scratch 3 times, understanding a little more each time) - but I don't
feel like I am doing too bad for a newbie.
Just wanted to take this opportunity to give some thanks to you for
writing PCL.
Brad
bradb wrote:
>>From a pure API point of view, the last time I looked at DX it was a
> mess, where OpenGL is actually nice. I really doubt that OGL support
> will be bad on Vista because there are too many developers (not just
> games, CAD tools) with an interest it OGL on Win being good.
it's not that bad, just emulated with Direct3D, and only if you enable the
new 3D Windows GUI, AFAIK. I don't think that CAD tool users would care
about, if there are native OpenGL with 200 fps or Direct3D emulated with
150 fps. And games are fullscreen anyway most of the time, so disabling the
3D Windows interface is no problem, as long as it can be done by the game
program and restored after program exit.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"Frank Buss" <··@frank-buss.de> wrote in message
·····································@40tude.net...
> bradb wrote:
>
>>>From a pure API point of view, the last time I looked at DX it was a
>> mess, where OpenGL is actually nice. I really doubt that OGL support
>> will be bad on Vista because there are too many developers (not just
>> games, CAD tools) with an interest it OGL on Win being good.
>
> it's not that bad, just emulated with Direct3D, and only if you enable the
> new 3D Windows GUI, AFAIK. I don't think that CAD tool users would care
> about, if there are native OpenGL with 200 fps or Direct3D emulated with
> 150 fps. And games are fullscreen anyway most of the time, so disabling
> the
> 3D Windows interface is no problem, as long as it can be done by the game
> program and restored after program exit.
Well my preference would be
(with-graphics-standard ((gl #|(or :open-gl :win-dx3d ...)|# &body body)
...)
and have the code work correctly in either case.
I keep thinking about a 'Game-Lisp', with the ability to: lock the REPL
in a package so READ could only use symbols explicitly included in that
package (user console + scripting); fine control over the gc, including
the ability to create areas that the gc never looks at but instead can
be collected en masse for things like level data; full CL + compiler.
Picture walking across an open field, in the distance a translucent flat
rectangle floats in the air and on it, in glowing type, is written:
+--------------------------+-+
|WELCOME,FRIEND |x|
+--------------------------+-+
|GAME-USER 1 > _ |
| |
| |
| |
+----------------------------+
----
Geoff
fireblade wrote:
> Doing console it's tricky, you must acquire the license from Sony,
> Nintendo ... which is impossible for me.
if you don't want to make money with it, you can develop for free for PSP:
http://ps2dev.org/
I've ported Lua to it and enhanced it with some own functions:
http://www.luaplayer.org/
(and now with the downgrade exploit, you can even downgrade your 2.0
European PSP to a 1.5 version, to execute own programs on it, if you don't
need the web browser).
The PSPSDK provides a full Unix environment, so it should be easy to
compile some Lisp implementation for it.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
"fireblade" <········@YAHOO.COM> writes:
> So my fellow Lispers who care about Lisp in Game development lets shut
> the f**k up our mouths and start writing games in it.
> When we'll have some game using Lisp we could discuss this issue.
I don't really know anything about game development, but the arguments
I've seen in threads like this seem to boil down to the fact that the
tool chains are written for C++ game developers, not Lisp game
developers. Naughty Dog had a tool, but has apparently abandoned it.
Rather than jumping straight into games (which seem rather complex to
me), perhaps it would be wiser to build up the required tool chains
for Lisp development of games? Lisp is quite good for building tools.
--
http://www.david-steuber.com/
The UnBlog | Lisp on OS X topics for the most part
Click all the links you want. I'll make more!
>Rather than jumping straight into games (which seem rather complex to
>me), perhaps it would be wiser to build up the required tool chains
>for Lisp development of games? Lisp is quite good for building tools.
Actually I plan to use it for AI , game logic and scripting staff .
Even for novice Lisper like me who doesn't even understand CLOS
and use STRUCT instead work in the game logic staff is piece of cake.
The first thing I love about Lisp is it containers . I couldn't imagine
doing
high level staff without lists when i can put everything in, floats,
structs , pointer to other lists even functions . I\m sometimes even
tempted to write functionally in C++
and than i understand how much details i could just not define with
Lisp.
fireblade wrote:
> > Nowdays C/C++ rules and Lisp sucks for games no matter we like that or
> > not.
>
>
> >>>Change it.
> I'm working on it .
Blade is anybody else working Lisp with DirectX ?
fireblade wrote:
> > Nowdays C/C++ rules and Lisp sucks for games no matter we like that or
> > not.
> >>>Change it.
> I'm working on it .
>Blade is anybody else working Lisp with DirectX ?
Not as far as i know
>> Nowdays C/C++ rules and Lisp sucks for games no matter we like that or
>> not.
>>>>Change it.
>>> I'm working on it .
>Nice! That's the spirit! :-)
thanks
http://blazeski.blogspot.com/
On 2005-09-30 12:46:21, fireblade wrote:
>> Nowdays C/C++ rules and Lisp sucks for games no matter we like that or
>> not.
>
>>>>Change it.
> I'm working on it .
Nice! That's the spirit! :-)
Some more thoughts on this topic...
In one of Paul Graham's essay about his startup he states that using
lisp gave him an advantage over his competitors. So given that, rather
than say "nobody uses lisp in games therefore I won't", the same spirit
would suggest "well i will write games in lisp, giving my company a
competitive advantage".
So then the Naughty Dog example comes up, and here we can see an
example of a company that wholly embraced lisp and succeeded in making
a huge hit game.
But they had a couple of highly talented, MIT trained, lisp experts,
and you have to ask the question was it lisp that made the difference,
or the team and people that used it?
Without more examples it's hard to say.
A lot of posts on this topic have stated that tools do not work with
lisp which is why professional developers would be unable to change.
Well I'm not so sure about that. DirectX, OpenGL and things like the
Sony and Nintendo library code are all perfectly wrappable given a
suffiently powerful way to interface them. A few weeks work is the most
it would take you do that.
As for external tools like Max and Maya exporters, in a typically 18
month to 2 year project you are going to get time to get your graphics
pipeline exactly how you want it... so in otherwords writing Max and
Maya exporters that will export just right for your system is not going
to be a big deal.
My guess is that some kind of hybrid between a very low level C++ and
game library level system with a lisp system running on top of it would
be the ideal way to go.
The most serious problem with using lisp is that you won't be starting
with expert lisp programmers. There just aren't any waiting around for
game programming jobs. So you need to come up with a way to train them
to be lisp experts, that can write lisp code in a way that will run in
limited memory environments with slow processors.
Naughty Dog's lisp experts built a compiler and a language and no doubt
most of their game systems before they started bringing more people in.
I'm a new lisp programmer, and I've already passed the point where if I
want to write a little program or utility I will instinctively and
quickly write it in lisp. Some of those tools will start to make it
into my workplace, and there may be a gradual infection of those who
are interested.
Justin Heyes-Jones
justinhj wrote:
>
> The most serious problem with using lisp is that you won't be starting
> with expert lisp programmers. There just aren't any waiting around for
> game programming jobs. So you need to come up with a way to train them
> to be lisp experts, that can write lisp code in a way that will run in
> limited memory environments with slow processors.
>
Its a mistaken impression is that you have to be an expert Lisp programmer
to use Lisp. Lisp is no different that any other language, in that, to
write good programs you need really good/expert programmers. C++ game
programmers encounter the very same memory allocation issues that Lisp
programmers would encounter, the knowledge is transferable.
There are no slow processors and limited memory environments anymore.
Even if one undertook to write a new game, if it took 3 years to
do, processor speed would be 4x what it is now.
Wade
"Its a mistaken impression is that you have to be an expert Lisp
programmer
to use Lisp. Lisp is no different that any other language, in that, to
write good programs you need really good/expert programmers. C++ game
programmers encounter the very same memory allocation issues that Lisp
programmers would encounter, the knowledge is transferable."
C++ is only an OOP extension of C, and C is virtually a machine
independent compiler. In games we are used to a thin layer of
abstraction between us and the hardware. You're often dealing with raw
data types, doing lots of custom memory allocation and making systems
optimal in terms of data size and speed.
With lisp a lot of that stuff goes on in the background. If you want to
know what data types are being used you need to compile and look at the
output, or force it with keywords. You need to understand cons'ing in
detail. You need to know how and when garbage collection happens. I
think by the time you understand all that stuff you're an expert lisp
programmer.
In fact Naughty Dogs lisp like language for game development on the ps2
avoided cons'ing at all, and allowed memory and objects to be allocated
and freed at the time when the programmers wanted them to be.
"There are no slow processors and limited memory environments anymore.
Even if one undertook to write a new game, if it took 3 years to
do, processor speed would be 4x what it is now. "
That is misinformed. People will be programming GBA games for another
three years at least. Then you have cell phones, dvd players and cable
boxes and other limited devices like $20 tv games.
All of these systems are slow, and limited in terms of memory.
Even on the latest consoles memory is pretty tight for most game
titles. As the memory grows, so does the resolution and detail of the
graphics and sound that goes into the game. This is unlikely to be any
different on the next, or forseeable generations of game console.
Justin
justinhj wrote:
> You're often dealing with raw
> data types, doing lots of custom memory allocation and making systems
> optimal in terms of data size and speed.
Still? I'm sure they did this five years ago, but it seems increasingly
unimportant. Even most cellphone apps are done in *Java* today! By the
way, the cellphone I got a month ago has 24MB RAM (plus MMC-card)!!
That's nothing to sneeze it. I don't know what CPU it has, but probably
something above 30MHz.
> That is misinformed. People will be programming GBA games for another
> three years at least. Then you have cell phones, dvd players and cable
> boxes and other limited devices like $20 tv games.
Ok, the GBA is different, but even cellphones seem to be pretty much on
the high-memory side now.
> All of these systems are slow, and limited in terms of memory.
Maybe slow.
> Even on the latest consoles memory is pretty tight for most game
> titles. As the memory grows, so does the resolution and detail of the
> graphics and sound that goes into the game. This is unlikely to be any
> different on the next, or forseeable generations of game console.
So you just licence and use another 3D-engine. The game itself can be
done in Lisp. Either that, or happy greenspunning...
--
Do or do not. There is no try.
Yoda
Yes, it is still the case that at least for high performance games,
memory usage and code optimization make a difference. For the most part
this is because of the ever increasing size and complexity of the
graphics....there's more processor speed available which has allowed
game design and functionality to grow, but when you get to the graphics
layer, this is still an area where a lot of care is needed. To pump the
quantity of graphic information to the graphics card, it is important
that data be set up properly, and the quantity of calls to the graphics
library is minimized.
This is a language independent issue. As Wade has said, you don't need
expert lisp programmers, you need expert programmers. Understanding of
the need for setting up the memory and how to maximize use of the
graphics library is language independent and where skill is needed.
Nor is it burried under the covers in lisp. At this point you need to
use the explicit, implementation dependent routines to ensure your data
is properly set up and passed on.
This means knowing how your implementation uses memory, what
specialized routines to call (ffi land). The same thing occurs in the
C, C++ world, but there it is more of a direct correlation. C++ game
developers pull out tuning tools to ensure that their data and code are
being optimized for the processor pipeline. Language independent issues
again.
E.g. for my game client , using LispWorks, I need to know that the
quickest way to load data and send data to the GL is to have properly
typed arrays allocated in the static area (using lisp arrays or foreign
arrays) and how to minimize the number of calls I make to the GL. No
specific lisp knowlege is involved there.
Some have commented on having an intermediate C++ layer between Lisp
and the machine but the only reasin I can see for that is to take
advantage of existing game engines and only writing the game logic in
lisp. I think in the long run it probably takes as long to integrate
and mess with customizing the game engine than to create one natively
in Lisp anyway.
It also depends upon your interests too. If you have no desire to write
the game engine, but do want to write the game logic, then taking
advantage of existing tools could make sense.
My belief is that it makes more sense to to it all in lisp so that is
what I'm doing.
brad
Brad Might:
My belief is that it makes more sense to to it all in lisp so that is
what I'm doing.
I have been following your project with interest and wish you luck.
justinhj wrote:
> You're often dealing with raw
> data types, doing lots of custom memory allocation and making systems
> optimal in terms of data size and speed.
Ulrich Hobelmann wrote:
> Still? I'm sure they did this five years ago, but it seems increasingly
> unimportant. Even most cellphone apps are done in *Java* today! By the
> way, the cellphone I got a month ago has 24MB RAM (plus MMC-card)!!
> That's nothing to sneeze it. I don't know what CPU it has, but probably
> something above 30MHz.
I've been writing video games for 12 years and it's the same now as it
was the day I started. There is less need now for tightly optimised
assembler, although there are pockets of that in some projects. But in
terms of memory use and data size it's still extremely critical.
I could write a couple of paragraphs on the use of Java on cell phones
but that would be a different topic. I know a few developers and they
don't hold a high opinion on J2ME and its variable implementation
quality on various phones.
justinhj wrote:
> I could write a couple of paragraphs on the use of Java on cell phones
> but that would be a different topic. I know a few developers and they
> don't hold a high opinion on J2ME and its variable implementation
> quality on various phones.
Yes, I've heard those stories too, and I'd *love* to have a portable (or
maybe only as portable as J2ME) C library to write to and a linker that
I can install on a Mac (i.e. no proprietary crap), but that seems to be
too much to ask for. A C program could probably do five times as much
as Java before running into memory trouble.
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
"justinhj" <········@gmail.com> writes:
> So then the Naughty Dog example comes up, and here we can see an
> example of a company that wholly embraced lisp and succeeded in making
> a huge hit game.
>
> But they had a couple of highly talented, MIT trained, lisp experts,
> and you have to ask the question was it lisp that made the difference,
> or the team and people that used it?
Perhaps they are connected.
> The most serious problem with using lisp is that you won't be starting
> with expert lisp programmers.
Perhaps it is simply the case that dumb people can't use lisp.
Joe Marshall wrote:
>> The most serious problem with using lisp is that you won't be starting
>> with expert lisp programmers.
>
> Perhaps it is simply the case that dumb people can't use lisp.
"I so dumb. I could never learn Chinese."
Yet people were born and learnt it.
And of course dumb people can't really use Java, either.
--
Do or do not. There is no try.
Yoda
> So you just licence and use another 3D-engine. The game itself can be
> done in Lisp. Either that, or happy greenspunning...
Licensing high class 3D-engine is not an option unless you have a
publisher to pay for it and no publisher won't even want to talk with
Joe Nobody unless you have a nearly complete game to show it , which of
course
you can't make without the engine.
Another option is affordable (few hundreds bucks like garagegames,
TV3D) or OpenSource engines like Irrlicht and Ogre .
They are written in C++ and even none of them has Common Lisp
interface , so you have to write it yourself which is not an trivial
thing regarding the tools to help you BErrazano/CFFI just started to
show up. Your Lisp must INTERFACE with C++ not C .
Also you probably have to customize the engine (if you have the source
code) READ you have to use C++ .
When you need advise about some code about various features you want
to implement you will have go through various books , published source
code even posts on forums and newsgroups and speak their language the
C++.
Even if you use OpenGl for graphics what about input , networking ,
sound etc? (Which future in the WIn market is at least cloudy )
Many folks like Dave Astle from gamedev.net use using OPenGl with
other
elements of DirectX like DirectInput, DirectNetworking sound etc
So you probably have to use some components of DX if you're for the WIn
market to save your time . And that means COM C++ classes.
So if you're in a 3d world you're in the kingdom of C++ one way or
another you have to read/write C++ code .
The bottom line is that your game will have to use C++.The question is
just how much?
fireblade wrote:
> They are written in C++ and even none of them has Common Lisp
> interface , so you have to write it yourself which is not an trivial
> thing regarding the tools to help you BErrazano/CFFI just started to
> show up.
So what? Have you tried them? Do you know of problems with them? Do you
prefer ten year old unmaintained tools? Anything new is no good? Talk
about a self-fulfilling prophecy.
Both projects were huge successes. All they need now are more users to
unearth what problems may remain, or drive new development.
> Even if you use OpenGl for graphics what about input , networking ,
> sound etc?
The idea behind Verrazano was to give Lisp applications the same access
to C++ libraries as C++. If you want that, get involved with Verrazano.
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
> fireblade wrote:
> > They are written in C++ and even none of them has Common Lisp
> > interface , so you have to write it yourself which is not an trivial
> > thing regarding the tools to help you Verrazano/CFFI just started to
> > show up.
>
> So what? Have you tried them? Do you know of problems with them? Do you
> prefer ten year old unmaintained tools? Anything new is no good? Talk
> about a self-fulfilling prophecy.
>
> Both projects were huge successes. All they need now are more users to
> unearth what problems may remain, or drive new development.
>
Kenny I'm thrilled about Verrazano and CFFI , hat down to Rayiner and
Luis.
The only reason I didn't try them is lack of time .I have one exam
left to earn my bachelor degree (plan to finish it this October and go
through papirology till the end of November) and the time left when i'm
not styding i spent on working with DirectX and C++ making various
demo's which code i plan to use for my engine , and trying various
game logic ideas with Lisp.
I'm in the first phase of experimenting and making and improving code
that later will be used as building blocks.
My experience is very scarce with DirectX with only two 2d games made
Tetris clone and airplane shooter , now I'm working on my first 3d
demo,
full 3d camera movement through city street .This demo will be the
base for creation of the 3d world builder.
> > Even if you use OpenGl for graphics what about input , networking ,
> > sound etc?
>
> The idea behind Verrazano was to give Lisp applications the same access
> to C++ libraries as C++. If you want that, get involved with Verrazano.
Kenny even if Verrazano works flowlessy with DirectX 9 and some
engines
made in C++ (like Irrlicht and Newton) I will certainly have to
customize
them read write C++ code.
I allready made my choice to leave DirectX to C++ use my own
Winterstorm engine or customized Irrlicht and connect through
Verrazano or less likely FLI ,with high-level game logic staff written
in Lisp .
I don't understand what is wrong about that?
Will coding in Lisp with DirectX library through Verrazano make me a
REAL Lisper ?
Well i can't do that . And i don't want to do it . What will happen if
my project needs another programmer(s) ? There's many with C++/DirectX
but how many of them have Common Lisp and DirectX in their protfolio?
Lisp is lovely tool but it's just that , a tool.The only reason i do
programming is to make my game . And if f#++ will help me to make it
easier i will learn it and use it .
slobodan
http://blazeski.blogspot.com
fireblade wrote:
> Kenny Tilton wrote:
>
>>fireblade wrote:
>>
>>>They are written in C++ and even none of them has Common Lisp
>>>interface , so you have to write it yourself which is not an trivial
>>>thing regarding the tools to help you Verrazano/CFFI just started to
>>>show up.
>>
>>So what? Have you tried them? Do you know of problems with them? Do you
>>prefer ten year old unmaintained tools? Anything new is no good? Talk
>>about a self-fulfilling prophecy.
>>
>>Both projects were huge successes. All they need now are more users to
>>unearth what problems may remain, or drive new development.
>>
>
> Kenny I'm thrilled about Verrazano and CFFI , hat down to Rayiner and
> Luis.
> The only reason I didn't try them is lack of time .I have one exam
> left to earn my bachelor degree (plan to finish it this October and go
> through papirology till the end of November) and the time left when i'm
> not styding i spent on working with DirectX and C++ making various
> demo's which code i plan to use for my engine , and trying various
> game logic ideas with Lisp.
> I'm in the first phase of experimenting and making and improving code
> that later will be used as building blocks.
>
> My experience is very scarce with DirectX with only two 2d games made
> Tetris clone and airplane shooter , now I'm working on my first 3d
> demo,
> full 3d camera movement through city street .This demo will be the
> base for creation of the 3d world builder.
>
>
>>>Even if you use OpenGl for graphics what about input , networking ,
>>>sound etc?
>>
>>The idea behind Verrazano was to give Lisp applications the same access
>>to C++ libraries as C++. If you want that, get involved with Verrazano.
>
>
> Kenny even if Verrazano works flowlessy with DirectX 9 and some
> engines
> made in C++ (like Irrlicht and Newton) I will certainly have to
> customize
> them read write C++ code.
>
> I allready made my choice to leave DirectX to C++ use my own
> Winterstorm engine or customized Irrlicht and connect through
> Verrazano or less likely FLI ,with high-level game logic staff written
> in Lisp .
Good idea. Game logic in Lisp, talking to C++ libraries that do not need
to be re-invented (and are big).
> I don't understand what is wrong about that?
What is wrong with using Lisp? I must have misunderstood the prior
paragraph.
> Will coding in Lisp with DirectX library through Verrazano make me a
> REAL Lisper ?
Yes.
> Well i can't do that . And i don't want to do it .
OK, I definitely misunderstood. I thought you said game logic would be
in Lisp.
> What will happen if
> my project needs another programmer(s) ? There's many with C++/DirectX
> but how many of them have Common Lisp and DirectX in their protfolio?
Two questions:
Why does the experience in DirectX suddenly go away if they are calling
it from a different language?
The second question is multi-part. To make things easier, I will suppy
your answers:
- Were you planning on hiring a good programmer or bad? [good]
- How do you think a good C++ programmer will react when turned on to
Lisp? [rediscover their love of programming and stay up all night doing
Lisp]
- Will their excitement and the greater productivity of Lisp
counterbalance the productivity loss during the learning curve? [yes]
- Will the learning curve be shorter because they are working alongside
a Lisper? [yes]
- Will the learning period come to an end? [yes]
- How productive will they be once they are reasonably comfortable with
Lisp? [insanely]
- Does a sea anchor like C++ ever stop holding a ship back? [no]
> Lisp is lovely tool but it's just that , a tool.
You have a short memory. You forgot that the tool is lovely. By lovely
you mean vastly more productive.
> The only reason i do
> programming is to make my game . And if f#++ will help me to make it
> easier I will learn it...
I think you mean "harder". Ease means productivity, and you have now
talked yourself into a less productive language. Which you now have to
learn. Hmmmm....
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Kenny Tilton wrote:
> fireblade wrote:
>
> > Kenny Tilton wrote:
> >
> >>fireblade wrote:
> >>
> >>>They are written in C++ and even none of them has Common Lisp
> >>>interface , so you have to write it yourself which is not an trivial
> >>>thing regarding the tools to help you Verrazano/CFFI just started to
> >>>show up.
> >>
> >>So what? Have you tried them? Do you know of problems with them? Do you
> >>prefer ten year old unmaintained tools? Anything new is no good? Talk
> >>about a self-fulfilling prophecy.
> >>
> >>Both projects were huge successes. All they need now are more users to
> >>unearth what problems may remain, or drive new development.
> >>
> >
> > Kenny I'm thrilled about Verrazano and CFFI , hat down to Rayiner and
> > Luis.
> > The only reason I didn't try them is lack of time .I have one exam
> > left to earn my bachelor degree (plan to finish it this October and go
> > through papirology till the end of November) and the time left when i'm
> > not styding i spent on working with DirectX and C++ making various
> > demo's which code i plan to use for my engine , and trying various
> > game logic ideas with Lisp.
> > I'm in the first phase of experimenting and making and improving code
> > that later will be used as building blocks.
> >
> > My experience is very scarce with DirectX with only two 2d games made
> > Tetris clone and airplane shooter , now I'm working on my first 3d
> > demo,
> > full 3d camera movement through city street .This demo will be the
> > base for creation of the 3d world builder.
> >
> >
> >>>Even if you use OpenGl for graphics what about input , networking ,
> >>>sound etc?
> >>
> >>The idea behind Verrazano was to give Lisp applications the same access
> >>to C++ libraries as C++. If you want that, get involved with Verrazano.
> >
> >
> > Kenny even if Verrazano works flowlessy with DirectX 9 and some
> > engines
> > made in C++ (like Irrlicht and Newton) I will certainly have to
> > customize
> > them read write C++ code.
> >
> > I allready made my choice to leave DirectX to C++ use my own
> > Winterstorm engine or customized Irrlicht and connect through
> > Verrazano or less likely FLI ,with high-level game logic staff written
> > in Lisp .
>
> Good idea. Game logic in Lisp, talking to C++ libraries that do not need
> to be re-invented (and are big).
>
> > I don't understand what is wrong about that?
>
> What is wrong with using Lisp? I must have misunderstood the prior
> paragraph.
> > Will coding in Lisp with DirectX library through Verrazano make me a
> > REAL Lisper ?
>
> Yes.
>
> > Well i can't do that . And i don't want to do it .
>
> OK, I definitely misunderstood. I thought you said game logic would be
> in Lisp.
>
>
> "I've wrestled with reality for 35 years, Doctor, and I'm happy to state
> I finally won out over it."
> Elwood P. Dowd, "Harvey", 1950
Ok let's write once what exactly i plan to do :
DirectX is very very low level , even for drawing a simple spinning
cube with 3d camera movement and simple textures you need a lot of
code .
So if i call DirectX from Lisp that going to be a lot of calls and
callbacks , not very good scenario considering that i have to rewrite
a lot of code and if i stack someplace i will have to rewrite it in C++
to ask for tip in the forums.
So here's the plan:
Imagine player character needs to enter the house , Lisp checks what
kind of house it is , and calls C++ engine to draw it.
C++ code loads the house mesh , assigns proper textures , rotates
world matrix apropriately and finaly draws the house and send a
message to Lisp.There is only one call between Lisp code and C++
engine, if there
was a DX lisp directly calling there would be hundreds of FFI calls and
callbacks.
Lisp code holds players data like health , weapons , money ,..and take
cares who are his friends and who are his enemies and how they want to
help/hurt the player .C++ engine takes care how the player looks like ,
what are the skinned mesh animation for walking , shootin , standing
...
The game loop is like that :
1 Player input (Keyboard and Mouse)
2 C++ pass the input to Lisp
3 Lisp logic :
a process the input
b decides what will draw/play
c call C++ engine to draw it / play it
4 C++ engine executes and returns the message to Lisp
I still didn't decided where the collision detection and gamephysics
will be processed , i will have to experiment and make some demos
before i make a decision . Actually it's the game physics that worries
me .
But will see.
> > What will happen if
> > my project needs another programmer(s) ? There's many with C++/DirectX
> > but how many of them have Common Lisp and DirectX in their protfolio?
>
> Two questions:
>
> Why does the experience in DirectX suddenly go away if they are calling
> it from a different language?
>
They have to learn the other language and learn to call it, also they
have to rewrite his previous code. If i need 3d camera i don't write
any code
i just copy paste one.
> The second question is multi-part. To make things easier, I will suppy
> your answers:
>
> - Were you planning on hiring a good programmer or bad? [good]
1 I don't have a budget to hire anybody ,so i have to hire my friends
or the ones that believe in me and can do the job for free .
Currently i don't need programmers I need art (3d models,textures
...)and i have in my mind someones to help me.
2 When i'll look find a publisher that means i allready have playable
game , or finished that's the worse keys i could think what kind of
help i need.
> - How do you think a good C++ programmer will react when turned on to
> Lisp? [rediscover their love of programming and stay up all night doing
> Lisp]
1 Nobody wants to try it , I'm continously questioned why do i use it.
They've heard that some AI is done in Lisp but developing in Lisp. Huh
> - Will their excitement and the greater productivity of Lisp
> counterbalance the productivity loss during the learning curve? [yes]
See (1) , they don't want to even try it.
> - Will the learning curve be shorter because they are working alongside
> a Lisper? [yes]
See (1)
> - Will the learning period come to an end? [yes]
It won't even start.
> - How productive will they be once they are reasonably comfortable with
> Lisp? [insanely]
They won't even come to this point.
> - Does a sea anchor like C++ ever stop holding a ship back? [no]
I don't understand this.
> > Lisp is lovely tool but it's just that , a tool.
>
> You have a short memory. You forgot that the tool is lovely. By lovely
> you mean vastly more productive.
>
Agreed
> > The only reason i do
> > programming is to make my game . And if f#++ will help me to make it
> > easier I will learn it...
>
> I think you mean "harder". Ease means productivity, and you have now
> talked yourself into a less productive language. Which you now have to
> learn. Hmmmm....
Maybe ,maybe not.
Do you mind if I ask a few questions? I'm not trying to get you to
change your mind, I'm just new to Lisp and would like to see some of
your perspectives.
I also understand that from a practical standpoint, graphics and tools
are generally done in C/C++ - so I can see why you're sticking to that
toolchain.
Also, at some stage (in a couple of months when I know Lisp a little
better) I am planning on writing a simple OpenGL based engine in Lisp -
so I am interested on your opinion on 3D graphics in Lisp.
1) You mention that there is a lot of code just to draw a simple cube,
do you think that this code can be more compact with a layer of Lisp
macros/a mini language?
2) You are concerned about the calls to DX & callbacks via FFI - aside
from generating the FFI interface, are there runtime in-efficiencies
here? I thought that most Lisps could generate compiled calls that
would be no different to C calls.
3) Are you concerned about garbage collection and other memory
management?
>From reading this group, Lisp can do anything :) I guess I'll find
out more as I attempt my engine, but it is nice to try and be aware of
issues early.
Thanks
Brad
bradb wrote:
> Do you mind if I ask a few questions? I'm not trying to get you to
> change your mind, I'm just new to Lisp and would like to see some of
> your perspectives.
> I also understand that from a practical standpoint, graphics and tools
> are generally done in C/C++ - so I can see why you're sticking to that
> toolchain.
> Also, at some stage (in a couple of months when I know Lisp a little
> better) I am planning on writing a simple OpenGL based engine in Lisp -
> so I am interested on your opinion on 3D graphics in Lisp.
>
> 1) You mention that there is a lot of code just to draw a simple cube,
> do you think that this code can be more compact with a layer of Lisp
> macros/a mini language?
Theoretically yes but considering i don't do OpenGl you have to try it
yourself .
> 2) You are concerned about the calls to DX & callbacks via FFI - aside
> from generating the FFI interface, are there runtime in-efficiencies
> here? I thought that most Lisps could generate compiled calls that
> would be no different to C calls.
I like to avoid many indirections and i plan to call C++ not c .
I would lose lot of the power of DirectX considering c code can't use a
lot of classes . Of course there is wrappers but I want doing my game
instead of write wrappers.
> 3) Are you concerned about garbage collection and other memory
> management?
Graphic resources are expensive if there wasn't certain tricks /
techniques overflowing the vertex and index buffer is very easy to
happen.
In C++ i control when objects are created and distroyed in Lisp i
don't
GC do it for me .
> >From reading this group, Lisp can do anything :) I guess I'll find
> out more as I attempt my engine, but it is nice to try and be aware of
> issues early.
>
> Thanks
> Brad
Better ask for opinion someone with more Lisp / OpenGL experience.
1) The quantity of calls to the drawing library is the same whether C
or Lisp
2) DX being Com based, normally accessed by C++. I'm not sure how
Verrazano allows CL to call C++, is there some extra code so that lisp
calls C calls C++? COM is not specifically C++ so there's no reason it
couldn't be called directly. Do Franz and Lispworks and Corman have
direct COM interfaces? If you call COM directly, then there is no
additional overhead on your graphic library accesses.
3) Garbage collection and memory management issues can be dealt with in
most cases by (a) 'manually' managing the memory as you would have to
do in C++ anyway and (b) using implementation specific calls to manage
when the gc actually does get called.
There are instances when you may get better performance out of C++ in
some cases, and the FFI management is extra overhead from the Lisp
side, but in general, unless you are attempting to write a AAA title
game which pushes the most advanced computers to their limits, most
Lisp limitations are figments of imagination.
If I get to the point where CL is a bottleneck to my application then
(a) I will be very happy that i have managed to accomplish that much
and (b) I will address the bottlenecks when/where they occur.
In the meantime I have an incredibly powerful language which lets me do
a whole lot all by myself with much higher rates of productivity.
Brad Might wrote:
> 1) The quantity of calls to the drawing library is the same whether C
> or Lisp
> 2) DX being Com based, normally accessed by C++. I'm not sure how
> Verrazano allows CL to call C++, is there some extra code so that lisp
> calls C calls C++? COM is not specifically C++ so there's no reason it
> couldn't be called directly. Do Franz and Lispworks and Corman have
> direct COM interfaces? If you call COM directly, then there is no
> additional overhead on your graphic library accesses.
> 3) Garbage collection and memory management issues can be dealt with in
> most cases by (a) 'manually' managing the memory as you would have to
> do in C++ anyway and (b) using implementation specific calls to manage
> when the gc actually does get called.
>
> There are instances when you may get better performance out of C++ in
> some cases, and the FFI management is extra overhead from the Lisp
> side, but in general, unless you are attempting to write a AAA title
> game which pushes the most advanced computers to their limits, most
> Lisp limitations are figments of imagination.
>
> If I get to the point where CL is a bottleneck to my application then
> (a) I will be very happy that i have managed to accomplish that much
> and (b) I will address the bottlenecks when/where they occur.
>
> In the meantime I have an incredibly powerful language which lets me do
> a whole lot all by myself with much higher rates of productivity.
In addition, depending on the nature of your graphics code, it's just
possible that you will actually see performance gains in some areas from
using Lisp. I worked on a project at Apple where some of the pre-release
versions of a product had a system written in Lisp. A parallel project
implemented a similar system in C++. Some graphics performance was
superior in the Lisp version. One example of why is that we reused
buffers that in the C++ version were copied, presumably because the C++
client code couldn't be sure whether it was safe to deallocate the buffer.
> The quantity of calls to the drawing library is the same whether C
> or Lisp
It's interesting to note that DX or OGL calls can be surprisingly
expensive. Every DX call is an indirect call, and there are usually a
couple of more in the driver's state machine. Even NVIDIA's very
performant OGL driver uses at least one indirect call in the hot case.
Even if an FFI call is several times slower than a regular C function
call, the impact relative to the indirect calls in the driver is going
to be minimal.
> DX being Com based, normally accessed by C++. I'm not sure how
> Verrazano allows CL to call C++, is there some extra code so that lisp
> calls C calls C++? COM is not specifically C++ so there's no reason it
> couldn't be called directly.
VZN knows the v-table format for the target compiler, and emits v-fun
calls as small Lisp thunks that do the v-table lookup and call through
the resultant pointer. VZN won't work with COM at the moment, but since
Visual C++ uses the same v-table format for regular C++ objects, it'll
automatically be supported when I get a VC++ backend into CVS. If the
OP is curious about this, watch the mailing list this weekend, and I'll
be posting some info on it.
I like the sound of that. I will definitely give it a consideration
if/when I need to hook up to C++. Currently I'm hoping not to, going
directly to OpenGL and possibly OpenAL for sound, both of which are C
interfaces.
DirectInput, DirectSound I'm hoping to avoid as they are windows only
and I definitely want to run on Macintosh as well.
In fact as a low budget effort I wonder whether Mac would be the more
important market to chase, given that the competition in that space is
much smaller.
"Brad Might" <······@gmail.com> wrote in message ·····························@z14g2000cwz.googlegroups.com...
> 1) The quantity of calls to the drawing library is the same whether C
> or Lisp
> 2) DX being Com based, normally accessed by C++. I'm not sure how
> Verrazano allows CL to call C++, is there some extra code so that lisp
> calls C calls C++? COM is not specifically C++ so there's no reason it
> couldn't be called directly. Do Franz and Lispworks and Corman have
> direct COM interfaces? If you call COM directly, then there is no
> additional overhead on your graphic library accesses.
It's more a matter of the time you are willing to invest in
getting Lisp to talk to DX correctly. In my attempt, I chose
DirectDraw because the interface is comparatively simpler,
after several failed attempts at creating an FFI definition,
I ended up manually rewriting the header file into an IDL file
and using LW IDL->fasl facility. I don't know about now, but
none of the .h->.lisp converters were up to the task of
handling one of the DX header files.
Of course one of the other reasons I chose the DirectDraw is
the fact that it's no longer being developed and is fixed on
its COM interface. DX3D, on the other hand, doesn't present
itself to C++ as a COM interface anymore, but as a linked library
that handles the COM connection for the programmer. Which raises
the question on whether the interface presented by MS will remain
to be a direct representation of the COM interface itself. In
future incarnations, assuming it doesn't already do it, the
library may present one set of interfaces to the programmer and
use a completely different setup under the covers.
So, you end up with a couple of choices, you can spend time
creating FFI definitions so you can talk to DX directly, you
can create a DLL wrapper and FFI definitions to get the C++
presentation, you can find a lisp that will link an MS C++
library directly, or you can design top-down in Lisp, figure
out the kind of interface you want and build the C++ side
as a bridge between what suits Lisp and the DX interface.
As a bonus, if the Lisp-to-C interface is removed enough
from DX it may be possible to build an OGL connection as well.
> 3) Garbage collection and memory management issues can be dealt with in
> most cases by (a) 'manually' managing the memory as you would have to
> do in C++ anyway and (b) using implementation specific calls to manage
> when the gc actually does get called.
>
> There are instances when you may get better performance out of C++ in
> some cases, and the FFI management is extra overhead from the Lisp
> side, but in general, unless you are attempting to write a AAA title
> game which pushes the most advanced computers to their limits, most
> Lisp limitations are figments of imagination.
Well, assuming you may at least giving my argument a little
consideration, it now becomes a question of where to draw the line
between the responsibilities of the C++ code and the Lisp code.
Lisp is great at dynamics, things created on the fly, we have the
GC for when things get too crowded. C/C++ is great with the semi-static,
I need X amount of memory for T time, then we can release it.
And unlike most programming, game data usually contains a lot of
static areas. You don't usually see the textures alter from cement
to wood or glass when you are looking at a wall, or the corridor
you've just walked down morph into a water cooler. So...pass it
to the C++ side, the GC doesn't need to see it, move it around,
or even be aware of it's existance, when its time is up you can
destroy or recycle the buffer for the next area, cuts down GC
time to the stuff that is handled dynamically, planning, movement,
creation and removal of enemies, etc.
> If I get to the point where CL is a bottleneck to my application then
> (a) I will be very happy that i have managed to accomplish that much
> and (b) I will address the bottlenecks when/where they occur.
>
> In the meantime I have an incredibly powerful language which lets me do
> a whole lot all by myself with much higher rates of productivity.
Well, once again, it's a matter of where you spend your time, once a
link it established to DX, then comes the business of adapting all
the C++ example code into useable Lisp. Once it's done, you may be
right in the long run, but the first steps on that path appear both
treacherous and steep.
--
Geoff
Well I'm just avoiding the complexity of interfacing to DX by ignoring
DX altogether and using OpenGL. OpenGL gets additional points because
that is the 3d GL for the Macintosh (which is what i would be
immediately targetting if they hadn't pulled the intel switch...which
for the moment has my Mac plans on hold).
Yes, there is a lot more static memory usage in 3d programs. As you
say, textures and Meshs are loaded into static memory, used for a
while, then disposed of. I do this explicitly in LispWorks
(sys:in-static-area (make-array size :element-type 'single-float)).
Lifetime management of the buffers under lisp is a bit different.
Without having an explicit free, you have to break the link and let the
GC take care of the cleanup. For the most part this only introduces the
same memory management that you have to worry about with C++. If there
is no finalization cleanup required, then you don't have to explicity
manage the links, the memory will be cleaned up when there are no more
references. If there are cleanup issues (e.g. releasing graphics
resources), the choice is now tougher.
Do I manually track my buffer usage and perform a cleanup when I know
its no longer in use, or do I set a finalizer (implementation dependent
once again) and let the GC call the finalizer?
The problem with finalizers is that the GC has to notice that it needs
to be run. If the memory has been in use for a while, then it could be
in a higher, rarely collected generation. This introduces some
trade-offs.
How important is it that the resource be freed in a timely manner (e.g.
releasing a named texure object back to OpenGL), vs the cost of forcing
a complete GC to ensure that the finalizers are run....and do you keep
track of what has been freed so you can trigger the GC so that the
finalizer gets run? If so, why not track the resource anyway.
One solution to this problem that I am pondering, is identifying
specific points where calling a full GC is appropriate and not going to
be obvious or painful to the end user.
Re-using static buffers instead of relying on the GC is another idea
where it works (e.g. when I calculate the vertex interpolation in an
animation, i only need 1 buffer at a time so i use the same one (as a
class variable in vertex-animation-model) repeatedly every time I
calculate the animations. In this case I know that when I am using the
buffer i will have no conflicts. In other cases (loading a new mesh) I
don't have knowlege of what buffers are or are not being used, so I
allocate new ones.
Since I'm not using DirectX..where i can understand the plethora of
ugly C++ code that exists to deal with it, I don't see any advantage at
all to dropping in a layer between my lisp and the machine.
brad
"fireblade" <········@YAHOO.COM> writes:
> Ok let's write once what exactly i plan to do :
> DirectX is very very low level , even for drawing a simple spinning
> cube with 3d camera movement and simple textures you need a lot of
> code .
> So if i call DirectX from Lisp that going to be a lot of calls and
> callbacks , not very good scenario considering that i have to rewrite
> a lot of code and if i stack someplace i will have to rewrite it in C++
> to ask for tip in the forums.
First of all, check whether doing it the straightforward way is so
costly. If you stay in Lisp, you also get interactive debugging
(judging from the howling of incomprehension when things go wrong on
comp.graphics...opengl, this sounds like a major win), macros, lots of
ready-made collections, etc etc.
You could probably write a little language with macros that expand to
a mess of DirectX calls (basically like what the code in the books
looks like) -- the advantage being that you can write your code in the
little language. If performance isn't good enough, perhaps you can use
the expanded code as a roadmap for a subsequent translation to C++.
If you have performance problems you think are due to Lisp (and not
due to algorithmic choices, say), first check that the compiler is
generating the code you expect. Many Common Lisps have powerful
foreign function interfaces, so invoking DirectX _might_ not be so
expensive either. Again, you would have to experiment a bit.
> Lisp code holds players data like health , weapons , money ,..and take
> cares who are his friends and who are his enemies and how they want to
> help/hurt the player .C++ engine takes care how the player looks like ,
> what are the skinned mesh animation for walking , shootin , standing
I think writing the level loaders etc in Lisp could be another win, by
the way. And you could perhaps generate shaders in Lisp, then store
and load them outside of Lisp (again, if staying in Lisp is even a
problem?). There is probably quite a bit of code which is not time
critical in the first place.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
fireblade wrote:
> Will coding in Lisp with DirectX library through Verrazano make me a
> REAL Lisper ?
If you use a real Lisp, that also allows you to use stuff outside the CL
standard, then I suppose so ;)
> Well i can't do that . And i don't want to do it . What will happen if
> my project needs another programmer(s) ? There's many with C++/DirectX
> but how many of them have Common Lisp and DirectX in their protfolio?
> Lisp is lovely tool but it's just that , a tool.The only reason i do
> programming is to make my game . And if f#++ will help me to make it
> easier i will learn it and use it .
Lisp is a tool, and so is C++. If Lisp makes writing high-level code
easier for you, then it's the tool to use. If not, not. Other
programmers, if they're worthy of the name, will be able to learn CL
just like any other tool, technology, or libary, say, Make, Ant,
DirectX. And if Lip makes coding easier for you, then I suppose you
could show/explain that to the other guys as well, using your working code.
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Hi,
fireblade wrote:
>
> My experience is very scarce with DirectX with only two 2d games made
> Tetris clone and airplane shooter , now I'm working on my first 3d
> demo,
> full 3d camera movement through city street .This demo will be the
> base for creation of the 3d world builder.
>
Have you read "3D Game engine design" by David Eberly ? If not you
should do before coding a world builder or anything in this complexity.
Some other notes:
First point:
And since you mention irrlicht engine some mails ago: The concept of
that engine is a quite nice example of a game engine because it shows
the usual separation between game engine and game content. All serious
games that i have seen in the past few years try to separate these two
parts. The reason is quite simple. Game content is made by artists (more
or less). Artists usually don't want to think about quarternions or DGLs.
So modern engines hide the ugly details but provide a kind of high-level
scripting language to the artists that can be used to implement the
game stuff. The programmers part is mostly to extend the game engine
with new features and make them available in the scripting language.
See the light ? ;-)
Second point:
Much was said about LISP vs. C performance (so boring ...).
Why don't start to implement all in LISP then looking at the
bottlenecks and if needed move the computing intensive parts into a C
layer. From my (small) experience this will remove a lot of headache
from your doing. This, btw., is exactly what you would do when writing
an engine in C++ (remember the sin/cos tables ;-). But due to the
interactive nature of lisp you don't waste time to implement stuff like
scene-graph inspectors or so. Simple use the build-in lisp stuff.
See the light ?
Third point:
OGL or 3DX ? I wouldn't care for the first moment. Why ? Simple:
A mesh is a mesh is a mesh. And a mesh @ (50,-130.23, 10) is just
a mesh @ (50,-130.23, 10). The data & operations are independent from
what 3D kit you are using. And if you really need to provide
implementaion specific stuff - this is LISP - compile it at runtime.
Again, see the light ?
Just my $0.01
Kind regards
AHz
I can understand him wanting to choose one API only. Having 2 APIs to
support means that you need to do a lot more abstraction to get things
working right. Yes, the 3D concepts are the same, but the devil is in
the details. Only using 1 API - at least initially is a good choice.
Brad
>>>I can understand him wanting to choose one API only. Having 2 APIs to
support means that you need to do a lot more abstraction to get things
working right. Yes, the 3D concepts are the same, but the devil is in
the details. Only using 1 API - at least initially is a good choice.
It's nice to abstract away the interface to your graphics API so that
you can switch if required, and to give the code a longer life.
Justin
I am definitely not advocating less abstraction. I've written (or
helped write) 2 toy engines - they really didn't do anything more than
Quake2ish graphics. The first one was me and another guy & right from
the start we abstracted the graphics API. We found that the
abstractions we'd designed sometimes didn't fit well with the
underlying API, and we ended up with ugly code to add to the
intermediate layer.
The second engine I wrote targetted OGL only, code was much cleaner
with less abstraction hoops to jump through. I basically had all the
OGL calls isolated to a handful of files, so adding DX support at a
later date probably wouldn't have been too bad.
When I write my next engine (I seem to have this weird itch to
half-write graphics engines), it will be in Lisp & targetting OGL.
Brad
The hardest part of encapsulation is figuring out where to draw the
line between the abstract API and the actual API.
Sounds like you had your abstraction layer too low down, but if you
have it too high up then you find that you can't do everything you need
to do.
The best way to figure these design issues out, I find, is to think
about all the things you want to do with the high level API - draw
models, change properties on models, load and free up models, for
example. Then set that layer of functionality as your abstraction
layer.
If you're writing the graphics engine just to have fun, then you're
probably quite right to have the bare minimum wrapper around a
particular graphics library.
When writing games you'd be surprised how often even something as low
level as a graphics engine ends up having to be ported to some other
middeware api half way through a project.
Justin
Andreas Hinze wrote:
> Hi,
>
> fireblade wrote:
>
>>
>> My experience is very scarce with DirectX with only two 2d games made
>> Tetris clone and airplane shooter , now I'm working on my first 3d
>> demo,
>> full 3d camera movement through city street .This demo will be the
>> base for creation of the 3d world builder.
>>
> Have you read "3D Game engine design" by David Eberly ? If not you
> should do before coding a world builder or anything in this complexity.
>
Obiously i meant "3D game engine ARCHITECTURE" by David Eberly. In this
book he shows how to organize the infrastructure of an game engine (the
other book explains the basic algorithms). Sorry for the mistake.
Kind regards
AHz
Andreas Hinze wrote:
> Andreas Hinze wrote:
> > Hi,
> >
> > fireblade wrote:
> >
> >>
> >> My experience is very scarce with DirectX with only two 2d games made
> >> Tetris clone and airplane shooter , now I'm working on my first 3d
> >> demo,
> >> full 3d camera movement through city street .This demo will be the
> >> base for creation of the 3d world builder.
> >>
> > Have you read "3D Game engine design" by David Eberly ? If not you
> > should do before coding a world builder or anything in this complexity.
> >
> Obiously i meant "3D game engine ARCHITECTURE" by David Eberly. In this
> book he shows how to organize the infrastructure of an game engine (the
> other book explains the basic algorithms). Sorry for the mistake.
>
> Kind regards
> AHz
Nope , I have "3D Game engine design" , but still didn't study through
it,
fireblade wrote:
> After visiting the physics I found one things that lisp will
> doubtlessly shine.
>
> slobodan
> http://blazeski.blogspot.com/
>
Only one ?
Whats about having closures as actuators for dynamic objects directly
in your scene graph ?
(Around 100000000000000000000000000000000000000 other advantages
available on request ;-)
Regards
AHz
Andreas Hinze wrote:
> fireblade wrote:
> > After visiting the physics I found one things that lisp will
> > doubtlessly shine.
> >
> > slobodan
> > http://blazeski.blogspot.com/
> >
> Only one ?
> Whats about having closures as actuators for dynamic objects directly
> in your scene graph ?
> (Around 100000000000000000000000000000000000000 other advantages
> available on request ;-)
>
> Regards
> AHz
Cool the optimisam untill I finish the game ,
untill we are ready to deliver .
fireblade wrote:
> Andreas Hinze wrote:
>
>>Andreas Hinze wrote:
>>
>>>Hi,
>>>
>>>fireblade wrote:
>>>
>>>
>>>>My experience is very scarce with DirectX with only two 2d games made
>>>>Tetris clone and airplane shooter , now I'm working on my first 3d
>>>>demo,
>>>>full 3d camera movement through city street .This demo will be the
>>>>base for creation of the 3d world builder.
>>>>
>>>
>>>Have you read "3D Game engine design" by David Eberly ? If not you
>>>should do before coding a world builder or anything in this complexity.
>>>
>>
>>Obiously i meant "3D game engine ARCHITECTURE" by David Eberly. In this
>>book he shows how to organize the infrastructure of an game engine (the
>>other book explains the basic algorithms). Sorry for the mistake.
>>
>>Kind regards
>>AHz
>
>
> Nope , I have "3D Game engine design" , but still didn't study through
> it,
>
Maybe you should read it. I get a lot of knowledge and a lot of ideas
out of these two books.
Btw: Is the source code of your programs available ?
Regards
AHz
>>Btw: Is the source code of your programs available ?
I don't plan to open source my whole code , but I don't see nothing
wrong
to post some snippets or maybe some library for others to use.
BTW I tried some FFI interactions with FLI and it works fine,
considering my Initial design I'm worried about accuracy of collision
detection, considering I want Lisp to handle it but actually all mesh
data are only in C++ part.
So will see what happen.
fireblade wrote:
> The bottom line is that your game will have to use C++.The question is
> just how much?
The question is if it's easier to write some C/C++ wrappers and
interface to those, or to duplicate the Lisp features you like in C. I
think the interfacing overhead should be constant (and needs to be done
only once) and after that you're more flexible, but I'm just talking
cheap here, not developing games ;)
--
We're glad that graduates already know Java,
so we only have to teach them how to program.
somewhere in a German company
(credit to M. Felleisen and M. Sperber)
Joe Marshall wrote:
>"justinhj" <········@gmail.com> writes:
>> So then the Naughty Dog example comes up, and here we can see an
>> example of a company that wholly embraced lisp and succeeded in making
>> a huge hit game.
>> But they had a couple of highly talented, MIT trained, lisp experts,
>> and you have to ask the question was it lisp that made the difference,
>> or the team and people that used it?
>Perhaps they are connected.
Indeed, and they decided to stop using lisp too.
"justinhj" <········@gmail.com> writes:
> Joe Marshall wrote:
> >"justinhj" <········@gmail.com> writes:
> >> So then the Naughty Dog example comes up, and here we can see an
> >> example of a company that wholly embraced lisp and succeeded in making
> >> a huge hit game.
>
> >> But they had a couple of highly talented, MIT trained, lisp experts,
> >> and you have to ask the question was it lisp that made the difference,
> >> or the team and people that used it?
>
> >Perhaps they are connected.
>
> Indeed, and they decided to stop using lisp too.
Didn't you report that the story was that those people left?
"justinhj" <········@gmail.com> writes:
> Some more thoughts on this topic...
>
> In one of Paul Graham's essay about his startup he states that using
> lisp gave him an advantage over his competitors. So given that, rather
> than say "nobody uses lisp in games therefore I won't", the same spirit
> would suggest "well i will write games in lisp, giving my company a
> competitive advantage".
>
> So then the Naughty Dog example comes up, and here we can see an
> example of a company that wholly embraced lisp and succeeded in making
> a huge hit game.
>
> But they had a couple of highly talented, MIT trained, lisp experts,
> and you have to ask the question was it lisp that made the difference,
> or the team and people that used it?
>
> Without more examples it's hard to say.
You might wonder why talented, MIT trained, expert
programmers chose to do it in Lisp...
Unfortunately there are compelling reasons to use C++ when doing
professional game development.
Naughty Dog have been forced to abandon their in house lisp efforts and
are doing exactly the kind of C++ meta programming you're talking
about.
Justin
>From what I have read on the sweng-gamedev list, the issues seem to be:
- it was a custom lisp built using Franz's ACL (it was targetted at a
console platform, PS2 i think)
- the creator/maintainer left the company
- the target platform has changed (now PS/3) which would probably
require a complete rewrite of the language...something that was an
issue first time around as the game development was slowed by
concurrent language development
- the company has been bought (by Sony/SOE I believe) and I'm sure that
it would be a much tougher sell to the new, corporate management
- the developers loved the language and wished they could still use it
- they are using c++ because they have to and are looking for ways to
get as much of the power of lisp back as possible
- based upon the above, i'd predict that they (if there are remaining
personel who are familiar enough with the orginal system) end up
greenspuning heavily (either in native code or creating custom
scripting language on top of it) to try and retrieve that power.
Brad Might wrote:
> For those new to CL, these C++ efforts are the type of pain that makes
> us wonder
> why people continue to think it's so great.
I'm a n00b to CL, and I haven't used C++ for a long time, and even then,
I did almost no GUI stuff. Lately, I've been trying to write a
proof-of-concept program that has a GUI in it.
First I tried Lisp. What excited me was the idea of being able to extend
the business logic once the basic application had been written. I tried
Corman Lisp, which kept crashing. I think it was partly my fault, and
partly due to some Corman flakiness. I couldn't find a decent
alternative GUI for Lisp on Windows XP, so it was onto the next thing ...
I installed an old version of Visual C++ and generated a default GUI
app. I rapidly realised that there is basically sh*t everywhere. You
have to hook your stuff in all over the show. No doubt that this is not
helped by Microsoft's idea of a Windowing system.
Next on my list was Haskell; which I also know nothing about. It had
something called wxHaskell - which is a Haskell wrapping for wxWidgets .
It installed OK, and I liked the declarative way that the GUI is
defined. Monads gave me brain damage, and I decided that things would
just be plain easier if I could access some global state (yes, I know
state is supposed to be the root of all evil). Actually, I think have
just had a bit of insight into WTF monads are doing. I'm speculating
that it uses a Continuation Passing Style to achieve its effect.
Now I'm on to Lisp, part 2. I'm using CLISP, and noticed that a project
called wxCL exists. I gave it a bit of a spin, and find it to my liking.
wxCL doesn't have a declarative-style wrapper, but I'm thinking that
what I've got is good enough. I've also got plain-odbc working for
CLISP, so things are looking quite promising.
On Tue, 27 Sep 2005 17:37:18 +0100, Mark Carter <··@privacy.net> wrote:
> First I tried Lisp. What excited me was the idea of being able to
> extend the business logic once the basic application had been
> written. I tried Corman Lisp, which kept crashing. I think it was
> partly my fault, and partly due to some Corman flakiness. I couldn't
> find a decent alternative GUI for Lisp on Windows XP, so it was onto
> the next thing ...
You didn't try very hard, did you?
<http://www.lispworks.com/products/capi.html>
<http://www.franz.com/support/documentation/7.0/doc/cgide.htm>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Tue, 27 Sep 2005 17:37:18 +0100, Mark Carter <··@privacy.net> wrote:
>
>
>>First I tried Lisp. What excited me was the idea of being able to
>>extend the business logic once the basic application had been
>>written. I tried Corman Lisp, which kept crashing. I think it was
>>partly my fault, and partly due to some Corman flakiness. I couldn't
>>find a decent alternative GUI for Lisp on Windows XP, so it was onto
>>the next thing ...
>
> <http://www.lispworks.com/products/capi.html>
> <http://www.franz.com/support/documentation/7.0/doc/cgide.htm>
For now, I'm trying to produce something that our secretary can use. The
versions you suggested do not do application delivery as freebies, and I
can't imagine our secretary relishing the prospect of opening up lisp
projects.
I'm from Scotland you know, so I can't imagine my boss being willing to
fork out the cash required by the offerings you suggested. Personally, I
would have contemplated buying Corman myself, but I noticed quite a bit
of flakiness, and I was concerned about how well it would work with some
of the interesting libraries out there on the internet.
What people like me are really looking for is a good free (BSD, not GPL
or LGPL) lisp that works on Windows, and has a tonne of libraries. I am
sure this is an argument that has been hacked to death many times over
and over and over on this newsgroup. It's an argument that generates
more heat than light, with both parties ending up in the same position
as they started.
Mark Carter wrote:
> Edi Weitz wrote:
> > On Tue, 27 Sep 2005 17:37:18 +0100, Mark Carter <··@privacy.net> wrote:
> >
> >
> >>First I tried Lisp. What excited me was the idea of being able to
> >>extend the business logic once the basic application had been
> >>written. I tried Corman Lisp, which kept crashing. I think it was
> >>partly my fault, and partly due to some Corman flakiness. I couldn't
> >>find a decent alternative GUI for Lisp on Windows XP, so it was onto
> >>the next thing ...
> >
>
>
> > <http://www.lispworks.com/products/capi.html>
> > <http://www.franz.com/support/documentation/7.0/doc/cgide.htm>
>
>
> For now, I'm trying to produce something that our secretary can use. The
> versions you suggested do not do application delivery as freebies, and I
> can't imagine our secretary relishing the prospect of opening up lisp
> projects.
Perhaps you've heard of this new technology called "the Web" which lets
you deliver applications to people (even secretaries!) using programs
called "browsers" accessing a program called a "web server." Sarcasm
aside for now, that web server can very easily be based on a Common
Lisp implementation running whatever business logic you desire. Your
secretary has only to be comfortable with Internet Explorer to run your
app.
··············@hotmail.com wrote:
> Mark Carter wrote:
>
>>Edi Weitz wrote:
>>
>>>On Tue, 27 Sep 2005 17:37:18 +0100, Mark Carter <··@privacy.net> wrote:
>>>
>>>
>>>
>>>>First I tried Lisp. What excited me was the idea of being able to
>>>>extend the business logic once the basic application had been
>>>>written. I tried Corman Lisp, which kept crashing. I think it was
>>>>partly my fault, and partly due to some Corman flakiness. I couldn't
>>>>find a decent alternative GUI for Lisp on Windows XP, so it was onto
>>>>the next thing ...
>>>
>>
>>> <http://www.lispworks.com/products/capi.html>
>>> <http://www.franz.com/support/documentation/7.0/doc/cgide.htm>
>>
>>
>>For now, I'm trying to produce something that our secretary can use. The
>>versions you suggested do not do application delivery as freebies, and I
>>can't imagine our secretary relishing the prospect of opening up lisp
>>projects.
>
>
> Perhaps you've heard of this new technology called "the Web" which lets
> you deliver applications to people (even secretaries!) using programs
> called "browsers" accessing a program called a "web server." Sarcasm
> aside for now, that web server can very easily be based on a Common
> Lisp implementation running whatever business logic you desire. Your
> secretary has only to be comfortable with Internet Explorer to run your
> app.
>
That would negate the advantage of the original reason behind Edi
suggesting Lispworks or Franzs in the first place (i.e. for GUIs).
Besides, I had mentioned in my original post that I managed to get wxCL
working in CLISP on Windows, and much approved of it. And yes, as it
happens, I have heard of this new technology which you call "the Web",
and actually did consider it as a form of delivery. I decided against it
because a bog-standard application would be preferrable.
Whilst I'm experimenting, I'm also thinking ahead about how Lisp might
be used for our commercial development work. Well, there are of course
pros and cons of webapps versus normal apps, but I'm thinking that a
normal app is the most appropriate solution in my case. I'm thinking
that if I really like wxCL, then I might try to see how well it sits
with Corman Lisp; and I'll be more convinced that Lisp will actually be
something worth greater consideration.