Xojo Conferences
MBSSep2018MunichDE
XDCMay2019MiamiUSA

REALbasicGL (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: MorphMap Class
Next thread: Maximum optimization


[ANN] Preview of RBD 2.4   -   Marc Zeedar
  REALbasicGL   -   cap'n bishop
   Re: REALbasicGL   -   Nick Lockwood
   Re: REALbasicGL   -   Frank Condello
   Re: REALbasicGL   -   Nick Lockwood
    Re: REALbasicGL   -   Jurriaan Schulman
     Re: REALbasicGL   -   Frank Condello
      Re: REALbasicGL   -   Jurriaan Schulman
       Re: REALbasicGL   -   Frank Condello
   Re: REALbasicGL   -   Asher Dunn
   Re: Fast memory manipulation (Was: REALbasicGL)   -   Asher Dunn

REALbasicGL
Date: 28.03.05 06:32 (Sun, 27 Mar 2005 21:32:31 -0800 (PST))
From: cap'n bishop
I'm starting an open source framework for OpenGL in REALbasic (which
should evolve into a game engine) as an alternative to RB3D.

I know there are others out there who would be interested in such a
project, so I figured I might gather a few talented minds together and
see what they might have developed already.

Anyway I've got the beginings of some base code. An overall structure
and the like.

It would be nice to keep it somewhat similar to RB3D for the sake of
those who are already familiar, but I also intend to maintain OpenGL's
versatility.

A good case of point would be that there's an RBGLObject class; but it
only store information like position, orientation, scale, etc. This
class then has a Render event, so a subclass would have to make use of
this to do the actual drawing- this allows for any type of data
structure, so if all you needed was a simple heightmap, then that's all
you need to keep track of (why build a full data structure like a
TriMesh when all you need is a two dimentional array?). The framework
I'd like to build would ideally include several different sub object
classes to cator to specific or general needs.

Anyway I thought I'd see who else is interested out there.


__________________________________
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/
_______________________________________________
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: REALbasicGL
Date: 02.04.05 11:28 (Sat, 2 Apr 2005 11:28:42 +0100)
From: Nick Lockwood
Not sure if this is any use to anyone, but re: the discussion about
performance of memoryblocks versus arrays, I knocked up a quick memory
utilities plugin for allocating and manipulating memory.

You can find the plugin here:
http://www.charcoaldesign.co.uk/MemUtilsPlugin.zip

It includes full source code (codewarrior) and documentation, and also
includes a handy profiling project that compares performance of arrays,
memory blocks and the plugin memory functions.

In short, the plugin is faster than either for every operation, at
least on my machine :-)

Enjoy,

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: REALbasicGL
Date: 02.04.05 22:21 (Sat, 2 Apr 2005 16:21:50 -0500)
From: Frank Condello
On 2-Apr-05, at 5:28 AM, Nick Lockwood wrote:

> Not sure if this is any use to anyone, but re: the discussion about
> performance of memoryblocks versus arrays, I knocked up a quick memory
> utilities plugin for allocating and manipulating memory.
>
> You can find the plugin here:
> http://www.charcoaldesign.co.uk/MemUtilsPlugin.zip
>
> It includes full source code (codewarrior) and documentation, and also
> includes a handy profiling project that compares performance of
> arrays, memory blocks and the plugin memory functions.
>
> In short, the plugin is faster than either for every operation, at
> least on my machine :-)

Same results here - unfortunately the speedup when getting/setting
bytes is negligible (but that's to be expected). RB's Achilles heel
(IMO) is that there's no way to directly access random bytes. Arrays,
memoryblocks and your plugin all use setter and getter functions, and
the function call overhead alone is to blame for the poor performance.
(Actually, I'm not sure about Arrays, they're a bit of an oddball, but
I do wish they were faster and could be passed to declares as pointers
- that would solve a lot of problems).

I've given this a bit of thought but I can't see an obvious way to add
fast random memory access to RB even with a plugin. The best you can do
is create methods that work on entire blocks of memory, similar to the
RGBsurface's Transform method. These can't be made totally generic
however, so you have to identify areas where blocks of regular-sized
data can be manipulated predictably and just code for those situations.

A few "all or nothing" situations come to mind:

- Turning a Picture into RGB(A) data and back (I promised Asher a
plugin for this a few months back but I haven't actually got around to
it!)

- Averaging values in 2 or more blocks of memory, with optional
weighting. This is very important for interpolating 3D key frames or
applying morph maps at a reasonable speed. Doing this in pure RB code
would greatly limit the number of animated meshes you could display at
playable framerates.

- Applying a formula to regular data in a block of memory. Useful for
certain procedural or UV animations.

It would probably be best to create specialized classes for common data
types. Some 32bit float arrays would be most useful: VecBlock,
Vec2Block, Vec3Block, Vec4Block would cover a lot of situations.
Similar classes for bytes, ints or doubles could also come in handy.
Normal getters/setters would have to be implemented for unforeseeable
situations (and to fill the data in the first place) but ideally those
can be avoided when speed is required.

Frank.
------------
Open Source RB Plugins and Classes
<http://developer.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: REALbasicGL
Date: 02.04.05 23:46 (Sat, 2 Apr 2005 23:46:11 +0100)
From: Nick Lockwood
These all sound like good ideas Frank. I've been thinking along the
same lines, but it sound like you've put more coherent thought into it
than I have.

If you'd like to come up with a clear spec for what is needed, I'd be
happy to code up a plugin for it and release it with source code.

One thing that put me off adding a vector class to my plugin was than I
couldn't think of a convenient package for the vectors themselves. It's
easy to add a function that accesses 12 or 16 bytes of data in a block
of memory, but how would it be returned? As soon as you package it into
an RB class you add masses of overhead, and if you just return an
address (as an integer) and have accessor functions, then it seems to
me no different than my current implementation, which would let you
implement vectors of any size by just incrementing pointers.

If you can think of a range of specific functions that could be applied
to an array of data and would be useful as a general purpose tool, then
I would be much obliged if you'd share them.

Nick

> On 2-Apr-05, at 5:28 AM, Nick Lockwood wrote:
>
>> Not sure if this is any use to anyone, but re: the discussion about
>> performance of memoryblocks versus arrays, I knocked up a quick
>> memory utilities plugin for allocating and manipulating memory.
>>
>> You can find the plugin here:
>> http://www.charcoaldesign.co.uk/MemUtilsPlugin.zip
>>
>> It includes full source code (codewarrior) and documentation, and
>> also includes a handy profiling project that compares performance of
>> arrays, memory blocks and the plugin memory functions.
>>
>> In short, the plugin is faster than either for every operation, at
>> least on my machine :-)
>
> Same results here - unfortunately the speedup when getting/setting
> bytes is negligible (but that's to be expected). RB's Achilles heel
> (IMO) is that there's no way to directly access random bytes. Arrays,
> memoryblocks and your plugin all use setter and getter functions, and
> the function call overhead alone is to blame for the poor performance.
> (Actually, I'm not sure about Arrays, they're a bit of an oddball, but
> I do wish they were faster and could be passed to declares as pointers
> - that would solve a lot of problems).
>
> I've given this a bit of thought but I can't see an obvious way to add
> fast random memory access to RB even with a plugin. The best you can
> do is create methods that work on entire blocks of memory, similar to
> the RGBsurface's Transform method. These can't be made totally generic
> however, so you have to identify areas where blocks of regular-sized
> data can be manipulated predictably and just code for those
> situations.
>
> A few "all or nothing" situations come to mind:
>
> - Turning a Picture into RGB(A) data and back (I promised Asher a
> plugin for this a few months back but I haven't actually got around to
> it!)
>
> - Averaging values in 2 or more blocks of memory, with optional
> weighting. This is very important for interpolating 3D key frames or
> applying morph maps at a reasonable speed. Doing this in pure RB code
> would greatly limit the number of animated meshes you could display at
> playable framerates.
>
> - Applying a formula to regular data in a block of memory. Useful for
> certain procedural or UV animations.
>
> It would probably be best to create specialized classes for common
> data types. Some 32bit float arrays would be most useful: VecBlock,
> Vec2Block, Vec3Block, Vec4Block would cover a lot of situations.
> Similar classes for bytes, ints or doubles could also come in handy.
> Normal getters/setters would have to be implemented for unforeseeable
> situations (and to fill the data in the first place) but ideally those
> can be avoided when speed is required.
>
> Frank.
> ------------
> Open Source RB Plugins and Classes
> <http://developer.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: REALbasicGL
Date: 03.04.05 12:25 (Sun, 03 Apr 2005 13:25:12 +0200)
From: Jurriaan Schulman
Although I have been thinking about writing a scene graph in Realbasic
myself, I think it would propably be easier to write a plugin to use an open
source framework like e.g. Open Scene Graph (www.openscenegraph.org) or Ogre
(www.ogre3d.org). What would be the reason to try to write a game
engine/scene graph in RB instead of using one of the many existing
frameworks?

Cheers,

Jurriaan

_______________________________________________
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: REALbasicGL
Date: 03.04.05 19:57 (Sun, 3 Apr 2005 14:57:47 -0400)
From: Frank Condello
On 3-Apr-05, at 7:25 AM, Jurriaan Schulman wrote:

> Although I have been thinking about writing a scene graph in Realbasic
> myself, I think it would propably be easier to write a plugin to use
> an open
> source framework like e.g. Open Scene Graph (www.openscenegraph.org)
> or Ogre
> (www.ogre3d.org). What would be the reason to try to write a game
> engine/scene graph in RB instead of using one of the many existing
> frameworks?

I've tried just about every open source 3D engine/scenegraph out there
and there are a few reasons most aren't very attractive:

- Viral licenses (GPL) don't work for everyone.

- Some try to "do it all" using their own windowing and event layers
which often don't get along well with RB.

- Mac OS X support is an afterthought that tends to lag behind
Win32/Linux builds and often requires silly linux-like installation
with a bunch of dependancies.

I'm not saying they are all that bad, and if you're only targeting
Win32 or Linux there are actually some decent choices out there. I just
haven't found one that runs on well on OS X without a lot of fuss.

Frank.
------------
Open Source RB Plugins and Classes
<http://developer.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: REALbasicGL
Date: 03.04.05 21:49 (Sun, 03 Apr 2005 22:49:55 +0200)
From: Jurriaan Schulman
Hi Frank,

> I've tried just about every open source 3D engine/scenegraph out there
> and there are a few reasons most aren't very attractive:

I see what you mean. However, you might want to take a second look at Open
Scene Graph. It has a LGLP license, which basicly means that you can use the
library without having to opensource your own code.

Open Scene Graph is also windowing system independent and as far as I know
the OS X port is on par with the Windows and Linux ports. OS X binaries
(frameworks) are available at: http://www.create.ucsb.edu/OSG/index.html

As I said before, I like the idea of writing a scene graph in Realbasic.
However I also think one would be spending a lot of time reinventing the
wheel and it might be difficult to get the same kind of performance using RB
compared to a good C++ framework.

Regards,

Jurriaan

_______________________________________________
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: REALbasicGL
Date: 04.04.05 06:20 (Mon, 4 Apr 2005 01:20:18 -0400)
From: Frank Condello
On 3-Apr-05, at 4:49 PM, Jurriaan Schulman wrote:

>> I've tried just about every open source 3D engine/scenegraph out there
>> and there are a few reasons most aren't very attractive:
>
> I see what you mean. However, you might want to take a second look at
> Open
> Scene Graph. It has a LGLP license, which basicly means that you can
> use the
> library without having to opensource your own code.

The OSG license is OK, and the OS X port is farther along than last
time I checked it out. So I downloaded it, but more than half the
pre-compiled examples bail out to Crash Reporter (not an encouraging
start!). It also consists of a dozen separate frameworks, plus some 30
odd plugins, which seems a tad overkill. I know you can cut that number
down somewhat without the Producer-a-like stuff or plugins you won't
use but you're still looking at about 10-20MB in dependancies. The
terrain engine seems to be MIA in the OS X build as well...

I'll keep my eye on this in the future but for now it seems too bloated
and buggy.

> As I said before, I like the idea of writing a scene graph in
> Realbasic.
> However I also think one would be spending a lot of time reinventing
> the
> wheel and it might be difficult to get the same kind of performance
> using RB
> compared to a good C++ framework.

That's basically why RB3D uses Quesa. Though I can understand why
people may feel Quesa isn't adequate for their needs.

Frank.
------------
Open Source RB Plugins and Classes
<http://developer.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: REALbasicGL
Date: 29.03.05 03:16 (Mon, 28 Mar 2005 21:16:01 -0500)
From: Asher Dunn

On Mar 28, 2005, at 12:32 AM, cap'n bishop wrote:

> I'm starting an open source framework for OpenGL in REALbasic (which
> should evolve into a game engine) as an alternative to RB3D.

Been there, done that, but I would be interested in seeing what you
come up with.

> I know there are others out there who would be interested in such a
> project, so I figured I might gather a few talented minds together and
> see what they might have developed already.
>
> Anyway I've got the beginings of some base code. An overall structure
> and the like.
>
> It would be nice to keep it somewhat similar to RB3D for the sake of
> those who are already familiar, but I also intend to maintain OpenGL's
> versatility.
>
> A good case of point would be that there's an RBGLObject class; but it
> only store information like position, orientation, scale, etc. This
> class then has a Render event, so a subclass would have to make use of
> this to do the actual drawing- this allows for any type of data
> structure, so if all you needed was a simple heightmap, then that's all
> you need to keep track of (why build a full data structure like a
> TriMesh when all you need is a two dimentional array?). The framework
> I'd like to build would ideally include several different sub object
> classes to cator to specific or general needs.

Sounds cool -- a slightly different approach than I took.

> Anyway I thought I'd see who else is interested out there.

I'm interested, but I would rather not contaminate your ideas with mine
until you have some working classes. Then maybe we can make a
best-of-both library.
Just my thoughts.

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>