gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Level Editing

[Javier A. <ja...@py...>]

phi...@pl... wrote:

> Or indeed, any other tools that people
> are writing plug-ins for.

I guess it doesn't count, but after the recent Photoshop 7's braindead
monkeying around with TGA's alpha channel (and their terribly unhelpful
developer relations - almost worse than not having one at all, their
standard response to any question is "you are wrong"), I decided to write a
Photoshop plugin myself, either a transparency filter or a TGA file format.
Simple thing...

I was horrified at what I saw after installing the SDK. What a terrible
mess. Projects linked to sourcesafe databases, wrong file headers included
on PC, samples that Just Don't Work... 3DS4 IPAS programming seemed like a
blessing in comparison. I mean, it _can_ be done, but it was not going to be
the couple-hour hack such a simple thing should have been. In the end I
talked with my lead artist and we figured out a Photoshop action to help us
with the whole alpha / transparency mess. They're sticking with Photoshop 6
as well, Adobe's not getting upgrade money from us this year.

Sorry I had to get out of my chest. :)

  Javier Arevalo
  Pyro Studios

Re: [GD-General] Level Editing

[<phi...@pl...>]

This is pretty much what we do, only with Maya. We're happy with the Maya
SDK, and MEL scripting is very flexible, allowing you to knock up new bits
if UI very quickly . My only concern is  that of tying yourself to the
fortunes of one particular package. Fortunately both Max and Maya seem to
be staying the course. I would be interested to hear if there are any other
modelling packages that people have gone down this route with though. Or
indeed, any other tools that people are writing plug-ins for.

Cheers,
Phil

PS Especially if anyone's tied their mast to an open-source package.



                                                                                                                                          
                    "Evan Bell" <eb...@au...>                                                                                   
                    Sent by:                                     To:     <gam...@li...>                     
                    gam...@li...urc       cc:                                                                      
                    eforge.net                                   Subject:     Re: [GD-General] Level Editing                              
                                                                                                                                          
                                                                                                                                          
                    09/03/2002 10:53 PM                                                                                                   
                                                                                                                                          
                                                                                                                                          




> - do all the editing inside 3ds Max

So far using Max has worked well for us.
We use a plug-in( called the "Populator" ) to create game objects.
It is important that you have a general mechanism for creating game objects
in Max.
Unless you want to script + code every dialogue needed for an exhaustive
list of game objects.
We also keep the max files in source control, and export fresh game data
when necessary.
This allows modellers to easy modifiy levels by importing data from other
max files.
Using Max also allows use of other game related plug-ins, like the Havok
exporter.

The draw backs with Max approach are as follows:
Total system hog: even after it is shut down it slows down gcc builds.
Dependency on the poorly documented, sometimes buggy, Max SDK.

However, if you build your own editor, it easier to support a MOD community
because you can
ship it with the game.

Evan Bell
ev...@ed...
www.edgeofreality.com






-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
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] Level Editing

[Evan B. <eb...@au...>]

> - do all the editing inside 3ds Max

So far using Max has worked well for us.
We use a plug-in( called the "Populator" ) to create game objects.
It is important that you have a general mechanism for creating game objects
in Max.
Unless you want to script + code every dialogue needed for an exhaustive
list of game objects.
We also keep the max files in source control, and export fresh game data
when necessary.
This allows modellers to easy modifiy levels by importing data from other
max files.
Using Max also allows use of other game related plug-ins, like the Havok
exporter.

The draw backs with Max approach are as follows:
Total system hog: even after it is shut down it slows down gcc builds.
Dependency on the poorly documented, sometimes buggy, Max SDK.

However, if you build your own editor, it easier to support a MOD community
because you can
ship it with the game.

Evan Bell
ev...@ed...
www.edgeofreality.com

RE: [GD-General] Level Editing

[Philip H. <ph...@me...>]

We go for the third option...

> - editor
> Build a 3d editor with tools to modify or create the level and provide

> a
> simple interface to import data from Max.
> This could be the better choice but it's an huge amount of work and 
> modellers'll probably complain because 'it's not max'.

Yes it is a lot of work but there are plenty of advantages. For example
our current editor lets you pause the game, switch to edit mode, make a
change then resume playing from where you left off.

Philip Harris
Batfish Studios Ltd
http://www.batfishstudios.com
 

Re: [GD-General] Level Editing

[Javier A. <ja...@py...>]

Tiziano Lena <tl...@li...> wrote:

> changes in the 3d level during the development. For a game (such as a
> FPS) there are a lot of other informations
> that are needed (such as trigger positions, paths, custom shaders,
> lights). Well, every time that a modified level is exported from Max
> this data is lost and it needs to be reimported.

You might try using custom data => text you can add to your objects,
materials, etc inside MAX.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] Level Editing

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

On Sep 01, 2002 at 05:02 +0200, Tiziano Lena wrote:

> I have a problem in level editing and I wonder if anyone has any
> good idea.  Let's say that a game uses models created for example
> with 3DS Max and that there are several changes in the 3d level
> during the development. For a game (such as a FPS) there are a lot
> of other informations that are needed (such as trigger positions,
> paths, custom shaders, lights).  Well, every time that a modified
> level is exported from Max this data is lost and it needs to be
> reimported.  I thought about some alternatives but no one seems to
> me the silver bullet of level editing (if one exist :)).
> 
> do all the editing inside 3ds Max I think programming a plugin like
> this is not so easy... 

IMO MaxScript is pretty decent; you can knock out plugins reasonably
quick.  Max itself has some issues, but then so do all 3D editors.

> and what if the next project uses Maya or
> Lightwave?

Tough :)

These days I think making a plug-in of some type is the easiest route.

-- 
Thatcher Ulrich
http://tulrich.com

[GD-General] Level Editing

[Tiziano L. <tl...@li...>]

Hi to all!
I have a problem in level editing and I wonder if anyone has any good idea.
Let's say that a game uses models created for example with 3DS Max and that 
there are several
changes in the 3d level during the development. For a game (such as a FPS) 
there are a lot of other informations
that are needed (such as trigger positions, paths, custom shaders, lights).
Well, every time that a modified level is exported from Max this data is 
lost and it needs to be reimported.
I thought about some alternatives but no one seems to me the silver bullet 
of level editing (if one exist :)).

- do all the editing inside 3ds Max
I think programming a plugin like this is not so easy... and what if the 
next project uses Maya or Lightwave?

- merge
Starting from the old level the objects are merged in the new (empty) 
level. The problem is that some data are geometry
dependent (eg. shaders, paths) and can be lost or invalid.

- editor
Build a 3d editor with tools to modify or create the level and provide a 
simple interface to import data from Max.
This could be the better choice but it's an huge amount of work and 
modellers'll probably complain because 'it's not max'.
Thank you!

P.S. sorry for bad english 

RE: [GD-General] Scaling GUI graphics

[Phil T. <ph...@mi...>]

The file format is publicly available at macromedia:

http://www.macromedia.com/software/flash/open/licensing/fileformat/

I believe there are some errors in the documentation; however, there are
some corrections floating around on the web (once again google is your
friend here).

Phil

-----Original Message-----
From: phi...@pl...
[mailto:phi...@pl...]=20
Sent: Monday, August 26, 2002 1:53 PM
To: cor...@el...
Cc: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


Err, I reckon it probably took Bob a month of core programming, plus
ongoing support and maintanence. He's still tweaking and optimising it,
as
there's always something to improve (currently it's the text rendering).

I believe it's a binary format, but one that's well documented (I'd ask
Bob, but he's on holiday at the moment, I myself would have replied
earlier, but I've just come back from honeymoon;). The main saving was
one
of not having to write the front end editor, although obviously we still
had to write all the hooks.

Communication between the flash interpreter and the game code is a bit
hairy, but boils down to shared memory. The flash does all the menu
logic,
setting state variables which the game code polls. This meant that our
flash designer/artist/programmer (he's a flexible guy) could try
different
layouts and structures without hassling the programmers too much.

It was most definately worth the initial hassle, especially since we're
re-using all the code for our current project. The only thing that
worries
me is relying on an old version of the macromedia tools to enforce our
restrictions. Hopefully if more people start using it, Macromedia will
take
note.

As to rendering, everything is converted into tristrips, in a
pre-process.
I believe we can control anti-aliasing on a per-object basis, although
we
may have had to remove it for certain primitives. I think there were
issues
with spider-webbing on translucent objects.

Cheers,
Phil



=20

                    "Corrinne Yu"

                    <corrinne@elapsesof       To:
<phi...@pl...>                             =20
                    tware.com>                cc:

                                              Subject:     RE:
[GD-General] Scaling GUI graphics                      =20
                    08/19/2002 06:35 PM

                    Please respond to

                    corrinne

=20

=20





-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
phi...@pl...
Sent: Tuesday, June 25, 2002 2:40 PM
To: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

-- Cool. How long did it take you? (And was it worth it time wise?)

-- Did you read Flash 4 file format? Is it a text or binary file? It is
kind of cool because you saved programming time of programming the GUI
and programming time of programming a GUI editor (which very few
programmers make anyway).







-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

RE: [GD-General] Scaling GUI graphics

[<phi...@pl...>]

Err, I reckon it probably took Bob a month of core programming, plus
ongoing support and maintanence. He's still tweaking and optimising it, as
there's always something to improve (currently it's the text rendering).

I believe it's a binary format, but one that's well documented (I'd ask
Bob, but he's on holiday at the moment, I myself would have replied
earlier, but I've just come back from honeymoon;). The main saving was one
of not having to write the front end editor, although obviously we still
had to write all the hooks.

Communication between the flash interpreter and the game code is a bit
hairy, but boils down to shared memory. The flash does all the menu logic,
setting state variables which the game code polls. This meant that our
flash designer/artist/programmer (he's a flexible guy) could try different
layouts and structures without hassling the programmers too much.

It was most definately worth the initial hassle, especially since we're
re-using all the code for our current project. The only thing that worries
me is relying on an old version of the macromedia tools to enforce our
restrictions. Hopefully if more people start using it, Macromedia will take
note.

As to rendering, everything is converted into tristrips, in a pre-process.
I believe we can control anti-aliasing on a per-object basis, although we
may have had to remove it for certain primitives. I think there were issues
with spider-webbing on translucent objects.

Cheers,
Phil



                                                                                                                       
                    "Corrinne Yu"                                                                                      
                    <corrinne@elapsesof       To:     <phi...@pl...>                              
                    tware.com>                cc:                                                                      
                                              Subject:     RE: [GD-General] Scaling GUI graphics                       
                    08/19/2002 06:35 PM                                                                                
                    Please respond to                                                                                  
                    corrinne                                                                                           
                                                                                                                       
                                                                                                                       




-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
phi...@pl...
Sent: Tuesday, June 25, 2002 2:40 PM
To: gam...@li...
Subject: RE: [GD-General] Scaling GUI graphics


We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

-- Cool. How long did it take you? (And was it worth it time wise?)

-- Did you read Flash 4 file format? Is it a text or binary file? It is
kind of cool because you saved programming time of programming the GUI
and programming time of programming a GUI editor (which very few
programmers make anyway).

RE: [GD-General] physics and networking

[Aaron D. <ri...@in...>]

> The simple matter is that you can't trust client software anymore. You
> have to have an authoritative state-of-play machine.

Urrr. Not necessarily. In a lock-step peer-to-peer setup (such as the
original doom which just broadcast players controls to other players),
cheating is still not possible unless All players cheat as the game
would otherwise get out of sync on the cheaters PC.

- Aaron

Re[2]: [GD-General] physics and networking

[Cruise <cr...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

> -- I wonder what most of you decide to do in your code regarding physics
> chain reactions of moving objects.

> -- Does server arbitrate all large to small physics, which rock or which
> object gets pushed or bounced or rag-dolled to which positions?
If it could potentially affect another client, then yes. "Effects",
anything that is mere eye-candy, can be generated entirely on the client.
Explosions, bullet effects, decals, etc.

> -- Player positions rotation, even player opening doors, isn't such a
> big deal. Player motion that causes motion and position changes on a
> chain of other objects is a big deal.

> -- In a perfect world, every position of every object that moves must be
> arbitrated by server. Any object that has the potential of blocking or
> bouncing or twirling or pushing another object which eventually blocks a
> player must be centrally arbitrated.

Correct.

> -- In the non-perfect world, the number of arbitrating entities becomes
> really large the more an application displays physics-ness in the world.
> Do all of you really arbitrate and (continually) broadcast all these
> moving dynamic objects big and small 's absolute positions and not
> client predict them at all?

Fortunately, scale works for as well as against. You only
need to tell each client about the things within the PVS. Naturally,
if you're game world is a huge flat savannah, then the PVS will be
quite large. But, hopefully, the game world will be correspondingly
larger, and the physics "density" (the number of things that need to
be tracked) less.

Also, many things are deterministic (or have known random seeds), and
don't need to be broadcast continually. Once the intial angle and
velocity of a grenade is known, for example, the clients can /usually/
work out the path themselves.

That doesn't always hold true, obviously, especially if you have a
highly interactive enviroment. However, you can get away with a lower
broadcast frequency. Player states are the most important. You can
predict most everything else "good enough" as long as you know what
the players are doing.

> -- Or do you client predict some and "backtrack" when the server
> disagrees with the prediction? What are your backtrack methods if you do
> client predict.

Yes. That way the player can play quite happily until the next
broadcast. The client can work on it's own data until such time as the
server's becomes available.

In Half-Life, backtracking simply resets the positions to the server's
version. Because there tends to be little in the way of moving
objects, and fewer of any size or speed, this is an acceptable method.
Every so often a player will "flicker", but people are used to that online.

If speeds are high, or many noticable objects are being predicated,
then you require something more subtle, such as bringing the positions
into line over several frames. This can result in things rolling up
hill, and other weirdness, so it isn't ideal either. There isn't really
a good answer, unfortunately.

There is another difficult choice, too. An uncorrected difference can
mean enough motion to take someone out of cover on the client, while
in fact they stopped. If the local player then shoots this projected
version, what do you do? If you use the client's version, players
complain about being shot "round corners". If you use the servers
version, then players complain about seemingly "invulnerable"
opponents.

Again, Half-Life recently switched to the first method from the
second, as in general, it makes life much easier for clients on slower
connections. They don't have to worry about "leading" or
second-guessing other players so much, as if they shoot the version on
their machine, then it counts as a hit, even if the player wasn't in
actuality "there".

> -- I gratefully await your experience in these areas.



[ cruise / www.casual-tempest.net / www.transference.org ]

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUAPWTXG/di0Z5STRufAQEhMQP/ZFXsb04tFoA+eulkpMSICWvaF/uIwqIi
rbbczKjsgi9kiTZQoGR9tW6HN9Ah1tU7hJKwJymOsx9noyHZ/nS0ELdstflFO/yr
Q+8ITO+w5ykQSeCh76PH4Ia1+TdtKitID1FVjD6i0to9ZKKqqTTZXxhxwiX2NiEm
elllfbtF3Ng=
=xCgb
-----END PGP SIGNATURE-----

RE: [GD-General] physics and networking

[Corrinne Y. <cor...@el...>]

> The bookkeeping isn't bad for simple player position, rotation, etc.
But
> chains of complex physics reaction becomes quite a pain of the neck to
> be maintained and received from a "remote" arbitrator all the time. :(
> It easily "doubles" the code to type to have the server minds itself
> with so many complex collisions arbitrations. :(

-- I wonder what most of you decide to do in your code regarding physics
chain reactions of moving objects.

-- Does server arbitrate all large to small physics, which rock or which
object gets pushed or bounced or rag-dolled to which positions?

-- Player positions rotation, even player opening doors, isn't such a
big deal. Player motion that causes motion and position changes on a
chain of other objects is a big deal.

-- In a perfect world, every position of every object that moves must be
arbitrated by server. Any object that has the potential of blocking or
bouncing or twirling or pushing another object which eventually blocks a
player must be centrally arbitrated.

-- In the non-perfect world, the number of arbitrating entities becomes
really large the more an application displays physics-ness in the world.
Do all of you really arbitrate and (continually) broadcast all these
moving dynamic objects big and small 's absolute positions and not
client predict them at all?

-- Or do you client predict some and "backtrack" when the server
disagrees with the prediction? What are your backtrack methods if you do
client predict.

-- I gratefully await your experience in these areas.

Re: [GD-General] Scaling GUI graphics

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

On Aug 20, 2002 at 08:53 -0500, Corrinne Yu wrote:
> 
> We do all our front-end / HUD stuff in Flash, although our scripting
> support is limited to Flash 4, and there's a couple of rendering things
> we
> don't do, either for performance, or 'bang for buck' issues. IIRC some
> of
> our game logic was in it for a while (I certainly recall having to read
> state changes back out of the flash interface class).
> 
> We're doing this for authoring reasons, rather than re-sizing issues
> though. Closest we get to resolution changes are supporting 4:3 / 16:9
> and
> PAL / NTSC.
> 
> -- This sounds kind of interesting. Do you read the raw Flash 4 file
> output and implement the entire Flash 4 API?

I'm also interested in details...

> -- Is Flash 4 a text or binary file format? I apologize for being a
> Flash neophyte. Do you parse the text or the binary, and where does one
> find a script and API reference to Flash 4 (if one has never used it
> before)?

see http://www.openswf.org -- swf is a packed binary format, actually
very clever IMO.  There's some GPL code, and apparently you may be
able to license code from Macromedia.  I keep threatening to write a
public domain SWF library, but it's mostly vapor at the moment.

> -- It really depends how thick the API is whether it may be too heavy
> weight in our case to implement as a GUI displayer.

The shape display is oriented around curved outlines, and definitely
has the look of something that wants to use an antialiased scanline
renderer.  But it definitely seems possible to do an OpenGL or D3D
implementation.

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] Scaling GUI graphics

[Corrinne Y. <cor...@el...>]

We do all our front-end / HUD stuff in Flash, although our scripting
support is limited to Flash 4, and there's a couple of rendering things
we
don't do, either for performance, or 'bang for buck' issues. IIRC some
of
our game logic was in it for a while (I certainly recall having to read
state changes back out of the flash interface class).

We're doing this for authoring reasons, rather than re-sizing issues
though. Closest we get to resolution changes are supporting 4:3 / 16:9
and
PAL / NTSC.

-- This sounds kind of interesting. Do you read the raw Flash 4 file
output and implement the entire Flash 4 API?

-- Is Flash 4 a text or binary file format? I apologize for being a
Flash neophyte. Do you parse the text or the binary, and where does one
find a script and API reference to Flash 4 (if one has never used it
before)?

-- It really depends how thick the API is whether it may be too heavy
weight in our case to implement as a GUI displayer.

-- Thank you for your help.

Re: [GD-General] physics and networking

[Cruise <cr...@ca...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: MD5

> I have a few questions for all of you. I would be grateful to hear from
> all your varied experience.
[snip]
> Do you think an entire "simple death match" MP game can get away with it
> being peer to peer?
Depends on how many players your game will have. The current
multiplayer trend, especially with the rise in team based multiplayer,
is getting as many people into a match as possible. An upper limit of
64 players is not uncommon now. That's clearly unworkable in a full
peer-to-peer system except on a LAN.

> What kind of things must you always arbitrate by a server? Can one
> "design" the game play out of any necessary server arbitration?

> It would save a lot of data structure bookkeeping if each client can
> become more powerful (and the server to arbitrate almost nothing, or
> just not exist at all).
Though that would be lovely from a bandwidth and latency point of
view, it's just not practical in real terms. The more authority the
client has, the more potential there is for someone to abuse it.

The lesson from Half-Life is that if your game has any decent number
of players, then some of those players will be cheating. And they'll
be damn ingenious cheats too.

The simple matter is that you can't trust client software anymore. You
have to have an authoritative state-of-play machine.

> The bookkeeping isn't bad for simple player position, rotation, etc. But
> chains of complex physics reaction becomes quite a pain of the neck to
> be maintained and received from a "remote" arbitrator all the time. :(
> It easily "doubles" the code to type to have the server minds itself
> with so many complex collisions arbitrations. :(

Agreed. It is a shame. But the enviroment in which the code is
deployed makes it necessary.

[ cruise / www.casual-tempest.net / www.transference.org ]

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUAPWIaMvdi0Z5STRufAQH9SwP/RjWxxk7NOpXRQtZITx1RyoK99QfRcDyt
ucX4rZtbe4IFikLE4b1Tgla9hyWPq4xDEPaQlLDmhZxz2gBpjmFmBHKSovrHni3l
xEYV7/G963QbKsmT+rT4hbZiuh4MeJB9/SiGC4VwzNYtjbSau17LbPIcGrzITW6m
EHpVPDUtZKA=
=FV3n
-----END PGP SIGNATURE-----

RE: [GD-General] Scaling GUI graphics

[brian h. <bri...@py...>]

This doesn't really help, since you're still limited by texture size.  
The key is whether you're going to scale your graphics or not to meet 
the screen res.  If you do scale it up, then you're effectively dealing 
with a fixed resolution GUI (not necessarily bad, just doesn't take 
advantage of the increased resolution to provide either higher 
resolution or more usable area).

> Another possible easy option is to do the interface in 3D, especially 
if
> you are running the GUI over a 3D engine anyway.

[GD-General] physics and networking

[Corrinne Y. <cor...@el...>]

I have a few questions for all of you. I would be grateful to hear from
all your varied experience.

Which physics structures do you always server broadcast and arbitrate?

Which physics structures do you occasionally broadcast?

Which physics structures do you client predict most of the time, and
server arbitrate occasionally?

Which physics structures do you only client predict and never worry
about synchronizing?

What about trying to do it in a peer to peer model instead of a full
roundtrip of server client? Which physics structures do you think can
get away with in peer to peer?

Do you think an entire "simple death match" MP game can get away with it
being peer to peer?

What kind of things must you always arbitrate by a server? Can one
"design" the game play out of any necessary server arbitration?

It would save a lot of data structure bookkeeping if each client can
become more powerful (and the server to arbitrate almost nothing, or
just not exist at all).

The bookkeeping isn't bad for simple player position, rotation, etc. But
chains of complex physics reaction becomes quite a pain of the neck to
be maintained and received from a "remote" arbitrator all the time. :(
It easily "doubles" the code to type to have the server minds itself
with so many complex collisions arbitrations. :(

RE: [GD-General] Scaling GUI graphics

[Corrinne Y. <cor...@el...>]

Another possible easy option is to do the interface in 3D, especially if
you are running the GUI over a 3D engine anyway.

Re: [GD-General] worker threads, level loading and progress bars

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

Well, thanks for all the input. I'll finally stick with the threaded
mechanism, with the loader thread loading the textures into memory, and the
main thread uploading them to vram. The thing I like about this approach is
that it can be extended with ease to load resources during the game without
too much interruption.

I still have a few calls to the progress bar in the worker thread, to update
the progress position, but it's interpolated nicely in the main thread.

My worker thread has a higher priority than the main thread, (above_normal
in win2k and highest in win9x). So that it doesn't take only 50% of the
loading time. This seems to work ok, but will probably also add some
signals, to ensure that the worker thread doesn't take all the time.

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


> Thatcher Ulrich <tu...@tu...> wrote:
> > I took a stab at this (loading in a background thread) in Soul Ride.
> > In Win32, it's pretty easy to set up a new OpenGL render context, and
> > use wglShareLists() so that textures defined in one thread are usable
> > in the other thread.
> >
> > In captivity it worked, pretty well in fact.  But at the time
> > (early/mid 2000, IIRC) it was highly vulnerable to bugs in driver
> > thread support, so I gave up and fell back on the DoWork() pattern.
> >
> > Under X, there seems to be a way to share textures across threads, but
> > I never got around to trying it.  Nowadays I try to use SDL for all
> > video setup & config, and it does not have a facility like
> > wglShareLists :(
> >
> > The worker queue thing works as well; my Chunked LOD demo uses this
> > pattern -- I load the image data in the loader thread, and bind it in
> > the foreground thread.  But it still means some extra, unnecessary
> > work for the foreground thread; plus the coding work.
> >
> > -Thatcher
> >
> > On Aug 07, 2002 at 04:44 +0200, Ignacio Casta?o wrote:
> >> Hmm... it seems to my now, that the problem with the multiple
> >> threads could be easily solved.
> >>
> >> The only OpenGL operation performed by the worker thread is to upload
> >> textures, so my texture manager could have a list of textures
> >> waiting to be uploaded, and I could process them on each game loop.
> >>
> >> Anyway, I still would like to hear how others have solve this
> >> problem.
> >>
> >>



_______________________________________________________________
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

RE: [GD-General] worker threads, level loading and progress bars

[Tom F. <to...@mu...>]

The slow part of loading texture is loading them off disk - just load them
using another thread into any app-defined memory you have lying around. Then
have the loader thread signal that the texture is loaded, then the main
thread copies it into the D3D/OGL-owned buffer. It's very quick - you won't
be doing more than one of these a frame, so the speed bump will hardly be
noticeable.

For smooth progress bars, I just have a little routine (not in a thread)
that you call really frequently, and it keeps a record of when it was last
called. If it was less than say 100ms ago, it just returns. Otherwise it
does a smooth interpolation of the progress bar (just a displayed_val = 0.9F
* displayed_val + real_val * 0.1f; does nicely) and draws it to the screen.
Then you scatter calls to this liberally all over your loading routines, and
there you go - smooth loading bars.

Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Thatcher Ulrich [mailto:tu...@tu...]
> Sent: 07 August 2002 04:27
> To: gam...@li...
> Subject: Re: [GD-General] worker threads, level loading and progress
> bars
> 
> 
> I took a stab at this (loading in a background thread) in Soul Ride.
> In Win32, it's pretty easy to set up a new OpenGL render context, and
> use wglShareLists() so that textures defined in one thread are usable
> in the other thread.
> 
> In captivity it worked, pretty well in fact.  But at the time
> (early/mid 2000, IIRC) it was highly vulnerable to bugs in driver
> thread support, so I gave up and fell back on the DoWork() pattern.
> 
> Under X, there seems to be a way to share textures across threads, but
> I never got around to trying it.  Nowadays I try to use SDL for all
> video setup & config, and it does not have a facility like
> wglShareLists :(
> 
> The worker queue thing works as well; my Chunked LOD demo uses this
> pattern -- I load the image data in the loader thread, and bind it in
> the foreground thread.  But it still means some extra, unnecessary
> work for the foreground thread; plus the coding work.
> 
> -Thatcher
> 
> On Aug 07, 2002 at 04:44 +0200, Ignacio Casta?o wrote:
> > Hmm... it seems to my now, that the problem with the 
> multiple threads could
> > be easily solved.
> > 
> > The only OpenGL operation performed by the worker thread is 
> to upload
> > textures, so my texture manager could have a list of 
> textures waiting to be
> > uploaded, and I could process them on each game loop.
> > 
> > Anyway, I still would like to hear how others have solve 
> this problem.
> > 
> > 
> > Ignacio Casta?o
> > cas...@ya...
> > 
> > 
> > Ignacio Casta?o wrote:
> > > Hi,
> > > to display a progress bar during the level loads, I've always used
> > somekind
> > > of callback mechanism, or a simple 'DoWork' function that 
> performs a
> > little
> > > part of the work in each call and returns a special value 
> when the work
> > has
> > > been finished. Those approaches worked ok, but the 
> progress of the bar
> > > wasn't smooth and the resulting code was not very clean:
> > > ...
> > 
> > 
> > _______________________________________________________________
> > Copa del Mundo de la FIFA 2002
> > El ?nico lugar de Internet con v?deos de los 64 partidos. 
> > ?Ap?ntante ya! en http://fifaworldcup.yahoo.com/fc/es/
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> -- 
> Thatcher Ulrich
> http://tulrich.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] worker threads, level loading and progress bars

[Javier A. <ja...@py...>]

My approach has always been to have a global subsystem with the following
API:

ProgressBar::Init()
ProgressBar::StartSection(percent, numTicks)
ProgressBar::Progress()
   which calls ProgressBar::Render()

Then spread calls to Progress() around the calls that load stuff. This is
probably the callback mechanism Ignacio mentioned, but I don't like the idea
of passing the "ProgressCallback" object around these calls - it makes the
API uglier without need.

Proper adjustment of the "percent" and "numTicks" of each section for each
level, can make it quite smooth. (Log times and number of actual calls, for
each level load, then put those into the config file, log again to check and
you're set). Advancing the progress bar based on some realtime clock will
give you trouble.

Render() decides if it's a good time to update the visual progress bar
depending on how frequently do you . (Note: when optimizing load times on
"Commandos: Beyond The Call Of Duty", this one showed up as taking 50% of
the load time - it wasn't being smart about when to update and was causing
1000's of PageFlip()s)

This system is terribly simple, doesn't require any fancy technologies, plus
it doesn't bind knowledge of the internals of any subsystem to any other, so
it's architecturaly as clean as you can get. Fancy solutions like
multithreading may be more interesting but are so much less practical in all
respects...

If you want a console-style continuously animated progress bar then you need
either more calls to Progress() or a secondary thread. The single-threaded
approach may be slightly less efficient, but much easier and safer to
implement.

Thatcher Ulrich <tu...@tu...> wrote:
> I took a stab at this (loading in a background thread) in Soul Ride.
> In Win32, it's pretty easy to set up a new OpenGL render context, and
> use wglShareLists() so that textures defined in one thread are usable
> in the other thread.
>
> In captivity it worked, pretty well in fact.  But at the time
> (early/mid 2000, IIRC) it was highly vulnerable to bugs in driver
> thread support, so I gave up and fell back on the DoWork() pattern.
>
> Under X, there seems to be a way to share textures across threads, but
> I never got around to trying it.  Nowadays I try to use SDL for all
> video setup & config, and it does not have a facility like
> wglShareLists :(
>
> The worker queue thing works as well; my Chunked LOD demo uses this
> pattern -- I load the image data in the loader thread, and bind it in
> the foreground thread.  But it still means some extra, unnecessary
> work for the foreground thread; plus the coding work.
>
> -Thatcher
>
> On Aug 07, 2002 at 04:44 +0200, Ignacio Casta?o wrote:
>> Hmm... it seems to my now, that the problem with the multiple
>> threads could be easily solved.
>>
>> The only OpenGL operation performed by the worker thread is to upload
>> textures, so my texture manager could have a list of textures
>> waiting to be uploaded, and I could process them on each game loop.
>>
>> Anyway, I still would like to hear how others have solve this
>> problem.
>>
>>
>> Ignacio Casta?o
>> cas...@ya...
>>
>>
>> Ignacio Casta?o wrote:
>>> Hi,
>>> to display a progress bar during the level loads, I've always used
>>> somekind of callback mechanism, or a simple 'DoWork' function that
>>> performs a little part of the work in each call and returns a
>>> special value when the work has been finished. Those approaches
>>> worked ok, but the progress of the bar wasn't smooth and the
>>> resulting code was not very clean: ...
>>
>>
>> _______________________________________________________________
>> Copa del Mundo de la FIFA 2002
>> El ?nico lugar de Internet con v?deos de los 64 partidos.
>> ?Ap?ntante ya! en http://fifaworldcup.yahoo.com/fc/es/
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> Gamedevlists-general mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557


  Javier Arevalo
  Pyro Studios

Re: [GD-General] worker threads, level loading and progress bars

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

I took a stab at this (loading in a background thread) in Soul Ride.
In Win32, it's pretty easy to set up a new OpenGL render context, and
use wglShareLists() so that textures defined in one thread are usable
in the other thread.

In captivity it worked, pretty well in fact.  But at the time
(early/mid 2000, IIRC) it was highly vulnerable to bugs in driver
thread support, so I gave up and fell back on the DoWork() pattern.

Under X, there seems to be a way to share textures across threads, but
I never got around to trying it.  Nowadays I try to use SDL for all
video setup & config, and it does not have a facility like
wglShareLists :(

The worker queue thing works as well; my Chunked LOD demo uses this
pattern -- I load the image data in the loader thread, and bind it in
the foreground thread.  But it still means some extra, unnecessary
work for the foreground thread; plus the coding work.

-Thatcher

On Aug 07, 2002 at 04:44 +0200, Ignacio Casta?o wrote:
> Hmm... it seems to my now, that the problem with the multiple threads could
> be easily solved.
> 
> The only OpenGL operation performed by the worker thread is to upload
> textures, so my texture manager could have a list of textures waiting to be
> uploaded, and I could process them on each game loop.
> 
> Anyway, I still would like to hear how others have solve this problem.
> 
> 
> Ignacio Casta?o
> cas...@ya...
> 
> 
> Ignacio Casta?o wrote:
> > Hi,
> > to display a progress bar during the level loads, I've always used
> somekind
> > of callback mechanism, or a simple 'DoWork' function that performs a
> little
> > part of the work in each call and returns a special value when the work
> has
> > been finished. Those approaches worked ok, but the progress of the bar
> > wasn't smooth and the resulting code was not very clean:
> > ...
> 
> 
> _______________________________________________________________
> Copa del Mundo de la FIFA 2002
> El ?nico lugar de Internet con v?deos de los 64 partidos. 
> ?Ap?ntante ya! en http://fifaworldcup.yahoo.com/fc/es/
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] worker threads, level loading and progress bars

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

Hmm... it seems to my now, that the problem with the multiple threads could
be easily solved.

The only OpenGL operation performed by the worker thread is to upload
textures, so my texture manager could have a list of textures waiting to be
uploaded, and I could process them on each game loop.

Anyway, I still would like to hear how others have solve this problem.


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


Ignacio Castaño wrote:
> Hi,
> to display a progress bar during the level loads, I've always used
somekind
> of callback mechanism, or a simple 'DoWork' function that performs a
little
> part of the work in each call and returns a special value when the work
has
> been finished. Those approaches worked ok, but the progress of the bar
> wasn't smooth and the resulting code was not very clean:
> ...


_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos. 
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/

[GD-General] worker threads, level loading and progress bars

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

Hi,
to display a progress bar during the level loads, I've always used somekind
of callback mechanism, or a simple 'DoWork' function that performs a little
part of the work in each call and returns a special value when the work has
been finished. Those approaches worked ok, but the progress of the bar
wasn't smooth and the resulting code was not very clean:

int DoWork( int prev_step ) {
    if( prev_step==0 ) {
        "do some work"
        return ++prev_step;
    }
    else if( prev_step==1 ) {
        ...
    }
    ...
    else return finish_step;
}

I've been thinking about moving to a multithreaded approach. This worked
nicely until I tried to load textures, that of course didn't work because I
had to create a new rendering context for the new thread. My system and
specially the render was not designed with multithreading in mind, so I've
noticed that this approach would need many changes in my current design.
(creating multiple rendering context, locking and unlocking the render,
etc.).

Loading and uploading textures is almost half of the job, so unless I change
my architecture, the threaded approach doesn't seem very usefull, since I
still have to use the previous dirty work partition.

Instead of using multiple threads I could also try to use the current
method, but cleanly. For example by using an abstract job class, and a job
queue that manages and process the pending jobs. Decomposing all the work in
simple jobs, childs of the base job class and created by the job queue like
in a parametrized factory. Queueing the jobs at the beginning and processing
them secuentially on each 'DoWork' call.

But before doing so, I would like to know what other people are doing.

Thanks in advance,


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

_______________________________________________________________
Yahoo! Messenger
Nueva versión: Webcam, voz, y mucho más ¡Gratis! 
Descárgalo ya desde http://messenger.yahoo.es

Re: [GD-General] Pong ball mechanics

[Javier A. <ja...@py...>]

Joe Collins <dar...@ya...> wrote:

> I believe the speed of the ball is also a function
> of the distance from the center of the paddle as
> well. I think its supposed to speed up when the
> angle increases...

The horizontal speed of the ball was always the same I think, therefore as
the angle increases the linear speed is greater.

  Javier Arevalo
  Pyro Studios