184 lines
8.6 KiB
Text
184 lines
8.6 KiB
Text
|
------------------------ RELEASE 1.0.0 ---------------------------------
|
||
|
|
||
|
* We now have working exporters for Max5, Max6, Max7, Maya5, Maya6
|
||
|
|
||
|
* The Max exporter is dramatically improved:
|
||
|
|
||
|
- it now includes support for character studio.
|
||
|
- the polygon winding bug has been fixed.
|
||
|
|
||
|
* Panda no longer requires any registry keys or environment
|
||
|
variables. This means it is now possible to:
|
||
|
|
||
|
- run panda directly from a compact disc
|
||
|
- install multiple copies of panda on a single machine
|
||
|
- install panda by copying the tree from another computer
|
||
|
|
||
|
Note that the installer does add the panda 'bin' directory to
|
||
|
your PATH, and it does store an uninstall key in the registry,
|
||
|
but neither of these is needed for panda to function.
|
||
|
|
||
|
* The 'makepanda' build system is now capable of building
|
||
|
prepackaged games for Windows. These prepackaged games are simply
|
||
|
copies of panda with the game code included, some of the
|
||
|
unnecessary stuff stripped out, and some changes to the start
|
||
|
menu. See "Airblade - Installer" on the panda downloads page
|
||
|
for an example.
|
||
|
|
||
|
* All of the sample programs have been tested. The ones that didn't
|
||
|
work have been removed, the ones that do work have been (lightly)
|
||
|
documented.
|
||
|
|
||
|
* This is the first release to include not just a binary installer
|
||
|
for windows, but:
|
||
|
|
||
|
- a binary installer (RPM) for Fedora 2
|
||
|
- a binary installer (RPM) for Fedora 3
|
||
|
- a binary installer (RPM) for Redhat 9
|
||
|
- a binary installer for windows, as always
|
||
|
- a source tar-ball for linux
|
||
|
- a source zip-file for windows
|
||
|
|
||
|
------------------------ RELEASE 2004-12-13 ---------------------------------
|
||
|
|
||
|
* Basic server-client networking support is back in Panda3D. There is a
|
||
|
networking sample in the samples directory. This uses the Panda3d
|
||
|
distributed object system.The README file will explain how to run this.
|
||
|
Documentation of this if forthcoming.
|
||
|
|
||
|
* Panda3d now reduces the number of environment variables such that only 2
|
||
|
are needed now - PRC_PATH and PLAYER.
|
||
|
|
||
|
* GraphicsChannel and GraphicsLayer class have been removed from the
|
||
|
panda/src/display directory. Most Panda applications won't need to be
|
||
|
changed, since most applications simply use ShowBase.py (which has been
|
||
|
adjustedappropriately) to open a window and do the initial setup. For
|
||
|
those rare applications where you need to create your own DisplayRegions,
|
||
|
the makeDisplayRegion() interface has been moved from GraphicsLayer to
|
||
|
GraphicsWindow (actually, to GraphicsOutput, which is the base class of
|
||
|
GraphicsWindow). You can modify your application to call
|
||
|
base.win.makeDisplayRegion() accordingly. If you have something like
|
||
|
displayRegion.getLayer(), replace it with displayRegion.getWindow()
|
||
|
instead.
|
||
|
|
||
|
* Effective with the current version of Panda, the way that HPR angles are
|
||
|
calculated will be changing. The change will make a difference to existing
|
||
|
code or databases that store a hard-coded rotation as a HPR, but only when
|
||
|
R is involved, or both H and P are involved together. That is to say more
|
||
|
precisely, HPR angles with (R != 0 || (H != 0 && P != 0)) now represent a
|
||
|
different rotation than they used to. If you find some legacy code that no
|
||
|
longer works correctly (e.g. it introduces crazy rotations), try putting
|
||
|
the following in your Config.prc file:
|
||
|
|
||
|
temp-hpr-fix 0
|
||
|
|
||
|
To turn off the correct behavior and return to the old, broken behavior.
|
||
|
Note that a longer-term solution will be to represent the HPR angles
|
||
|
correctly in all legacy code. The function oldToNewHpr() is provided to
|
||
|
aid this transition.
|
||
|
|
||
|
* PandaNode definition has been changed to support setting an
|
||
|
into_collide_mask for any arbitrary node, in particular for any GeomNode.
|
||
|
It used to be that only CollisionNodes had an into_collide_mask. This
|
||
|
change obviates the need for CollisionNode::set_collide_geom(), which is
|
||
|
now a deprecated interface and will be removed at some point in the future.
|
||
|
|
||
|
Details:
|
||
|
There's now a NodePath::set_collide_mask() and
|
||
|
NodePath::get_collide_mask(), which operate on all CollisionNodes and
|
||
|
GeomNodes at and below the current node. By default, set_collide_mask()
|
||
|
will replace the entire collide mask, but you may also specify (via a
|
||
|
second parameter) the subset of bits that are to be changed; other bits
|
||
|
will be left alone. You can also specify a particular type of node to
|
||
|
modify via a third parameter, e.g. you can adjust the masks for GeomNodes
|
||
|
or CollisionNodes only.
|
||
|
|
||
|
The NodePath set_collide_mask() interface changes the into_collide_mask.
|
||
|
Those familiar with the collision system will recall that a CollisionNode
|
||
|
(but only a CollisionNode) also has a from_collide_mask. The
|
||
|
from_collide_mask of the active mover is compared with the into_collide_mask
|
||
|
of each object in the world; a collision is only possible if there are some
|
||
|
bits in common.
|
||
|
|
||
|
It used to be that only other CollisionNodes had an into_collide_mask. A
|
||
|
mover would only test for collisions with CollisionNodes that matched its
|
||
|
collide_mask. If you wanted to make your mover detect collisions with
|
||
|
visible geometry which had no into_collide_mask, you had to call
|
||
|
set_collide_geom(1). This allowed the mover to detect collisions with *all*
|
||
|
visible geometry; it was either an all-or-none thing.
|
||
|
|
||
|
Now that GeomNodes also have an into_collide_mask, there's no longer a need
|
||
|
for set_collide_geom(). A mover will detect collisions with any
|
||
|
CollisionNodes or GeomNodes that match its collide_mask. This means, for
|
||
|
the purposes of collision detection, you can use CollisionNodes and
|
||
|
GeomNodes pretty much interchangeably; simply set the appropriate bits on
|
||
|
the objects you want to collide with, regardless of whether they are
|
||
|
invisible collision solids or visible geometry.
|
||
|
|
||
|
(This should not be taken as a license to avoid using CollisionNodes
|
||
|
altogether. The intersection computation with visible geometry is still
|
||
|
less efficient than the same computation with collision solids. And visible
|
||
|
geometry tends to be many times more complex than is strictly necessary for
|
||
|
collisions.)
|
||
|
|
||
|
There's one more detail: every GeomNode, by default, has one bit set on in
|
||
|
its collide_mask, unless it is explicitly turned off. This bit is
|
||
|
GeomNode::get_default_collide_mask(). This bit is provided for the
|
||
|
convenience of programmers who still want the old behavior of
|
||
|
set_collide_geom(): it allows you to easily create a CollisionNode that
|
||
|
will collide with all visible geometry in the world.
|
||
|
|
||
|
Along the same lines, there's also CollisionNode::get_default_collide_mask(),
|
||
|
which is 0x000fffff. This is the default mask that is created for a new
|
||
|
CollisionNode (and it does not include the bit reserved for GeomNodes,
|
||
|
above). Previously, a new CollisionNode would have all bits on by default.
|
||
|
|
||
|
|
||
|
|
||
|
------------------------ RELEASE 2004-11-11 -----------------------------------
|
||
|
|
||
|
* Multiple mice can now be used with Panda3D. showbase has a list called
|
||
|
pointerWatcherNodes. The first mouse on this list is the system mouse. The
|
||
|
getMouseX() and getMouseY() will return coordinates relative to the
|
||
|
application window. The rest of the mice on the list will give raw mouse
|
||
|
positions and will change when they are moved on the screen.
|
||
|
|
||
|
In addition there are new events for mouse buttons. Each mouse will be have
|
||
|
a corresponding event. mouse1 will send mousedev1-mouse1, mousedev1-mouse2
|
||
|
and mousedev1-mouse3 events. mouse2 and any other mouse attached
|
||
|
will send similar events mousedev2-mouse1 etc.
|
||
|
|
||
|
The old mouse buttons work too. mouse1, mouse2, mouse3 events will be
|
||
|
triggered if that button is pressed on any mouse
|
||
|
|
||
|
------------------------ RELEASE 2004-10-13 -----------------------------------
|
||
|
|
||
|
General
|
||
|
|
||
|
* Release notes: Each release will now have an entry associated with
|
||
|
it in this document. This will be updated in reverse-chronological order.
|
||
|
|
||
|
Panda3D
|
||
|
* Distributed with this release is a working version of the SceneEditor
|
||
|
created in Spring 2004 at the ETC. Documentation will be forthcoming on the
|
||
|
website. This can be found in <InstallPath>/SceneEditor
|
||
|
|
||
|
* The latest version of FMOD is distributed with this release. The latest
|
||
|
version is 3.73.
|
||
|
|
||
|
* AudioSound object now allows more types of sound. These include wma and
|
||
|
ogg vorbis formats. This is valid when using the fmod sound system. Midi,
|
||
|
Mod, s3m, it, xm and such sequencer type file formats are not supported.
|
||
|
Exception - Midi files can be played. This is not fully implemented.
|
||
|
|
||
|
* A bug in SoundInterval is fixed. SoundInterval looping would incorrectly
|
||
|
add a minimum of 1.5 seconds to the sound. This has been fixed. Sound
|
||
|
looping problems in general should be fixed. Midi's still don't support
|
||
|
looping through the AudioSound object. They should loop through
|
||
|
SoundIntervals though.
|
||
|
|
||
|
* Cg support has been added to Panda3D. Documentation for this is
|
||
|
forthcoming.
|
||
|
|
||
|
|