Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

Alternate 3D (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: Why Games Die
Next thread: Project Idea: Rhythm Games


[ANN] Preview of RBD 2.4   -   Marc Zeedar
  Alternate 3D   -   Joseph Nastasi
   Re: Alternate 3D   -   Lars Jensen
    Re: Alternate 3D   -   Joseph Nastasi
     Re: Alternate 3D   -   Lars Jensen
      Re: Alternate 3D   -   Joseph Nastasi
       Re: Alternate 3D   -   Lars Jensen
        Re: Alternate 3D   -   Frank Condello
        Re: Alternate 3D   -   Joseph Nastasi
         Re: Alternate 3D   -   Lars Jensen
          Re: Alternate 3D   -   Joseph Nastasi
          Re: Alternate 3D   -   John Balestrieri
          Re: Alternate 3D   -   Frank Condello
          Re: Alternate 3D   -   Joseph Nastasi
          Re: Alternate 3D   -   Joseph Nastasi
           Re: Alternate 3D   -   Lars Jensen
            Re: Alternate 3D   -   Joseph Nastasi
             Re: Alternate 3D   -   Lars Jensen
              Re: Alternate 3D   -   Joseph Nastasi
               Re: Alternate 3D   -   Lars Jensen
          Re: Alternate 3D   -   John Balestrieri
          Re: Alternate 3D   -   Frank Condello
          Re: Alternate 3D   -   Frank Condello
          Re: Alternate 3D   -   Joseph Nastasi
          Re: Alternate 3D   -   Frank Condello
          Re: Alternate 3D   -   Joseph J. Strout
          Re: Alternate 3D   -   Frank Condello
        Re: Alternate 3D   -   Frank Condello
       Re: Alternate 3D   -   Lars Jensen
        Re: Alternate 3D   -   Joseph Nastasi
   RE: Alternate 3D   -   Lynn Fredricks
    Re: Alternate 3D   -   Joseph Nastasi
     RE: Alternate 3D   -   Lynn Fredricks
    Re: Alternate 3D   -   Frank Condello
    Re: Alternate 3D   -   Joseph Nastasi
    Re: Alternate 3D   -   Joseph J. Strout
     Re: Alternate 3D   -   Lars Jensen
      Re: Alternate 3D   -   Joseph Nastasi
       Why Games Die   -   Lynn Fredricks
    Re: Alternate 3D   -   Joseph Nastasi
    Re: Alternate 3D   -   Frank Condello
   Re: Alternate 3D   -   Frank Condello
   Re: Alternate 3D   -   Joseph Nastasi
   Re: Alternate 3D   -   Seth Willits
   Re: Alternate 3D   -   Joseph J. Strout
   Re: Alternate 3D   -   John Balestrieri
   Re: Alternate 3D   -   Jay Kyburz
    Re: Alternate 3D   -   Lars Jensen
     Re: Alternate 3D   -   Dustin Evermore
      Re: Alternate 3D   -   Lars Jensen
       Re: Alternate 3D   -   Seth Willits
       Re: Alternate 3D   -   Joseph Nastasi
        Re: Alternate 3D   -   Lars Jensen
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Frank Condello
       Re: Alternate 3D   -   Seth Willits
       Re: Alternate 3D   -   Frank Condello
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Seth Willits
       Re: Alternate 3D   -   Frank Condello
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Joseph J. Strout
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Asher Dunn
       Re: Alternate 3D   -   Seth Willits
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D   -   Asher Dunn
       Re: Alternate 3D   -   Nick Lockwood
       Re: Alternate 3D   -   Chris Dillman
       Re: Alternate 3D - BANG! 3D   -   Chris Dillman
     Re: Alternate 3D   -   Chris Dillman
      Re: Alternate 3D   -   Lars Jensen
       Re: Alternate 3D   -   Chris Dillman
        Re: Alternate 3D   -   Lars Jensen
         Re: Alternate 3D   -   Chris Dillman
          Re: Alternate 3D   -   Lars Jensen
           Re: Alternate 3D   -   Chris Dillman
           Re: Alternate 3D   -   Frank Condello
            Re: Alternate 3D   -   Lars Jensen
         Re: Alternate 3D   -   Daniel Lurie
     Re: Alternate 3D   -   Dustin Evermore
      Re: Alternate 3D   -   Lars Jensen
       Re: Alternate 3D   -   Adam Cuipka
        Re: Alternate 3D   -   Chris Dillman
         Re: Alternate 3D   -   Lars Jensen
         Re: Alternate 3D   -   Adam Cuipka
          Re: Alternate 3D   -   Nick Lockwood
          Re: Alternate 3D   -   Nick Lockwood
          Re: Alternate 3D   -   Frank Condello
          Re: Alternate 3D   -   Chris Dillman
           Re: Alternate 3D   -   Adam Cuipka
            Re: Alternate 3D   -   Frank Condello
             Re: Alternate 3D   -   Adam Cuipka
              Re: Alternate 3D   -   Asher Dunn
              Re: Alternate 3D   -   John Balestrieri
              Re: Alternate 3D   -   Ben Lilburne
              Re: Alternate 3D   -   Joseph Nastasi
            Re: Alternate 3D   -   Asher Dunn
            Re: Alternate 3D   -   Frank Condello
            Re: Alternate 3D   -   Asher Dunn
            Re: Alternate 3D   -   Frank Condello
           Re: Alternate 3D   -   Adam Cuipka
            Re: Alternate 3D   -   Chris Dillman
             Re: Alternate 3D (Chris)   -   Adam Cuipka
          Re: Alternate 3D   -   Chris Dillman
          Re: Alternate 3D   -   Nick Lockwood
          Re: Alternate 3D   -   Nick Lockwood
          Re: Alternate 3D   -   Frank Condello
     Re: Alternate 3D   -   Daniel Lurie
     Re: Alternate 3D   -   Daniel Lurie

Alternate 3D
Date: 11.05.05 15:45 (Wed, 11 May 2005 10:45:13 -0400)
From: Joseph Nastasi
<soapbox>
I've looked at all of the declares, alternate plugins, etc. that have
come over the wire in the last few years. Just to level set everyone, I
come from a time when RB had no 3D API. My problem with all of these
ventures, is not with any technical shortcomings, but with long term
support and longevity. I am definitely not suggesting that Frank or
Asher stop developing their frameworks. But as someone who is relying
on a 3D API for $$$ (and that is where the main focus of my income is
going), I get real nervous at the thought of betting on someone's part
time development effort.

No one would like to drop kick Quesa across the universe more than I.
No slight to Dair and the Quesa crew (including our own
rhythmically-excitable Joe Strout :-), but I've dealt with too many
issues over the years. While Asher's work is very impressive (I saw
demos at REALworld and Geoff Perlman certainly was interested enough to
look investigate it further), it's not and will not be nearly ready as
a full drop in replacement anytime soon.

I won't reveal details, but the RB3D API is getting a huge shot in the
arm, hopefully in the 2005 timeframe. Nothing is committed officially
by RS, so don't put it on your calendars yet.

The reason I mention this is that no matter what great alternate
solution anyone comes up with, it is now extremely unlikely that it
will be able to compete with the internal RB3D API. It might be
technically better in performance and features, but the momentum is
clearly and irreversibly towards RB3D. It's a business fact of life.

So, the smart thing to do is to continue with the bug/feature reports
and individually push RS for continued improvement for the
system_in_place.

But the REALLY, REALLY smart thing to do is to develop games and
applications that use RB3D. Finish them, sell them and make sure RS
sees them being marketed and sold. Nothing says "this feature is
important" to RS like its use in finished, released and (hopefully)
commercial applications.

Everyone wants to build the next great game engine, but no one wants to
develop the games. It's not just here. That's the reason why the game
industry is just now really embracing 3rd party middleware. But unless
there are applications, serious, fully-developed applications out
there, there's no real point for RS to improve the RB3D API. Except
possibly when I crawl on my hands and knees at REALworld. :-)

RB could be a DarkBasic alternative. DB is a VB-like environment that
is totally tuned towards games and is used both for smaller projects
and as prototyping tool for large houses. That's where we need to go
and, like it or not, the only supported game in town is the RB3D API
and, (a hopefully internalized) Quesa.

Again, this is not a knock on Frank and Asher's work. Their
contribution to the RB game community is well-known and appreciated.

I guess I am asking folks to not re-invent the wheel. Make RS improve
the wheel and build some really hot cars with it.
</soapbox>

Re: Alternate 3D
Date: 11.05.05 16:20 (Wed, 11 May 2005 11:20:48 -0400)
From: Lars Jensen
> (a hopefully internalized) Quesa.

What would be the advantage of that?

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 16:54 (Wed, 11 May 2005 11:54:43 -0400)
From: Joseph Nastasi

On May 11, 2005, at 11:20 AM, Lars Jensen wrote:

>> (a hopefully internalized) Quesa.
>
> What would be the advantage of that?

Internalized in two movements:
1. the runtime is incorporated into the RB framework when RB3D is used.
No more Quesa download requirements.
2. RS has complete control of their version. Considering the number of
active Quesa developers and the fact Joe S. is Mr. 3D at RS, it would
seem not to be an advantage. But if more companies start using RB3D,
taking control of their own version of the source allows RS to add
features and fix bugs that are important to RB. RB3D drives Quesa
development, not a small open source community.

It is MUCH more likely that we will see the first movement happen.
Obviously, RS will need to get a source snapshot to allow the linker to
access it, but that's much different than movement two, which is a
complete ownership of their own copy.

Re: Alternate 3D
Date: 11.05.05 18:17 (Wed, 11 May 2005 13:17:19 -0400)
From: Lars Jensen
> 1. the runtime is incorporated into the RB framework when RB3D is used.
> No more Quesa download requirements.

The RS (i.e. Joe's) recommendation up to now has been to install Quesa in
your system. Personally I ship it with all my apps, so that users pay a
small, ongoing download tax, but never have to worry about tampering with
their system, or whether they have the latest version.

So at first blush, internalizing Quesa would seem to be benign for my needs.
However, if I lose the ability to use a later version of Quesa than is built
into RB, that would not be good. I can think of a few instances where Quesa
has improved substantially between RB major releases. Even if RS makes the
RB release schedule more frequent, that doesn't mean RB3D will get timely
attention.

> 2...taking control of their own version of the source allows RS to add
> features and fix bugs that are important to RB.

In what way are they inhibited from doing that today? If RB demands new
features, Joe can put them in. If he doesn't have time, he can ask for help
from other Quesa devs. If it goes internal, he can't.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 18:38 (Wed, 11 May 2005 13:38:05 -0400)
From: Joseph Nastasi

On May 11, 2005, at 1:17 PM, Lars Jensen wrote:

>> 1. the runtime is incorporated into the RB framework when RB3D is
>> used.
>> No more Quesa download requirements.
>
> The RS (i.e. Joe's) recommendation up to now has been to install Quesa
> in
> your system. Personally I ship it with all my apps, so that users pay a
> small, ongoing download tax, but never have to worry about tampering
> with
> their system, or whether they have the latest version.

For the masses, this is not the way to go. The less crap that has to be
directly installed, the better. I do the same thing (bundle with the
product), but I'm not thrilled about it.

>
> So at first blush, internalizing Quesa would seem to be benign for my
> needs.
> However, if I lose the ability to use a later version of Quesa than is
> built
> into RB, that would not be good. I can think of a few instances where
> Quesa
> has improved substantially between RB major releases. Even if RS makes
> the
> RB release schedule more frequent, that doesn't mean RB3D will get
> timely
> attention.

Really, I can think of none, really. Well, no "official" Quesa releases
anyway. Sure I could go and get the source and compile anytime I want,
but I will not do that, just like I won't recompile the open source XML
code that RB uses as well. (whatever it is, see it worked: it's part of
RB!)
>> 2...taking control of their own version of the source allows RS to add
>> features and fix bugs that are important to RB.
>
> In what way are they inhibited from doing that today? If RB demands new
> features, Joe can put them in. If he doesn't have time, he can ask for
> help
> from other Quesa devs. If it goes internal, he can't.

They are not inhibited, but are not likely to work on it unless it's
absolutely required. Besides, if RB3D is being used, then they will
apply more brain power to it as needed. Sure, Joe S can ASK for help,
but getting it is highly dependent on issues that are not necessarily
aligned with RS's needs. (or mine!)

Again, not to knock the valiant effort but, in the long run, Quesa
needs to be owned by RS if it's going to be used as part of the system.
If Quesa was supported by a larger, broader organization (like OpenGL
or the XML library RB uses - damn, can't remember what that IS!), this
would not be necessary. But that's not the case.

Re: Alternate 3D
Date: 11.05.05 19:56 (Wed, 11 May 2005 14:56:58 -0400)
From: Lars Jensen
I'm personally neutral about RB3D/Quesa vs Asher's Demo vs Frank's Mystery
Project...I just want an easy API that I can write to. Also, I should say up
front that I don't do this for money. (Not yet anyway, and probably not
ever...my games tend to have niche appeal. :)

That said, I'm hearing things that sound sensible at a high level, but don't
make sense to me in the details.

> I do the same thing (bundle [Quesa] with the
> product), but I'm not thrilled about it.

But you'd be thrilled if RB bundled it with your product instead? I don't
see the difference -- it's just another file sitting there next to the app,
the README, and the Data folder. (Maybe you don't have a README and a Data
folder, in which case OK there's a tiny gain...)

>> Quesa has improved substantially between RB major releases.
>
> Really, I can think of none, really.

Here are the ones I have been able to take advantage of between RB releases:

- 32-bit depth buffer
- object picking from mouseXY on Windows
- performance improvements
- [there's another one, but I'm blanking on it]

> Well, no "official" Quesa releases anyway.

I'll "Grant" you that. (Ha ha, get it?) But still, it solved a problem that
would have otherwise taken months to solve -- assuming RS was willing to put
someone on it in the first place.

>> In what way are [RS] inhibited from [improving Quesa] today?
>
> They are not inhibited, but are not likely to work on it unless it's
> absolutely required.

Lack of demand is what inhibits RB3D improvements. Making Quesa internal
won't affect demand, it will just remove a big avenue for improvement. If RB
had internalized Quesa a year ago, my apps would look today like they
did...a year ago...(shudder!)

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:17 (Wed, 11 May 2005 15:17:11 -0400)
From: Frank Condello
On 11-May-05, at 2:56 PM, Lars Jensen wrote:

>>> Quesa has improved substantially between RB major releases.
>>
>> Really, I can think of none, really.
>
> Here are the ones I have been able to take advantage of between RB
> releases:
>
> - 32-bit depth buffer
> - object picking from mouseXY on Windows
> - performance improvements
> - [there's another one, but I'm blanking on it]

These come to mind:

- Automatic Texture Mipmapping
- Texture Filtering
- Texture & Colour Blending
- Improved Transparency Sorting

Frank.
------------------------------------
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:24 (Wed, 11 May 2005 15:24:32 -0400)
From: Joseph Nastasi

On May 11, 2005, at 3:17 PM, Frank Condello wrote:

> On 11-May-05, at 2:56 PM, Lars Jensen wrote:
>
>>>> Quesa has improved substantially between RB major releases.
>>>
>>> Really, I can think of none, really.
>>
>> Here are the ones I have been able to take advantage of between RB
>> releases:
>>
>> - 32-bit depth buffer
>> - object picking from mouseXY on Windows
>> - performance improvements
>> - [there's another one, but I'm blanking on it]
>
> These come to mind:
>
> - Automatic Texture Mipmapping
> - Texture Filtering
> - Texture & Colour Blending
> - Improved Transparency Sorting

But many of these are not accessible (right now) through the RB API.
That's what needs to change.

Also, RB has always put out several new releases a year (though with
2005 it's more official) so they could easily pull in the latest Quesa
for any of them.

Re: Alternate 3D
Date: 11.05.05 23:02 (Wed, 11 May 2005 18:02:39 -0400)
From: Lars Jensen
> My point was that very few are developing games to completion and
> commercial release, and the reason I keep hearing is that RB3D/Quesa is
> stopping development. I think the real reason has more to do with
> wanting to build engine technology because it's cool.

Well _I_ think the reason is that people who can conceive and develop a game
worthy of commercial release are much rarer than those who can make an
engine. For every 10,000 people who think "I want to make a game" there are
probably 1000 who stay interested after finding out that it's not easy, 100
who are willing to put in the work (the engine people make it this far), 10
who are capable of doing the project management, and 1 who is capable of
creating something worth doing.

So when we did this:

http://ljensen.com/rb/gamedev_outline.htm

the big demand was for a better SpriteSurface, which leads me to think that
the people casting the votes are the ones who will never develop a
commercial title -- and indeed, who might never finish a game at all.

Now in a sense, that's just fine -- hobbyists are paying customers and they
deserve consideration. I'm in that group myself (although I'm not a sprite
guy). I'm just saying that the right answer for those people probably has
little to do with the right answer for the high-end folks, so this
discussion will be most useful if we know who RS's target is.

> But [AOK] still sold because it was more than just 3D effects.

Right, that's my point -- RB3D is good enough for many purposes _today_,
unlike many other things that developers stumble on. High-end developers
have the resources to overcome those stumbling blocks on their own. Low-end
ones don't. Which would RS rather court today?

> ...the basics need to be taken up a huge notch, IMHO before we get to the
> sexy stuff like dynamics.

Strategic talk is useless without a shared understanding of the details.
Perhaps you (and others) can list some specific things that RB3D lacks that
would improve your ability to sell products. (I'm happy to collate response
to a new survey if JoeS thinks it would be useful.)

> Also, RB has always put out several new releases a year (though with
> 2005 it's more official) so they could easily pull in the latest Quesa
> for any of them.

I'm very skeptical about that. RS would have to dedicate testing resources
at the very least. I don't think they'd do it for every release -- maybe not
even every six months.

Also, that comment makes me wonder if I understand the "internalize Quesa"
proposal -- I thought it meant "grab a snapshot of today's Quesa and never
look back". Perhaps instead it means "build the best Quesa we know of at the
time of RB release, and include that, but anticipate getting new Quesas in
the future". That would make a big difference. (See what I mean about
details?)

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 23:19 (Wed, 11 May 2005 18:19:55 -0400)
From: Joseph Nastasi

On May 11, 2005, at 6:02 PM, Lars Jensen wrote:
> Well _I_ think the reason is that people who can conceive and develop
> a game worthy of commercial release are much rarer than those who can
> make an engine. For every 10,000 people who think "I want to make a
> game" there are probably 1000 who stay interested after finding out
> that it's not easy, 100 who are willing to put in the work (the engine
> people make it this far), 10 who are capable of doing the project
> management, and 1 who is capable of creating something worth doing.

I sort of agree, but even developing an engine is hard, maybe harder.
And where are the completed engines? (RB usable ones I mean)

> http://ljensen.com/rb/gamedev_outline.htm

AH! A nostalgic look at the past!
>
> the big demand was for a better SpriteSurface, which leads me to think
> that the people casting the votes are the ones who will never develop
> a commercial title -- and indeed, who might never finish a game at
> all.

Are you saying because the SS was perceived as easier? That's probably
true.

> Now in a sense, that's just fine -- hobbyists are paying customers and
> they deserve consideration. I'm in that group myself (although I'm not
> a sprite guy). I'm just saying that the right answer for those people
> probably has little to do with the right answer for the high-end
> folks, so this discussion will be most useful if we know who RS's
> target is.
>
>> But [AOK] still sold because it was more than just 3D effects.
>
> Right, that's my point -- RB3D is good enough for many purposes
> _today_, unlike many other things that developers stumble on. High-end
> developers have the resources to overcome those stumbling blocks on
> their own. Low-end ones don't. Which would RS rather court today?

I'm not so sure that "good enough" is where they need to stay. It's not
really good enough. Many basic, simple things are missing: you can't
get a count of the number of shapes, for example. Bigger things:
accessing Trimesh. Once that kind of stuff is done, then there are
others that can contribute things like particle generators, IK code,
etc. That kind of thing does not have to be built in, Accessing Trimesh
does.

> Strategic talk is useless without a shared understanding of the
> details. Perhaps you (and others) can list some specific things that
> RB3D lacks that would improve your ability to sell products. (I'm
> happy to collate response to a new survey if JoeS thinks it would be
> useful.)

Let's just say that some of this has been indicated to RS in a very
specific and detailed manner. They know what it needs.

>> Also, RB has always put out several new releases a year (though with
>> 2005 it's more official) so they could easily pull in the latest
>> Quesa for any of them.
> I'm very skeptical about that. RS would have to dedicate testing
> resources at the very least. I don't think they'd do it for every
> release -- maybe not even every six months.

I would want them only to include "blessed" Quesa releases. I live far
enough out on the bleeding edge with A-OK!; I don't need to add
developer releases as well.

> build the best Quesa we know of at the time of RB release, and include
> that, but anticipate getting new Quesas in the future". That would
> make a big difference.

Yes, that's it. Just compiling it in via the linker, that's all. Sure,
if RB3D becomes very important to the RS bottom line, you can bet they
will grab the code and take it from there. Just like they are doing
with SQLlitePro. But that is not going to happen right now. I just want
the Quesa library file to be a non-entity for the user. One less thing
they can screw up.

> (See what I mean about details?)

Again, RS understands this concept, definitely.

Cheers,
Joe

Re: Alternate 3D
Date: 11.05.05 23:39 (Wed, 11 May 2005 18:39:36 -0400)
From: John Balestrieri
I think I threw in my 2c earlier on this one... Who can afford to
develop a game engine without an expected return? I think we have now
what the market can afford.

Re: Alternate 3D
Date: 12.05.05 08:26 (Thu, 12 May 2005 03:26:28 -0400)
From: Frank Condello
On 11-May-05, at 6:19 PM, Joseph Nastasi wrote:

> I'm not so sure that "good enough" is where they need to stay. It's
> not really good enough. Many basic, simple things are missing: you
> can't get a count of the number of shapes, for example. Bigger
> things: accessing Trimesh. Once that kind of stuff is done, then
> there are others that can contribute things like particle
> generators, IK code, etc. That kind of thing does not have to be
> built in, Accessing Trimesh does.

As long as Quesa is an external library, you don't *need* trimesh
access built-in (ya it would be nice, but it's not the end of the
world). Joe has several examples of how to manipulate a trimesh (some
are on the RB CD, and there's an RB Developer article or two on the
topic as well). I also have a Trimesh3D class in the Quesa Wrappers,
with Object3D extensions to easily grab all the trimeshes in any Shape.

Let us know what you need to do with a mesh, and I'm sure we can
solve it - you just have to accept the fact that declares aren't evil ;)

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 12:18 (Thu, 12 May 2005 07:18:23 -0400)
From: Joseph Nastasi
My point here is that others are willing to do it for nothing. But they
really don't deliver completed engines either.
I certainly understand why someone would make the decision not to build
an engine because of the lack of market.
It's an uphill battle since the market is very small and RS already has
something in place.

On May 11, 2005, at 6:39 PM, John Balestrieri wrote:

> I think I threw in my 2c earlier on this one... Who can afford to
> develop a game engine without an expected return? I think we have now
> what the market can afford.
>
> --
> John Balestrieri
> REALbasic Consulting, www.tinrocket.com
>
> SuperSpriteSurface, a 2D OpenGL game engine for REALbasic:
> http://www.tinrocket.com/products/superspritesurface/index.html
>
> On May 11, 2005, at 6:19 PM, Joseph Nastasi wrote:
>
>> I sort of agree, but even developing an engine is hard, maybe harder.
>> And where are the completed engines? (RB usable ones I mean)
>>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 12:42 (Thu, 12 May 2005 07:42:39 -0400)
From: Joseph Nastasi

On May 12, 2005, at 3:26 AM, Frank Condello wrote:

> On 11-May-05, at 6:19 PM, Joseph Nastasi wrote:
>
>> I'm not so sure that "good enough" is where they need to stay. It's
>> not really good enough. Many basic, simple things are missing: you
>> can't get a count of the number of shapes, for example. Bigger
>> things: accessing Trimesh. Once that kind of stuff is done, then
>> there are others that can contribute things like particle generators,
>> IK code, etc. That kind of thing does not have to be built in,
>> Accessing Trimesh does.
>
> As long as Quesa is an external library, you don't *need* trimesh
> access built-in (ya it would be nice, but it's not the end of the
> world). Joe has several examples of how to manipulate a trimesh (some
> are on the RB CD, and there's an RB Developer article or two on the
> topic as well). I also have a Trimesh3D class in the Quesa Wrappers,
> with Object3D extensions to easily grab all the trimeshes in any
> Shape.
>
> Let us know what you need to do with a mesh, and I'm sure we can solve
> it - you just have to accept the fact that declares aren't evil ;)

I do not accept that at all. The API needs to support these features. I
know all about Joe's stuff and your wrappers. But they are NOT
supported by the company I fork over a fair amount of money to every
year for multi-platform licenses and the Developers Program. So, I
expect and in fact was sold on the concept that RB3D would be improved
over time. Not surprisingly, that has languished over the last couple
of years because of much bigger deeds that needed to be done.

I think after 26 years of software development, I can learn how to use
declares. I can relearn C++ too. Why? That's not what I bough into is
it? The RB syntax was the #1 reason I moved to the platform. (there
were a bunch of #2 reasons) I do not want to base my entire product
line and therefore, business on the use of wrappers or declares when an
API already exists. If RB3D never existed, I surely would have had to
use OpenGL via declares and lived with it. But that's not the way it
is.

The attitude of being able to say, "well, I just can't release anything
until all the tools are exactly the way I want them." is just not
something I can afford to do. Nor can I afford to base my projects on
3rd party code that is not even being advertised as a financially
motivated, because there is little to stop the developer from just
walking away. And making it open source doesn't help me. The rest of
the project is complicated enough; I don't need to fix other 3rd party
components just to get them to work.

Additionally, like it or not, I am not about to advertise all the
details of what I am doing by letting the group know what I need to do
with a mesh. It's one thing to ask a particular question, but I have to
be careful of what I expose. For example, the Control Panel Library
that I am writing about in my RBD column, The Topographic Apprentice,
has many details and features left out. It's enough to teach the
technique and even allow others to use, but I keep all the stuff that
is unique private.

Like it or not, the only reason we are even on this forum is because
Geoff turned someone's part-time venture into a profitable business.
And the business of gaming is the only thing that will advance RB in
that field.

I've stated over and over again that it's great that people are trying
these alternate engine ideas. However, as sustainable alternatives for
financially motivated product, they will fail. If someone is really
interested in using RB for game-related software, they have to:

1. Accept the fact that the RB3D/Quesa/OpenGL model is here to stay.
2. Push RS into making improvements on that model.
3. Publish products using that model and stop using it's shortcomings
as excuses.

It's not about technical issues. It's about business.

Re: Alternate 3D
Date: 12.05.05 17:41 (Thu, 12 May 2005 12:41:23 -0400)
From: Lars Jensen
> Who is going to develop a complete and supported dynamics
> engine for free?

Newton and ODE seem to be examples, unless by "supported" you mean
"commercial", in which you should simply say "I'm not willing to use
non-commercial technology", which seems to be the essence of your
philosophy.

I'm not knocking that, just trying to get people to be more explicit about
what they mean around this topic, which for some reason seems always to be
discussed in terms too abstract to be useful.

(However I will point out that if RS had used that same acid test, from what
I can tell, there would be no RB3D today.)

> ...I've laid out exactly what I feel is needed. What they do with it is up to
> them... Anyone who understands the business end of this...understands that
> improving the current API is the only way to go.

You might get support from people who aren't ready to do a commercial game
but nevertheless feel the same way you do about certain features.

> So, there really is not any major item that does not work in Quesa that
> prevents the successful development of a successful game.

I agree. So why this insistence that "improving the current API is the only
way to go"? To go where? You're claiming that every sensible author with
commercial ambitions has the same no-compromise attitude toward
noncommercial components, regardless of their status or complexity, that you
do. I haven't seen that in other areas of programming, so I don't see why it
would be true for 3D in RB.

> The attitude of being able to say, "well, I just can't release anything
> until all the tools are exactly the way I want them." is just not
> something I can afford to do.

You seem to be arguing for exactly that -- you refuse to consider Declares
simply because you haven't paid for them, in the form of seeing them in the
RB3D API.

> I can learn how to use declares. I can relearn C++ too.

Come on now, the two are hardly in the same league.

> Additionally, like it or not, I am not about to advertise all the
> details of what I am doing by letting the group know what I need to do
> with a mesh.

Nobody's asking for those kinds of details. I'm simply saying that the more
requests you can share, the more support you're likely to get from the
community in the form of feature requests, sign-ons, and positive comments
here -- or ways to work around thing. You seem to disregard that avenue
completely. That's up to you, but when you insist that RS spend their scarce
resources on stuff that's not blocking you just because you have a distaste
for declares, I get huffy because there's other stuff I want, and I'm a
paying customer too. Therefore I ask you for more details, so that perhaps
we can get RS to concentrate first on the stuff we both want.

>> a game is still too much work
>
> The #1 reason games don't get completed...And that is very rarely admitted.

Around here, I see people saying it right and left. I don't see what
relevance it has though, because RS and the community can't do anything
about it.

What they/we _can_ do is to identify the building blocks of a game, see
what's not covered, and attempt to fill in the holes. We agree that 3D is
covered to a degree, even though it's less than ideal. I harp on dynamics
because it's not covered at all. Yes, a sufficiently smart and motivated
person can overcome that, if motivated by a sound business plan. Do you want
RB gaming to be relevant only to those people? I don't.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 18:57 (Thu, 12 May 2005 13:57:31 -0400)
From: Joseph Nastasi

On May 12, 2005, at 12:41 PM, Lars Jensen wrote:

>> Who is going to develop a complete and supported dynamics
>> engine for free?
>
> Newton and ODE seem to be examples, unless by "supported" you mean
> "commercial", in which you should simply say "I'm not willing to use
> non-commercial technology", which seems to be the essence of your
> philosophy.

That is exactly what I mean. I can't afford to have something go away 6
- 24 months down the road. It has happened before and it cost me dearly

> (However I will point out that if RS had used that same acid test,
> from what I can tell, there would be no RB3D today.)

Not really true. They were looking for a 3D engine (partially based on
my whining, uh feedback), that included coming close to buying one from
someone that was developing a plugin. In fact, when the RB3D/Quesa
option was discussed, my question was the same. The difference is the
response was: "we bring the code in-house." So, RS really has taken
ownership of Quesa in a roundabout way. And a more direct way, as Joe
has contributed to the open source effort.

>> ...I've laid out exactly what I feel is needed. What they do with it
>> is up to them... Anyone who understands the business end of
>> this...understands that improving the current API is the only way to
>> go.
>
> You might get support from people who aren't ready to do a commercial
> game but nevertheless feel the same way you do about certain features.

That's not what I'm seeing. Lately I see a lot of debate, but no
suggestions on improvements to the API.
>
>> So, there really is not any major item that does not work in Quesa
>> that prevents the successful development of a successful game.
>
> I agree. So why this insistence that "improving the current API is the
> only way to go"? To go where?

To improve RB's use as a gaming platform. With a properly designed API,
you can write editors, do complex mesh animations and other things,
using the same syntax you use for most every other aspect of an RB app.
Why is that not a good aiming point? RS apparently felt that way when
they started creating the RB3D API, so why _wouldn't_ anyone want it
improved as much as possible?

> You're claiming that every sensible author with commercial ambitions
> has the same no-compromise attitude toward noncommercial components,
> regardless of their status or complexity, that you do.

No, I am talking about companies not individuals. I am in a very small
minority as a single person shop with that type of commitment and
attitude. However, that's not really true as I am working with a team
of 6 other developers under a legally binding agreement and am in the
process of expanding.

However, I think every sensible author with commercial ambitions SHOULD
have that attitude.
Again, if someone wants to use Frank's wrappers or Asher's engine,
that's great. But it's a calculated risk that a commercial venture is
highly unlikely to take and it does nothing to push the state of the
art in the IDE of choice. Not that everyone should feel responsible for
that.

> I haven't seen that in other areas of programming, so I don't see why
> it would be true for 3D in RB.

You've got to be kidding? Every commercial project I have been involved
with in RB had to make a decision about using 3rd party libraries or
plugins. It's always a problem. Some are easy: MBS, Einhuger, Electric
Butterfly, Pyramid Design (and a few others) all have products that
people use in commercial products because they have proven to be fully
supportive and committed to the product.
>
>> The attitude of being able to say, "well, I just can't release
>> anything until all the tools are exactly the way I want them." is
>> just not something I can afford to do.
>
> You seem to be arguing for exactly that -- you refuse to consider
> Declares simply because you haven't paid for them, in the form of
> seeing them in the RB3D API.

Except I've actually brought product to market. A huge differentiator.
I'm not saying I _won't_ produce product using declares. If I have to I
will, but I don't accept that very easily when there's an API already
in the IDE!

>> I can learn how to use declares. I can relearn C++ too.
>
> Come on now, the two are hardly in the same league.

Well, from my personal perspective, no. Using declares means I get to
unravel the interfaces for C/C++ routines in the library. Even with
wrappers, I have to know details of Quesa in a format (C/C++ calls)
that frankly, makes me projectile vomit.

>> Additionally, like it or not, I am not about to advertise all the
>> details of what I am doing by letting the group know what I need to
>> do
>> with a mesh.
>
> Nobody's asking for those kinds of details.

That was in response to Frank's comment of "tell us what you need..."

My point is that I can't really divulge too much info on certain
subjects so the group can't help me in the way that Frank seemed to be
implying which may not be true.

> But when you insist that RS spend their scarce resources on stuff
> that's not blocking you just because you have a distaste for declares,
> I get huffy because there's other stuff I want, and I'm a paying
> customer too. Therefore I ask you for more details, so that perhaps we
> can get RS to concentrate first on the stuff we both want.

Isn't it obvious that even after you produced the great request matrix,
that nothing was happening? I surely didn't need half the stuff there,
but in the end, none of it was done. So, how is a group discussion of
features going to make it happen this time?

But then, that's not what's being discussed here. What's being
discussed is not RB features, but alternates to RB3D, remember? And
that's what I feel is a dead end for commercial 3D work using RB. Now I
saw a serious, commercial, supported alternative being discussed, I'd
really take notice. Even though the Quesa wrappers and Asher's stuff is
really very good from a technical standpoint, they are both lacking as
a true alternative until they are commercial.
>
>>> a game is still too much work
>>
>> The #1 reason games don't get completed...And that is very rarely
>> admitted.
>
> Around here, I see people saying it right and left. I don't see what
> relevance it has though, because RS and the community can't do
> anything about it.

RS can't. But people could start identifying markets and creating games
to fill those markets. And that would give RS more incentive to enlarge
RB3D's capabilities.

> We agree that 3D is covered to a degree, even though it's less than
> ideal. I harp on dynamics
> because it's not covered at all.

The 3D API is not a good foundation the way it stands. The syntax needs
to be more orthogonal and cover more of what Quesa has. Some would
argue that RB needs a particle generator or 3D sound support. But
without a good solid 3D API, you're building on a shaky foundation. The
API is the core of everything. If RS replaces Quesa with their own
engine or a OpenGL-based one, do you think they'll change the API? No.
So improving the API is #1 issue.

> Yes, a sufficiently smart and motivated person can overcome that, if
> motivated by a sound business plan. Do you want RB gaming to be
> relevant only to those people? I don't.

Of course not. But unless more those types appear, RS is NOT going to
invest too deeply in improving what they have, much less tackle
something like a dynamics engine. It's just not going to happen.

I understand this kind of heavy dose business reality is bummer, but it
IS the engine that drives what effort RS will drive into 3D and other
gaming issues.

Re: Alternate 3D
Date: 12.05.05 22:26 (Thu, 12 May 2005 17:26:37 -0400)
From: Lars Jensen
> Lately I see a lot of debate, but no suggestions on improvements to the API.

I'm not making any because there's other stuff I want more. Your call as to
how private you want yours to be, but I don't believe that suggesting
specific but generic API improvements will do anything but improve their
chances.

> Isn't it obvious that even after you produced the great request matrix,
> that nothing was happening? I surely didn't need half the stuff there,
> but in the end, none of it was done.

That's just plain wrong:

- The top vote-getters weren't in 3D, because that list was for games in
general, and we've got a bunch of sprite-heads on this list.

- Two of the four top vote-getters (two that you voted for, in fact) were
implemented in RB, along with a few other items (the ones in italics).

- The top vote-getter in 3D was addressed by Frank, who contributed his RB
code to the community.

- The remaining items that you voted for were addressed by JoeS in RBD
articles, even though they weren't top vote-getters.

I wish more were done as well, and I don't know how much the outline had to
do with any of it. But outright dismissal is unwarranted.

> So, how is a group discussion of features going to make it happen this time?

I never said we could make anything happen, just that more voices make
something more likely. Please don't recast my reasonable claims as absurd
ones.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 23:28 (Thu, 12 May 2005 18:28:24 -0400)
From: Joseph Nastasi
On May 12, 2005, at 5:26 PM, Lars Jensen wrote:

>> Lately I see a lot of debate, but no suggestions on improvements to
>> the API.
>
> I'm not making any because there's other stuff I want more. Your call
> as to how private you want yours to be, but I don't believe that
> suggesting specific but generic API improvements will do anything but
> improve their chances.

Over time, I have suggested very specific improvements. I'm not worried
about RS taking care of things. The improvements were delayed because
of understandably higher priorities, but I believe the time is right
for improvements.

The whole point of this was to lament that fact that producing
alternatives to RB3D doesn't necessarily solve the problem of it's
limitations. And the other point was the general dearth of completed
project/products. And I was not accepting the excuse of limitations in
RB.

> I never said we could make anything happen, just that more voices make
> something more likely. Please don't recast my reasonable claims as
> absurd ones.

I didn't say you DID say that. There were no guarantees from you and I
thought it a good enough idea that I participated. Don't put words in
my mouth, either.

This isn't personal after all.

Re: Alternate 3D
Date: 13.05.05 00:35 (Thu, 12 May 2005 19:35:51 -0400)
From: Lars Jensen
> I didn't say you DID say that.

My apologies if I over-read your remarks. (The gamedev ballot wasn't my
idea, by the way -- I just categorized it, formatted it, and counted votes.)

> The whole point of this was to lament that fact that producing
> alternatives to RB3D doesn't necessarily solve the problem of it's
> limitations.

Well my whole point was to understand its limitations better so I could
recalibrate my ambitions and make more appropriate contributions to the
community. I can't say I achieved that... :/

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 17:30 (Thu, 12 May 2005 12:30:34 -0400)
From: John Balestrieri
ROTFLOL

John

On May 12, 2005, at 7:18 AM, Joseph Nastasi wrote:

> My point here is that others are willing to do it for nothing. But
> they really don't deliver completed engines either.
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 19:57 (Thu, 12 May 2005 14:57:56 -0400)
From: Frank Condello
On 12-May-05, at 7:18 AM, Joseph Nastasi wrote:

> My point here is that others are willing to do it for nothing. But
> they really don't deliver completed engines either.

I'm building an engine with the intent of releasing shareware games.
I have a business plan, and I'm not new to any of this - I also know
how to manage my time vs features. All I can say is that this _will_
get done, but wether or not you beleive that is for you to decide.

That said, the 3D components alone don't make an engine. I spent a
lot of time getting RB to play nicely with FMOD for 3D audio and
music (it's a commercially supported library - you might want to try
it!). I also spent a lot of time on my input and event-command
parsing plugins/modules. I've released most of my input stuff, but
I'm keeping the command module to myself 'cause that's what I
consider the heart of the engine. The 3D stuff is easy in comparison,
and I'll probably release at least a subset of that at some point.

My point here is that others are doing it seemingly for nothing, but
just because you don't see a completed engine doesn't mean they don't
(or won't) exist. Also, I don't have plans to release a "complete"
engine (and never said I would) but I just maybe will release some of
the 3D rendering bits.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 20:45 (Thu, 12 May 2005 15:45:35 -0400)
From: Frank Condello
On 12-May-05, at 7:42 AM, Joseph Nastasi wrote:

> So, I expect and in fact was sold on the concept that RB3D would be
> improved over time. Not surprisingly, that has languished over the
> last couple of years because of much bigger deeds that needed to be
> done.

If you were promised something by RS then you should be complaining
directly to RS...

> I think after 26 years of software development, I can learn how to
> use declares. I can relearn C++ too. Why? That's not what I bough
> into is it? The RB syntax was the #1 reason I moved to the platform.

I guess we just have different philosophies. The _only_ reason I've
stuck with RB is the fact that I can declare to externals use custom
C plugins. If those features weren't there I'd be spending a lot more
time in Codewarrior - simple as that.

> The attitude of being able to say, "well, I just can't release
> anything until all the tools are exactly the way I want them." is
> just not something I can afford to do.

Neither can I, so I write my own tools - what's wrong with that?

> Nor can I afford to base my projects on 3rd party code that is not
> even being advertised as a financially motivated, because there is
> little to stop the developer from just walking away.

I do contract work; if you want some commercially supported code
(based on open source stuff or written from scratch) contact me off
list and I'll be glad to do business with you.

> And making it open source doesn't help me. The rest of the project
> is complicated enough; I don't need to fix other 3rd party
> components just to get them to work.

You're assuming things will break. If something works, right now, why
not use it to make your life easier? I prefer to worry about problems
when they occur, but again, we've got a different outlook on things...

> Additionally, like it or not, I am not about to advertise all the
> details of what I am doing by letting the group know what I need to
> do with a mesh. It's one thing to ask a particular question, but I
> have to be careful of what I expose.

I wasn't suggesting you divulge trade secrets or anything, but if you
need to do something specific to mesh (specific in mathematical
terms) where's the harm in asking for help? If someone comes along
and asks: "I need to shift all the vertices in my model n units along
their normals". I won't reply with "why the heck do you want to do
that!?!?!?", I'd likely post a few lines of code that simply does
what they ask. I can't fathom a situation where you'd have to get so
specific that your livelihood is endangered...

> 1. Accept the fact that the RB3D/Quesa/OpenGL model is here to stay.

That's fine with me. I *like* RB3D/Quesa, it's just not an end-all
solution. For example, I also like OpenAsPicture, but that didn't
stop me from writing a plugin to import PNG files with a little more
control - there's no difference here...

> 2. Push RS into making improvements on that model.

I have been, and I've actually helped out with real live code patches
for Quesa - complaining only gets you so far...

> 3. Publish products using that model and stop using it's
> shortcomings as excuses.
>
> It's not about technical issues. It's about business.

If the built-ins work for _your_ business then that's fine and dandy,
but here's a couple examples of technical issues with built-ins that
would've prevented me from doing business, if not for the fact that
RB supports declares and plugins:

I wrote a CDROM/kiosk app for a client last year in RB, where they
wanted to obfuscate the data files into packages to prevent casual
tampering. First thing I did was stick all the data files in a
Virtual Volume (i.e. used built-in APIs). I quickly discovered that
a) You can't open pictures without writing out a temp file, and b)
You can't use a VV on locked media (e.g. a CDROM). What to do? I
wrote two plugins; PNG Utilities, can reconstruct an image from raw
data, and ZZip Utilities that allowed me to easily access zipped
files in place of vv's. Without those plugins, I couldn't have
completed this project in RB and wouldn't have gotten paid.

Example #2 - My sole piece of shareware ATM is a realtime MIDI filter
for Win32. Guess what? RB doesn't do MIDI (well other than
noteplayer, but that was of no use for this app). I whipped up some
declares and it lol and behold it worked, I can get and send MIDI
events in realtime to and from any attached device - something RB
simply can't do out of the box.

The moral of this story is: Their are many technical issues in RB
that prevent you from doing business. I'd love to see all this stuff
built-in, but the fact that something isn't supported natively
shouldn't stop anyone from implementing it themselves - it's the same
with the 3D API...

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 23:13 (Thu, 12 May 2005 18:13:14 -0400)
From: Joseph Nastasi

On May 12, 2005, at 3:45 PM, Frank Condello wrote:

> On 12-May-05, at 7:42 AM, Joseph Nastasi wrote:
>
>> So, I expect and in fact was sold on the concept that RB3D would be
>> improved over time. Not surprisingly, that has languished over the
>> last couple of years because of much bigger deeds that needed to be
>> done.
>
> If you were promised something by RS then you should be complaining
> directly to RS...

Directly promised, no, but the concept of letting something languish
for two years is not good.

>
>> I think after 26 years of software development, I can learn how to
>> use declares. I can relearn C++ too. Why? That's not what I bough
>> into is it? The RB syntax was the #1 reason I moved to the platform.
>
> I guess we just have different philosophies. The _only_ reason I've
> stuck with RB is the fact that I can declare to externals use custom C
> plugins. If those features weren't there I'd be spending a lot more
> time in Codewarrior - simple as that.

I thought so and that's valid. But I absolutely hate C syntax ( and
being an AT&T programming type in the late 80's to mid 90's that's all
I saw), I love the IDE (for the most part) and speed of development. I
just cannot see myself going back to that. Now, others working for me
are using C for some plugins, but I remember enough to be able to wade
through plugins, if I need to see something for myself.

>> The attitude of being able to say, "well, I just can't release
>> anything until all the tools are exactly the way I want them." is
>> just not something I can afford to do.
>
> Neither can I, so I write my own tools - what's wrong with that?

For your needs? Absolutely nothing. But I don't want to write stuff
that really should be in the RB3D API. I have too many _other_ tools to
write or have written (like eight or so specialized editors) to bother
with that. A particle generator, for example, is a separate enough and
high level enough feature not to be absolute require.
>
>> And making it open source doesn't help me. The rest of the project is
>> complicated enough; I don't need to fix other 3rd party components
>> just to get them to work.
>
> You're assuming things will break. If something works, right now, why
> not use it to make your life easier? I prefer to worry about problems
> when they occur, but again, we've got a different outlook on things...

I'm basing this on several events (not one, two, _several_) where I got
burned.

> I can't fathom a situation where you'd have to get so specific that
> your livelihood is endangered...

That's true.

>
>> 1. Accept the fact that the RB3D/Quesa/OpenGL model is here to stay.
>
> That's fine with me. I *like* RB3D/Quesa, it's just not an end-all
> solution. For example, I also like OpenAsPicture, but that didn't stop
> me from writing a plugin to import PNG files with a little more
> control - there's no difference here...
>
>> 2. Push RS into making improvements on that model.
>
> I have been, and I've actually helped out with real live code patches
> for Quesa - complaining only gets you so far...
>
>> 3. Publish products using that model and stop using it's shortcomings
>> as excuses.
>>
>> It's not about technical issues. It's about business.
>
> If the built-ins work for _your_ business then that's fine and dandy,
> but here's a couple examples of technical issues with built-ins that
> would've prevented me from doing business, if not for the fact that RB
> supports declares and plugins:
>
> ? I wrote two plugins; PNG Utilities, can reconstruct an image from
> raw data, and ZZip Utilities that allowed me to easily access zipped
> files in place of vv's. Without those plugins, I couldn't have
> completed this project in RB and wouldn't have gotten paid.

Those type of things are very isolated functions. I don't want to be
doing things like accessing mesh, removing shapes via declares or
wrappers. REALbasic doesn't support SGP orbital trajectory equations
and I had some legacy C code that is now a plugin in A-OK!, so it's not
an alien concept.

>
> Example #2 - My sole piece of shareware ATM is a realtime MIDI filter
> for Win32. Guess what? RB doesn't do MIDI (well other than noteplayer,
> but that was of no use for this app). I whipped up some declares and
> it lol and behold it worked, I can get and send MIDI events in
> realtime to and from any attached device - something RB simply can't
> do out of the box.

But it's not like they had a MIDI API that was missing key features.
This is exactly the approach I would have taken if they never put in
RB3D API (with OpenGL), but I am invested in it and it's time to
improve things.

> The moral of this story is: Their are many technical issues in RB that
> prevent you from doing business. I'd love to see all this stuff
> built-in, but the fact that something isn't supported natively
> shouldn't stop anyone from implementing it themselves - it's the same
> with the 3D API...

Wait, it's not stopping me. I've already released a product and dealt
with severe limitations and working on one now with a more capable API,
but one that is still missing some of the basics. I just prefer and
think that most people designing something that needs support,
long-term support, would want to see basic functionality in the native
tool.

Re: Alternate 3D
Date: 12.05.05 23:49 (Thu, 12 May 2005 18:49:42 -0400)
From: Frank Condello
On 12-May-05, at 6:13 PM, Joseph Nastasi wrote:

> I don't want to be doing things like accessing mesh, removing
> shapes via declares or wrappers.

First I just want to say that I can see your point(s), and for the
most part you're just being cautious due to bad past experiences -
BUT - why is accessing a mesh something that absolutely *has* to be
built-in? Manipulate the data with a few declares and be done with it
- it's not difficult, mystical, or in any way more dangerous than
built-in methods would be. Also, built-in methods would, out of
necessity, be very generic, so it's quite possible you'd get better
performance for certain specific mesh manipulations by doing things
yourself anyway, even if Rb3D had the API's you're looking for...

If you're stalling on this point to make a stand then I'd humbly
recommend getting over it. Rb3D's been around for years with no
direct mesh manipulation, and there's no indication that'll change in
RB 2005.

Please don't take this the wrong way, I'm really just trying to help
- I don't like seeing people suffer ;)

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 14:41 (Fri, 13 May 2005 08:41:03 -0500)
From: Joseph J. Strout
At 6:49 PM -0400 5/12/05, Frank Condello wrote:

>First I just want to say that I can see your point(s), and for the
>most part you're just being cautious due to bad past experiences -
>BUT - why is accessing a mesh something that absolutely *has* to be
>built-in? Manipulate the data with a few declares and be done with
>it - it's not difficult, mystical, or in any way more dangerous than
>built-in methods would be.

Well, to be fair, that's not really true. Suppose we were to decide
to replace our Quesa underpinnings with something else, maybe custom
code that speaks directly to OpenGL or Direct3D or whatnot. In that
case, any projects depending on Quesa declares would no longer work,
whereas anything that uses only the built-in methods would
(presumably) continue to work fine.

Not that that's likely to happen, but it does illustrate how relying
on declares can potentially make it harder for you to move forward as
RB evolves.

Best,
- Joe

Re: Alternate 3D
Date: 13.05.05 20:09 (Fri, 13 May 2005 15:09:40 -0400)
From: Frank Condello
On 13-May-05, at 9:41 AM, Joseph J. Strout wrote:

> At 6:49 PM -0400 5/12/05, Frank Condello wrote:
>
>> First I just want to say that I can see your point(s), and for the
>> most part you're just being cautious due to bad past experiences -
>> BUT - why is accessing a mesh something that absolutely *has* to
>> be built-in? Manipulate the data with a few declares and be done
>> with it - it's not difficult, mystical, or in any way more
>> dangerous than built-in methods would be.
>
> Well, to be fair, that's not really true. Suppose we were to
> decide to replace our Quesa underpinnings with something else,
> maybe custom code that speaks directly to OpenGL or Direct3D or
> whatnot. In that case, any projects depending on Quesa declares
> would no longer work, whereas anything that uses only the built-in
> methods would (presumably) continue to work fine.

True enough, but as I pointed out in one of my earlier posts, I tend
to worry about problems when and if they pop up :) Although I prefer
to future-proof things, in general, if something works right now,
I'll use it, if it breaks or proves inadequate, I'll fix it (or use
something else) - some people find this approach disturbing - and
it's not just code, I treat everything like this!

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 22:04 (Wed, 11 May 2005 17:04:12 -0400)
From: Frank Condello
On 11-May-05, at 3:24 PM, Joseph Nastasi wrote:

> On May 11, 2005, at 3:17 PM, Frank Condello wrote:
>
>> On 11-May-05, at 2:56 PM, Lars Jensen wrote:
>>
>>>>> Quesa has improved substantially between RB major releases.
>>>>
>>>> Really, I can think of none, really.
>>>
>>> Here are the ones I have been able to take advantage of between RB
>>> releases:
>>>
>>> - 32-bit depth buffer
>>> - object picking from mouseXY on Windows
>>> - performance improvements
>>> - [there's another one, but I'm blanking on it]
>>
>> These come to mind:
>>
>> - Automatic Texture Mipmapping
>> - Texture Filtering
>> - Texture & Colour Blending
>> - Improved Transparency Sorting
>
> But many of these are not accessible (right now) through the RB API.
> That's what needs to change.

They're are all automatic - Check out the texture filtering/mipmapping
(or lack thereof) in an old version of Quesa (pre 1.6d16 or so) vs. the
latest release. The colour blending is implemented in 3DMF models, so
as long as your modeller supports it, you can use it - same with
transparency.

Frank.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:09 (Wed, 11 May 2005 15:09:05 -0400)
From: Lars Jensen
It seems to me that this discussion is missing a description of the target
RS is trying to hit with its 3D offering. I can think of these markets:

- High-end: big teams, big budgets -- the next Unreal

- Low-end: Small teams and solo devs -- "oddball" (in the affectionate
sense) titles like A-OK that might or might not be commercial, and might not
require state of the art performance and rendering

- Non-game: CADD, election-results graphics, etc.

I think of RB as "we do the stuff that's too much work for you to do
yourself" (not just in 3D -- also in things like cross-platform, app
bundling, etc.) This (along with its weak support for team development at
present) tends to make it a natural fit in the "low-end" space.

If that's where RS is aiming, I think RB has far more to gain from a nice
dynamics engine than from 3D improvements. Despite big avenues for potential
improvement, graphics and sound are already well represented. But dynamics
are still a huge stumbling block for many of the people that would like to
be using a tool like RB to develop games and other 3D stuff.

Or have I got it all wrong?

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:32 (Wed, 11 May 2005 15:32:50 -0400)
From: Joseph Nastasi

On May 11, 2005, at 3:09 PM, Lars Jensen wrote:

> It seems to me that this discussion is missing a description of the
> target
> RS is trying to hit with its 3D offering. I can think of these markets:
>
> - High-end: big teams, big budgets -- the next Unreal

Not really a market for them. However, as a tool to product proof of
concept pieces it could be useful in this market. It's always a real
good idea to not prototype in the same language/tool you plan to do the
final in so that you start fresh and don't inherit quick and dirty
code.

> - Low-end: Small teams and solo devs -- "oddball" (in the affectionate
> sense) titles like A-OK that might or might not be commercial, and
> might not
> require state of the art performance and rendering

A-OK! WoM did require it. And it got slammed for its antique 3D
graphics. I couldn't get it at the time (still can't). Hell, RB3D did
not even have boundary detection or the ability to tell me if an object
was in the field of view or not. But it still sold because it was more
than just 3D effects. Most really good games are. If I took the "I'll
build an engine myself" approach, I would not have released anything.

> If that's where RS is aiming, I think RB has far more to gain from a
> nice
> dynamics engine than from 3D improvements. Despite big avenues for
> potential
> improvement, graphics and sound are already well represented.

No. The RB3D has miles to go before it sleeps! You can't even change
the pitch of a sound for doppler effects. No, the basics need to be
taken up a huge notch, IMHO before we get to the sexy stuff like
dynamics.

RE: Alternate 3D
Date: 11.05.05 17:20 (Wed, 11 May 2005 09:20:52 -0700)
From: Lynn Fredricks
> I've looked at all of the declares, alternate plugins, etc.
> that have come over the wire in the last few years. Just to
> level set everyone, I come from a time when RB had no 3D API.
> My problem with all of these ventures, is not with any
> technical shortcomings, but with long term support and
> longevity. I am definitely not suggesting that Frank or Asher
> stop developing their frameworks. But as someone who is
> relying on a 3D API for $$$ (and that is where the main focus
> of my income is going), I get real nervous at the thought of
> betting on someone's part time development effort.
>
> No one would like to drop kick Quesa across the universe more than I.
> No slight to Dair and the Quesa crew (including our own
> rhythmically-excitable Joe Strout :-), but I've dealt with
> too many issues over the years. While Asher's work is very
> impressive (I saw demos at REALworld and Geoff Perlman
> certainly was interested enough to look investigate it
> further), it's not and will not be nearly ready as a full
> drop in replacement anytime soon.

There is a "chasm" problem in RB Games. There are many, many 3D solutions
out there for other environments, many of which cost very little for what
you get. But what you get is no promises. That's why the big boys like
NDL/Gamebryo cost so much. So not only does tech have to be good, it has to
be well supported.

The game situation is of great interest to me as Proactive has been fairly
active in games, both in solutions through our Meshbox division
(http://www.meshbox.com), in distribution and venture capital raising.

There were no advocates stronger for RB3D/Quesa than Joe S. and myself, but
I have to admit that Ive been somewhat discouraged by the pace of Quesa
improvements. One thing (from a business standpoint) that Quesa has going
for it is that its core development is not dependent on REALbasic alone. If
that were the case, then the maximum amount of interest generated would be
the maximum number of game developers using REALbasic.

As a comparision, despite the SQLite announcement, Valentina for REALbasic
is doing extremely well (and will continue to do well). But, if the
REALbasic version were the only one available, it would be tough indeed to
support a business. So there are versions for Director, C++, .COM, and more,
and Ill tell you, having a REALbasic version has brought developers from
those camps over to REALbasic.

What Im trying to say is, a good replacement for RB3D/Quesa is a system
that:

1. Isnt dependent on REALbasic only for its core technical success (like
Quesa), but leverages RB's ease of use.

2. Has ore technology leverages desirable 3D technologies on targeted
platforms; desireable to support DirectX to capture the Windows market.

3. Built on a business model that leverages RB's strengths but can also be
deployable on other platforms so that the business can generate enough
revenue to support the support Joe N. and others need for it to be viable.

4. Expect that costs can scale up over time. Early adopters now probably
wont pay for a $1,000 plugin, but once they generate revenue from their
games, they should be able to afford that.

Best regards,

Lynn Fredricks
President
Proactive International, LLC

- Because it is about who you know.(tm)


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 17:52 (Wed, 11 May 2005 12:52:51 -0400)
From: Joseph Nastasi

On May 11, 2005, at 12:20 PM, Lynn Fredricks wrote:
> . That's why the big boys like
> NDL/Gamebryo cost so much. So not only does tech have to be good, it
> has to
> be well supported.

Amen to that.

> There were no advocates stronger for RB3D/Quesa than Joe S. and
> myself, but
> I have to admit that Ive been somewhat discouraged by the pace of Quesa
> improvements. One thing (from a business standpoint) that Quesa has
> going
> for it is that its core development is not dependent on REALbasic
> alone. If
> that were the case, then the maximum amount of interest generated
> would be
> the maximum number of game developers using REALbasic.

Let's face it, the only real reason for Quesa's existence IS REALbasic.
I know a handful of other programs might use it directly, but it's
really the RB3D API that give it a reason to live.

> What Im trying to say is, a good replacement for RB3D/Quesa is a system
> that:
>
> 1. Isnt dependent on REALbasic only for its core technical success
> (like
> Quesa), but leverages RB's ease of use.

Agreed.

> 2. Has ore technology leverages desirable 3D technologies on targeted
> platforms; desireable to support DirectX to capture the Windows market.

Direct X is very, very desirable, but not absolutely necessary. OpenGL
is a lot easier to sell than Quesa/OpenGL. That's why having Quesa as a
internally linked RB library is a good idea. And really, if RB3D is
used more, it IS possible (although not proven) for Quesa to drive
Direct X.

You cannot just support Direct X and blow out the Mac OS market,
though. I just won't work because there's still a large education and
scientific market that could use 3D based applications that are still
on Mac.

> 3. Built on a business model that leverages RB's strengths but can
> also be deployable on other platforms

> 4. Expect that costs can scale up over time. Early adopters now
> probably wont pay for a $1,000 plugin, but once they generate revenue
> from their games, they should be able to afford that.

Watch how fast I pay $1000 for the above wish list! :-)

Here's the problem: What great collection of minds amongst us is going
to build, market and support this great idea?
From where I'm sitting, there is nothing on the horizon, nothing.
Therefore, as much as I love this ideal vision, I'm unfortunately stuck
with reality.

So that's why I go back to getting RS to improve what they already have.

RE: Alternate 3D
Date: 11.05.05 18:17 (Wed, 11 May 2005 10:17:18 -0700)
From: Lynn Fredricks
> Let's face it, the only real reason for Quesa's existence IS
> REALbasic.
> I know a handful of other programs might use it directly, but
> it's really the RB3D API that give it a reason to live.

I haven't made any effort to find out what others are doing with it. It
existed before RB3D, certainly. I think Quesa being a part of RB3D is the
most validation its gotten.

> > 2. Has ore technology leverages desirable 3D technologies
> on targeted
> > platforms; desireable to support DirectX to capture the
> Windows market.
>
> Direct X is very, very desirable, but not absolutely
> necessary. OpenGL is a lot easier to sell than Quesa/OpenGL.
> That's why having Quesa as a internally linked RB library is
> a good idea. And really, if RB3D is used more, it IS possible
> (although not proven) for Quesa to drive Direct X.

Functionally, OpenGL can do it. But from a marketing standpoint, DirectX has
massive mindshare, and that impacts all levels of adoption, from the actual
developer up through top management. There are some significant champions
for OpenGL based gaming, but it's the weight of the industry.

> You cannot just support Direct X and blow out the Mac OS
> market, though. I just won't work because there's still a
> large education and scientific market that could use 3D based
> applications that are still on Mac.

Right, I understand that. Ideally, to have both would be best.

> > 3. Built on a business model that leverages RB's strengths but can
> > also be deployable on other platforms
>
> > 4. Expect that costs can scale up over time. Early adopters now
> > probably wont pay for a $1,000 plugin, but once they
> generate revenue
> > from their games, they should be able to afford that.
>
> Watch how fast I pay $1000 for the above wish list! :-)

Perspective is much different when its part of the lifeblood ;-)

> Here's the problem: What great collection of minds amongst us
> is going to build, market and support this great idea?
> From where I'm sitting, there is nothing on the horizon, nothing.
> Therefore, as much as I love this ideal vision, I'm
> unfortunately stuck with reality.
>
> So that's why I go back to getting RS to improve what they
> already have.

That's understandable.

Much as its maligned in this country, I do have access to some very
reasonably priced developers overseas with 3D game experience. For me, it's
a matter of how thin I can stretch my own internal resources (too many
operations Im involved in still require my brain or secret sauce). Ive been
evaluating several technologies for some level of integration with REALbasic
-- a high level of integration of course would require REAL signing off on
it. Nothing is solid yet, which is why Im cool about talking about such
things openly. Id like to see anyone come up with a good solution.

I don't have any answers yet either; but this isnt something Im ignoring.
Id like to faciliate some sort of good solution.

Best regards,

Lynn Fredricks
President
Proactive International, LLC

- Because it is about who you know.(tm)

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:16 (Wed, 11 May 2005 15:16:28 -0400)
From: Frank Condello
On 11-May-05, at 12:52 PM, Joseph Nastasi wrote:

> Let's face it, the only real reason for Quesa's existence IS
> REALbasic. I know a handful of other programs might use it directly,
> but it's really the RB3D API that give it a reason to live.

Actually, it's that handful of other apps that has kept Quesa above
water for months. Those are the devs most active on the Quesa CVS, and
the guys actually packaging releases (Quesa 1.7 just came out BTW).

>> 2. Has ore technology leverages desirable 3D technologies on targeted
>> platforms; desireable to support DirectX to capture the Windows
>> market.
>
> Direct X is very, very desirable, but not absolutely necessary.

I'll have to totally disagree with you there. Much of the casual PC
game market consists of machines with "on board" graphics, very few of
which support OpenGL out of the box. Lane Roathe (Ideas From the Deep)
who publishes several older Pangea games on the PC that rely on Quesa,
has been very vocal on the topic of Quesa's lack of D3D support - the
bulk of his customer support for those games is dealing with people who
don't have OpenGL installed. He actually hired someone to implement a
D3D renderer for Quesa, but they gave up after a couple of weeks - that
was a tad discouraging...

>> 4. Expect that costs can scale up over time. Early adopters now
>> probably wont pay for a $1,000 plugin, but once they generate revenue
>> from their games, they should be able to afford that.
>
> Watch how fast I pay $1000 for the above wish list! :-)
>
> Here's the problem: What great collection of minds amongst us is going
> to build, market and support this great idea?
> From where I'm sitting, there is nothing on the horizon, nothing.
> Therefore, as much as I love this ideal vision, I'm unfortunately
> stuck with reality.
>
> So that's why I go back to getting RS to improve what they already
> have.

RS is finally coming around, but I have to believe that the fact people
are choosing to implement their own 3D system instead of using RB3D is
forcing them to rethink their 3D API. I don't see any of these 3rd
party 3D projects to be a waste of time or resources, the more the
better if ya ask me!

Frank.
------------------------------------
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 21:02 (Wed, 11 May 2005 16:02:00 -0400)
From: Joseph Nastasi

On May 11, 2005, at 3:16 PM, Frank Condello wrote:
>> .
>> Direct X is very, very desirable, but not absolutely necessary.
>
> I'll have to totally disagree with you there.
> Much of the casual PC game market consists of machines with "on board"
> graphics, very few of which support OpenGL out of the box. Lane Roathe
> (Ideas From the Deep) who publishes several older Pangea games on the
> PC that rely on Quesa, has been very vocal on the topic of Quesa's
> lack of D3D support - the bulk of his customer support for those games
> is dealing with people who don't have OpenGL installed.

A smart installer would lower the instances of that problem. You could
install OpenGL for the customer if it's not there.

> He actually hired someone to implement a D3D renderer for Quesa, but
> they gave up after a couple of weeks - that was a tad discouraging...

Yeah, well I'm having problems with someone I hired as well...

> RS is finally coming around, but I have to believe that the fact
> people are choosing to implement their own 3D system instead of using
> RB3D is forcing them to rethink their 3D API.

Well, I think that has been a bit of factor, but not the only one.

> I don't see any of these 3rd party 3D projects to be a waste of time
> or resources, the more the better if ya ask me!

My point was that very few are developing games to completion and
commercial release, and the reason I keep hearing is that RB3D/Quesa is
stopping development. I think the real reason has more to do with
wanting to build engine technology because it's cool. And it _is_ cool
and even helpful.

BUT I STILL AIN'T SEEING ANY PRODUCTS!!!!!!!!!

Lynn and I can't be the only capitalists on this list!
:-)

Re: Alternate 3D
Date: 11.05.05 21:08 (Wed, 11 May 2005 15:08:18 -0500)
From: Joseph J. Strout
At 4:02 PM -0400 5/11/05, Joseph Nastasi wrote:

>A smart installer would lower the instances of that problem. You
>could install OpenGL for the customer if it's not there.

That's much harder than it sounds. There is an astounding array of
video cards in the PC world, and generally the drivers have to come
directly from the vendor. I don't think it would be practical to
include all those drivers in your installer, though perhaps you could
cover the few most common ones.

I think the standard practice is to assume that the end-user has
already downloaded and installed the appropriate drivers. That will
generally be true for any serious PC gamer, though probably not for
casual or nontraditional gamers.

>My point was that very few are developing games to completion and
>commercial release, and the reason I keep hearing is that RB3D/Quesa
>is stopping development. I think the real reason has more to do with
>wanting to build engine technology because it's cool. And it _is_
>cool and even helpful.

I think the other reason is that finishing a game is much harder than
starting one (or even building engine technology, which is very
similar to starting a game).

Unfortunately, a shiny new engine wouldn't change that -- it would
just remove (or modify) a convenient excuse. :)

Best,
- Joe

Re: Alternate 3D
Date: 12.05.05 07:22 (Thu, 12 May 2005 02:22:50 -0400)
From: Lars Jensen
> I think the other reason is that finishing a game is much harder than starting
> one...Unfortunately, a shiny new engine wouldn't change that -- it would just
> remove (or modify) a convenient excuse. :)

What kind of engine are you thinking about? I specifically mentioned a
dynamics engine because I know for a fact it is stopping at least one
developer (can you guess who?) from making progress on a game or two. It's a
big, difficult piece of work that I expect most RB'ers who want to make
games aren't ready to tackle. Including kinematics, it's the biggest piece
of the 3D gaming puzzle that's not available to the RB coder, to my
knowledge, even as a commercial product.

> I think I threw in my 2c earlier on this one... Who can afford to
> develop a game engine without an expected return? I think we have now
> what the market can afford.

Again, it depends on what you mean by "engine", but I suspect that this
crowd is capable of putting together a fairly kick-*ss open source gamedev
system. We're just not very well coordinated, and there's the question of
whether there's enough overlap in what we all want to make it worth the
inevitable compromises. (Not to mention the question of whether anyone
actually wants to use it -- or will they say "Wow, this thing rocks! But a
game is still too much work, see ya...")

> But many of these [Quesa features] are not accessible (right now) through the
> RB API. That's what needs to change.

Why? Frank said they were automatic, and for the other stuff you mentioned,
Declares are easy enough to deal with. Why are these an obstacle to your
business?

> Let's just say that some of this has been indicated to RS in a very
> specific and detailed manner. They know what it needs.

Hmm, well play it close to the vest if you like, but I would think you'd
want to rally support.

> I would want them only to include "blessed" Quesa releases.

Ay caramba, you _do_ want things to happen slowly!

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 12.05.05 13:13 (Thu, 12 May 2005 08:13:56 -0400)
From: Joseph Nastasi

On May 12, 2005, at 2:22 AM, Lars Jensen wrote:

>> I think the other reason is that finishing a game is much harder than
>> starting
>> one...Unfortunately, a shiny new engine wouldn't change that -- it
>> would just
>> remove (or modify) a convenient excuse. :)
>
> What kind of engine are you thinking about? I

Anything. Who is going to develop a complete and supported dynamics
engine for free?

>
>> I think I threw in my 2c earlier on this one... Who can afford to
>> develop a game engine without an expected return? I think we have now
>> what the market can afford.
>
> Again, it depends on what you mean by "engine", but I suspect that
> this crowd is capable of putting together a fairly kick-*ss open
> source gamedev system. We're just not very well coordinated,

And that is why most internet-born ideas fail. There is certainly an
over abundance of technical expertise actively participating in this
group. There may be more out there, lurking. But without a solid
consensus and commitment, it will never happen.

> and there's the question of whether there's enough overlap in what we
> all want to make it worth theinevitable compromises.

The work involved in hammering out a specification for what any library
needs to do take a lot of time and a lot of compromise. My experience
has shown me that very little newsgroup-born ideas come to the final
fruition of a released product or application. Not just with software,
I've seen it in robotics groups, electronics groups. Actually the only
type of group that ever created and finished projects started on the
internet were high power rocketry projects. Must be the "right stuff"
attitude. :-)

Now, this group is very valuable for many, many reasons.

> or will they say "Wow, this thing rocks! But a game is still too much
> work, see ya...")

The #1 reason games don't get completed. And that is one ANY platform
or system you care to examine. And that is very rarely admitted. The
idea just dies.

>
>> But many of these [Quesa features] are not accessible (right now)
>> through the RB API. That's what needs to change.
>
> Why? Frank said they were automatic, and for the other stuff you
> mentioned, Declares are easy enough to deal with. Why are these an
> obstacle to your business?

Declares are an stop gap measure when the RB API has holes in it. Once
RS made the decision to create the RB3D API, I have full expectation
that, over time, I can use THAT to access the features I need. Not an
adhoc set calls that force me to think about things that the API is
designed to hide. People think using declares are easy because, They
don't have to deal with the 10,000 other things an application has to
do. Why? Because they are busy playing with declares and creating their
own engine and frameworks. Instead, they should be pushing RS to
provide a fully featured 3D API that covers all the basics. Right now
it's got a lot of silly and not-so-silly holes that I have to work
around. And when the fixes do come a year from now, I have to
re-engineer in order to keep current with the system I am invested in.
In my opinion, I've earned the right to push RS into doing this
because:
1. I understand their business issues
2. I'm reasonable.
3. I've delivered product EVEN with glaring holes missing in the API.

If more developers had #3 under their belt, there would be more reason
for RS to improve the API.

>> Let's just say that some of this has been indicated to RS in a very
>> specific and detailed manner. They know what it needs.
>
> Hmm, well play it close to the vest if you like, but I would think
> you'd want to rally support.

There's nothing being kept close to the vest. It's just that I've laid
out exactly what I feel is needed. What they do with it is up to them.

As far a "rallying support", who do I need rallying support from? The
support I need is from RS and despite some feet dragging, they provide
that.
Support for the API from other developers? Anyone who understands the
business end of this and wants to create completed products using 3D
and RB, understands that improving the current API is the only way to
go. If someone is using doing this as a hobby or for educational
purposes, great.

>> I would want them only to include "blessed" Quesa releases.
>
> Ay caramba, you _do_ want things to happen slowly!

No, I just have been cut too many times dancing on the bleeding edge.
Pagena (sp?) release several very successful games using QD3D and then
Quesa. My kids own and still play all of them. On OS X. They are not
bleeding edge graphic-wise, but are really fun games that are
professionally done. So, there really is not any major item that does
not work in Quesa that prevents the successful development of a
successful game. A blessed release once a year would be fine. Once RS
has developed the RB3D API more fully, they might consider helping to
accelerate Quesa development. Or take it in-house. But not if I'm the
only one using it.

I stand behind my earlier comments that the lack of fully developed
games has everything to do with lack of determination and resolve than
anything else.

Re: Alternate 3D
Date: 11.05.05 21:20 (Wed, 11 May 2005 16:20:19 -0400)
From: Joseph Nastasi

On May 11, 2005, at 4:08 PM, Joseph J. Strout wrote:
> I think the standard practice is to assume that the end-user has
> already downloaded and installed the appropriate drivers. That will
> generally be true for any serious PC gamer, though probably not for
> casual or nontraditional gamers.

Yeah, that is true.

It worked for A-OK! WoM for the Windows beta. Most of them we're not
gamers. BUT, they did have a highly specialized application that they
desperately wanted to try and that pushed them into installing it.
Causal gamers are indeed less likely to do so.

>> My point was that very few are developing games to completion and
>> commercial release, and the reason I keep hearing is that RB3D/Quesa
>> is stopping development. I think the real reason has more to do with
>> wanting to build engine technology because it's cool. And it _is_
>> cool and even helpful.
>
> I think the other reason is that finishing a game is much harder than
> starting one (or even building engine technology, which is very
> similar to starting a game).
>
> Unfortunately, a shiny new engine wouldn't change that -- it would
> just remove (or modify) a convenient excuse. :)

Bingo.

Re: Alternate 3D
Date: 11.05.05 22:03 (Wed, 11 May 2005 17:03:28 -0400)
From: Frank Condello
On 11-May-05, at 4:02 PM, Joseph Nastasi wrote:

> Lynn and I can't be the only capitalists on this list!
> :-)

Actually, that probably has a lot to do with it - many of us are
hobbyists, so "coolness" outweighs sales figures.

Frank.
------------------------------------
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 19:50 (Wed, 11 May 2005 14:50:51 -0400)
From: Frank Condello
On 11-May-05, at 10:45 AM, Joseph Nastasi wrote:

> <soapbox>
> ... I get real nervous at the thought of betting on someone's part
> time development effort.

That's understandable, and that's the main reason all my stuff is open
source. I rely on RB for income as well (not the 3D aspects however) so
I'm just as weary of third party additions. However, I use open source
classes & plugins without a second thought - if an opensource plugin
breaks and the author drops off the face of the planet, chances are
good that I or someone else can fix it.

> No one would like to drop kick Quesa across the universe more than I.
> No slight to Dair...

Well, Dair dropped kicked it months ago - he's officially no longer
developing Quesa.

> The reason I mention this is that no matter what great alternate
> solution anyone comes up with, it is now extremely unlikely that it
> will be able to compete with the internal RB3D API. It might be
> technically better in performance and features, but the momentum is
> clearly and irreversibly towards RB3D. It's a business fact of life.

That's fine with me - I'm developing this stuff for selfish reasons,
and if no one else likes it, well then tough beans :)

I'm all for better built-in 3D support, and that's why the Quesa
Wrappers exist - they were designed specifically to augment RB3D, not
replace it. Unfortunately some of the coolest stuff I came up with
won't see the light of day because published Quesa API's aren't working
as advertised.

> So, the smart thing to do is to continue with the bug/feature reports
> and individually push RS for continued improvement for the
> system_in_place.

I've logged many RB3D and Quesa bugs (and fixed a few as well).
Incidentally, if I hadn't created the Quesa Wrappers, I wouldn't have
found half those bugs.

> But the REALLY, REALLY smart thing to do is to develop games and
> applications that use RB3D. Finish them, ...

Here's my problem - I _am_ developing games, but I can't finish them
because of bugs and limitations inside Quesa. I'd probably have an RB
game released by now if I didn't spend so much time hunting down Quesa
bugs... :/

> I guess I am asking folks to not re-invent the wheel. Make RS improve
> the wheel and build some really hot cars with it.

RS has not (until very recently) shown much interest in improving it's
wheel (although Joe certainly has, and may finally be getting through
to the rest of the crew). I don't want to re-invent the wheel, but I
need a wheel that doesn't go flat when you throw something unexpected
at it. If that means building something new from scratch then so be it.

Frank.
------------------------------------
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:18 (Wed, 11 May 2005 15:18:57 -0400)
From: Joseph Nastasi

On May 11, 2005, at 2:50 PM, Frank Condello wrote:
> if an opensource plugin breaks and the author drops off the face of
> the planet, chances are good that I or someone else can fix it.

As far as me fixing it, my application is too complicated for me to fix
a third party tool. That's why I need to know that it is supported.
"Someone else" is too nebulous for me. Again, mostly because it's
impossible (right now) for me and my partner to cover everything.
>
>> No one would like to drop kick Quesa across the universe more than I.
>> No slight to Dair...
>
> Well, Dair dropped kicked it months ago - he's officially no longer
> developing Quesa.

Holy cow, didn't realize that. Who the heck is left? Other than Joe. :-)

>> The reason I mention this is that no matter what great alternate
>> solution anyone comes up with, it is now extremely unlikely that it
>> will be able to compete with the internal RB3D API. It might be
>> technically better in performance and features, but the momentum is
>> clearly and irreversibly towards RB3D. It's a business fact of life.
>
> That's fine with me - I'm developing this stuff for selfish reasons,
> and if no one else likes it, well then tough beans :)

Which makes a lot of sense. It's not a question of liking it, though.
I'm looking at it from the context of improving the RB 3D environment
in a way that is most likely to happen: improving the status quo, not
starting over from the RS perspective.

>
> I'm all for better built-in 3D support, and that's why the Quesa
> Wrappers exist - they were designed specifically to augment RB3D, not
> replace it. Unfortunately some of the coolest stuff I came up with
> won't see the light of day because published Quesa API's aren't
> working as advertised.
>
>> So, the smart thing to do is to continue with the bug/feature reports
>> and individually push RS for continued improvement for the
>> system_in_place.
>
> I've logged many RB3D and Quesa bugs (and fixed a few as well).
> Incidentally, if I hadn't created the Quesa Wrappers, I wouldn't have
> found half those bugs.

I don't actually want people to stop doing these types of projects, it
just won't really help, in the short term (short = 1-2 years) to get
RB3D to a reasonable place.

>> But the REALLY, REALLY smart thing to do is to develop games and
>> applications that use RB3D. Finish them, ...
>
> Here's my problem - I _am_ developing games, but I can't finish them
> because of bugs and limitations inside Quesa. I'd probably have an RB
> game released by now if I didn't spend so much time hunting down Quesa
> bugs... :/

I have to challenge that. I released A-OK! WoM (on Mac OS 9/X) when
RB3D/Quesa were in much worse shape than they are now. I was very
unhappy with the antiquated look of the 3D graphics. However, that is
not the sum total of a game's worth. The industry would have you
believe that. Some reviewers would have you believe that. Gameplay is
first and if that's good, buyers (real buyers, not the little snots who
bitch on versiontracker.com) will overlook that to a certain extent.
The less stellar the graphics the better the gameplay better be, but
that could be a good thing as it can force the designer(s) to really
look at that aspect first instead of getting obsessed with the 3D
graphics.

> I don't want to re-invent the wheel, but I need a wheel that doesn't
> go flat when you throw something unexpected at it. If that means
> building something new from scratch then so be it.

See, I can't afford to start a tire company. I'll just kick Firestone's
door until the wheel don't go flat. :-) But, it's like the old doctor
joke: if it hurts when you do that, don't do that. If Quesa blows up on
when a developer tries something beyond the basics, is it worth
delaying the entire game because he needs to develop a new engine? Is
the developer's game concept so dependent on the features that Quesa
chokes on that the game won't work? If a game idea is fully thought
out, it can overcome missing or buggy 3d features.

RB3D does a great job as a sprite machine. There's very little in Quesa
that inhibits a developer from using it that way.

I've seen some really interesting demos that use RB3D in the last
couple of years, so I really do not think that Quesa's warts are really
preventing game development in the RB3D community.

Just making it extremely painful and difficult. :-)

Re: Alternate 3D
Date: 11.05.05 20:24 (Wed, 11 May 2005 12:24:41 -0700)
From: Seth Willits
On May 11, 2005, at 11:50 AM, Frank Condello wrote:

>> No one would like to drop kick Quesa across the universe more than
>> I. No slight to Dair...
>
> Well, Dair dropped kicked it months ago - he's officially no longer
> developing Quesa.

That's a big blow. He was the main contributor (asside from starting)
from what I could see.

> Here's my problem - I _am_ developing games, but I can't finish
> them because of bugs and limitations inside Quesa. I'd probably
> have an RB game released by now if I didn't spend so much time
> hunting down Quesa bugs... :/

That says a lot.



Seth Willits
----------------------------------------------------------
Freak Software - http://www.freaksw.com/
ResExcellence - http://www.resexcellence.com/realbasic/
----------------------------------------------------------
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 11.05.05 20:27 (Wed, 11 May 2005 14:27:02 -0500)
From: Joseph J. Strout
At 3:18 PM -0400 5/11/05, Joseph Nastasi wrote:

>>Well, Dair dropped kicked it months ago - he's officially no longer
>>developing Quesa.
>
>Holy cow, didn't realize that. Who the heck is left? Other than Joe. :-)

The whole rest of the steering committee, of which (as Frank
correctly pointed out) I have not been the most active member.

Best,
- Joe

Re: Alternate 3D
Date: 11.05.05 21:02 (Wed, 11 May 2005 16:02:34 -0400)
From: John Balestrieri
I have a 3d framework to that's been in development for some time
which is reasonably easy to use as my SuperSpriteSurface. The problem
is, who is paying any of these framework developer's for their work?
Obviously, most of these projects are not funded. If the interest
were there, the money would be there, and then something would
happen. Just my bitter opinion..

Re: Alternate 3D
Date: 12.05.05 00:08 (Thu, 12 May 2005 09:08:29 +1000)
From: Jay Kyburz
Joseph Nastasi wrote:
> <soapbox>
> I've looked at all of the declares, alternate plugins, etc. that have
> come over the wire in the last few years. Just to level set everyone, I
> </soapbox>

You all need to look at BlitzMax (www.blitzbasic.com).

I traditionally work in blitz and am only here playing with RB because
I'm toying with the idea of developing a cross platform IDE for
BlitzMax. (There is nothing good for the Mac yet)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 06:53 (Fri, 13 May 2005 01:53:17 -0400)
From: Lars Jensen
> You all need to look at BlitzMax (www.blitzbasic.com).

I looked at Blitz3D instead. Besides being cross-platform, what can RB do
that this can't?

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 07:02 (Fri, 13 May 2005 01:02:19 -0500)
From: Dustin Evermore

On May 13, 2005, at 12:53 AM, Lars Jensen wrote:

>> You all need to look at BlitzMax (www.blitzbasic.com).
>>
> I looked at Blitz3D instead. Besides being cross-platform, what can
> RB do
> that this can't?
>
> lj
>

Blitz3D is Windows-only. BlitzMax, which is currently only for Mac,
is only 2D. Blitz does not appear to be an actual cross-platform
development system.

DE
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 07:26 (Fri, 13 May 2005 02:26:23 -0400)
From: Lars Jensen
>> I looked at Blitz3D instead. Besides being cross-platform, what can RB do
>> that this can't?
>
> Blitz3D is Windows-only.

Right...so...what can RB3D do that Blitz3D can't?

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 07:46 (Thu, 12 May 2005 23:46:58 -0700)
From: Seth Willits
On May 12, 2005, at 11:26 PM, Lars Jensen wrote:

> Right...so...what can RB3D do that Blitz3D can't?

Read 3DMF models. :D


Seth Willits
----------------------------------------------------------
Freak Software - http://www.freaksw.com/
ResExcellence - http://www.resexcellence.com/realbasic/
----------------------------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 17:23 (Fri, 13 May 2005 12:23:23 -0400)
From: Joseph Nastasi

On May 13, 2005, at 2:46 AM, Seth Willits wrote:

> On May 12, 2005, at 11:26 PM, Lars Jensen wrote:
>
>> Right...so...what can RB3D do that Blitz3D can't?
>
> Read 3DMF models. :D

It's unfortunately, not too far off...
I looked a Blitz a while ago (years) and, the non Mac issue was a
showstopper because my educational market.
It's not quite, even now, as good language-wise as RB is, IMHO, but
that's about the only negative thing I can say.
It is something that RB3D dreams about being when it grows up. :-)

Re: Alternate 3D
Date: 13.05.05 17:31 (Fri, 13 May 2005 12:31:08 -0400)
From: Lars Jensen
> It is something that RB3D dreams about being when it grows up. :-)

D'oh!

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 08:37 (Sat, 14 May 2005 02:37:36 -0500)
From: Chris Dillman

Business case:

I think there is probably enough data available to justify a business case
for Real to hire a full time engineer to work on game related 3D tech
if they want to get into that market.

I do not have real hard numbers here but
I can point out some starting places one might look.

1. I do not think the Mac can justify a game engineer.
I do think if anything Windows might be able to.

2. On Windows there exists both a high end and low end for game
development tools. At the low end we have a number of products that
cost around 100$

Most of these companies are small but have been in business for years
making game only IDEs not general purpose IDEs like RB.

If these smaller companies can make a living making game only IDEs.
Then Im thinking that REAL could probably make a business case for hiring
one full time game and 3D engineer if they wanted to enter this market.

http://www.blitzbasic.com/
Take a look at the screen shots of games made with it.

http://darkbasic.thegamecreators.com/
This is interpreted basic.

http://www.conitec.net/a4info.htm
Game only IDE + scripting like javascript.
Check out the number of in store games that have been made with it.

Torque 2D http://www.garagegames.com/products/62
High speed script driven games.

3. On the high end we have tools costing from like
1000$ or 3000$ on up to 8000$ a pop.
These would be called pro tools.
Used for simulations etc.

http://www.anark.com/
Just left the mac as of version 3.0.
Seems they could not justify the engineers :(
With 3.0 they raised there price to like 3000$
And with that Im told they suddenly got many more sales.
They were taken more seriously in business markets it seems.

CosmosCreator $2495
http://www.radishworks.com/CosmosCreatorInfo.htm

Deep creator from http://www.righthemisphere.com/
BTW this link does not work in safari in 10.3 for me at all.
This i think they might have just bought a number of tools
like radish above.

http://www.virtools.com/
5000$???
Actually runs on Mac or builds apps for mac.

http://www.quest3d.com/
Looks neat.
900$

4. Here is a list of most of the tools and prices out these from the A6 FAQ.
http://www.conitec.net/a4faq.htm

Re: Alternate 3D
Date: 14.05.05 09:18 (Sat, 14 May 2005 04:18:51 -0400)
From: Frank Condello
On 14-May-05, at 3:37 AM, Chris Dillman wrote:

> Business case:
> ...

Oddly you mention Torque 2D but not the original (3D) Torque (?) You
also left out the uber-high-end: Renderware, Unreal, Quake/Doom,
Source, LithTech (or whatever they call it now) but I'll forgive you
for that, 'cause most small countries can't afford those licenses....

Personally I'm looking forward to trying out Unity: <http://otee.dk/>

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 09:36 (Sat, 14 May 2005 01:36:42 -0700)
From: Seth Willits
On May 14, 2005, at 1:18 AM, Frank Condello wrote:

> Oddly you mention Torque 2D but not the original (3D) Torque (?)

Torque 2D was mainly written in one developer's spare time over 9
months, and is built on top of the TGE (Torque 3D) code base. The
adoption of T2D while still in the early adopter phase is astounding,
and the number of TGE owners is equaly as amazing. Torque has a good
range of developers attracted to it because of its low price (and
thus mass appeal to little guys) and its capabilities and future
direction (appeal to the bigger guys).

I'm with Chris in thinking if RS wanted to, they could expand into
that market by adding on another developer. Whether there are
immediate benefits from that making it worth while at this point
time, I don't know.



Seth Willits
----------------------------------------------------------
Freak Software - http://www.freaksw.com/
ResExcellence - http://www.resexcellence.com/realbasic/
----------------------------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 19:46 (Sat, 14 May 2005 14:46:44 -0400)
From: Frank Condello
On 14-May-05, at 4:36 AM, Seth Willits wrote:

> On May 14, 2005, at 1:18 AM, Frank Condello wrote:
>
>> Oddly you mention Torque 2D but not the original (3D) Torque (?)
>
> Torque 2D was mainly written in one developer's spare time over 9
> months, and is built on top of the TGE (Torque 3D) code base. The
> adoption of T2D while still in the early adopter phase is
> astounding, and the number of TGE owners is equaly as amazing.
> Torque has a good range of developers attracted to it because of
> its low price (and thus mass appeal to little guys) and its
> capabilities and future direction (appeal to the bigger guys).

Yes, I know... I just found it odd that Chris mentioned Torque 2D
without mentioning plain old Torque Engine. Although Torque 2D is
based on Torque Engine, they are completely separate products.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 20:09 (Sat, 14 May 2005 14:09:51 -0500)
From: Chris Dillman
>On 14-May-05, at 3:37 AM, Chris Dillman wrote:
>
>>Business case:
>>...
>
>Oddly you mention Torque 2D but not the original (3D) Torque (?)

Well it was 3 am ;)

Actually I left and Torque for a reason.
I was trying to only list the high level tools and IDEs that
might be worth looking at.

Torque 3D and 2D have "ISSUES"
I own licenses to both.

Torque is not and IDE and unfortunately if you are a not a C++ coder
you can probably never ship anything it it.
The engines ship broken and a need a bunch of patching on Mac at least
to even get sound working.

> You also left out the uber-high-end: Renderware, Unreal,
>Quake/Doom, Source, LithTech (or whatever they call it now) but I'll
>forgive you for that, 'cause most small countries can't afford those
>licenses....

I don't think any of those fit in my list cause they are rendering Engins
and not tools or IDES etc.

Nothing Like RB

>

>Personally I'm looking forward to trying out Unity: <http://otee.dk/>

Opps I forgot that one.

BTW Booth Unity and Torque will be WWDC this year for anyone going.
I will be there.

Re: Alternate 3D
Date: 14.05.05 20:17 (Sat, 14 May 2005 14:17:56 -0500)
From: Chris Dillman
>On 14-May-05, at 3:37 AM, Chris Dillman wrote:
>
>>Business case:
>>...
>
>Oddly you mention Torque 2D but not the original (3D) Torque (?) You
>also left out the uber-high-end: Renderware, Unreal, Quake/Doom,
>Source, LithTech (or whatever they call it now) but I'll forgive you
>for that, 'cause most small countries can't afford those licenses....
>
Personally I'm looking forward to trying out Unity: <http://otee.dk/>

I forgot.
Torque 2D seems like the first version of Torque that shows promise of
non C++ coders being able to fairly easily ship real applications.
Just using scripts.

Re: Alternate 3D
Date: 14.05.05 20:39 (Sat, 14 May 2005 14:39:12 -0500)
From: Chris Dillman
>On 14-May-05, at 4:36 AM, Seth Willits wrote:
>
>>On May 14, 2005, at 1:18 AM, Frank Condello wrote:
>>
>>>Oddly you mention Torque 2D but not the original (3D) Torque (?)
>>
>>Torque 2D was mainly written in one developer's spare time over 9
>>months, and is built on top of the TGE (Torque 3D) code base. The
>>adoption of T2D while still in the early adopter phase is
>>astounding, and the number of TGE owners is equaly as amazing.
>>Torque has a good range of developers attracted to it because of
>>its low price (and thus mass appeal to little guys) and its
>>capabilities and future direction (appeal to the bigger guys).
>
>Yes, I know... I just found it odd that Chris mentioned Torque 2D
>without mentioning plain old Torque Engine. Although Torque 2D is
>based on Torque Engine, they are completely separate products.

As far as I can tell.
When you buy T2D you get the full T3D engine.
BUT its missing some scripts and also all the demos and example 3D
script projects.

But I THINK one could use it for 3D also.

Re: Alternate 3D
Date: 14.05.05 21:06 (Sat, 14 May 2005 15:06:49 -0500)
From: Chris Dillman

I had a thought.

Thinking about the cross plat form object frameworks I have seen.
Most of them support Open GL.
They do this by simply providing a simple Canvas object.

REAL could have done this a long time ago for both Open GL and D3D
and it would have painlessly been there for anyone who wanted that
level of control.

What I mean is using some kind of auto code generation tool or script
REAL can generate all the bindings to current versions of the APIs.
Thus it would take very little engineering support from reals side to open
up low more low level APIs with users having to mess with declares etc.

Another thought.
Under OS-X and maybe windows? DLLs?.

You can dynamically load frameworks and bundles and dylibs.
You can then ask for the address of a function in them.

I wonder if it would be easy and if it would be a good idea to add
something to the RB compiler that would work like this.

LIB gl = LOAD LIB( opengl.framework )

now in all other code I call

gl.glcolor( x, y, z )

What happens there is there is a dynamic look up of the function call
in the library pointed to by gl.

BUT with out any need of declares.
It all happens at runtime.

Or the declears part happens at run time.

Seems like something like that could really simplify the whole process of using
external libs.

Tell me if I missed something?

In the paste I have used basic compilers like zbasic and future basic
and I THINK they could all just call toolbox routines with out declears etc.

So when I needed something it could not do by default say copybits I
just grabbed it.

Re: Alternate 3D
Date: 14.05.05 21:09 (Sat, 14 May 2005 13:09:02 -0700)
From: Seth Willits
On May 14, 2005, at 12:39 PM, Chris Dillman wrote:

> As far as I can tell.
> When you buy T2D you get the full T3D engine.
> BUT its missing some scripts and also all the demos and example 3D
> script projects.
>
> But I THINK one could use it for 3D also.

Wavering off topic here, but much of the TGE functionality is ripped
out. Also, the Unreal engine isn't an IDE, for sure, but one of its
major advantages are the tools/editors that come with it. I'd kill
for those kind of tools :)

/me waits to see what the final version of Renegades turns out to be
like...



Seth Willits
----------------------------------------------------------
Freak Software - http://www.freaksw.com/
ResExcellence - http://www.resexcellence.com/realbasic/
----------------------------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 22:49 (Sat, 14 May 2005 17:49:13 -0400)
From: Frank Condello
On 14-May-05, at 3:09 PM, Chris Dillman wrote:

>> Oddly you mention Torque 2D but not the original (3D) Torque (?)
>>
> Well it was 3 am ;)
>
> Actually I left and Torque for a reason.
> I was trying to only list the high level tools and IDEs that
> might be worth looking at.

That's what I thought at first but I was under the impression you had
to compile Torque 2D yourself, just like Torque 3D (please correct me
if I'm wrong).

> The engines ship broken and a need a bunch of patching on Mac at least
> to even get sound working.

Too true... I was a Mac Torque (3D) beta tester and got a free
license for my troubles, but I've never been able to do a checkout
and just hit "compile" (neither in Codewarrior or Xcode - I don't
even think they've updated their ProjectBuilder project yet). They
_really_ need to fix this, especially since they put so much emphasis
on the Mac market (e.g. they say they will only publish games that
run on Mac OS X, and that Mac versions account for 65% of their game
sales).

>> You also left out the uber-high-end: Renderware, Unreal, Quake/
>> Doom, Source, LithTech (or whatever they call it now) but I'll
>> forgive you for that, 'cause most small countries can't afford
>> those licenses....
>
> I don't think any of those fit in my list cause they are rendering
> Engins
> and not tools or IDES etc.

Some of these tools blur the lines between IDE and middleware (like
Torque) so I wasn't sure what kind of list you were going for. For
example, you don't need to touch the engine source with Quake/DooM/
Unreal - they're all "scripted" (though Quake/DooM basically use real
C/C++). Unreal actually has it's own script editor, so it's actually
more an "IDE" than Torque... Still too expensive though :)

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 22:59 (Sat, 14 May 2005 16:59:00 -0500)
From: Chris Dillman
>On 14-May-05, at 3:09 PM, Chris Dillman wrote:
>
>>>Oddly you mention Torque 2D but not the original (3D) Torque (?)
>>>
>>Well it was 3 am ;)
>>
>>Actually I left and Torque for a reason.
>>I was trying to only list the high level tools and IDEs that
>>might be worth looking at.
>
>That's what I thought at first but I was under the impression you
>had to compile Torque 2D yourself, just like Torque 3D (please
>correct me if I'm wrong).

No its comes with built versions on Mac and I think On Win32
but not on Linux.

So if you get the mac verison you have the mac builds
and you have the code
and you have the make files etc for all the other platforms.

>
>>The engines ship broken and a need a bunch of patching on Mac at least
>>to even get sound working.
>
>Too true... I was a Mac Torque (3D) beta tester and got a free
>license for my troubles, but I've never been able to do a checkout
>and just hit "compile" (neither in Codewarrior or Xcode - I don't
>even think they've updated their ProjectBuilder project yet).

Im using the PB projects in Xcode just fine.
I did not see a CW project and did not want to try and make it work.

>They _really_ need to fix this, especially since they put so much
>emphasis on the Mac market (e.g. they say they will only publish
>games that run on Mac OS X, and that


>Mac versions account for 65% of their game sales).

Wow

>
>>> You also left out the uber-high-end: Renderware, Unreal,
>>>Quake/Doom, Source, LithTech (or whatever they call it now) but
>>>I'll forgive you for that, 'cause most small countries can't
>>>afford those licenses....
>>
>>I don't think any of those fit in my list cause they are rendering Engins
>>and not tools or IDES etc.
>
>Some of these tools blur the lines between IDE and middleware (like
>Torque) so I wasn't sure what kind of list you were going for. For
>example, you don't need to touch the engine source with
>Quake/DooM/Unreal - they're all "scripted" (though Quake/DooM
>basically use real C/C++). Unreal actually has it's own script
>editor, so it's actually more an "IDE" than Torque... Still too
>expensive though :)

:)

Re: Alternate 3D
Date: 15.05.05 02:47 (Sat, 14 May 2005 20:47:33 -0500)
From: Joseph J. Strout
At 3:06 PM -0500 5/14/05, Chris Dillman wrote:

>What I mean is using some kind of auto code generation tool or script
>REAL can generate all the bindings to current versions of the APIs.
>Thus it would take very little engineering support from reals side to open
>up low more low level APIs with users having to mess with declares etc.

SWIG (Simple Wrapper Interface Generator) does this sort of thing,
for other languages -- to my knowledge, no one has bothered to make a
REALbasic module for it. I brought this up a year or two ago, and
there was some interest, but not enough for anyone to actually do
anything about it.

It's a nontrivial thing to do, starting from scratch, because you
basically need a C parser just to get started. But SWIG already
handles that, so it would form a good starting point.

>I wonder if it would be easy and if it would be a good idea to add
>something to the RB compiler that would work like this.
>
>LIB gl = LOAD LIB( opengl.framework )
>
>now in all other code I call
>
>gl.glcolor( x, y, z )
>
>What happens there is there is a dynamic look up of the function
>call in the library pointed to by gl.

I don't think this could be done in a reliable manner -- x, y, and z
aren't generally enough to fully specify the prototype of the
external function. And if we were to guess incorrectly, your app
will go down in flames. So you have to tell us what the function
prototype is. And we already have that functionality -- it's what
the Declare statement does.

Moreover, once you've written a couple of Declare statements, it's
not very hard to write more. If you know enough to correctly make a
call like the above, you know enough to write a Declare and then make
the call.

>In the paste I have used basic compilers like zbasic and future basic
>and I THINK they could all just call toolbox routines with out declears etc.

They probably had built-in wrappers for the toolbox routines you were calling.

Best,
- Joe

Re: Alternate 3D
Date: 15.05.05 03:29 (Sat, 14 May 2005 21:29:52 -0500)
From: Chris Dillman
>At 3:06 PM -0500 5/14/05, Chris Dillman wrote:
>
>>What I mean is using some kind of auto code generation tool or script
>>REAL can generate all the bindings to current versions of the APIs.
>>Thus it would take very little engineering support from reals side to open
>>up low more low level APIs with users having to mess with declares etc.
>
>SWIG (Simple Wrapper Interface Generator) does this sort of thing,
>for other languages -- to my knowledge, no one has bothered to make
>a REALbasic module for it. I brought this up a year or two ago, and
>there was some interest, but not enough for anyone to actually do
>anything about it.

I kind of thought you had a binding app in house for some reason.

>
>It's a nontrivial thing to do, starting from scratch, because you
>basically need a C parser just to get started.

Its actually really easy.
I built one in PHP for C++ in about a week ( at night )

And if you a selective bindings... example your own code but you only want
to bind certain vars or functions you can stick a tag in front of them like

BIND_VAR

or BIND_FUNCTION

and then you just look for the tags you know what will follow.

Some how I think parsers scare a lot of people.

> But SWIG already handles that, so it would form a good starting point.
>
>>I wonder if it would be easy and if it would be a good idea to add
>>something to the RB compiler that would work like this.
>>
>>LIB gl = LOAD LIB( opengl.framework )
>>
>>now in all other code I call
>>
>>gl.glcolor( x, y, z )
>>
>>What happens there is there is a dynamic look up of the function
>>call in the library pointed to by gl.
>
>I don't think this could be done in a reliable manner -- x, y, and z aren't

I meant that x, y, x
would be known by RB cause they would be like vars declared in RB.

integer x, y, z;

Then the function would be called and passed those vars.

>generally enough to fully specify the prototype of the external
>function. And if we were to guess incorrectly, your app will go
>down in flames.

Crashing would be expectable in this case cause it would be up to the
user to input the correct parameters since RB does not really know
what is going on here with out real bindings.

> So you have to tell us what the function prototype is. And we
>already have that functionality -- it's what the Declare statement
>does.

I know... and that is a lot of work by hand.

It not automatic and also ends up with even more wrapper functions
around everything and assume they do not get inlined etc.

What I was suggesting was a more generic interface to all libs.

User beware.

But at least you then have access to everything in the OS no declears needed.

See my point?

>
>Moreover, once you've written a couple of Declare statements, it's
>not very hard to write more. If you know enough to correctly make a
>call like the above, you know enough to write a Declare and then
>make the call.
>
>>In the paste I have used basic compilers like zbasic and future basic
>>and I THINK they could all just call toolbox routines with out declears etc.
>
>They probably had built-in wrappers for the toolbox routines you were calling.

It been years.
Maybe I should ask them.
Or Im sure Mars knows actually?

Re: Alternate 3D
Date: 15.05.05 04:43 (Sat, 14 May 2005 23:43:51 -0400)
From: Asher Dunn

On May 14, 2005, at 4:06 PM, Chris Dillman wrote:

> Thinking about the cross plat form object frameworks I have seen.
> Most of them support Open GL.
> They do this by simply providing a simple Canvas object.
>
> REAL could have done this a long time ago for both Open GL and D3D
> and it would have painlessly been there for anyone who wanted that
> level of control.
>
> What I mean is using some kind of auto code generation tool or script
> REAL can generate all the bindings to current versions of the APIs.
> Thus it would take very little engineering support from reals side to
> open
> up low more low level APIs with users having to mess with declares etc.

<http://www.fireyesoftware.code/opengldeclares/>

Asher Dunn
--------------------------------------------------------
President and Head Developer of Fireye Software
<http://www.fireyesoftware.com/>
AIM and Yahoo: fireye7517

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 04:45 (Sat, 14 May 2005 20:45:51 -0700)
From: Seth Willits
On May 14, 2005, at 8:43 PM, Asher Dunn wrote:

> <http://www.fireyesoftware.code/opengldeclares/>

<http://www.fireyesoftware.com/code/opengldeclares/>

I got your back ;)


Seth Willits
----------------------------------------------------------
Freak Software - http://www.freaksw.com/
ResExcellence - http://www.resexcellence.com/realbasic/
----------------------------------------------------------

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 05:27 (Sat, 14 May 2005 23:27:23 -0500)
From: Chris Dillman
>On May 14, 2005, at 8:43 PM, Asher Dunn wrote:
>
>><http://www.fireyesoftware.code/opengldeclares/>
><http://www.fireyesoftware.com/code/opengldeclares/>
>I got your back ;)

Oh yeah I know I know its out there :)

I was suggesting something different so in the future one would not
have to make
declare libs for other APIs

Re: Alternate 3D
Date: 15.05.05 05:31 (Sun, 15 May 2005 00:31:00 -0400)
From: Asher Dunn

On May 15, 2005, at 12:27 AM, Chris Dillman wrote:

> I was suggesting something different so in the future one would not
> have to make
> declare libs for other APIs

I agree with what you said, I was just pointing out that for OpenGL, a
declare library is already out there.
But man, were those modules a pain to make. Going through header files
*shudder*.

Asher Dunn
--------------------------------------------------------
President and Head Developer of Fireye Software
<http://www.fireyesoftware.com/>
AIM and Yahoo: fireye7517

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 11:56 (Sun, 15 May 2005 11:56:52 +0100)
From: Nick Lockwood
>>> I wonder if it would be easy and if it would be a good idea to add
>>> something to the RB compiler that would work like this.
>>>
>>> LIB gl = LOAD LIB( opengl.framework )
>>>
>>> now in all other code I call
>>>
>>> gl.glcolor( x, y, z )
>>>
>>> What happens there is there is a dynamic look up of the function
>>> call in the library pointed to by gl.
>>
>> I don't think this could be done in a reliable manner -- x, y, and z
>> aren't
>
> I meant that x, y, x
> would be known by RB cause they would be like vars declared in RB.
>
> integer x, y, z;
>
> Then the function would be called and passed those vars.

The problem I see is that numeric constants are ambiguous, so for
example if you said

gl.glcolor(1,2,3)

RB would be unable to tell if it was supposed to pass those values as
integers, singles or doubles.

Even if you pass the values as 1.0, 2.0, 3.0 it is still ambiguous
between double and single, and in any case I think such a requirement
(where writing 1 instead of 1.0 would make a program crash) would be
unacceptable from a usability standpoint.

I very much like the idea in principle though.

Certainly the ability to load arbitrary libraries and functions at
runtime would be a nice addition. Monkeybread offers support for this,
although the interface is a little unwieldy, and could be improved with
some proper syntactical support for this feature in the language.

Maybe something could be done with the operator_lookup feature?

Nick

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 18:39 (Sun, 15 May 2005 12:39:43 -0500)
From: Chris Dillman
>
>The problem I see is that numeric constants are ambiguous, so for
>example if you said
>
>gl.glcolor(1,2,3)
>
>RB would be unable to tell if it was supposed to pass those values
>as integers, singles or doubles.

>Even if you pass the values as 1.0, 2.0, 3.0 it is still ambiguous
>between double and single, and in any case I think such a
>requirement (where writing 1 instead of 1.0 would make a program
>crash) would be unacceptable from a usability standpoint.

Ok I totally see now.

/me dumb :(

>
>I very much like the idea in principle though.
>
>Certainly the ability to load arbitrary libraries and functions at
>runtime would be a nice addition. Monkeybread offers support for
>this, although the interface is a little unwieldy, and could be
>improved with some proper syntactical support for this feature in
>the language.
>
>Maybe something could be done with the operator_lookup feature?

I have not seen that?

Re: Alternate 3D
Date: 13.05.05 17:03 (Fri, 13 May 2005 11:03:04 -0500)
From: Chris Dillman
>On May 13, 2005, at 12:53 AM, Lars Jensen wrote:
>
>>>You all need to look at BlitzMax (www.blitzbasic.com).
>>>
>>I looked at Blitz3D instead. Besides being cross-platform, what can RB do
>>that this can't?
>>
>>lj
>>
>Blitz3D is Windows-only. BlitzMax, which is currently only for Mac,
>is only 2D. Blitz does not appear to be an actual cross-platform
>development system.

BlitzMax replaces Blitz3D
and a completely cross platform.

Im told you can make windows builds right now...
That might be a beta feature Im not sure.

BlitzMax is 3D
as in it give easy access to all of open gl
so you can do ever you want in it.

In the future BlitzMax will feature a full 3D game engine and tools(?)
written in BlitzMax itself.

Re: Alternate 3D
Date: 13.05.05 17:29 (Fri, 13 May 2005 12:29:23 -0400)
From: Lars Jensen
> BlitzMax is 3D as in it give easy access to all of open gl so you can do ever
> you want in it.

I see...it looks (from DL'ing the demo) like BlitzMax gives you a bunch of
cross-platform 2D libraries plus OpenGL access, whereas Blitz3D gives you a
bunch of Windows-only 3D stuff (using D3D) plus 3D libraries.

So BlitzMax is not really a replacement for Blitz3D (otherwise it wouldn't
be $20 less).

But I would still be interested in knowing what RB3D can do that Blitz3D
can't.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 18:37 (Fri, 13 May 2005 12:37:53 -0500)
From: Chris Dillman
> > BlitzMax is 3D as in it give easy access to all of open gl so you
>can do ever
>> you want in it.
>
>I see...it looks (from DL'ing the demo) like BlitzMax gives you a bunch of
>cross-platform 2D libraries plus OpenGL access, whereas Blitz3D gives you a
>bunch of Windows-only 3D stuff (using D3D) plus 3D libraries.
>
>So BlitzMax is not really a replacement for Blitz3D (otherwise it wouldn't
>be $20 less).

You are wrong here.

BlitzMax is the future of the Blitz platform.
It is replacing Blitz 3D.

Pricing most likely reflects that its is not at the point that Blitz3D is at
currently on Windows.

>But I would still be interested in knowing what RB3D can do that Blitz3D
>can't.

Re: Alternate 3D
Date: 13.05.05 20:03 (Fri, 13 May 2005 15:03:40 -0400)
From: Lars Jensen
>> So BlitzMax is not really a replacement for Blitz3D (otherwise it wouldn't
>> be $20 less).
>
> You are wrong here.
>
> BlitzMax is the future of the Blitz platform.
> It is replacing Blitz 3D.

"will replace" and "is a replacement" aren't the same thing.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 07:21 (Sat, 14 May 2005 01:21:57 -0500)
From: Chris Dillman
> >> So BlitzMax is not really a replacement for Blitz3D (otherwise it wouldn't
>>> be $20 less).
>>
>> You are wrong here.
>>
>> BlitzMax is the future of the Blitz platform.
>> It is replacing Blitz 3D.
>
>"will replace" and "is a replacement" aren't the same thing.

Has already.

It has shipped.
It works.
You can make full 3D games in it now.

No more work is being done on Blitz3D.

Im seeing number of very cool beta 3D games done by idevgames members.
Blitz even with its horrible IDE (IMO) seems to be giving people a
much faster leg up then RB does when it comes to games.

Im seeing games with glow maps and bump mapping being done by beginners.

Something odd about Blitz... not sure this is true...
But I was told that it translates basic to C++ and then uses GCC to compile it.

Re: Alternate 3D
Date: 14.05.05 08:01 (Sat, 14 May 2005 03:01:41 -0400)
From: Lars Jensen
> You can make full 3D games in it now.

I DL'ed BlitzMax and saw none of the high-level demos for things like
terrain, dynamics, etc that were in Blitz3D. In terms of 3D, I saw only a
head and a cube. Did I miss them?

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 08:41 (Sat, 14 May 2005 02:41:19 -0500)
From: Chris Dillman
> > You can make full 3D games in it now.
>
>I DL'ed BlitzMax and saw none of the high-level demos for things like
>terrain, dynamics, etc that were in Blitz3D. In terms of 3D, I saw only a
>head and a cube. Did I miss them?

No the demos I have seen has all been private betas.
Not on Blitz site.

Those tools and engine etc are being ported to the new blitzmax.
But this time around they will be written in bltz and you will have access
to all the source code.

I will see if I can find info on the status later this weekend.

Once they have done the engine once it will be easy to do it again.

Re: Alternate 3D
Date: 14.05.05 09:28 (Sat, 14 May 2005 04:28:08 -0400)
From: Frank Condello
On 14-May-05, at 3:01 AM, Lars Jensen wrote:

>> You can make full 3D games in it now.
>
> I DL'ed BlitzMax and saw none of the high-level demos for things like
> terrain, dynamics, etc that were in Blitz3D. In terms of 3D, I saw
> only a
> head and a cube. Did I miss them?

I was under the impression that BlitzMax didn't actually "do" 3D out
of the box, but gives you access to OpenGL API calls, so you can do
it yourself. That doesn't seem much different than using declares in
RB or even C/C++, so I'm not sure I see the point... Plus, the demo
can't seem to actually build anything on my Mac (path errors) and
told me it's expired 5 minutes after I downloaded it :/

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 17:00 (Sat, 14 May 2005 12:00:34 -0400)
From: Lars Jensen
> Plus, the demo can't seem to actually build anything on my Mac (path errors)
> and told me it's expired 5 minutes after I downloaded it :/

Odd...it worked for me (the BlitzMax demo on Mac OS X) with no expiration
hassles.

> It seems that you want all the power and speed, but are not willing to
> sacrifice the simplicity and almost worry-free programming environment of
> REALBasic.

That's about right. (Instead of "all" the power and speed, I'd settle for
95%.) The notion that easy = slow is a myth, it just takes more work to have
a system that's both.

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 15:08 (Sat, 14 May 2005 10:08:56 -0400)
From: Daniel Lurie
Yeah. It uses gcc under the hood to compile. So, you can augment Blitz
with any flavor of C you like.

On May 14, 2005, at 2:21 AM, Chris Dillman wrote:

> Im seeing number of very cool beta 3D games done by idevgames members.
> Blitz even with its horrible IDE (IMO) seems to be giving people a
> much faster leg up then RB does when it comes to games.
>
> Im seeing games with glow maps and bump mapping being done by
> beginners.
>
> Something odd about Blitz... not sure this is true...
> But I was told that it translates basic to C++ and then uses GCC to
> compile it.
>
=DcDkDoDSDDaniel R. Lurie
=GD?DGD?DGDhttp://www.vikingdan.com

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 13.05.05 22:38 (Fri, 13 May 2005 16:38:25 -0500)
From: Dustin Evermore

On May 13, 2005, at 11:03 AM, Chris Dillman wrote:

> BlitzMax replaces Blitz3D
> and a completely cross platform.
>
> Im told you can make windows builds right now...
> That might be a beta feature Im not sure.
>
> BlitzMax is 3D
> as in it give easy access to all of open gl
> so you can do ever you want in it.
>
> In the future BlitzMax will feature a full 3D game engine and tools(?)
> written in BlitzMax itself.

That is interesting -- for the future.

It's just that in the current product description, for the currently
available version, it said 2D only for Mac. To answer another person
who continued to ask what RB3D can do that Blitz can't after my last
reply, I thought it was obvious -- no 3D available for Mac versions
right now.

DE

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 02:54 (Fri, 13 May 2005 21:54:14 -0400)
From: Lars Jensen
> To answer another person who continued to ask what RB3D can do that Blitz
> can't after my last reply, I thought it was obvious -- no 3D available for
> Mac versions right now.

It was indeed obvious -- which is why I began my original question with
"Besides being cross-platform..." ;)

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 06:19 (Fri, 13 May 2005 22:19:44 -0700)
From: Adam Cuipka

I've been peeking at the current diatribe and its driving me nuts. I do
not know why you expect REALBasic to perform with the same efficiency as
environments which use C, C++, Objective-C, or even Java.

Royal You, you, want REALBasic to retain its Beginner's All-Purpose
simplicity, yet be sophisticated enough to contend within the REAL - world
video game market.

Please, I beg you, give me a break. You want to go hard-core, go hard.
Otherwise, ... go REALBasic.

If you want to write the next Great American Novel, start writing.

Adam

Re: Alternate 3D
Date: 14.05.05 07:11 (Sat, 14 May 2005 01:11:40 -0500)
From: Chris Dillman
> I've been peeking at the current diatribe and its driving me nuts. I do
>not know why you expect REALBasic to perform with the same efficiency as
>environments which use C, C++, Objective-C, or even Java.

Yes.
No reason it can not.

RB is a compiler and a set of EASY To use objects.

Java is a compiler and a set of EASY to use objects.

Obj-C / COCOA is a compiler and a dynamically bound language and a
set of objects called COCOA.

Is there something you do not understand about how this all works?

>
> Royal You, you, want REALBasic to retain its Beginner's All-Purpose
>simplicity, yet be sophisticated enough to contend within the REAL - world
>video game market.

There have been languages and IDEs that have done this before.
IDEs that scale well from high level to low level.

>
> Please, I beg you, give me a break. You want to go hard-core, go hard.
>Otherwise, ... go REALBasic.
>
> If you want to write the next Great American Novel, start writing.

Re: Alternate 3D
Date: 14.05.05 07:20 (Sat, 14 May 2005 02:20:30 -0400)
From: Lars Jensen
> Royal You, you, want REALBasic to retain its Beginner's All-Purpose
> simplicity, yet be sophisticated enough to contend within the REAL - world
> video game market.

I see no reason to want anything else. :)

lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 09:55 (Sat, 14 May 2005 01:55:34 -0700)
From: Adam Cuipka

I really do not know how to reply to your comments Chris. I think it is
self-evident that your grasp on the details is a little simple.

It seems that you want all the power and speed, but are not willing to
sacrifice the simplicity and almost worry-free programming environment of
REALBasic. It doesn't make any sense.

And, if I may state Chris, REALBasic, Java, and Objective-C all use
dynamic binding. For example, consider the following object heirarchy:

LifeForm->Animal->Dog->Border Collie

This means that Border Collie can respond to messages sent to any of its
four interfaces. Basic Polymorphism. Consider this:

dim myLifeForm as LifeForm

myLifeForm = createRandomLifeForm() //plant, fish, dog, cat, chris

myLifeForm.die() //calls some sort of die.

Polymorphism -> Dynamic binding. Comp Sci 101

Adam

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 11:12 (Sat, 14 May 2005 11:12:29 +0100)
From: Nick Lockwood
Polymorphism and dynamic binding are nothing to do with each other, at
least not in the context Chris is talking about.

The dynamic binding he means refers to the linker-level operations
performed by the operating system in order to connect programs with
shared libraries of code.

Chris is an experienced coder and a long time contributor to these
forums, flaming him because you missed the point of what he is saying
is ill advised.

Going back to the original point that Chris was making, ease of use
doesn't imply inefficiency. The underlying implementation of REALbasic
should be capable of matching the performance of any of these other
development environments. REALbasic compiles into platform-native
machine code which is (at least in principle) the most efficient
executable format. Compare this to Java which compiles to virtual
bytecode which must be effectively *emulated* by a virtual machine on
each platform, and it becomes reasonable to question why REALbasic is
so slow.

I've done some playing with C code and managed to write a simple
virtual machine that loops through a set of instructions stored in
array and "executes" them by selecting functions in a switch statement.
I was gob-smacked to find that in a simple looping example, the
performance of this crude un-optimised VM was actually almost identical
(and slightly superior) to REALbasic. Actually, to do a fair test I
compared my code with an RB loop of the form:

dim i as integer = 10000
start:
i = i - 1
if i > 0 then goto start

when I compared it with the equivalent empty for loop then the
performance of REALbasic was about half that of the VM.

So not only is RB's compiled code slower than a crude VM, but even
simple loop structures are poorly optimised compared to implementing
the loop manually.

I have to wonder where this inefficiency is occurring. The usual story
that RB has to implement everything using cross-platform libraries
doesn't really wash when the construct being implemented is something
as simple as above that should compile to half a dozen machine
instructions or less, and makes no library calls.

Perhaps Mars would like to explain how (and why) a loop such as the one
above is compiled in RB...?

Nick

On 14 May 2005, at 09:55, Adam Cuipka wrote:

>
> I really do not know how to reply to your comments Chris. I think
> it is
> self-evident that your grasp on the details is a little simple.
>
> It seems that you want all the power and speed, but are not
> willing to
> sacrifice the simplicity and almost worry-free programming environment
> of
> REALBasic. It doesn't make any sense.
>
> And, if I may state Chris, REALBasic, Java, and Objective-C all use
> dynamic binding. For example, consider the following object heirarchy:
>
> LifeForm->Animal->Dog->Border Collie
>
> This means that Border Collie can respond to messages sent to any
> of its
> four interfaces. Basic Polymorphism. Consider this:
>
> dim myLifeForm as LifeForm
>
> myLifeForm = createRandomLifeForm() //plant, fish, dog, cat, chris
>
> myLifeForm.die() //calls some sort of die.
>
> Polymorphism -> Dynamic binding. Comp Sci 101
>
> Adam
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 16:36 (Sat, 14 May 2005 16:36:34 +0100)
From: Nick Lockwood
Hmm...

Apparently goto performance improves dramatically when running outside
the debugger, so maybe REAL's code isn't quite so bad :-)

The for loop still sucks though.

Nick

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 19:48 (Sat, 14 May 2005 14:48:44 -0400)
From: Frank Condello
On 14-May-05, at 11:36 AM, Nick Lockwood wrote:

> Hmm...
>
> Apparently goto performance improves dramatically when running
> outside the debugger, so maybe REAL's code isn't quite so bad :-)
>
> The for loop still sucks though.

Did you disable background tasks for the loop (and nil object
checking, and bounds checking, etc., etc.,)? RB does a lot more than
just run your loop otherwise.

I keep the following text clipping in the "IDE Extras" folder:

#if NOT DebugBuild
#pragma BackgroundTasks False
#pragma BoundsChecking False
#pragma NilObjectChecking False
#pragma StackOverflowChecking False
#endif

Comes in handy! Also, as you've discovered, never use RB debug builds
for speed comparisons - same goes for any other language...

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 20:34 (Sat, 14 May 2005 14:34:00 -0500)
From: Chris Dillman
>
> I really do not know how to reply to your comments Chris. I think it is
>self-evident that your grasp on the details is a little simple.
>
> It seems that you want all the power and speed, but are not willing to
>sacrifice the simplicity and almost worry-free programming environment of
>REALBasic. It doesn't make any sense.

Once again I don't see you stating any reason for why you can't have both
Speed and simplicity?

Please support your case of why this is not possible.

Personally a good java IDE feels a lot like coding in RB.
I have a tone of basic utility objects and I have GC.

> And, if I may state Chris, REALBasic, Java, and Objective-C all use
>dynamic binding. For example, consider the following object heirarchy:

Only Obj-C has dynamic binding of functions at runtime.

Java comes close with all its object introspection and being able to link
at the beginning of the start up process.

Obj-C looks up all method calls dynamically.
Nothing is linked.
You can insert new code or commands at runtime.

This is like most scripting languages out there.

>LifeForm->Animal->Dog->Border Collie
>
> This means that Border Collie can respond to messages sent to any of its
>four interfaces. Basic Polymorphism. Consider this:
>
> dim myLifeForm as LifeForm
>
> myLifeForm = createRandomLifeForm() //plant, fish, dog, cat, chris
>
> myLifeForm.die() //calls some sort of die.
>
> Polymorphism -> Dynamic binding. Comp Sci 101

Polymorphism does not equal Dynamic binding.

See wiki
You will read here that dynamic binding is a common solution for Polymorphism.
It requires runtime look up of the functions used.
As far as I know onlt Obj-C does this.

http://en.wikipedia.org/wiki/Dynamic_binding#Dynamic_binding_for_polymorphism

A good example would be javascript.
Where you can call any method on any object at runtime by passing it a string.
The method is then looking up in basically a hash table and if it is
found it is run if not it is discarded.

You can also take an object and add new methods to it at runtime.

Example something like

var a = new object();

a[ "test" ] = function test(){ print( "TEST"); }

Re: Alternate 3D
Date: 15.05.05 22:08 (Sun, 15 May 2005 14:08:42 -0700)
From: Adam Cuipka

I have been programming for over twenty-years. I first started out with
BASIC and LOGO on the Vic-20, and continued with BASIC and LOGO for the
Commadore-64. While studying mathematics and computer science in
university, I began programming in C, C++, and Java, as well as with Perl
and PHP. Recently, I have been using Xcode, (a very excellent IDE and is
free) for Objective-C programming. So, I know my theory, my programming,
and my languages very well.

When I became aware, in 2003, that REALBasic had become Object-Oriented,
I decided to give REALBasic a try. What I needed was an IDE which would
allow me to rapidly develop application prototypes for both the Macintosh
and Windows OS's. So, REALBasic suited me just fine.

However, I never thought of REALBasic as the tool to write fast,
real-time, realistic 3D. Because BASIC was designed not for writing fast
programs, it was designed to allow non-programmers to program a computer to
solve relatively simple problems.

Of course, REALBasic has evolved from these beginnings, into an
object-oriented language for beginner's and professional's alike, but
REALBasic is still BASIC.

The fundamental reason I argue that REALBasic cannot compete against the
C family, (C, C++, Objective-C), for rendering fast real-time, realistic 3D
graphics, is that pointers are not available in REALBasic while they are
fundamental and crucial to the C family.

Arrays, for example, compose a critical point along the path for
rendering 3D graphics. Therefore, the speed with which a language can
perform array operations critically affects the speed with which the
language can render a dynamic 3D environment.

Array operations are slow in REALBasic, while pointer's give the C family
the ability to perform these operations extremely fast.

Pointers provide tremendous power, and along with that power comes great
responsibility. Pointers cannot be used without great care. In any but the
most simple projects, it is imperative that you know exactly the state of
your pointers, when they live and when they die.

If, for example, you use a pointer incorrectly, what happens is
undefined. The bad pointer may be affecting some completely un-related,
distant part of your code. So, when you experience a bug caused by this bad
pointer, it is quite possible you'll have no idea of where to look for the
cause.

However, just because pointers can cause tricky bugs, it is not reason
enough not to use them. You just need to use great care.

Now, I do not mean to say that REALBasic cannot become faster unless
REALBasic adds pointers. Indeed, REALBasic can increase its performance for
3D graphics without using pointers. However, it is the pointer which gives
the C family the razor's edge for fast, real-time, realistic 3D rendering.

Therefore, I cannot see REALBasic seriously competing against
industry-standard language for 3D graphics.

So, unless you change the nature of the beast, REALBasic is not the tool
to use to write 3D games capable of competing in the video game market. If
you want hardcore, you have to go hardcore.

This was, simply my point.

Now, regarding Polymorphism and Dynamic Binding.

Let me first say that if you are getting all your theoretical knowledge
from Wiki, you need to look elsewhere.

Secondly, I think you are confusing Dynamic Linking with Dynamic
Binding. Linking and Binding are completely different.

A method is dynamically bound to an implementation, if this binding can
only occur at Runtime.

Consider the following example:

Let all lifeForms have a method named "die"
Let Fish, Rats, Cats and Lizards all be LifeForms
Each type of lifeForm, (cat,rat,lizard etc) may or may not implement
their own versions of the die method.

Now consider the following method of some other class (say Window1):

Sub createRandomLifeForm() As LifeForm
{

dim random as Random
dim number as integer

dim fish as Fish
dim cat as Cat
dim lizard as Lizard

random = new Random()

number = random.number() * 3 + 1 //chooses either 1, 2 or 3 at random

select case number:

case 1: //fish
return new Fish()

case 2: //cat
return new Cat()

case 3://lizard
return new Lizard()

end case

return nil
}

Since a random number must first be generated in order to determine
which kind of life form is returned, and since the random number is only
generated at Runtime, the compiler can not bind any implementation to any of
the methods of the life form objects. Therefore, the binding between
implementation and method occurs at Runtime.

Ie.


At Compile time, the compiler only knows that createRandomLifeForm
returns a kind-of LifeForm, it does know which kind-of lifeForm is actually
returned. Therefore, the compiler cannot bind any implementation to the die
method of the LifeForm. It simply does not know which implementation to
bind.

The compiler does not know which implementation to bind to the die
method because first a random number must be generated. Since the random
number is only generated at Runtime


Therefore, the compiler can not bind the implementation
it is not known which object will actually be returned by
createRandomLifeForm(). In order to know which type of object is going to
be returned, we must first generate a random number. This number is only
generated at Runtime.

Dynamic Binding simply means, that method can be bound to some
implementation oat Runtime.

>>
>> I really do not know how to reply to your comments Chris. I think it is
>> self-evident that your grasp on the details is a little simple.
>>
>> It seems that you want all the power and speed, but are not willing to
>> sacrifice the simplicity and almost worry-free programming environment of
>> REALBasic. It doesn't make any sense.
>
> Once again I don't see you stating any reason for why you can't have both
> Speed and simplicity?
>
> Please support your case of why this is not possible.
>
> Personally a good java IDE feels a lot like coding in RB.
> I have a tone of basic utility objects and I have GC.
>
>> And, if I may state Chris, REALBasic, Java, and Objective-C all use
>> dynamic binding. For example, consider the following object heirarchy:
>
> Only Obj-C has dynamic binding of functions at runtime.
>
> Java comes close with all its object introspection and being able to link
> at the beginning of the start up process.
>
> Obj-C looks up all method calls dynamically.
> Nothing is linked.
> You can insert new code or commands at runtime.
>
> This is like most scripting languages out there.
>
>> LifeForm->Animal->Dog->Border Collie
>>
>> This means that Border Collie can respond to messages sent to any of its
>> four interfaces. Basic Polymorphism. Consider this:
>>
>> dim myLifeForm as LifeForm
>>
>> myLifeForm = createRandomLifeForm() //plant, fish, dog, cat, chris
>>
>> myLifeForm.die() //calls some sort of die.
>>
>> Polymorphism -> Dynamic binding. Comp Sci 101
>
> Polymorphism does not equal Dynamic binding.
>
> See wiki
> You will read here that dynamic binding is a common solution for Polymorphism.
> It requires runtime look up of the functions used.
> As far as I know onlt Obj-C does this.
>
> http://en.wikipedia.org/wiki/Dynamic_binding#Dynamic_binding_for_polymorphism
>
> A good example would be javascript.
> Where you can call any method on any object at runtime by passing it a string.
> The method is then looking up in basically a hash table and if it is
> found it is run if not it is discarded.
>
> You can also take an object and add new methods to it at runtime.
>
> Example something like
>
> var a = new object();
>
> a[ "test" ] = function test(){ print( "TEST"); }
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 23:14 (Sun, 15 May 2005 18:14:06 -0400)
From: Frank Condello
On 15-May-05, at 5:08 PM, Adam Cuipka wrote:

> The fundamental reason I argue that REALBasic cannot compete
> against the
> C family, (C, C++, Objective-C), for rendering fast real-time,
> realistic 3D
> graphics, is that pointers are not available in REALBasic while
> they are
> fundamental and crucial to the C family.

You're right of course, and REAL Software is aware that this is a
problem in general. We've had lengthy discussions on this topic in
the past - lookup "vector plugin" in the games NUG archive. What I
(and many others) do is simply profile suspect code, and move slow
bits into C plugins. Accept things for what they are and use the best
tool for the job...

> So, unless you change the nature of the beast, REALBasic is not the
> tool
> to use to write 3D games capable of competing within the video game
> market.
> If you want hardcore, you have to go hardcore.

Depends what you mean by "video game market"... If you're talking
about the high-end FPS shooter market then ya, you might have a few
problems keeping up using pure RB code, but if you use plugins where
appropriate I don't see why RB couldn't be used for a major product.
You may consider plugins "going hardcore" in themselves but I find
doing the bulk of the work in RB to be far preferable to doing all of
the work in C. You're entitled to your own opinions of course.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 17.05.05 19:28 (Tue, 17 May 2005 11:28:15 -0700)
From: Adam Cuipka
On 5/15/05 3:14 PM, "Frank Condello" <<email address removed>> wrote:

>> So, unless you change the nature of the beast, REALBasic is not the
>> tool
>> to use to write 3D games capable of competing within the video game
>> market.
>> If you want hardcore, you have to go hardcore.
>
> Depends what you mean by "video game market"... If you're talking
> about the high-end FPS shooter market then ya, you might have a few
> problems keeping up using pure RB code, but if you use plugins where
> appropriate I don't see why RB couldn't be used for a major product.
> You may consider plugins "going hardcore" in themselves but I find
> doing the bulk of the work in RB to be far preferable to doing all of
> the work in C. You're entitled to your own opinions of course.

I checked out the "vector plugin" thread you suggested.

Your discussions in that thread are pretty much what I'm trying to say.
Personally, I was quite surprised that REALBasic even provided any kind of
3D capability. Furthermore, I was impressed by what REALBasic did offer for
3D programming.

However, as your discussions in the "vector plugin" thread elucidate,
there is no way beyond using plug-ins to improve the 3D capabilities of
REALBasic. This imposes a serious constraint on someone wanting more than
what is already offered.

All I was trying to say, originally, was that what REALBasic offers is
about as good as its going to get for 3D, unless you incorporate some
serious power into the language. At which point, the Beginner's All-purpose
accessibility of REALBasic diminishes.

If someone where to ask me: "What language should I use if I want to
program 3D games for the Macintosh?" I would answer Objective C. If
someone where to ask me: "What language should I use if I want to learn
programming?", or "What language makes it easy to write applications quickly
for the Macintosh?" or "What language is made by a company which knows how
to take money from its loyal customer base?" I'd answer REALBasic.

Personally, I have an affinity for the C-family, I just like the
language, always have. But, when I just want to start coding, explore an
idea, produce something without a lot of hassle I right away go to
REALBasic. I think that is the strength of the REALBasic. However, as with
any strength, it comes with a cost. It just seemed to me people wanted it
for free.

Adam

-
Let 1 = 0 and say good-bye

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 18.05.05 20:40 (Wed, 18 May 2005 15:40:36 -0400)
From: Asher Dunn

On May 17, 2005, at 2:28 PM, Adam Cuipka wrote:

> ...there is no way beyond using plug-ins to improve the 3D
> capabilities of
> REALBasic.

That is simply not true.

Asher Dunn (not an idiot)
--------------------------------------------------------
President and Head Developer of Fireye Software
<http://www.fireyesoftware.com/>
AIM and Yahoo: fireye7517

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 19.05.05 03:30 (Wed, 18 May 2005 22:30:31 -0400)
From: John Balestrieri
I strongly disagree.

John Balestrieri
<http://www.tinrocket.com/>



On May 17, 2005, at 2:28 PM, Adam Cuipka wrote:

> All I was trying to say, originally, was that what REALBasic
> offers is
> about as good as its going to get for 3D, unless you incorporate some
> serious power into the language. At which point, the Beginner's
> All-purpose
> accessibility of REALBasic diminishes.



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 19.05.05 03:54 (Thu, 19 May 2005 12:54:36 +1000)
From: Ben Lilburne
Yep, the performance of the language is fine, and the "power" of the
language is the same, in total, as any other turing-complete
programming language.

The 3D API in RealBasic could be improved significantly, in
capability, rendering quality and performance - it's simply not used
enough to justify that development by Real Software. There is no
particular language feature that is needed for a 3D API which RB does
not already have.

On 19/05/2005, at 12:30 PM, John Balestrieri wrote:
> I strongly disagree.
>
> John Balestrieri
> <http://www.tinrocket.com/>
> On May 17, 2005, at 2:28 PM, Adam Cuipka wrote:
>> All I was trying to say, originally, was that what REALBasic
>> offers is
>> about as good as its going to get for 3D, unless you incorporate some
>> serious power into the language. At which point, the Beginner's
>> All-purpose
>> accessibility of REALBasic diminishes.
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 19.05.05 12:23 (Thu, 19 May 2005 07:23:23 -0400)
From: Joseph Nastasi

On May 18, 2005, at 10:54 PM, Ben Lilburne wrote:

> Yep, the performance of the language is fine, and the "power" of the
> language is the same, in total, as any other turing-complete
> programming language.

Of course. The compiler will surely improve, but there is nothing
inherently wrong with the language.
>
> The 3D API in RealBasic could be improved significantly, in
> capability, rendering quality and performance - it's simply not used
> enough to justify that development by Real Software.

If you haven't already, there are a boatload of RB3D bug reports that
can be signed. This is one of the ways RS gauges interest. It's a
chicken/egg thing. RS would like to see more applications that use
RB3D, but the incomplete API makes that difficult (but NOT impossible).
Seeing a growing number of votes in the bug base is another way to get
their attention

If you have a serious (that means you intend to release, not
necessarily sell) project that you started and have major snags caused
by RB3D, talk to RS directly.

> There is no particular language feature that is needed for a 3D API
> which RB does not already have.

Definitely true.

Re: Alternate 3D
Date: 16.05.05 02:17 (Sun, 15 May 2005 21:17:26 -0400)
From: Asher Dunn

On May 15, 2005, at 5:08 PM, Adam Cuipka wrote:

> Arrays, for example, compose a critical point along the path for
> rendering 3D graphics. Therefore, the speed with which a language can
> perform array operations critically affects the speed with which the
> language can render a dynamic 3D environment.

When using OpenGL, OpenGL does the pointer array crawling, and all you
do is pass a "pointer" to the array (a memoryBlock).

Asher Dunn
--------------------------------------------------------
President and Head Developer of Fireye Software
<http://www.fireyesoftware.com/>
AIM and Yahoo: fireye7517

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 16.05.05 05:12 (Mon, 16 May 2005 00:12:08 -0400)
From: Frank Condello
On 15-May-05, at 9:17 PM, Asher Dunn wrote:

> On May 15, 2005, at 5:08 PM, Adam Cuipka wrote:
>
>> Arrays, for example, compose a critical point along the path for
>> rendering 3D graphics. Therefore, the speed with which a language
>> can
>> perform array operations critically affects the speed with which the
>> language can render a dynamic 3D environment.
>
> When using OpenGL, OpenGL does the pointer array crawling, and all
> you do is pass a "pointer" to the array (a memoryBlock).

Yes, but if you manipulate that memoryblock's data every frame (say,
for animation or visibility culling) you'll incur a lot of function
call overhead and stuff can quickly bog down.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 17.05.05 01:42 (Mon, 16 May 2005 20:42:54 -0400)
From: Asher Dunn

On May 16, 2005, at 12:12 AM, Frank Condello wrote:

> On 15-May-05, at 9:17 PM, Asher Dunn wrote:
>
>> On May 15, 2005, at 5:08 PM, Adam Cuipka wrote:
>>
>>> Arrays, for example, compose a critical point along the path for
>>> rendering 3D graphics. Therefore, the speed with which a language
>>> can
>>> perform array operations critically affects the speed with which the
>>> language can render a dynamic 3D environment.
>>
>> When using OpenGL, OpenGL does the pointer array crawling, and all
>> you do is pass a "pointer" to the array (a memoryBlock).
>
> Yes, but if you manipulate that memoryblock's data every frame (say,
> for animation or visibility culling) you'll incur a lot of function
> call overhead and stuff can quickly bog down.

Animation, I can see that, but visibility culling? You wouldn't cull
per vertex!

Asher Dunn
--------------------------------------------------------
President and Head Developer of Fireye Software
<http://www.fireyesoftware.com/>
AIM and Yahoo: fireye7517

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 17.05.05 04:21 (Mon, 16 May 2005 23:21:06 -0400)
From: Frank Condello
On 16-May-05, at 8:42 PM, Asher Dunn wrote:
>
> On May 16, 2005, at 12:12 AM, Frank Condello wrote:
>
>> On 15-May-05, at 9:17 PM, Asher Dunn wrote:
>>
>>> On May 15, 2005, at 5:08 PM, Adam Cuipka wrote:
>>>
>>>> Arrays, for example, compose a critical point along the path
>>>> for
>>>> rendering 3D graphics. Therefore, the speed with which a
>>>> language can
>>>> perform array operations critically affects the speed with which
>>>> the
>>>> language can render a dynamic 3D environment.
>>>
>>> When using OpenGL, OpenGL does the pointer array crawling, and
>>> all you do is pass a "pointer" to the array (a memoryBlock).
>>
>> Yes, but if you manipulate that memoryblock's data every frame
>> (say, for animation or visibility culling) you'll incur a lot of
>> function call overhead and stuff can quickly bog down.
>
> Animation, I can see that, but visibility culling? You wouldn't
> cull per vertex!

You wouldn't normally *test* per-vertex, but you'd almost certainly
end up with new vertex arrays every frame (unless the view is
stationary).

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 22:18 (Sun, 15 May 2005 14:18:41 -0700)
From: Adam Cuipka

Please ignore my previous post. I accidentally sent my rough draft.

I have been programming for over twenty-years. I first started out with
BASIC and LOGO on the Vic-20, and continued with BASIC and LOGO for the
Commadore-64. While studying mathematics and computer science in
university, I began programming in C, C++, and Java, as well as with Perl
and PHP. Recently, I have been using Xcode, (a very excellent IDE and is
free) for Objective-C programming. So, I know my theory, my programming,
and my languages very well.

When I became aware, in 2003, that REALBasic had become Object-Oriented,
I decided to give REALBasic a try. What I needed was an IDE which would
allow me to rapidly develop application prototypes for both the Macintosh
and Windows OS's. So, REALBasic suited me just fine.

However, I never thought of REALBasic as the tool to write fast,
real-time, realistic 3D. Because BASIC was designed not for writing fast
programs, it was designed to allow non-programmers to program a computer to
solve relatively simple problems.

Of course, REALBasic has evolved from these beginnings, into an
object-oriented language for beginner's and professional's alike, but
REALBasic is still BASIC.

The fundamental reason I argue that REALBasic cannot compete against the
C family, (C, C++, Objective-C), for rendering fast real-time, realistic 3D
graphics, is that pointers are not available in REALBasic while they are
fundamental and crucial to the C family.

Arrays, for example, compose a critical point along the path for
rendering 3D graphics. Therefore, the speed with which a language can
perform array operations critically affects the speed with which the
language can render a dynamic 3D environment.

Array operations are slow in REALBasic, while pointer's give the C family
the ability to perform these operations extremely fast.

Pointers provide tremendous power, and along with that power comes great
responsibility. Pointers cannot be used without great care. In any but the
most simple projects, it is imperative that you know exactly the state of
your pointers, when they live and when they die.

If, for example, you use a pointer incorrectly, what happens is
undefined. The bad pointer may be affecting some completely un-related,
distant part of your code. So, when you experience a bug caused by this bad
pointer, it is quite possible you'll have no idea of where to look for the
cause.

However, just because pointers can cause tricky bugs, is not reason
enough not to use them. You just need to use great care.

Now, I do not mean to say that REALBasic cannot become faster unless
REALBasic adds pointers. Indeed, REALBasic can increase its performance for
3D graphics without using pointers. However, it is the pointer which gives
the C family the razor's edge for fast, real-time, realistic 3D rendering.

Therefore, I cannot see REALBasic seriously competing against
industry-standard language for 3D graphics.

So, unless you change the nature of the beast, REALBasic is not the tool
to use to write 3D games capable of competing within the video game market.

If you want hardcore, you have to go hardcore.

This was simply my point.

Now, regarding Polymorphism and Dynamic Binding.

Let me first say that if you are getting all your theoretical knowledge
from Wiki, you need to look elsewhere.

Secondly, I think you are confusing Dynamic Linking with Dynamic
Binding. Linking and Binding are completely different.

A method is dynamically bound to an implementation, if this binding can
only occur at Runtime.

Consider the following example:

Let all lifeForms have a method named "die"
Let Fish, Rats, Cats and Lizards all be LifeForms
Each type of lifeForm, (cat,rat,lizard etc) may or may not implement
their own versions of the die method.

Now consider the following method of some other class (say Window1):

Sub createRandomLifeForm() As LifeForm
{

dim random as Random
dim number as integer

dim fish as Fish
dim cat as Cat
dim lizard as Lizard

random = new Random()

number = random.number() * 3 + 1 //chooses either 1, 2 or 3 at random

select case number:

case 1: //fish
return new Fish()

case 2: //cat
return new Cat()

case 3://lizard
return new Lizard()

end case

return nil
}

Since a random number must first be generated in order to determine
which kind of life form is returned, and since the random number is only
generated at Runtime, the compiler can not bind any implementation to any of
the methods of the life form objects. Therefore, the binding between
implementation and method occurs at Runtime.

Since the binding occurs at runtime, the binding is called dynamic
binding.

Polymorphism doesn't necessarily imply Dynamic Binding, you are correct.
But as the above example shows, if method overriding is a part of
Polymorphism, (as it should be), then Polymorphism requires Dynamic Binding.

Adam

-
Let 1 = 0 and say Good-Bye World.



_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 16.05.05 09:54 (Mon, 16 May 2005 03:54:19 -0500)
From: Chris Dillman
>
> If you want hardcore, you have to go hardcore.
>
> This was simply my point.

1. I swear we were talking about the speed of RB3D and Quesa a C API.
Not in doing 3D in straight RB code.

2. Ptrs would be nice but are really not needed for doing modern 3D games.

To start with take a look at.

http://www.bytonic.de/html/jake2.html

Is a direct port of Quake 2 from C into Java using OpenGL and OpenAL.

3. Modern 3D game engines actually consist of mostly static geometry
which is pre processed and is mostly cached on the 3D card.
Something RB can certainly handle.

> Now, regarding Polymorphism and Dynamic Binding.
>
> Let me first say that if you are getting all your theoretical knowledge
>from Wiki, you need to look elsewhere.
>
> Secondly, I think you are confusing Dynamic Linking with Dynamic
>Binding. Linking and Binding are completely different.

What you are talking about only loosely fits the definition of dynamic binding
in so much as it fits a text book definition.

Really what you have is statically typed dynamic binding
where all possible functions are defined in the base class
and the compiler determines static linking of of all functions based
on the object created.

So at run time there is nothing really dynamic
about it since you can't change an objects behavior.

What Im talking about is actual runtime dynamic binding
Where the function to run is looked up at runtime.

With true dynamic binding any object can be passed any message even if it
can not respond to it.

C++ is static.

Javs is almost static but you can fake it being dynamic through
java.lang.reflect

Obj C is dynamic.

JS is dynamic

You could also call this dynamic linking if you wanted to.
But most of the world calls it dynamic binding.

Re: Alternate 3D
Date: 14.05.05 21:15 (Sat, 14 May 2005 15:15:00 -0500)
From: Chris Dillman
>Polymorphism and dynamic binding are nothing to do with each other,
>at least not in the context Chris is talking about.
>
>The dynamic binding he means refers to the linker-level operations
>performed by the operating system in order to connect programs with
>shared libraries of code.
>
>Chris is an experienced coder and a long time contributor to these
>forums, flaming him because you missed the point of what he is
>saying is ill advised.

Thanks Nick.

Though Im wondering what would happen to Adam.

Am I going to sic my large horde of ferrets on him ;)

Re: Alternate 3D
Date: 15.05.05 11:36 (Sun, 15 May 2005 11:36:59 +0100)
From: Nick Lockwood
> Thanks Nick.
>
> Though Im wondering what would happen to Adam.
>
> Am I going to sic my large horde of ferrets on him ;)

Heh :-)

No, it wasn't a veiled threat, I just meant he risked looking like a
moron.

Nick

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 12:48 (Sun, 15 May 2005 12:48:53 +0100)
From: Nick Lockwood
Thanks Frank,

I've done that and the performance is now what I would expect.

I had no idea about two of those pragmas, the only ones I'd heard of
before are BackgroundTasks and BoundsChecking. My own experience with
BackgroundChecking disabled is that the performance improvements are
minimal and the side effects are annoying (window/mouse responsiveness
broken). As for DisableBoundsChecking, the last I'd heard was that it
had originally applied only to one-dimensional boolean arrays, and that
even this optimisation had been removed in the RB 5.0 compiler rewrite.
Has this optimisation now been re-implemented for all arrays?

I think REAL are shooting themselves in the foot a little by not
advertising these features more. I got a factor of 10 speed improvement
using them, but they are poorly documented in the help system.

A little note saying "Use of these pragmas is not recommended during
the debug cycle as they may mask errors and lead to more serious
crashes, however we recommend enabling them for final distribution
builds as they can increase application performance by a factor of 10
or more in some cases." would be a nice addition IMHO.

Also some check-boxes to enable these features globally for an
application would be handy.

Nick

> Did you disable background tasks for the loop (and nil object
> checking, and bounds checking, etc., etc.,)? RB does a lot more than
> just run your loop otherwise.
>
> I keep the following text clipping in the "IDE Extras" folder:
>
> #if NOT DebugBuild
> #pragma BackgroundTasks False
> #pragma BoundsChecking False
> #pragma NilObjectChecking False
> #pragma StackOverflowChecking False
> #endif
>
> Comes in handy! Also, as you've discovered, never use RB debug builds
> for speed comparisons - same goes for any other language...
>
> Frank.
> –––––––––––––––––––––––––––––––––
> Open Source RB Goodies and Shareware
> <http://developer.chaoticbox.com/>
> <http://www.chaoticbox.com/>
> –––––––––––––––––––––––––––––––––
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 15.05.05 20:19 (Sun, 15 May 2005 15:19:31 -0400)
From: Frank Condello
On 15-May-05, at 7:48 AM, Nick Lockwood wrote:

> As for DisableBoundsChecking, the last I'd heard was that it had
> originally applied only to one-dimensional boolean arrays, and that
> even this optimisation had been removed in the RB 5.0 compiler
> rewrite. Has this optimisation now been re-implemented for all arrays?

I honestly don't know the details, but something must catch
OutOfBoundsException for all arrays and pseudo-arrays (like
memoryblocks) and turning off BoundsChecking can cause any out of
bounds situation to crash (or at least not work right) so it must be
doing something.

> I think REAL are shooting themselves in the foot a little by not
> advertising these features more. I got a factor of 10 speed
> improvement using them, but they are poorly documented in the help
> system.

I agree. Even a short "Performance Tweaking Guide" would go a long
way, as the same issues come up over and over on these NUGs. It would
also be nice to know some more details on how each pragma works. I
tend to slap these pragmas anywhere I'd like a speed up, but I know
some have little or no affect in certain situations - I just don't
know which and why.

> Also some check-boxes to enable these features globally for an
> application would be handy.

Not sure I'd want to do it globally, but ya, there's got to be a
better way to handle these. Sticking them in almost every method does
get tedious, so maybe a way to do it per-module/class or even just a
combined pragma statement that disables everything in one shot.

Frank.
–––––––––––––––––––––––––––––––––
Open Source RB Goodies and Shareware
<http://developer.chaoticbox.com/>
<http://www.chaoticbox.com/>
–––––––––––––––––––––––––––––––––

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 15:06 (Sat, 14 May 2005 10:06:40 -0400)
From: Daniel Lurie

On May 13, 2005, at 5:38 PM, Dustin Evermore wrote:
>> In the future BlitzMax will feature a full 3D game engine and tools(?)
>> written in BlitzMax itself.
>
> That is interesting -- for the future.
>
> It's just that in the current product description, for the currently
> available version, it said 2D only for Mac. To answer another person
> who continued to ask what RB3D can do that Blitz can't after my last
> reply, I thought it was obvious -- no 3D available for Mac versions
> right now.
>
> DE

That's not strictly true either. 3D is avaliable via OpenGL. You can
use all OpenGL functions in it right now. It does not provide a 3d
engine yet. But, 3D is certainly possible.

=3D?DGDoDgDDaniel R. Lurie
=?D3D?D3D?Dhttp://www.vikingdan.com

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Alternate 3D
Date: 14.05.05 15:11 (Sat, 14 May 2005 10:11:45 -0400)
From: Daniel Lurie

On May 13, 2005, at 12:03 PM, Chris Dillman wrote:
>> Blitz3D is Windows-only. BlitzMax, which is currently only for Mac,
>> is only 2D. Blitz does not appear to be an actual cross-platform
>> development system.
>
> BlitzMax replaces Blitz3D
> and a completely cross platform.
>
> Im told you can make windows builds right now...
> That might be a beta feature Im not sure.

You can build for Mac, Windows, and Linux. Unlike RB, you have to
compile on the target platform (unless you use VPC or some such.) You
do not need a separate license for each platform though.

>
> BlitzMax is 3D
> as in it give easy access to all of open gl
> so you can do ever you want in it.
>

> In the future BlitzMax will feature a full 3D game engine and tools(?)
> written in BlitzMax itself.
>

Righty right. The upcoming 3D module will use OpenGL on all 3 platforms
(and optionally DirectX on Windows.)

=GDDcDkDoDDaniel R. Lurie
=?DGD?DGD?Dhttp://www.vikingdan.com

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>