canonical OpenGL binding for Scheme
Brandon J. Van Every
available that have one, but I'm interested in Bigloo Scheme. The
OpenGL support in bigloo-lib really isn't there, i.e. it doesn't build.
The author has suggested that I shouldn't rely on it, and only to take
it as an example of how one might create a binding.
Even for those Schemes that have an OpenGL binding, I believe none of
them are current. This is an ongoing industrialization problem that I
wonder, as a game developer, if I should try to solve. I don't exactly
relish the prospect of working on an OpenGL binding and then watching it
decay. I don't like the idea of being stuck with 1 Scheme
implementation. I don't like the idea of me being the only guy
interested in keeping up with this sort of thing. So I'm wondering if
there's some kind of community process by which OpenGL could be put on a
"permanently good" footing in the Scheme world. Would it take a SRFI?
Is a SRFI an appropriate vehicle for such a thing?
I looked at the forums on www.opengl.org and tried to deduce if there
was an appropriate one to talk about OpenGL language bindings. Really
didn't see one with any traffic, so I thought I'd try here. For those
who have gone down this sort of road for other languages, I'd appreciate
your input on what pitfalls to watch out for. What causes these
projects to survive or decay over the long haul?
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
bunn...@gmail.com
>
> I looked at the forums on www.opengl.org and tried to deduce if there
> was an appropriate one to talk about OpenGL language bindings. Really
> didn't see one with any traffic, so I thought I'd try here. For those
> who have gone down this sort of road for other languages, I'd appreciate
> your input on what pitfalls to watch out for. What causes these
> projects to survive or decay over the long haul?
Since OpenGL is a relatively clean API, it should be trivial to wrap.
Someone recently generated bindings for Gambit using an interesting
approach: by parsing and rewriting the debug-output of Chicken's FFI
parser.
(Of course Chicken has OpenGL bindings, but I assume you're not
interested
in those)
cheers,
felix
Frank Buss
> Even for those Schemes that have an OpenGL binding, I believe none of
> them are current. This is an ongoing industrialization problem that I
> wonder, as a game developer, if I should try to solve. I don't exactly
> relish the prospect of working on an OpenGL binding and then watching it
> decay.
you don't need the latest API, only a version which supports the ARB
interface and your program can always query and use the latest features at
runtime.
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Brandon J. Van Every
>Brandon J. Van Every wrote:
>
>
>
>>Even for those Schemes that have an OpenGL binding, I believe none of
>>them are current. This is an ongoing industrialization problem that I
>>wonder, as a game developer, if I should try to solve. I don't exactly
>>relish the prospect of working on an OpenGL binding and then watching it
>>decay.
>>
>>
>
>you don't need the latest API, only a version which supports the ARB
>interface and your program can always query and use the latest features at
>runtime.
>
>
>
I am not interested in this approach to OpenGL. My attitude is to do
the exact opposite: use the Intel SDK to eliminate the need for such
futzing.
Markku S
> I am not interested in this approach to OpenGL. My attitude is to do
> the exact opposite: use the Intel SDK to eliminate the need for such
> futzing.
What's the Intel SDK and how is it different regarding OpenGL?
Frank Buss
> I am not interested in this approach to OpenGL. My attitude is to do
> the exact opposite: use the Intel SDK to eliminate the need for such
> futzing.
I assume you mean this:
http://oss.sgi.com/projects/ogl-sample/sdk.html
I have used it in C++ for testing the new Shader extension and it
simplifies the extension handling, but you still have to query the
extensions, because the Intel SDK is only a wrapper for the installed
OpenGL library on the system. For example if there are no OpenGL 2.0 shader
support from the installed OpenGL graphic card driver, you can't call the
functions because they don't exists. But would be nice to automaticly
generate the FFI interface for Scheme from the Intel SDK, like it has been
done with AH2CL for Common Lisp and the basic OpenGL library (
http://hocwp.free.fr/ah2cl/ ).
But if you don't want to implement games like Doom 3, the basic OpenGL
support, without extensions, is sufficient for a lot of applications.
Markku S
> But if you don't want to implement games like Doom 3, the basic OpenGL
> support, without extensions, is sufficient for a lot of applications.
If you require OpenGL core version 2.0, shouldn't that be quite enough for
Doom 3 too?
alex goldman
I'm just curious, how do you all plan to live with GC inside your Doom 3's?
MJ Ray
> [...] So I'm wondering if
> "permanently good" footing in the Scheme world. Would it take a SRFI?
> Is a SRFI an appropriate vehicle for such a thing?
That sounds like an excellent idea to me, especially if you can
define a general translation rule for the low-level OpenGL
instructions that will make updates to the SRFI "obvious".
I don't know much OpenGL, though.
--
MJR/slef
http://mjr.towers.org.uk/
Markku S
>> If you require OpenGL core version 2.0, shouldn't that be quite enough for
>> Doom 3 too?
>
> I'm just curious, how do you all plan to live with GC inside your Doom 3's?
What is a GC, and what is "my Doom 3"? Are you sure you wanted to ask me
something? Or did I just miss the point? :)
fungus
>
>> you don't need the latest API, only a version which supports the ARB
>> interface and your program can always query and use the latest
>> features at
>> runtime.
>>
> I am not interested in this approach to OpenGL.
>
Why not? It's the approach everybody else uses.
The OpenGL we all use on Windows is the same one
Microsoft shipped back in 1995.
--
<\___/>
/ O O \
\_____/ FTB. For email, remove my socks.
Matthias Buelow
> I'm just curious, how do you all plan to live with GC inside your Doom 3's?
That should work pretty well, since doom3 is a rather slow game. You
could probably prolong GC time until when the user pops up the PDA or
level changes, etc. Halflife2 for example loads stuff so often (even
annoyingly so) that doing GC during these loads would probably be
completely sufficient.
It would be a lot more problematic in tournament-style Quake or Cstrike
settings, which are basically realtime constrained, and where there are
no situations for hiding small pauses.
mkb.
Brandon J. Van Every
>But if you don't want to implement games like Doom 3, the basic OpenGL
>support, without extensions, is sufficient for a lot of applications.
>
>
Which, unfortunately, may be why modern OpenGL support in the Scheme
universe is so bad. No game developers.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
T-shirt that landed someone a job: "I'm not an asshole,
I'm a Shaper!" http://www.teams.org.uk/shaper.htm
Brandon J. Van Every
GC = Garbage Collection. "my Doom 3" probably means any high
performance game that someone might have had in mind to implement. My
philosophy on that is to cross that bridge when I come to it. First
off, there is no uniform GC behavior in the Scheme universe. Every
implementation is different, and some implementations are capable of
multiple behaviors. Second off, it is not clear that GC is a
catastrophic loss. Based on all the conflicting reports I've heard, it
just seems like an issue that performance jocks wring their hands about
a whole bunch. I suspect the wringing is quite disproportionate to the
actual problem.
Anyways, I would dearly appreciate it if this thread would drift back to
subject. Unfortunately, usually when I ask about / propose X, and
everyone starts talking about Y, that means people aren't terribly
interested in X. The one question I would like tangibly answered is
whether a SRFI is an appropriate vehcile for an OpenGL binding. I'm
inclined to guess that it isn't, as OpenGL is "not a property of
Scheme," but I could be mistaken.
Does anyone know if Draft SRFI 50, "Mixing Scheme and C," has any legs?
Are many Schemes implementing it?
http://srfi.schemers.org/srfi-50/srfi-50.html
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> Frank Buss wrote:
>>
>>> you don't need the latest API, only a version which supports the ARB
>>> interface and your program can always query and use the latest
>>> features at
>>> runtime.
>>>
>> I am not interested in this approach to OpenGL.
>
>
> Why not? It's the approach everybody else uses.
> The OpenGL we all use on Windows is the same one
> Microsoft shipped back in 1995.
>
>
Which is "wrong." Where "wrong" == bletcherous, tedious, inelegant.
There's a reason that people have created these static bindings to fix
what Microsoft has broken, so it is not true that 'everybody' else uses
the find-your-function-pointers approach.
Frank Buss
> Which is "wrong." Where "wrong" == bletcherous, tedious, inelegant.
> There's a reason that people have created these static bindings to fix
> what Microsoft has broken, so it is not true that 'everybody' else uses
> the find-your-function-pointers approach.
if you want to release your programs on Microsoft Windows, then you have to
use the find-your-function-pointers approach (but it might be simplified
with the Intel SDK). I don't know any library with available static
bindings of all functions, regardless which graphics driver is installed.
People have different graphics cards and today you simply can't use for
example pixel shaders on all computers.
And a SRFI for OpenGL is not useful. A SRFI for mixing C and Scheme is
sufficient for using all kinds of C libraries.
fungus
>
>> The OpenGL we all use on Windows is the same one
>> Microsoft shipped back in 1995.
>>
> Which is "wrong." Where "wrong" == bletcherous, tedious, inelegant.
> There's a reason that people have created these static bindings to fix
> what Microsoft has broken, so it is not true that 'everybody' else uses
> the find-your-function-pointers approach.
>
At some point you have to check whether
or not an extension exists. Whether you
check at the "find-your-function-pointer"
level or at some other level makes little
difference, the code still has to be there.
The only people who can avoid this are
the people who are in a position to
specify the graphics card the program
is going to run on.
alex goldman
> Based on all the conflicting reports I've heard, it
> just seems like an issue that performance jocks wring their hands about
> a whole bunch. I suspect the wringing is quite disproportionate to the
> actual problem.
It's more about jitter, rather than performance. Imagine playing Halo 2,
where every 3 seconds there is a 0.25 second pause. You'll probably go nuts
five minutes into the game, red eyes, nervous tics and everything.
I'm not saying Scheme/Lisp/FP should not be used for this kind of problem,
just not in a way you seem to invision it (Plain Bigloo calling OpenGL
through FFI)
BTW, check out PreScheme - it has no GC or run-time type tags. It does
partial evaluation, and generates efficient C. Because of the partial
evaluation, I suspect it might be many times faster than regular C for some
things I want. Now if I could just get Hello World to compile (see other
thread). No docs though, just a research paper.
(My interest in PreScheme has nothing to do with Game Programming. I think
games are best enjoyed by playing them, not by writing them)
Dave Eberly
message news:8xIle.8849$uR4....@newsread2.news.atl.earthlink.net...
> Which is "wrong." Where "wrong" == bletcherous, tedious, inelegant.
> There's a reason that people have created these static bindings to fix
> what Microsoft has broken, so it is not true that 'everybody' else uses
> the find-your-function-pointers approach.
This is not a Microsoft-specific problem. Microsoft only provides
OpenGL 1.1 in its gl.h; that is, they #define GL_VERSION_1_1.
The current graphics drivers provide functionality for later version
of OpenGL. The only way to access them is by querying for the
function pointers. On Linux boxes, you have to query for extensions
also. On Mac OS X 10.3.9 (the last release before Tiger), only
OpenGL 1.4 is supported, yet the graphics card drivers support
later features in OpenGL 1.5. Once again you have to query for
the function pointers, although Apple does have some 'agl' extensions
that are available through agl.h (not gl.h).
You claim that not everyone uses the find-your-function-pointers
approach. What alternatives are you referring to?
You wrote originally:
> Even for those Schemes that have an OpenGL binding, I believe none of them
> are current. This is an ongoing industrialization problem that I wonder,
> as a game developer, if I should try to solve. I don't exactly relish the
> prospect of working on an OpenGL binding and then watching it decay. I
> don't like the idea of being stuck with 1 Scheme implementation. I don't
> like the idea of me being the only guy interested in keeping up with this
> sort of thing. So I'm wondering if there's some kind of community process
> by which OpenGL could be put on a "permanently good" footing in the Scheme
> world.
Translation:
1. Current OpenGL bindings for Scheme have been abandoned.
2. I need an OpenGL binding.
3. I do not want to spend the time writing one.
4. Will someone else write one and let me use it?
The web is littered with freely available software components.
Some of them are good quality. Some of them are bad quality.
Some of them are maintained for more than a month. Some
longer, but abandoned none the less. Most are abandoned
because the people involved found out that it is relatively easy
to slap a software project onto a web site, but it takes a *lot*
of effort to maintain that software. Not an attractive proposition
when you get no revenue in reward for your efforts.
So. Take the plunge. Write your own OpenGL binding for
Scheme. Make it good quality. If you build it, they will come.
Maintain it for years on end and they will continue to come.
And, finally, post it at your web site so that for the first time in
recorded history, there will actually *be* something meaningful
at your notoriously vacuous web sites.
--
Dave Eberly
http://www.geometrictools.com
Frank Buss
> And, finally, post it at your web site so that for the first time in
> recorded history, there will actually *be* something meaningful
> at your notoriously vacuous web sites.
seeing something useful on his webpage will occur only when Xmas and Easter
fall on the same day :-)
Brandon J. Van Every
>And a SRFI for OpenGL is not useful. A SRFI for mixing C and Scheme is
>sufficient for using all kinds of C libraries.
>
>
Show me that job actually getting done! Concentration upon one specific
need might be the more practical way to get people involved. Also I
doubt that binding OpenGL is as hard as binding C in general.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Brandon's Law (after Godwin's Law):
"As a Usenet discussion grows longer, the probability of
a person being called a troll approaches one RAPIDLY."
Brandon J. Van Every
>BTW, check out PreScheme - it has no GC or run-time type tags. It does
>partial evaluation, and generates efficient C. Because of the partial
>evaluation, I suspect it might be many times faster than regular C for some
>things I want. Now if I could just get Hello World to compile (see other
>thread). No docs though, just a research paper.
>
>
I'll pass. Honestly I find myself moving in the exact opposite
direction, towards whatever language offers the best quality of tools.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.
Brandon J. Van Every
>Translation:
>1. Current OpenGL bindings for Scheme have been abandoned.
>2. I need an OpenGL binding.
>
>
Yes, that's what I wrote...
>3. I do not want to spend the time writing one.
>4. Will someone else write one and let me use it?
>
>
I'm not interested in your bullshit. It's perfectly reasonable to
solicit people to come up with a more practical engineering endeavor.
But of course people have to actually care, and clearly, they don't.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
likes to download and play with programming toys
all day long, there's something wrong with you.
alex goldman
> alex goldman wrote:
>
>>BTW, check out PreScheme - it has no GC or run-time type tags. It does
>>partial evaluation, and generates efficient C. Because of the partial
>>evaluation, I suspect it might be many times faster than regular C for
>>some things I want. Now if I could just get Hello World to compile (see
>>other thread). No docs though, just a research paper.
>>
>>
> I'll pass. Honestly I find myself moving in the exact opposite
> direction, towards whatever language offers the best quality of tools.
Implementation or language? PreScheme is a Scheme [1]. As to tools, is a
compiler a tool? Is a partial evaluator a tool?
[1] In the sense that if it compiles and does not run out of space, it
should do what the scheme standard specifies.
Brandon J. Van Every
>seeing something useful on his webpage will occur only when Xmas and Easter
>fall on the same day :-)
>
>
Well I don't see how you're of any use to me either...
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
bunn...@gmail.com
It has no legs, and is more or less identical to Scheme48's FFI
implementation.
It is currently hanging in limbo, since it showed up various
deficiencies that
restricted its usefulness under different memory-management and Scheme-
implementation strategies.
(BTW, I don't know why this SRFI hasn't been withdrawn yet)
cheers,
felix
Brandon J. Van Every
>Brandon J. Van Every wrote:
>
>
>
>>I'll pass. Honestly I find myself moving in the exact opposite
>>direction, towards whatever language offers the best quality of tools.
>>
>>
>
>Implementation or language? PreScheme is a Scheme [1]. As to tools, is a
>compiler a tool? Is a partial evaluator a tool?
>
>
>
I'm starting to think in terms of Eclipse, the JVM, and programming
tools that work really well. MinGW toolchain is baloney. Cygwin works,
but not if you want to avoid the GPL. I never cared about Java or the
JVM before. I have realized, however, that it has some major
advantages: it's cross-platform, tons of money have been dumped into it,
and "it builds."
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
Frank Buss
> Also I
> doubt that binding OpenGL is as hard as binding C in general.
for full OpenGL support you need:
- calling C functions
- Scheme functions as function arguments, which are called from OpenGL
- creating and using typed arrays as function arguments
- void* (so casting typed arrays before passing it to OpenGL)
- setting function pointers for the extensions
Ok, you don't need structs, so it is easier than the full C support :-)
Thant Tessman
> Brandon J. Van Every wrote:
>
>
>>Also I
>>doubt that binding OpenGL is as hard as binding C in general.
>
>
> for full OpenGL support you need:
[...]
> - Scheme functions as function arguments, which are called from OpenGL
Why would you need this? GLUT uses this, but not OpenGL as far as I know.
[...]
-thant
--
We have now sunk to a depth at which restatement of the obvious is the
first duty of intelligent men. -- George Orwell (attributed)
Frank Buss
>> - Scheme functions as function arguments, which are called from OpenGL
>
> Why would you need this? GLUT uses this, but not OpenGL as far as I know.
yes, you are right, callbacks are not needed for OpenGL. I've used GLUT for
my tests in Common Lisp and I mixed this up with OpenGL.
Oliver Kreylos
> Thant Tessman wrote:
>>>- Scheme functions as function arguments, which are called from OpenGL
>>Why would you need this? GLUT uses this, but not OpenGL as far as I know.
> yes, you are right, callbacks are not needed for OpenGL. I've used GLUT for
> my tests in Common Lisp and I mixed this up with OpenGL.
It's right, there are no callbacks in core OpenGL. There are, however,
callbacks in GLU (which is lower level than a window system wrapper like
glut) - the GLU polygon tessellation routines need a callback to do
their job right. Check gluTessCallback.
It's of course completely up to taste whether a language X binding for
OpenGL should contain GLU.
Oliver
--
Email: kre...@cs.ucdavis.edu
WWW: http://graphics.cs.ucdavis.edu/~okreylos/ResDev
fungus
>
> It's of course completely up to taste whether a language X binding for
> OpenGL should contain GLU.
>
Some of the functions are trivial one liners - gluOrtho2D()
Others are much harder to code, gluBuild2DMipmaps()
is very commonly used, trimmed NURBS is even harder
but not many people use it.
Matthias Buelow
> I'm starting to think in terms of Eclipse, the JVM, and programming
> tools that work really well. MinGW toolchain is baloney. Cygwin works,
> but not if you want to avoid the GPL. I never cared about Java or the
> JVM before. I have realized, however, that it has some major
> advantages: it's cross-platform, tons of money have been dumped into it,
> and "it builds."
Plus, with Harmony by apache.org, the "portability" thing of Java might
for once become more substantial than pure marketing hype.
Although that might still take a while. I wish them good luck.
mkb.
Ray Dillinger
> Anyways, I would dearly appreciate it if this thread would drift back to
> subject. Unfortunately, usually when I ask about / propose X, and
> everyone starts talking about Y, that means people aren't terribly
> interested in X. The one question I would like tangibly answered is
> whether a SRFI is an appropriate vehcile for an OpenGL binding. I'm
> inclined to guess that it isn't, as OpenGL is "not a property of
> Scheme," but I could be mistaken.
Actually, I think it would be a perfect venue for someone to specify
the form of an OpenGL binding. You'd have to provide a reference
implementation, but there are a couple; I think the main issue would
be documenting them adequately and getting the permission of their
authors to use them as a SRFI reference implementation. Or you could
roll your own.
A graphics library ought to be no less a property of scheme than a
strings library, IMO. Right now there's not really what I'd consider
an "appropriate" graphics library for a functional language -- OpenGL
for example holds and relies on a lot of state information -- but
first, you can do imperative programming in Scheme if you want to, and
second, I think that given openGL bindings someone could certainly
build one. And that -- "functional interface to Graphics library"
could be an additional SRFI that uses the "bindings for OpenGL"
SRFI in its reference implementation.
Bear
Ray Dillinger
> And a SRFI for OpenGL is not useful. A SRFI for mixing C and Scheme is
> sufficient for using all kinds of C libraries.
I think that "mixing scheme and C" proposals are of limited
usefulness. The proposals that I've seen have a nasty tendency
to be unimplementable if a scheme implementor has made unusual
design choices, and several different kinds of fundamental design
choices are totally appropriate for a language whose stack
and function invocation semantics are so very different from C's.
So while it may not even be possible for a given implementor to
support any particular kind of generalized C-to-Scheme interface,
support for the functions of an individual library may be relatively
easy.
Another thing is that a SRFI for OpenGL bindings *is* useful. If
I want to create a graphical application, I'm going to be looking
for graphics functionality FIRST, and be annoyed if I have to
"roll my own" by dancing some klugey multiple-language interface
dance that (A)makes my build process more complicated, (B)raises
the bar for maintainers who now have to know more than one language,
(C), exposes my code to yet one more source of possible obsolescence
or breakage, and (D)can't be supported across very many schemes.
Bear
Ray Dillinger
> Brandon J. Van Every wrote:
>
>
>>Based on all the conflicting reports I've heard, it
>>just seems like an issue that performance jocks wring their hands about
>>a whole bunch. I suspect the wringing is quite disproportionate to the
>>actual problem.
>
>
> It's more about jitter, rather than performance. Imagine playing Halo 2,
> where every 3 seconds there is a 0.25 second pause. You'll probably go nuts
> five minutes into the game, red eyes, nervous tics and everything.
I certainly haven't noticed pauses in Jak & Daxter; I think they're
using a much finer-grained collector. And I've written a collector
myself that amortizes collection effort across every allocation, and
"throttles" itself smoothly so that it doesn't waste effort when
there's nothing to collect. It wasn't even hard.
So, I don't think this is a "real" problem except for those who are
using some kind of stop© collector.
Bear
qo...@purdue.edu
Back in the late 1990's, Richard Mann used FFIGEN to parse the header
files for Xlib and OpenGL. He then automatically created an
implementation-neutral S-expression form of FFI bindings for Xlib and
OpenGL. He also created small C functions that allocate and free all of
the specific data structures needed for these APIs and get and set all
of the slots of those data structures. He automatically created FFI
bindings for these allocate, free, get, and set functions as well. He
then created simple translators that tooks these implementation-neutral
FFI bindings and automatically generated implementation-specific FFI
bindings for several Common Lisp and Scheme implementations, including
GCL, Allegro, Scheme->C, Gambit C, and Stalin.
He may have created other implementation specific bindings as well. In
any case, it is fairly trivial to do so. What is important about this
is that the same API is exposed in all of these implementations.
I'm sure that Richard will give you these bindings if you contact him.
And the Stalin bindings for Xlib and OpenGL have been included with
Stalin for at least the past 5 or 6 years.
Ray Dillinger
>
> It's perfectly reasonable to
> solicit people to come up with a more practical engineering endeavor.
> But of course people have to actually care, and clearly, they don't.
In the same sense it's reasonable to ask strangers for money
on the street.... If you want people to care enough about your
needs to contribute code, you need to also make some kind of
contribution. Your frequently-expressed feelings about open
licenses make it clear that you never will - so anything
someone contributes, specifically to you, will be for no gain
to any community, other than just a means for you to make
money. Why should someone do that if you're not cutting him
in for a share?
Now, it's possible that someone will undertake to do what you
want for reasons that have nothing to do with you; they may
care that much about doing graphics in scheme, they may care
that much about making a commercial implementation (which
you'd have to pay for), or maybe they've got a buddy who's
working on bindings for the sound system and plan to exchange
code to make cool games. That would be "getting lucky" as
far as you're concerned. If it happens, it's likely to
have an open source license, like existing OpenGL bindings
for Scheme, but it may be one you can use without compromising
your standards of commerce.
Standing around with your hat out, offering to make no reciprocal
contribution, isn't going to make it any more likely.
Bear
MJ Ray
> I'm sure that Richard will give you these bindings if you contact him.
> And the Stalin bindings for Xlib and OpenGL have been included with
> Stalin for at least the past 5 or 6 years.
It sounds like there's something stopping these bindings becoming
popular. Are they published for general use, or is it "on request"
each and every time? Have you asked for general release, to save
your poor fingers?
--
MJR/slef
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> It's perfectly reasonable to solicit people to come up with a more
>> practical engineering endeavor. But of course people have to
>> actually care, and clearly, they don't.
>
>
> In the same sense it's reasonable to ask strangers for money
> on the street....
Ray, I'm not interested in your bullshit, or anyone else's bullshit. I
don't know about you, but I'm not paid to do *anything* in Scheme. Nor
am I paid to do anything in computers, which leaves me with no cash
reserve and problems of staying one step ahead of my landlord. I'm not
your full service "I'm gonna whip up an OpenGL SRFI with butter and
garlic" guy. You want that level of service, you give me a job. Then
you'll see the goods in a hurry and no questions asked. But even then,
I would have asked whether a SRFI is an appropriate vehicle for
delivering an OpenGL spec, because I didn't know. I don't know why
certain people feel compelled to be an asshole when faced with such
questions.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Brandon J. Van Every
>I'm sure that Richard will give you these bindings if you contact him.
>And the Stalin bindings for Xlib and OpenGL have been included with
>Stalin for at least the past 5 or 6 years.
>
>
Thanks for the tip (again). I will look at these bindings, as they
sound like the best working example proximate to what I want. What I
want, are nearly automatically generated bindings. As an initial
strategy, I will dump some energy into Cigloo rather than anything
vendor neutral. My approach would be to generate a binding
automatically within a Bigloo environment, but specify it in such a way
that one could automatically or manually produce the same binding in a
reasonable Scheme implementation. I would use it for awhile, make sure
it's field tested, and 'someday' worry about a SRFI for it. The reality
is, since nobody's even vaguely interested in helping on such a thing,
it'll get done when it is profitable and emminently practical for me to
do so.
To my cat-callers: don't hold your breath. I suppose you'll be exerting
your "right to complain" about my product offerings and public image for
another 2 years yet. Well, at least OpenGL 2.0 will be common by then.
Brandon J. Van Every
Stalin itself is not popular. For all I know it may be excellent,
technically speaking. But from a visibility standpoint, it is the worst
open source project I've seen. At least, among those that actually have
significant substance to them. For instance, not even a primitive
webpage about the project, just a FTP site. No mailing list. No
releases in a long time, so no apparent 'pulse'. So, I don't know why
anyone would expect a Stalin OpenGL binding to be popular. Not a finger
is lifted to make Stalin popular. You have to discover it in a list of
Scheme implementations somewhere and then really really want to go deal
with it. It does not come to you in any way at all, except for Jeffrey
himself mentioning it (which does count for something, BTW).
Bigloo isnt that popular either, and has few 3rd party libraries that
actually work. But, there's a mailing list, questions can get answered
by multiple people in timely fashion, there's a visible process for bug
reports and patch contributions, etc. These are the reasons for me to
prefer Bigloo over Stalin, as they are both performance oriented projects.
I'm thankful, however, for Jeffrey's mention of the OpenGL bindings.
They may prove to be a good design example for my own effort. Also,
aside from the bigloo-lib author, I've not heard anyone else around here
pipe up about their own OpenGL bindings. Sure, several exist, but it's
nice to have a testimonial that someone actually did a good job that's
worth studying or borrowing from.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"Troll" - (n.) Anything you don't like.
Usage: "He's just a troll."
Christopher Browne
> Ray Dillinger wrote:
>> Brandon J. Van Every wrote:
>>> It's perfectly reasonable to solicit people to come up with a more
>>> practical engineering endeavor. But of course people have to
>>> actually care, and clearly, they don't.
>>
>> In the same sense it's reasonable to ask strangers for money on the
>> street....
>
> Ray, I'm not interested in your bullshit, or anyone else's bullshit.
> I don't know about you, but I'm not paid to do *anything* in Scheme.
> Nor am I paid to do anything in computers, which leaves me with no
> cash reserve and problems of staying one step ahead of my landlord.
> I'm not your full service "I'm gonna whip up an OpenGL SRFI with
> butter and garlic" guy. You want that level of service, you give me
> a job. Then you'll see the goods in a hurry and no questions asked.
> But even then, I would have asked whether a SRFI is an appropriate
> vehicle for delivering an OpenGL spec, because I didn't know. I
> don't know why certain people feel compelled to be an asshole when
> faced with such questions.
Well, then, I guess you can't afford to try to migrate to Scheme,
then.
If you cannot afford to contribute anything, then you can expect
nothing better than to be treated as a beggar.
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/slony.html
Rules of the Evil Overlord #159. "If I burst into rebel headquarters
and find it deserted except for an odd, blinking device, I will not
walk up and investigate; I'll run like hell."
<http://www.eviloverlord.com/>
Brandon J. Van Every
>After a long battle with technology, "Brandon J. Van Every" <mylastname...@mycompanyname.com>, an earthling, wrote:
>
>
>>Ray Dillinger wrote:
>>
>>
>>>Brandon J. Van Every wrote:
>>>
>>>
>>>>It's perfectly reasonable to solicit people to come up with a more
>>>>practical engineering endeavor. But of course people have to
>>>>actually care, and clearly, they don't.
>>>>
>>>>
>>>In the same sense it's reasonable to ask strangers for money on the
>>>street....
>>>
>>>
>>Ray, I'm not interested in your bullshit, or anyone else's bullshit.
>>I don't know about you, but I'm not paid to do *anything* in Scheme.
>>Nor am I paid to do anything in computers, which leaves me with no
>>cash reserve and problems of staying one step ahead of my landlord.
>>I'm not your full service "I'm gonna whip up an OpenGL SRFI with
>>butter and garlic" guy. You want that level of service, you give me
>>a job. Then you'll see the goods in a hurry and no questions asked.
>>But even then, I would have asked whether a SRFI is an appropriate
>>vehicle for delivering an OpenGL spec, because I didn't know. I
>>don't know why certain people feel compelled to be an asshole when
>>faced with such questions.
>>
>>
>
>Well, then, I guess you can't afford to try to migrate to Scheme,
>then.
>
>
WTF is this stuff about 'migrating' to Scheme? I'm not paid to do any
programming at all. I'd have the same issue with any unimplemented
library in any language. There's always an unimplemented library. If
there was a perfect language + library + tools system for my problem
domains, I'd be using them. There isn't.
>If you cannot afford to contribute anything, then you can expect
>nothing better than to be treated as a beggar.
>
>
I think you've got some kind of messed up open source hippie or else
ivory tower notion of what people are supposed to be doing with their
copious development time. Do you have any idea how long it can take
just to get some of these tools basically working on Windows? Where do
you get off thinking that anyone who isn't contributing buckets of code
to 'the common good', who asks a straightforward question in a public
forum about best practices for implementing standards, is somehow a
beggar? You paid anyone's way in the world lately?
From a productivity standpoint, all tools I've used in the Scheme
universe to date are a joke. Granted, I certainly haven't used all
Scheme implementations, and will never be doing so. But it is clear
that the learning curves are long, and you're really better off in a
Unix rather than a Windows universe. I have given up all pretense of
ever trying to sell anyone on Scheme as a business model. It is an
irrelevant joke. It only becomes relevant when an individual takes the
many months of lumps and becomes a guru. Sadly that's the path I'm on.
I ain't no guru yet, and I'm getting tired of you gurus who think it's
trivial for everyone and anyone to become a guru. This ain't the real
world, and there's a reason so few people use Scheme.
Open source as a business model is also pretty much a joke. The only
places where it works well are really big projects, like Eclipse for
instance. You get a whole pile of corporates backing something, who
understand the necessity of community building and marketing, and dump
real money into it, then yes you get some things out of the deal that
companies can rely on. This techie guru macho stuff ain't it, it
doesn't count at all. You can wave your tactical machismo around and
call people 'beggar' all you want. Strategically, it counts for
nothing. Scheme is exactly where it is today because it's mostly the
province of macho tacticians.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
weeds1...@hotmail.com
Brandon:
What is your conclusions up to know? As I gather you evaluated a lot of
programming languages (Scheme, Common Lisp, Python, OCaml, Haskell?,
Java?, etc?) and whether they will fit into any business models.
The problem actually turns out: for some people the tools which have
been evaluated by you just work for them and their problems. And they
are happy with it.
I mean what is your conclusion for now: will you go on evaluating
business models and its relevance to programming languages or will you
start using C++ eventually?
Why not start right now your long term game programming project in C++?
I mean the hurdles you will encounter every day in non mainstream
programming languages will not go away any time soon.
Schneewittchen
Thant Tessman
> Why not start right now your long term game programming project in C++?
Brandon J. Van Every has no intention of doing any actual work. He is
trying to take advantage of other people's ideological pride in their
chosen skillset and/or software business model and/or community spirit.
The goal seems to be to goad them into defend their ideology by building
him what he wants. He is best ignored.
-thant
Brandon J. Van Every
>Brandon J. Van Every wrote:
>
>
>
>>Open source as a business model is also pretty much a joke. The only
>>places where it works well are really big projects, like Eclipse for
>>instance. You get a whole pile of corporates backing something, who
>>understand the necessity of community building and marketing, and dump
>>real money into it, then yes you get some things out of the deal that
>>companies can rely on. This techie guru macho stuff ain't it, it
>>doesn't count at all. You can wave your tactical machismo around and
>>call people 'beggar' all you want. Strategically, it counts for
>>nothing. Scheme is exactly where it is today because it's mostly the
>>province of macho tacticians.
>>
>>
>
>Brandon:
>
>What is your conclusions up to know? As I gather you evaluated a lot of
>programming languages (Scheme, Common Lisp, Python, OCaml, Haskell?,
>Java?, etc?) and whether they will fit into any business models.
>
>The problem actually turns out: for some people the tools which have
>been evaluated by you just work for them and their problems. And they
>are happy with it.
>
>I mean what is your conclusion for now: will you go on evaluating
>business models and its relevance to programming languages
>
I've decided what kids of business models 'count', and I've identified
their overlap with open source. Projects like Eclipse, and companies
like www.jboss.com, count. Techies playing at macho altruistic
technocracy do *not* count. There really isn't much left to evaluate
anymore. I know what viable business models look like, having suffered
the lumps of those that don't work. Benevolent Dictators For Life don't
work. Academic research projects don't work. In the end it's really
pretty simple. You could pretty much figure it out by the slickness of
a project's webpage. It stands for a whole pile of other cultural issues.
Really the only question is whether these business-relevant open source
projects overlap with my own game problems. Unfortuantely, they don't
seem to. The vast majority of relevant game stuff is commercial,
proprietary, and based on regressive technologies.
>or will you start using C++ eventually?
>
>
I doubt I will touch C++ even for money. But never say never. I am far
more likely to start writing my own language. But I know I haven't
learned enough about compilers and metaprogramming yet to undertake such
an effort. My language would care about my concerns, which are
currently being discussed in comp.theory and comp.arch. Really this is
the extreme of the guru business model. If you're going to turn into a
guru, why do anything that anyone else does?
>Why not start right now your long term game programming project in C++?
>
>
Because right now I'm supposed to be out gathering signatures. And what
do you think an OpenGL binding for Bigloo Scheme is supposed to be,
chopped liver? It's not for funzies, it's a critical path component.
Although of course, I don't have to bind the whole thing to get
started. Nor was that my plan anyways (lacking community interest).
Anyways, I'm sticking to Bigloo Scheme for now, so that's why this has
to get done.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.
Brandon J. Van Every
> weeds1...@hotmail.com wrote to Brandon J. Van Every:
>
>> Why not start right now your long term game programming project in C++?
>
>
> Brandon J. Van Every has no intention of doing any actual work.
You have no cognizance of what 'actual work' is. For instance, getting
a working MinGW build system going on Windows is 40 hours of 'actual
work'. Downloading alphas of Bigloo almost every day and building them
is 'actual work'. You are probably in some kind of stable programming
environment where you are insulated from the rough edges of your tools.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie
Pascal Costanza
> I've decided what kids of business models 'count', and I've identified
> their overlap with open source. Projects like Eclipse, and companies
> like www.jboss.com, count. Techies playing at macho altruistic
> technocracy do *not* count. There really isn't much left to evaluate
> anymore. I know what viable business models look like, having suffered
> the lumps of those that don't work. Benevolent Dictators For Life don't
> work. Academic research projects don't work. In the end it's really
> pretty simple. You could pretty much figure it out by the slickness of
> a project's webpage. It stands for a whole pile of other cultural issues.
You mean, like this one: http://www.indiegamedesign.com/ ?
;)
Pascal
--
2nd European Lisp and Scheme Workshop
July 26 - Glasgow, Scotland - co-located with ECOOP 2005
http://lisp-ecoop05.bknr.net/
fredas...@yahoo.com
ONE OF HIS POSTS
1. He has never designed any game, nor contributed to the design of
any game, which has ever seen the light of day, despite referring
to himself as a "game designer." (In rebuttal, he pointed out his
"one complete game" from "1983" on the "Atari 800" which he showed
to his "8th grade math teacher.")
2. He has never been employed in the game industry, in any way,
shape, manner or form. Despite this, for some reason he managed
to get named as an Independent Games Festival judge; a curious
turn of events, since their stated intent is to appoint
"professionals in the game industry" (their quote, not his).
3. In fact, the only programming job he had listed on his resume was
for only "2 years" ending in "1998," working in C and assembly on
a graphics driver, as a "Sr. Software Engineer" -- a curious
title, since this was his first (and only) job in the software
industry. There is no evidence he has used C++, nor any other
language, professionally. (And the company in question is
defunct, anyway, so there is no way to verify his claim.)
4. The other jobs he has mentioned having after this one and only
items on his resume are: "yard maintenance work," "painting
apartments," "scrubbing floors," "sub minimum wage signature
gathering," and working for "$5/hour at a Vietnamese restaurant."
5. The only personal project he actually wrote code for and made
available in some manner was Free3d, a software 3D rendering
engine. Stating that its goals were to be "100% efficient, 100%
portable" and to release it in a "one year time frame," which he
started in "1993" and abandoned in "1996," admitting that it
"barely drew even a single polygon" and "did hardly anything in
the 3D department."
6. Almost every Internet community (Usenet newsgroup, mailing list,
etc.) he has ever introduced himself to has resulted in him
repeating the same pattern: asking leading questions, demanding
people do things his way, becoming hostile, annoying the other
participants, alienating them, and finally leaving in disgust.
7. Of the projects (open source and otherwise) whose communities he
has (briefly) joined, he has never contributed anything tangible
in terms of code or documentation.
8. The project he has intermittently claimed to be working on, Ocean
Mars, is vaporware -- and is one of his admitted "failures." He
allegedly sunk "nine months of full time 60 hours/week" and about
"$60K" into it with only a "spherical hexified icosahedron"
display to show for it (only allegedly, since it has never been
shown or demonstrated publicly).
9. Since his embarassing frustration with his Ocean Mars project, he
has decided that C and C++ aren't "worth anything as a resume
skill anymore," and embarked on a quest in 2003 to find a
high-level language that will suit his needs. After more than a
year, at least ten languages, and not having even "written a line
of code" in any of them, he still has yet to find a language that
will suit him.
10. Finally, despite vehemently insisting that he is not a troll, many
people quite understandingly have great difficulty distinguishing
his public behavior from that of a troll.
alex goldman
> 1. He has never designed any game, nor contributed to the design of
> any game, which has ever seen the light of day, despite referring
> to himself as a "game designer." (In rebuttal, he pointed out his
> "one complete game" from "1983" on the "Atari 800" which he showed
> to his "8th grade math teacher.")
I always figured him for an impatient 18 year old obsessed with games,
rather than for a 36 year old.
Brandon J. Van Every
> Brandon J. Van Every wrote:
>
>> I've decided what kids of business models 'count',
>
>
> You mean, like this one: http://www.indiegamedesign.com/ ?
>
> ;)
In 2 years of trying really really hard, I never found a business model
for what I'm doing. It doesn't stop me from continuing to try to do
what I'm doing, but since there's no business model in it, I don't
bother with the website spit 'n' polish. I just work on the problems
that actually matter, like getting Bigloo to run, and how to do OpenGL
bindings. When a website actually matters for my purposes, I'll cough
one out. There's a big difference between contributing to other
people's open source projects and stewarding your own. The latter is a
*huge* committment, not made lightly. At least 30% of your time will be
spent dealing with other people - answering mail, making websites,
documenting, etc. Apparently in the initial stages of Eclipse, that
cost was as high as 50%. I have no interest at all in bearing such
costs right now. That's all very "downstream" of solving my own problems.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Does your Myers Briggs Type Indicator determine how you
debate? http://www.personalitypage.com/
weeds1...@hotmail.com
Hello Brandon:
First let me say it is very legal from your side to check for
appropriateness of different programming languages and whether they
will fit.
However, what people would like to tell you is the following: it is
unavoidable that you start out right now if you want to succeed.
People often tell you you are the one who has to make first steps into
a foreign function interface. Once you have got a useable foreign
binding from your pet language you can move on.
My first steps into a foreign function binding from Bigloo to the high
quality plotting library DISLIN was very instable, though, it delivered
me some basic every day plotting routines for my needs. Later on I
decided to implement the whole lot of 570 DISLIN functions, though, I
was quite assure that I always will need only a tiny fraction of those.
And then over a period of 2 years I have implemented the aforementioned
570 foreign functions and the binding turned out being really stable
and I made it public. So, that was my small contribution to open
source.
I do not have any deep knowledge of C programming. However, making the
binding was some kind of doing it by rote.
I would really suggest to you that you start right off with your
project.
I haven't followed your Bigloo installation hurdles. Do you have at
least one running Bigloo on your Windows machine? I only mention it
because it is not always necessary to have the latesd Bigloo release
running.
Schneewittchen
PS: Why don't you install Linux on your system? I mean on Linux you
could test Bigloo and get comfortable with. Once you love Bigloo (or
not) you are in a better position for judging whether it is worthwhile
to invest time and effort in trying to get Bigloo running on Windows.
Jonathan Bartlett
>
>> But if you don't want to implement games like Doom 3, the basic OpenGL
>> support, without extensions, is sufficient for a lot of applications.
>>
>>
> Which, unfortunately, may be why modern OpenGL support in the Scheme
> universe is so bad. No game developers.
>
Have you tried Chicken's OpenGL?
Jon
Jonathan Bartlett
> Ok, you don't need structs, so it is easier than the full C support :-)
You're missing the point, though. For a general scheme->C binding you
have a lot of memory issues to work out, while OpenGL only has a
simplistic use of arrays.
Jon
Thant Tessman
Which is by design.
-thant
Brandon J. Van Every
>My first steps into a foreign function binding from Bigloo to the high
>quality plotting library DISLIN was very instable, though, it delivered
>me some basic every day plotting routines for my needs. Later on I
>decided to implement the whole lot of 570 DISLIN functions, though, I
>was quite assure that I always will need only a tiny fraction of those.
>And then over a period of 2 years I have implemented the aforementioned
>570 foreign functions and the binding turned out being really stable
>and I made it public. So, that was my small contribution to open
>source.
>
>
Thanks for your perspective on scope and timelines.
>I haven't followed your Bigloo installation hurdles. Do you have at
>least one running Bigloo on your Windows machine? I only mention it
>because it is not always necessary to have the latesd Bigloo release
>running.
>
>
As of last night I have 2. 2.6f builds fine, and the latest 2.7alpha
now builds fine. It is true I could just develop on 2.6f and forget
about 2.7a. But that's not in my mid-term self-interest, as I do want
2.7a to work well on Windows. It's not going to happen unless guys like
me submit the bug reports. Also, Manuel is very responsive about fixing
any bug report we deliver. With that kind of working relationship, who
am I to say no? Also, there are significant changes between 2.6f and
2.7a. For instance, bigloo-lib won't build anymore, and the author says
it would need a redesign.
>Schneewittchen
>PS: Why don't you install Linux on your system? I mean on Linux you
>could test Bigloo and get comfortable with.
>
Because Cygwin works fine. As I said, the mid-term goal is to make sure
Bigloo works well on Windows. I want to ship commercial games.
> Once you love Bigloo (or
>not) you are in a better position for judging whether it is worthwhile
>to invest time and effort in trying to get Bigloo running on Windows.
>
>
I have already invested 6 months in dancing around Bigloo. For games,
if Bigloo doesn't fulfil my needs, I will be writing my own language.
Why did it take 6 months? Partly because I went out of town to try to
make some money in LA on signature gathering, and I got skunked + my car
got totalled. Partly because that was a depressing experience. Partly
because despite Yannis Bres' good work, approaching Bigloo from a VC++
toolchain standpoint is the wrong way to go if you just want to get
things done right now. It took me quite a long time to break free of
the VC++ constraint; it really is a Windows guy crying "uncle! uncle!"
Also I've spent time trying to swallow Eclipse instead of the Bee IDE.
I very much dislike GNU Emacs, but that's what I'm stuck with for now.
Hmm, maybe I should try XEmacs again. Maybe it'll actually have
keystrokes displayed consistently on all the menus, unlike
some-are-some-aren't on GNU Emacs.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
Brandon J. Van Every
I haven't. Well, that's not literally true; I believe I downloaded an
egg about an L-System. It appeared to be one of the only open source
OpenGL examples available? I can't remember if it didn't build, or if I
just got distracted and didn't build it. At any rate I didn't reach
closure on Chicken's OpenGL capabilities, or the number of working
examples available out there. I may try again, but I'm too busy now.
For instance, I am yet again running an hour late on signature gathering
for the big festival that's supposed to make me the decent money to
allow me to keep up these tool futzing habits. Well, let's face it.
Even with a full night's sleep, I don't move fast in the morning.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
On Usenet, if you're not an open source hippie who
qo...@purdue.edu
years.
[...]
> I'm sure that Richard will give you these bindings if you contact
him.
> And the Stalin bindings for Xlib and OpenGL have been included
with
> Stalin for at least the past 5 or 6 years.
It sounds like there's something stopping these bindings becoming
popular.
Nothing other than general ignorance. A 30 second google search comes
up with:
http://tapir-server.uwaterloo.ca/~mannr/software.html
What a lot of people don't realize is that the free software community
has its roots in academic computer science. Academic computer
scientists have been freely sharing the fruits of their labor for at
least 50 years, predating the free software community by about 30-40
years. Its just that most of us don't have time to market our wares in
the new fangled way. We don't create web pages or blogs or CVS
repositories. We don't regularly release software updates. We don't
spend much effort because there is not much benefit to it. We simply
make our stuff available. Those who really want it and really care
about it will find it.
Are they published for general use, or is it "on request"
each and every time?
See above. They are published for general use. They were publicly
announced a long time ago.
Also, as I stated, the official public release of Stalin contains them
and has contained them for a long time. They are part of Debian and
have been part of Debian for a long time.
Have you asked for general release, to save
your poor fingers?
Why should *I* ask for a general release? You are welcome to do so if
you wish.
Shiro Kawai
> Frank Buss wrote:
>
> >But if you don't want to implement games like Doom 3, the basic OpenGL
> >support, without extensions, is sufficient for a lot of applications.
> >
> >
> Which, unfortunately, may be why modern OpenGL support in the Scheme
> universe is so bad. No game developers.
Well, we're working on OpenGL 2.0 support in Gauche-gl, albeit the
progress is slow since it's a spare-time project. But probably
you're not interested in an interpreted implementation. (We aim
at providing tools for the production pipeline rather than the engine.)
I just post this to tell that there are people in Scheme
community who do care and are working on it.
(Besides, if I were working in the commercial production, probably I
couldn't say much because of the NDA. So you can't assume there's
nothing in the world because you got no response here. I tell you
the best way to find these hidden Schemers in the industly. You
go ahead to write something nice and make it public; making it
open source or giving a talk at GDC or whatever. Probably you
won't get huge number, but you can lure some, I bet.)
--shiro
Brandon J. Van Every
>Well, we're working on OpenGL 2.0 support in Gauche-gl, albeit the
>progress is slow since it's a spare-time project. But probably
>you're not interested in an interpreted implementation. (We aim
>at providing tools for the production pipeline rather than the engine.)
>I just post this to tell that there are people in Scheme
>community who do care and are working on it.
>
>
Interpreted, no, nor would most C++-toting game developers be interested
in it either. But I'd be curious to know what you're doing that's
applicable to compiled Schemes.
>(Besides, if I were working in the commercial production, probably I
>couldn't say much because of the NDA. So you can't assume there's
>nothing in the world because you got no response here.
>
Sure... but I've seen no evidence of piles of Scheme going on in the
commercial game industry either. Actually, I've seen no evidence of
piles of Scheme going on in *any* industry. Even the Lisp industry is
modest.
> I tell you
>the best way to find these hidden Schemers in the industly. You
>go ahead to write something nice and make it public; making it
>open source or giving a talk at GDC or whatever. Probably you
>won't get huge number, but you can lure some, I bet.)
>
>
>
It's a worthy experiment, but it's far from evidence that people
currently care. I'm not convinced people even care about GOAL. 'Cuz,
after all, if Naughty Dog isn't releasing it for general use then why
should anyone else care? It just serves as a proof-of-concept, that you
can make money going the Lisp/Scheme route. The postmortems have also
said that GOAL is a two-edged sword, although I forget the details of why.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
"The pioneer is the one with the arrows in his back."
- anonymous entrepreneur
MJ Ray
> http://tapir-server.uwaterloo.ca/~mannr/software.html
>
> What a lot of people don't realize is that the free software community
> has its roots in academic computer science. Academic computer
> scientists have been freely sharing the fruits of their labor for at
> least 50 years, predating the free software community by about 30-40
> years.
Old-school academic computer scientists tend to only "freely
share" at the ideas level. Like the above URL, there's no
copyright notice in the files I checked, so it's just not useful
without getting a release every time. I have seen people hunted
down by academia's lawyers for using such code more than once.
Yet again, defeat is snatched from the jaws of victory.
> Its just that most of us don't have time to market our wares in
> the new fangled way. We don't create web pages or blogs or CVS
> repositories. We don't regularly release software updates. We don't
> spend much effort because there is not much benefit to it. We simply
> make our stuff available. Those who really want it and really care
> about it will find it.
I suggest that this is not about time and not really even
about incompetence at modern promotion as suggested above. It's
because some of you are primadonnas who think your time is more
important than that of anyone downstream, or who want to keep
the possibility of selling anything popular enough through a
"technology transfer company" and chasing down "copyright
infringers" using the published code. Some of you don't even
correctly attribute the author of newsgroup messages.
> Are they published for general use, or is it "on request"
> each and every time?
> See above. They are published for general use. They were publicly
> announced a long time ago.
See above about copyright. They are not for general use yet.
> Also, as I stated, the official public release of Stalin contains them
> and has contained them for a long time. They are part of Debian and
> have been part of Debian for a long time.
That's interesting and may give a useful general source for these
bindings, if they were integrated with permission.
> Have you asked for general release, to save
> your poor fingers?
> Why should *I* ask for a general release? You are welcome to do so if
> you wish.
You're the one who was grumbling.
Brandon J. Van Every
>I suggest that this is not about time and not really even
>about incompetence at modern promotion as suggested above. It's
>because some of you are primadonnas who think your time is more
>important than that of anyone downstream,
>
Why does one have to be a primadonna to feel that way? Interfacing to
other people and doing things for their needs is *work*. There's a
spectrum of who cares about who's work. If someone is very far towards
"I mostly/only care about my own work," I don't have a problem with
that. I just judge the merits of the open source project accordingly.
That is, such projects are usually useless, and the rare ones that
aren't are no better than a code mine. Projects that come with teams of
responsive people are way more valuable than code mines.
I just don't hold with this attitude of "I'm supposed to be doing things
for other people" that so many open source developers seem to have. I
only believe in open source to the extent that it's a practical business
model. I think it's practical to submit bug reports to a large project,
like I do with Bigloo Scheme. I think it makes sense to publish
solutions to boring "gruntwork" problems under MIT/BSD licenses, things
that you had to do anyways, so that boring problems go away and people
can concentrate on their own value-add problems. I don't believe in
publishing everything, nor in letting other people's problems drive your
development. If other people want to use lots of your time to solve
their problems (where "lots" means weeks of design and development, not
chit-chat on newsgroups), they can pay you or go into business with
you. Actually, in the latter case, you have to pick wisely as not
everyone's on your wavelength about what needs to get done. I know a
fantastic sculptor / animator, but we just can't seem to agree on duties
and deliverables, so I went back to worrying about my own problems and
not his.
>> Have you asked for general release, to save
>> your poor fingers?
>>Why should *I* ask for a general release? You are welcome to do so if
>>you wish.
>>
>>
>
>You're the one who was grumbling.
>
>
Not about the licensing of the OpenGL bindings.
--
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
Matthias Buelow
> Sure... but I've seen no evidence of piles of Scheme going on in the
> commercial game industry either. Actually, I've seen no evidence of
> piles of Scheme going on in *any* industry. Even the Lisp industry is
> modest.
Many programming languages are not primarily designed for consumption by
the industry.
mkb.