gamedevlists-general — List for discussing general game development issues

[GD-General] opensource for online play

[Mike W. <mi...@ub...>]

Hey all.

We've been slowly setting up the inner workings of the network play for 
our engine. One thing that has come up is the fact that our engine also 
happens to be Open Source, so how do we deal with security issues for 
hacking online games when we are giving the hackers all of our source code.

We've decided that the network side of things will be a .lib that we 
distribute, along with the source, for people that need to recompile the 
engine....most users don't, so this is no big deal...
 
This still leaves us with the problem of having someone create a stub 
exe using our network lib to create hacker tools mind you...

i've considered having some kind of 'GUID' or 'security passcode' that 
the game needs to validate, almost like the WonID system, only for the 
game itself, before the game server lets the client connect...

Perhaps some sort of time/date stamp authentication, along with a check 
of the exe's size (to make sure it's not hacked), etc...but overall, 
none of these systems seem to respect our 'open source roots'...

My company is moving into the position of being the sole administrators 
of the 'master servers' for the entire engine, as such as are setting up 
the master servers, chat/lobby servers and the like, as well as 
providing game server hosting for developers that are looking for 
affordable game server hosting (and publishing)...anyways..

i'd like to balance somehow the security issues (which proprietary 
closed source games can't seem to handle, let alone open source ones) 
with the open source traditions of our engine.

any suggestions on ways to proceed?  the GUID seems to be the most 
common sense method, but anyone with a hexcode reader can grab the GUID 
(and any kind of 'hard-coded' password that we include in the exe) and 
defeat the system...

anyone else been through this before and come up with any solutions?

the engine is called 'reality factory' - site is at 
http://rfactory.uber-geek.ca

screens of the multiplayer maps in action - 
http://www.uber-geek.ca/games/turing/ctf/

anyways...i'm curious how (if) people have managed this before, and what 
techniques they've used to provide security for your client applications...

cheers

mike w
www.uber-geek.ca

RE: [GD-General] Galaxy HQ, major trouble

[Brian H. <bri...@py...>]

He's been unsubbed, no worries -- we have the technology =3D)

On Sun, 9 Feb 2003 20:07:57 -0000, Gareth Lewin wrote:
>Ok, this is not funny anymore.
>
>I think he is "playing"
>http://www.pbm.com/~lindahl/pbm_list/descriptions/galaxyng.html
>
>Please stop.

RE: [GD-General] Galaxy HQ, major trouble

[Gareth L. <GL...@cl...>]

Ok, this is not funny anymore.

I think he is "playing"
http://www.pbm.com/~lindahl/pbm_list/descriptions/galaxyng.html

Please stop.

> -----Original Message-----
> From: Steven Webb [mailto:st...@ba...]
> Sent: 09 February 2003 19:38
> To: gam...@li...
> Subject: [GD-General] Galaxy HQ, major trouble
> 
> 
> 
> O wise leader your mail did not contain any orders.
> Remember orders start with,
>  #GALAXY <Galaxy Name> <Nation Name> <Password>
> and end with,
>  #END
> 
> Your orders have been discarded!
> Please correct the mistake and retransmit your orders.
> 
> 
> GalaxyNG release-5-0g, March 2001.
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] Galaxy HQ, major trouble

[Colin F. <cp...@ea...>]

#GALAXY "Milky Way" "USA" "admin"

  Give me all the money you can find!

  Transfer my brain to a robot body
  with all the latest FEATURES, if you
  know what I mean.

  Cure all diseases, end hunger, and
  bring peace to all planets in our
  sector.

  Improve the reception on my cellular
  phone.

  And stop discarding my orders, because
  of "syntax errors".  I'm your wise leader,
  and it's time for you to start acting like
  a loyal subject.  Obey!

  Oh, and maybe change the default password
  for these galaxy commands...  Hackers know
  that we can't afford good system administrators
  for our galaxies after our dot-com flameout.
  How many Big Bangs must we suffer before we
  wake up to the hostile world of hackers?!

#END




----- Original Message ----- 
From: "Steven Webb" <st...@ba...>
To: <gam...@li...>
Sent: Sunday, February 09, 2003 10:14 AM
Subject: [GD-General] Galaxy HQ, major trouble


> 
> O wise leader your mail did not contain any orders.
> Remember orders start with,
>  #GALAXY <Galaxy Name> <Nation Name> <Password>
> and end with,
>  #END
> 
> Your orders have been discarded!
> Please correct the mistake and retransmit your orders.
> 
> 
> GalaxyNG release-5-0g, March 2001.

[GD-General] Galaxy HQ, major trouble

[Steven W. <st...@ba...>]

O wise leader your mail did not contain any orders.
Remember orders start with,
 #GALAXY <Galaxy Name> <Nation Name> <Password>
and end with,
 #END

Your orders have been discarded!
Please correct the mistake and retransmit your orders.


GalaxyNG release-5-0g, March 2001.

Re: [GD-General] Good field recorder recommendations?

[Brian H. <bri...@py...>]

On Sun, 09 Feb 2003 00:12:00 -0600, Dave Barrett wrote:
>
>The newer Sony NetMDs (new MD players) have USB connections and
>line-in/mic-in.  I think MZ-N707 and MZ-N1 are the models, but=
 you
>should probably check that.  I know of a few audio guys who=
 have
>those handy with their own mics for input.

Those are good units, but they have a major flaw in that they=
 won't 
transfer from MD->PC.  The software is designed to rip and burn 
CD/MP3 to ATRAC/MD format, and supposedly Sony isn't too keen on=
 the 
idea of people being able to trivially transfer from MD to PC=
 (i.e. 
they don't want it to be a piracy vector).

Thanks,

Brian

[GD-General] Galaxy HQ, major trouble

[Steven W. <st...@ba...>]

O wise leader your mail did not contain any orders.
Remember orders start with,
 #GALAXY <Galaxy Name> <Nation Name> <Password>
and end with,
 #END

Your orders have been discarded!
Please correct the mistake and retransmit your orders.


GalaxyNG release-5-0g, March 2001.

Re: [GD-General] Good field recorder recommendations?

[Dave B. <bo...@au...>]

    The newer Sony NetMDs (new MD players) have USB connections and
line-in/mic-in.  I think MZ-N707 and MZ-N1 are the models, but you should
probably check that.  I know of a few audio guys who have those handy with
their own mics for input.

Dave Barrett



On 2/5/03 4:33 PM, "Brian Hook" <bri...@py...> wrote:

> And now for something way out of left field -- I'm looking for a
> decent portable field recorder.  Back in the day, the DATMan was the
> way to go, followed by the various MD recorders.  Unfortunately data
> transfer had to be done either analog or through a SPDIF connection,
> neither of which are particularly convenient in this day of USB
> mounting of remote devices.
> 
> Today it would seem obvious that solid state recording to CF,
> MemoryStick and the like is the way to go, but I'm amazed at how
> expensive some of these devices are -- over $1000 is fairly common
> for a decent recorder that supports CF.
> 
> Does anyone have any recommendations for a decent field-recorder --
> reasonably portable, USB connectivity or removable storage of some
> type, and which does standard WAV/AIFF 44.1/48 recording?  The iPod
> and the various other MP3 recorders would be great, but most such
> devices don't have recording facilities or they automatically
> compress.
> 
> -Hook
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

RE: [GD-General] Multiple Inheritance and RTTI

[Kyle W. <ky...@ga...>]

> This is one of those times where I wish I'd looked more carefully at
> what I wrote before sending it.  My comments sound pretty uncharitable
> but this company has a lot of talented people who have done some really
> great stuff.

Software development is, unfortunately, full of really, really dumb ideas
whose stupidity only becomes obvious after they've become an integral part
of your architecture.  I think most of us have done things that in various
ways have worked out as badly as re-implementing IUnknown.

Regards,
Kyle

RE: [GD-General] Multiple Inheritance and RTTI

[Donavon K. <kei...@ea...>]

This is one of those times where I wish I'd looked more carefully at
what I wrote before sending it.  My comments sound pretty uncharitable
but this company has a lot of talented people who have done some really
great stuff.  I'm sure some people here know which company this is and
may even be working there, so if I stepped on any toes, I regret it.

--Charm School Dropout

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Donavon Keithley
> Sent: Saturday, February 08, 2003 12:28 AM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> Instantiating a class by some means other than CoCreateInstance[Ex] is
> not re-implementing COM.  Many, many standard COM objects are not
> co-creatable (if I remember the jargon correctly).  Like... D3D, for
> instance.
> 
> COM only has a few mandatory rules, like implementing IUnknown and
> adhering to certain QueryInterface semantics.  It's not much of an
> imposition and it leaves you open to interoperating with the rest of
the
> COM world.  Implement a typelib and adhere to some basic type rules
and
> your objects will be callable from Visual Basic and .NET.  Implement
> IDispatch and you open your objects up to the scripting world.
> 
> Just don't do what one company I know did, and that's redefine
IUnknown.
> They called it "IUnknown", it had QI, AddRef, and Release, but IIDs
were
> strings, not GUIDs.  So their "custom" COM system looked just like
COM,
> but it was totally incompatible.  There was no possibility of interop
> and where they could have taken advantage of ATL's rich set of
classes,
> they instead had to redefine their own macros and template classes.
> 
> It was an utterly pointless exercise in NIH.
> 
> Donavon

RE: [GD-General] Multiple Inheritance and RTTI

[Donavon K. <kei...@ea...>]

Instantiating a class by some means other than CoCreateInstance[Ex] is
not re-implementing COM.  Many, many standard COM objects are not
co-creatable (if I remember the jargon correctly).  Like... D3D, for
instance.

COM only has a few mandatory rules, like implementing IUnknown and
adhering to certain QueryInterface semantics.  It's not much of an
imposition and it leaves you open to interoperating with the rest of the
COM world.  Implement a typelib and adhere to some basic type rules and
your objects will be callable from Visual Basic and .NET.  Implement
IDispatch and you open your objects up to the scripting world.

Just don't do what one company I know did, and that's redefine IUnknown.
They called it "IUnknown", it had QI, AddRef, and Release, but IIDs were
strings, not GUIDs.  So their "custom" COM system looked just like COM,
but it was totally incompatible.  There was no possibility of interop
and where they could have taken advantage of ATL's rich set of classes,
they instead had to redefine their own macros and template classes.  

It was an utterly pointless exercise in NIH.  

Donavon

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Gareth Lewin
> Sent: Thursday, February 06, 2003 4:31 AM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> COM basics are extremly simple to implement.
> 
> You really need a standard way to implement a "Give me this interface"
> function. (QueryIterface)
> A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> And a base interface that concreate class implements.  (IUnknown)
> 
> A lot of COM also uses Factories, Ref counting and sometimes smart
> pointers.
> They are not needed, but tend to fit well ( For example ref counting
works
> nice with QueryInterface because you might have a few interfaces to
the
> same
> object ).
> 
> Again, Inside COM is a must read if you plan on having a COM like
system.
> 
> > -----Original Message-----
> > From: gekido [mailto:mi...@ub...]
> > Sent: 05 February 2003 21:30
> > To: gam...@li...
> > Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >
> >
> > with this said, anyone know of any opensource projects
> > implementing a base
> > COM-style cross-platform & cross-compiler library out there?
> >
> > surely there must be someone that's done the hard part for us ;}
> >
> > just curious
> >
> > mike w
> > www.uber-geek.ca
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

Re: [GD-General] Multiple Inheritance and RTTI

[brian s. <pud...@po...>]

I think that might be too much of a simplification.  The ability to 
dynamic_cast implies object identity.  If I can dynamic_cast from 
InterfaceA * to InterfaceB *, I know that the pointer I'm holding 
points to an object that is both an InterfaceA * and a InterfaceB *.

QueryInterface doesn't mandate that.  If I query for InterfaceB* from 
an InterfaceA * pointer, I might get back a pointer that points to the 
same object as the InterfaceA *, like dynamic_cast would return.  But I 
could very well get back a pointer to a completely different object; 
the object pointed to by InterfaceA * could just as well return a 
pointer to a InterfaceB* member (see my previous post re: aggregation).

Why might I want to do that?  A few reasons:

1) I can inherit the behavior of an InterfaceB implementation without 
having that implementation exposed to me at all.  All I need is the 
definition of InterfaceB and a factory function that can create an 
object to implement InterfaceB for me.

2) I might want to delay creating an InterfaceB object until it's 
needed, if I know that it's heavyweight.

All that COM requires of QueryInterface is (1) consistency: if you can 
get an interface once, you can always get it and (2) identity: if you 
can get an InterfaceB * from an InterfaceA *, you can go back to the 
InterfaceA * from the InterfaceB *.  dynamic_cast goes further and 
implies an "is-a" relationship between InterfaceA and InterfaceB.

--brian

On Thursday, February 6, 2003, at 06:12  AM, Thatcher Ulrich wrote:

> To try to cut through the terminology a little:
>
> COM == RTTI

Re: [GD-General] Multiple Inheritance and RTTI

[Thatcher U. <tu...@tu...>]

On Feb 06, 2003 at 10:31 -0000, Gareth Lewin wrote:
> COM basics are extremly simple to implement.
> 
> You really need a standard way to implement a "Give me this interface"
> function. (QueryIterface)
> A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> And a base interface that concreate class implements.  (IUnknown)

To try to cut through the terminology a little:

COM == RTTI

    QueryInterface == dynamic_cast
    GUID == typeid
    IUnknown == any polymorphic class

Obviously the details vary.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Multiple Inheritance and RTTI

[Gareth L. <GL...@cl...>]

> But I asked for a real example (read taken from a real 
> project) of using
> (not implementing) the QI pattern, an example that demonstrates the
> superiority of QI over the alternatives.

Sorry, missunderstood. What are the alternatives that you want to compare it
with ? Internet explorer is an example I guess.

> FWIW, for the QI implementation, I prefer a 
> dynamic_cast-style interface:
> 
> if(IRenderable * p = queryInterface<IRenderable>(q))
> {
> // do stuff
> }

There are pros and cons to that. I prefer returning an error code like
HRESULT because the reason for the failure could be important. But it's a
matter of taste

> (when I feel like reinventing dynamic_cast at all, that is.)

COM isn't just a RTTI replacement. I personally use dynamic_cast in some of
my projects, but not as a way to build a concrete class out of interfaces.

YMMV I guess.

Re: [GD-General] Multiple Inheritance and RTTI

[Peter D. <pd...@mm...>]

Gareth Lewin wrote:
>> Out of curiosity, can someone post a real example of using the
>> QueryInterface pattern (in performance-critical code)?
>
> QueryInterface is fairly quick. A lot depends on the number of
> interfaces you are implementing per object.
>
> But most things use macros like
>
> (note, this is psuedo code.)
>
> START_INTERFACELIST
> ADD_INTERFACE(IID_IRender)
> ADD_INTERFACE(IID_IFoo)
> END_INTERFACELIST
>
> which becomes somethinglike
>
> bool QueryInterface(GUID iid, void** ppObject)
> {
> if (iid == IID_IRender)
> {
> (*ppObject) = reinterpret_cast<void*>(this);
> return true;

[...]

Thanks. :-)

But I asked for a real example (read taken from a real project) of using
(not implementing) the QI pattern, an example that demonstrates the
superiority of QI over the alternatives.

FWIW, for the QI implementation, I prefer a dynamic_cast-style interface:

if(IRenderable * p = queryInterface<IRenderable>(q))
{
// do stuff
}

(when I feel like reinventing dynamic_cast at all, that is.)

RE: [GD-General] Multiple Inheritance and RTTI

[Jamie F. <ja...@qu...>]

indeed; we use a cross platform version of COM in our engine.

not very helpful link:

http://www.qubesoft.com/docs/q-docs/qcom/faq.html

jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Gareth Lewin
Sent: 05 February 2003 20:48
To: gam...@li...
Subject: RE: [GD-General] Multiple Inheritance and RTTI


> > Personally I find COM very good at exactly what you want.
> 
> Except for the cross platform thing.

I specifically addressed that issue. COM is an idea not a tool. It can be
implemented on any platform. and as I said in my original post,
reimplementing the basics is a Good Thing because there is a lot ( Like
using the registry to find objects ) that you don't need from COM.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557

RE: [GD-General] Multiple Inheritance and RTTI

[Gareth L. <GL...@cl...>]

COM basics are extremly simple to implement.

You really need a standard way to implement a "Give me this interface"
function. (QueryIterface)
A standard way of iding interfaces (GUIDs or FourCCs or whatever)
And a base interface that concreate class implements.  (IUnknown)

A lot of COM also uses Factories, Ref counting and sometimes smart pointers.
They are not needed, but tend to fit well ( For example ref counting works
nice with QueryInterface because you might have a few interfaces to the same
object ).

Again, Inside COM is a must read if you plan on having a COM like system.

> -----Original Message-----
> From: gekido [mailto:mi...@ub...]
> Sent: 05 February 2003 21:30
> To: gam...@li...
> Subject: Re: [GD-General] Multiple Inheritance and RTTI
> 
> 
> with this said, anyone know of any opensource projects 
> implementing a base
> COM-style cross-platform & cross-compiler library out there?
> 
> surely there must be someone that's done the hard part for us ;}
> 
> just curious
> 
> mike w
> www.uber-geek.ca

RE: [GD-General] Multiple Inheritance and RTTI

[Gareth L. <GL...@cl...>]

>
> > Every frame we quickly cull out any scene nodes that are not visible
> > from a camera, and then for each scene node we query to see if they
> > implement the IRenderable interface.  If they do, they get a render
> > call.
> 
> Yes, I envisioned something like that.
> 
> What are the advantages of this approach over just providing 
> a (possibly
> empty) render() in every node type? A virtual call can never 
> lose to a QI +
> test + potential call.

It depends on the number of functions you have in the base class. If it's
just Render then sure, that's fine. But if you have 4 or 5 functions in each
interface and say 20 interfaces in the system ( with an average of 2-3 per
concrete object ) that would end up as 100 pure virtual functions, which
starts to get messy.

RE: [GD-General] Multiple Inheritance and RTTI

[Gareth L. <GL...@cl...>]

> Out of curiosity, can someone post a real example of using the
> QueryInterface pattern (in performance-critical code)?

QueryInterface is fairly quick. A lot depends on the number of interfaces
you are implementing per object.

But most things use macros like

(note, this is psuedo code.)

START_INTERFACELIST
	ADD_INTERFACE(IID_IRender)
	ADD_INTERFACE(IID_IFoo)
END_INTERFACELIST

which becomes somethinglike

bool QueryInterface(GUID iid, void** ppObject)
{
	if (iid == IID_IRender)
	{
		(*ppObject) = reinterpret_cast<void*>(this);
		return true;
	}
	if (iid == IID_IFoo)
	{
		(*ppObject) = reinterpret_cast<void*>(this);
		return true;
	}
	(*ppObject)=0;
	return false;
}

GUIDs can be anything. You could go the extreme "time+network card" which is
overkill. FourCCs work very well as well. As long as you make sure not to
clash. Depends on the size of the team I guess.

If you have a lot of interfaces per concrete class you might need a diff
solution.

RE: [GD-General] Multiple Inheritance and RTTI

[Nicolas R. <nic...@fr...>]

Well, I always managed to compile the simplest (and yet most
interesting) part of COM on any compiler I have ever found for ages
(like CW3 on MAC).

struct IUnknown
{
	virtual	HRESULT	QueryInterface(const GUID& id, void** ppOut) =
0;
	virtual	HRESULT	AddRef(void) = 0;
	virtual	HRESULT	Release(void) = 0;
};

Note that appart from the "GUID" and the "HRESULT" (that can be replaced
by virtually anything, though me think the windows declaration is good
enough), there is absolutely NO specific platform thing...

Of course, you wont have the threading model, the CoCreateInstance stuf,
and so on... But I really feel that for a game that should not be too
annoying, especially if you already have a set of factories for your
entities, a CreateInstance class is not too difficult to implement.


Nicolas Romantzoff.



-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
phi...@pl...
Except for the cross platform thing.

Cheers,
Phil

RE: [GD-General] Multiple Inheritance and RTTI

[Jay W. <woo...@Ro...>]

With a single virtual call to a parameterless Render function, there's =
not an advantage.  But in other situations and/or for other reasons, a =
QueryInterface style does have advantages:

1) When you want to call multiple functions offered by a single =
interface, you can query once, test once, then call many times with =
impugnity.  That's quite possibly more efficient than calling a bunch of =
potentially-empty virtual stubs.

2) Using a QueryInterface style allows you to avoid making the function =
call entirely.  If you use many virtual functions in place of an =
interface, and if the functions take many parameters, you'll still have =
to spend time pushing those parameters onto the stack, even if the =
function turns out to be just an empty stub.  (Compiler gurus please =
correct or clarify, but I'm sure this is usually true.)

3) At development time, you won't have to alter the virtual base class =
every time you want to add new functionality.


> -----Original Message-----
> From: Peter Dimov [mailto:pd...@mm...]
> Sent: Wednesday, February 05, 2003 1:25 PM
> To: gam...@li...
> Subject: Re: [GD-General] Multiple Inheritance and RTTI
>
> What are the advantages of this approach over just providing=20
> a (possibly empty) render() in every node type? A virtual call can =
never=20
> lose to a QI + test + potential call.

Re: [GD-General] Good field recorder recommendations?

[Colin F. <cp...@ea...>]

2003 February 5th
Wednesday

I'm not contributing very much to this thread when I
say that I bought a digital recorder with USB that
looked and cost like a microcassette recorder -- 
and, to my surprise (NOT!), it sounded just like
a microcassette recorder, even when I attached 
a professional microphone to it, uploaded the
resulting audio file to my PC, and played it
on decent speakers.

I don't understand why even the cheapest consumer
electronic devices have anything less than AWESOME
frequency response and recording quality.

My Nomad II MP3 player sounds AWESOME but can only
record "live" audio through a built-in microphone,
and my keychain USB drive holds 256MB, so why can't
someone build an inexpensive device to record 
sound over the full range of hearing (20Hz --> 20kHz)?

Maybe a small laptop computer isn't a bad way to
do this stuff!  The sound input can be pretty
good, and you have lots of recording format options,
and you could burn a CD-ROM on location!

--- Colin

cp...@ea...

[GD-General] Good field recorder recommendations?

[Brian H. <bri...@py...>]

And now for something way out of left field -- I'm looking for a=
 
decent portable field recorder.  Back in the day, the DATMan was=
 the 
way to go, followed by the various MD recorders.  Unfortunately=
 data 
transfer had to be done either analog or through a SPDIF=
 connection, 
neither of which are particularly convenient in this day of USB 
mounting of remote devices.

Today it would seem obvious that solid state recording to CF, 
MemoryStick and the like is the way to go, but I'm amazed at how=
 
expensive some of these devices are -- over $1000 is fairly=
 common 
for a decent recorder that supports CF.

Does anyone have any recommendations for a decent field-recorder=
 -- 
reasonably portable, USB connectivity or removable storage of=
 some 
type, and which does standard WAV/AIFF 44.1/48 recording?  The=
 iPod 
and the various other MP3 recorders would be great, but most such=
 
devices don't have recording facilities or they automatically 
compress.

-Hook

Re: [GD-General] Multiple Inheritance and RTTI

[<cas...@ya...>]

gekido wrote:
> with this said, anyone know of any opensource projects implementing a base
> COM-style cross-platform & cross-compiler library out there?
>
> surely there must be someone that's done the hard part for us ;}

You may want to have a look at mozilla XPCOM. It's not hard to implement it
yourself, though.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

Re: [GD-General] Multiple Inheritance and RTTI

[Noel L. <ll...@co...>]

On Wed, 05 Feb 2003 23:24:54 +0200
Peter Dimov <pd...@mm...> wrote:

> > Every frame we quickly cull out any scene nodes that are not visible
> > from a camera, and then for each scene node we query to see if they
> > implement the IRenderable interface.  If they do, they get a render
> > call.
> 
> Yes, I envisioned something like that.
> 
> What are the advantages of this approach over just providing a (possibly
> empty) render() in every node type? A virtual call can never lose to a QI +
> test + potential call.

Clearly, it's not there for performance reasons. The main thing it buys
us is some clarity (and maintainability) by keeping the interface of
each type of scene node to a minimum size. Especially if you use many
potentially different interfaces, things could get pretty cluttered.

It also makes it easier to create new types of objects. If I create a
new scene node I might not be sure exactly what functions I need to
override so it renders correctly. As soon as I inherit from IRenderable
things are very clear (and if they aren't, the compiler will remind me
to implement all those pure virtual functions).

In our case we ended up not having as many different types of scene
nodes or as many different interfaes as I initially anticipated, so we
could very well have folded the few functions in IRenderable back into
the SceneNode class.

I think that another potential advantage is that the QueryInterface
method might work better in a very heterogeneous environment, where you
are manipulating objects of all sorts of types, without a common base
class. Requiring that they all implement all the possible common
functions would be a total pain. But I haven't seen that in practice.


--Noel
ll...@co...