gamedevlists-windows

[GD-Windows] Beep error on exit

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

When my app exits under the debugger, I hear the "Error beep" in the
background, but I don't see any complaints in the debugger output, nor
do any asserts fire.  Putting a breakpoint at the last line of main() I
don't get any beep errors either.

Is there a simple, slick way to put in a handler to get called when any
type of error crops up, that way stuff that is "broken but magically
fixed because the app's exiting anyway" can get fixed correctly on my
part.

Thanks,

Brian

[GD-Windows] Process communication

[David H. <da...@em...>]

Very soon I'm going to be moving our currently very messy data storage
scheme consisting of hundreds of seperate sound/texture/binary files into a
properly managed data solution (ugh I've already started talking MS
techno-babble - I'll be using words like "leverage" and calling all our
projects solutions soon).

So...
    Our shiny new system needs to be client server based. All
artists/content providers compile their data into a single large database
residing on a seperate machine (or locally for debug purposes). Obviously to
manage all this more than blind file sharing is needed - I don't want to
have to wait 10 minutes whilst artist A copies his data over and keeps the
file locked. I need to send my data to a server application that controls
database access in a fair/interleaved monolithic timely safe fashion. The
server needs to be able to defrag the database in its spare time and clients
need to be able to browse it quickly, detemine changes and synchronise data
that has changed locally.

    The data storage format has to be understandable by the game and cross
platform so SQL or whatever probably isn't on the cards (I think?).

    I want this to run on win 98 machines up - but I suppose at a pinch we
could set the bar at ME/NT.

    What mechanisms should I be looking at in Windows for remote
inter-object communication?


David Hunt (Empire Interactive)

RE: [GD-Windows] Process communication

[Jon W. <hp...@mi...>]

The official solution is DCOM. Unfortunately, that's about as far 
from designed-for-games as you can come. In games, the real-time 
nature of a message ("I want it now") is much more important than 
something like "reliable, in-sequence delivery". This means that 
any RPC-like mechanism is doomed to failure, except for non-time-
critical operations. Of course, those, you'd like to take care of 
before the game even starts, using some protocol like rsync.

In your problem description, it was somewhat un-clear whether you 
were looking for a workflow/verioning system for in-house 
development and release management, or a run-time remote data 
management system. If what you meant was the former, I would 
suggest Perforce because of it's fast and flexible revision 
management, or possibly CVS because it's reliable and cheap.

Cheers,

			/ h+

>     What mechanisms should I be looking at in Windows for remote
> inter-object communication?

Re: [GD-Windows] Process communication

[David H. <da...@em...>]

Thanks Jon (*2;-)

    I'll look at DCOM. I'm not so much interested in managing multiple
resources or versioning, we find Sourcesafe adequate for that. I'm more
interested in developing a single monolihic (.wad) style file format
Gigabytes large containing all final/production binary assets of the game.

    In order to keep this database safe and allow timely shared access to it
I want to route all access to it through a server application (rather than
treating it as one big shared file on our network).

    I also need to understand the file format from within the game which
WILL just treat it as a big file (the game won't be a client, it will use a
local copy).

    This isn't a massive versioning exercise - all I want is a high capacity
pipe between myself and another application on another machine on our
intranet.


David Hunt

----- Original Message -----
From: "Jon Watte" <hp...@mi...>
To: "David Hunt" <da...@em...>;
<gam...@li...>
Sent: Monday, March 04, 2002 5:50 PM
Subject: RE: [GD-Windows] Process communication


>
> The official solution is DCOM. Unfortunately, that's about as far
> from designed-for-games as you can come. In games, the real-time
> nature of a message ("I want it now") is much more important than
> something like "reliable, in-sequence delivery". This means that
> any RPC-like mechanism is doomed to failure, except for non-time-
> critical operations. Of course, those, you'd like to take care of
> before the game even starts, using some protocol like rsync.
>
> In your problem description, it was somewhat un-clear whether you
> were looking for a workflow/verioning system for in-house
> development and release management, or a run-time remote data
> management system. If what you meant was the former, I would
> suggest Perforce because of it's fast and flexible revision
> management, or possibly CVS because it's reliable and cheap.
>
> Cheers,
>
> / h+
>
> >     What mechanisms should I be looking at in Windows for remote
> > inter-object communication?
>
>
>

RE: [GD-Windows] Process communication

[Jon W. <hp...@mi...>]

>     I'll look at DCOM. I'm not so much interested in managing multiple
> resources or versioning, we find Sourcesafe adequate for that. I'm more

To each his own, I guess :-)

> interested in developing a single monolihic (.wad) style file format
> Gigabytes large containing all final/production binary assets of the game.

You might want to make part of your build process be to re-generate
the wad file(s) from sources, with actual dependency maps. That way,
you have full control of what goes into it, and it's never fragmented
or out of date. You could do it on each client as part of make; the
only cost is extra disk space and sync time. Of course, with SourceSafe,
that might become a problem.

>     This isn't a massive versioning exercise - all I want is a
> high capacity
> pipe between myself and another application on another machine on our
> intranet.

I see. Basically, the remote-ness only comes into play in the development
environment, and it's there because you want one master machine that
stores and keeps assets, rather than having the assets and file building
go through source control to the clients.

Anything works, there. You might consider just banging something out with
raw sockets. Or you could use Apache with a plug-in and wrap it all in
HTTP. Or you could use network mounts and proper file locking. I'd prefer
either of these solutions to having to write and use something RPC-like
(such as DCOM). Yes, I'm no great RPC fan :-)

Cheers,

			/ h+

Re: [GD-Windows] Process communication

[Kent Q. <ken...@co...>]

Seems to me you're confusing two problems here:

a) Keeping a centralized set of assets everyone can use for development
b) Building the asset set for the game use

A system that's tuned for use by the game is probably going to be a mess
trying to update it during development, and vice-versa.

I suggest you make two systems -- one that's easy to maintain, and one
that's fast and compact for the game. Make the game software capable of
using both.

What we did (using Quake I's rudimentary but adequate-at-the-time .pak
file format) was make our game read all pakfiles AND the local
filesystem for all assets. The most recent version of the asset found
was used. It meant you could replace an asset simply by dropping a copy
into the local filesystem.

In your case, you're looking to use a networked system. What I'd do is
have your server keep a master directory that contains pointers to the
most current version of stuff, some of which will be in the master
archive file. Every night when no one's around, rebuild the master
archive from the most current assets. During the day, when someone
updates an asset, you just change the pointer in the directory.

If you need to make a local copy of the archive, you either have to wait
for it to build you a complete local copy, or you replicate the
directory functionality on the local machine.

I hope I haven't misunderstood your problem.

	Kent


David Hunt wrote:
> 
> Thanks Jon (*2;-)
> 
>     I'll look at DCOM. I'm not so much interested in managing multiple
> resources or versioning, we find Sourcesafe adequate for that. I'm more
> interested in developing a single monolihic (.wad) style file format
> Gigabytes large containing all final/production binary assets of the game.
> 
>     In order to keep this database safe and allow timely shared access to it
> I want to route all access to it through a server application (rather than
> treating it as one big shared file on our network).
> 
>     I also need to understand the file format from within the game which
> WILL just treat it as a big file (the game won't be a client, it will use a
> local copy).
> 
>     This isn't a massive versioning exercise - all I want is a high capacity
> pipe between myself and another application on another machine on our
> intranet.
> 
> David Hunt
> 
> ----- Original Message -----
> From: "Jon Watte" <hp...@mi...>
> To: "David Hunt" <da...@em...>;
> <gam...@li...>
> Sent: Monday, March 04, 2002 5:50 PM
> Subject: RE: [GD-Windows] Process communication
> 
> >
> > The official solution is DCOM. Unfortunately, that's about as far
> > from designed-for-games as you can come. In games, the real-time
> > nature of a message ("I want it now") is much more important than
> > something like "reliable, in-sequence delivery". This means that
> > any RPC-like mechanism is doomed to failure, except for non-time-
> > critical operations. Of course, those, you'd like to take care of
> > before the game even starts, using some protocol like rsync.
> >
> > In your problem description, it was somewhat un-clear whether you
> > were looking for a workflow/verioning system for in-house
> > development and release management, or a run-time remote data
> > management system. If what you meant was the former, I would
> > suggest Perforce because of it's fast and flexible revision
> > management, or possibly CVS because it's reliable and cheap.
> >
> > Cheers,
> >
> > / h+
> >
> > >     What mechanisms should I be looking at in Windows for remote
> > > inter-object communication?
> >
> >
> >
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________

Re: [GD-Windows] Process communication

[David H. <da...@em...>]

Jon and Kent thanks, I'll take what you both say about maintaining parallel
component based systems on board.

    But it seems to me that once you go the step of deciding you need to
compile to a big flat file for production data you might just as well design
around this big file in the first place and also design all the
associative/dependency stuff straight in there.
    Eg. If I know level 4 is dependant on Texture "brick4" with crc 0x12345,
why not simply store all that dependency stuff straight into the database
along with the texture and the level assuming I can make the process as fast
as a file copy (or similair through version control software). Once you've
written your core delete record,add record,replace record functionality I
can knock an entire level out of the database and come back in the morning
to find all data which makes up "level 4" gone except for shared
textures/objects.

:)


David