Generated by StatCvs v0.2-dev
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Summary Period: 2001-10-15 to 2001-10-12 (Commits 6445-6494 of 12744)
csInitializer::RequestPlugins() no longer needs a func-id after
the plugin name. This means that if you use CS_REQUEST_PLUGIN
you better remove everything after the ':' in the plugin name
(including the ':'). Note that in the future this notation will
still be useful. If given this will be used as the tag to register
this plugin with the object registry. That way you can request
plugins with another tag (normally it would be the default tag
which is the same as the interface name).
37 lines of code changed in:
Forgot to commit.
63 lines of code changed in:
Updated
44 lines of code changed in:
Fixed
7 lines of code changed in:
Automated Texinfo @node and @menu repair.
2 lines of code changed in:
- All func-id's are now changed so that they are equal to their
interface name. Basically this means:
VFS -> iVFS
VideoDriver -> iGraphics3D
VideoCanvas -> iGraphics2D
SoundRender -> iSoundRender
ImageLoader -> iImageIO
SoundLoader -> iSoundLoader
LevelLoader -> iLoader
FontServer -> iFontServer
NetDriver -> iNetworkDriver
Console.Output -> iConsoleOutput
Console.Input -> iConsoleInput
Engine -> iEngine
MotionManager -> iMotionManager
Reporter -> iReporter
Converter -> iModelConverter
CrossBuilder -> iCrossBuilder
TextSyntaxService -> iSyntaxService
This change was done in preparation for the removal of the
function id's.
- All 'System.Plugins' entries in the config files have to be modified
to the new func-id's above. For example, instead of:
System.Plugins.VideoDriver = crystalspace.graphics3d.software
you will now have to say:
System.Plugins.iGraphics3D = crystalspace.graphics3d.software
- In the future loading plugins like above (with interface name) will
mark them as the default plugin for that interface (using the
object registry). So if you do
CS_QUERY_REGISTRY(object_reg, iGraphics3D);
you will get the default plugin implementing iGraphics3D. If you
want to load additional plugins implementing some interface but
not mark them as default you can do this like this:
System.Plugins.iGraphics3D.Extra = ...
This will put them in the object registry with the tag
"iGraphics3D.Extra" (not at this moment though).
- CS_LOAD_PLUGIN no longer accepts the FuncID argument. Instead it
will use the interface name as the FuncID. This conforms well
with the rename of the FuncID's above. If you still want to load
a plugin with another FuncID then you can temporarily use
CS_LOAD_PLUGIN_OLD.
- Renamed the _CS_LOAD_PLUGIN (mark the additional underscore in
front) to CS_LOAD_PLUGIN_ALWAYS. Also removed the FuncID parameter.
- Removed the FuncID parameter from CS_QUERY_PLUGIN_CLASS. Instead
the interface name is used as the FuncID.
- Made networking driver optional in Blocks (it gave an error when
this plugin wasn't present).
132 lines of code changed in:
Oops, missed a couple of typos. Also, since Philip got upset because I made
fun of his and Eric's revertations, I added some ref counting for Norman to
find.... ;)
6 lines of code changed in:
Menu Fix
1 lines of code changed in:
Various typos and corrections. More work to be done on msvc5....we all know
how Philip is.....At least it's not Eric reverting Philip's revertations and
such... ;)
13 lines of code changed in:
Various typos and corrections. It would also seem that the actual name for
Mingw is really MinGW, so I changed it. :)
11 lines of code changed in:
Various typos and corrections. Filled out parts of the unix 'user.mak'
option list section in platform/unix.txi.
39 lines of code changed in:
Various typos and corrections.
15 lines of code changed in:
- new values for polygonqueue are now only updated if they changed
- added detection of ARB/EXT_texture_env_combine, will use this later to apply 2*src*dst for lightmaps in the multitexturing case
- in multitexturing case, the env_mode is now changed to GL_REPLACE instead of GL_MODULATE if the alpha value is 1.0
277 lines of code changed in:
Eliminated a compilation warning from ogl_txtmgr.cpp.
2 lines of code changed in:
removed inclusion of glext.h from the files. there seems to be dozens of version of glext out there and sometimes all of glext is included in gl.h and no glext.h exist at all. added the defines from glext.h to csglext.h, renamed the functiontypes to csPFNGL* to prevent collision with types defined in some gl.h variations.
3596 lines of code changed in:
The 'stdrep' plugin now depends on output console and
reporter plugins in SCF. This means that it will be loaded
after those two other plugins by csPluginLoader. This
fixes a bug where the stdrep plugin was not correctly
initialized in some cases.
13 lines of code changed in:
Updated the date of when doc was last modified
1 lines of code changed in:
Altered refrences to old winlibs and changed to msvc_libs.
Many thanks too Niels Gierse for bringing this to my attention.
4 lines of code changed in:
Fixed warning with missing newline.
2 lines of code changed in:
Fixed err vs. libc's err symbol conflict under FreeBSD.
4 lines of code changed in:
fix by Matthias Braun, csVector3Array is already used in csgeom/poly3d.h - this caused strange behaviour when compiled with gcc3
4 lines of code changed in:
fixed problem with generation of 1xN mipmaps
4 lines of code changed in:
added test if all extension function addresses could be retrieved
31 lines of code changed in:
Fixed compilation error in OpenGL Canvas for X.
3 lines of code changed in:
Fixed MIngW trying to include mesa inludes.
GL now OK now all Win32 supported compilers.
3 lines of code changed in:
Fixed SCF crasher under Windows.
GL works on MSVC Windows again, now to test MingW. :-)
1 lines of code changed in:
Minor fix.
Note there is still a crasher somwehere which I have yet to isolate.
1 lines of code changed in:
This fixes gl3d for MSVC, other issues remain unresolved.
9 lines of code changed in:
removed old extension includes
1605 lines of code changed in:
iOpenGLInterface
41 lines of code changed in:
- Added static function pointer variables to opengl 3d renderer.
They are filled with pointers to opengl extension functions, or left NULL if
extension is not present for a card (or disabled in opengl.cfg).
Extensions to check for are now listed in opengl.cfg.
These changes allow us to drop the #define USE_EXTENSION.
Dropped use of #define USE_EXTENSION :)
To find the function pointer to an extension function one needs platform specific opengl functions.
For windows this is wglGetProcAddress, for glx its glXGetProcAddressARB.
To access such functions i created a new interface iOpenGLInterface, which is implemented currently
in the glx canvas (tested) and windows opengl canvas (untested).
Other platforms i dont know - platform maintainers please check !
- Added use of compressed textures (if available). Read opengl.cfg !
- SourceFormats for opengl textures can now be directed to a specific TargetFormat (that is,
how they are stored in the texture memory of the card).
- For RGB and RGBA textures i added some code to possibly select a "better" sourceType for textures.
Better means here smaller. That is, texturedata is transformed to another base format (like RGB5_A1).
Until now the base format was always stored in RGBA. This new approach hopefully accelerates transfer of
texture data to the card.
- Upon preparation of the texture all mipmaps are now generated (if needed) and stored. Before mipmaps had
to be regenerated if texture was dropped and then loaded again.
- For procedural textures only mipmap level 0 is generated. Before all were generated but only the 0-th was
used. (currently only software procedural textures work, the backbuffer proctextures all show up in the
lower left of screen, funny but annoying)
- Added support for textures other than RGB and RGBA (read Alpha, Luminance, Intensity and others). Those
are not used yet, but for native alpha maps the first use comes to mind if one thinks of the halo
implementation.
- Added calculation of Luminance and Intensity to csRGBpixel
- csImage now calculates the mipmap correctly for 1xN (or Nx1) size mipmaps if you increase the level
by 1 only (that is: it becomes 1x(N>>1) size)
802 lines of code changed in:
Eric Sunshine fixed the Apple/NeXT ports so that applications which
utilize a 3D renderer no longer crash at launch time. The problem was
that csPlatformStartup() was getting invoked too late in the
initialization process, with the result that the platform-specific
"helper" object, NeXTAssistant was not available at plugin load time.
5 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Fixed a bug in csInitializer::CreateEnvironment() where it would leak
an iObjectRegistry if any of the invoked "creation" functions failed.
-*- Changed the order of application initialization so that
csPlatformStartup() is now called as the final step of
csInitializer::CreateEnvironment(), rather than being called by
csInitializer::Initialize(). The consequence of this change is that
csPlatformStartup() is now called considerably earlier in the startup
sequence, thus any platform-specific "helper" objects published by
csPlatformStartup() will now be available in the later initialization
step when plugins are loaded. This change was necessary since some
plugins expect the "helper" objects to be available at load time.
-*- Fixed a nasty bug in csEventQueue where, at destruction time, it would
unconditionally delete all event outlets even if other objects held
references to those outlets.
-*- Fixed the documentation for iEventQueue::CreateEventOutlet() so that
it informs the caller that it is the caller's responsibility to send
DecRef() to the outlet when no longer needed.
-*- Fixed a bug in NeXTAssistant where it failed to send IncRef() to the
shared event queue which it caches even though it was sending DecRef()
at destruction time (thus stealing some other object's reference to
the event queue).
2 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Fixed a bug in csInitializer::CreateEnvironment() where it would leak
an iObjectRegistry if any of the invoked "creation" functions failed.
-*- Changed the order of application initialization so that
csPlatformStartup() is now called as the final step of
csInitializer::CreateEnvironment(), rather than being called by
csInitializer::Initialize(). The consequence of this change is that
csPlatformStartup() is now called considerably earlier in the startup
sequence, thus any platform-specific "helper" objects published by
csPlatformStartup() will now be available in the later initialization
step when plugins are loaded. This change was necessary since some
plugins expect the "helper" objects to be available at load time.
-*- Fixed a nasty bug in csEventQueue where, at destruction time, it would
unconditionally delete all event outlets even if other objects held
references to those outlets.
-*- Fixed the documentation for iEventQueue::CreateEventOutlet() so that
it informs the caller that it is the caller's responsibility to send
DecRef() to the outlet when no longer needed.
-*- Fixed a bug in NeXTAssistant where it failed to send IncRef() to the
shared event queue which it caches even though it was sending DecRef()
at destruction time (thus stealing some other object's reference to
the event queue).
125 lines of code changed in:
Update
3 lines of code changed in:
Updated interface.
3 lines of code changed in:
Christopher:
+ Fixed parser to support connection maps.
+ Added support code for connection maps.
+ Note that connection maps are created, and that a certain amount of compile-time checking is done on them in skin definitions, but the connections are not actually made yet. This means for the user that a sink MUST EXIST before you load a definition file that uses it. e.g.:
component "LoginBtn" is "Command Button"
{
....
connect
{
sButtonClicked -> UserValidation::Login
}
}
This connection map requires that the sink "UserValidation" be registered with the SinkManager in order to compile the definition correctly. If a sink does not exist the connection is ignored and the compiler moves on to the next one.
382 lines of code changed in:
Eric Sunshine fixed a bad bug in mk/subs.mak where it neglected to include
mk/static.mak. Without static.mak, applications built with USE_PLUGINS=no
would fail miserably at run-time since none of the modules (such as VFS,
soft3d, etc.) would get linked into the application. Technically
speaking, without static.mak, the derived cslibref.cpp file was never
generated.
7 lines of code changed in:
Fixed compilation problem on FreeBSD: dlerror() returns const *
1 lines of code changed in:
Christopher:
+ Added crystalspace.window.sinkmanager
1 lines of code changed in:
Christopher:
+ Rename iAwsPrefs to iAwsPrefManager
5 lines of code changed in:
Christopher:
+ Plugified the awsSinkManager
+ Renamed iAwsPrefs interface to iAwsPrefManager
+ Made skeleton implementation of sink manager.
112 lines of code changed in:
Eliminated a couple "unused variable" warnings from perftest.cpp.
2 lines of code changed in:
Christopher:
+ Made maximize button active, and made it work correctly with moving controls.
+ Added recursive MoveChildren function that allows a component to make one call and move all children and nested children.
113 lines of code changed in:
Minor formatting update.
16 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Added the new function csDefaultRunLoop(). This function replaces
csInitializer::MainLoop(), which was non-portable. This function
should be called by applications which do not otherwise implement
their own run-loop. The run-loop implemented by this function is
guaranteed to be portable across all application (since each platform
is given the opportunity to provide an appropriate platform-specific
implementation). Each time through the run-loop, it advances the
virtual clock and processes the Crystal Space event queue.
csDefaultRunLoop() only returns when a csevBroadcast event is posted
to the Crystal Space event queue with command code cscmdQuit. Note,
that if your application already implements its own run-loop, then you
should _not_ call this function, since it would more-or-less
permanently interrupt your own run-loop and prevent it from doing its
work. For instance, if you are adding Crystal Space to an existing
Microsoft Windows application, which already has its own run-loop to
process the Windows event queue, then do _not_ call this function.
-*- csDefaultRunLoop() is intended to be implemented by each platform in a
fashion which is appropriate for implementing run-loops on the given
platform. For instance, with Apple's Cocoa frameworks,
csDefaultRunLoop() should arrange to have the NSApplication class
implement the run-loop; with BeOS's Application Kit,
csDefaultRunLoop() should arrange to have the BApplication class
implement the run-loop; etc.
-*- A default implementation of csDefaultRunLoop() is provided in
CS/libs/cssys/general/runloop.cpp for platforms which do not otherwise
have any special run-loop needs. The default implementation, however,
is very simple-minded in that it merely advances the virtual clock and
processes the event queue until cscmdQuit is received. It is not
particularly platform-friendly since it makes no attempt to yield the
CPU, nor does it make any attempt to interact nicely with a platform's
native GUI.
-*- Implemented a platform-specific csDefaultRunLoop() for the Apple/NeXT
ports. This function is essentially a one-liner which merely asks the
NeXTAssistant (from the object registry) to invoke the
platform-specific run-loop, which is implemented by Cocoa's
NSApplication class.
-*- All other platforms currently employ the default implementation of
csDefaultRunLoop() from runloop.cpp. In the future, however, some
platforms, such as BeOS, will implement their own versions of
csDefaultRunLoop().
-*- Added new functions csPlatformStartup() and csPlatformShutdown().
These functions are called by csInitializer::Initialize() and
csInitializer::DestroyApplication(), respectively, though they can
also be called manually in cases where csInitializer is not utilized.
These functions provide hooks for platform-specific initialization and
shutdown. csPlatformStartup() and csPlatformShutdown() are intended
to be implemented by each platform in some appropriate fashion. One
common use for these functions is to publish platform-specific
"helper" objects via the shared-object registry (iObjectRegistry).
-*- Created default implementations of csPlatformStartup() and
csPlatformShutdown() in CS/libs/cssys/general/sysinit.cpp. The
default implementations of these functions do nothing.
-*- Implemented platform-specific csPlatformStartup() and
csPlatformShutdown() for the Apple/NeXT ports. These functions
publish an iNeXTAssistant with the shared-object registry.
-*- All other platforms currently employ the default implementations of
csPlatformStartup() and csPlatformShutdown() from sysinit.cpp. In the
future, however, some platforms, such as BeOS, Windows, etc., will
implement their own versions of these functions in order to publish
their platform-specific "helper" objects.
-*- The functional version of csInitializer::SetupEventHandler() now
accepts an event mask, just like the object-oriented version. It also
provides a default event mask, which includes all event types in which
the typical application is interested.
-*- With the introduction of csDefaultRunLoop(), csPlatformStartup(), and
csPlatformShutdown(), it become possible to remove _all_ code from the
Apple/NeXT csSystemDriver subclass, thus the system driver for the
Apple/NeXT ports is now _completely_ empty and can be removed (though
this will not happen until all remaining code is removed from the
csSystemDriver subclasses of the other ports, as well).
-*- Adjusted the Apple/NeXT ports to take into account all of the recent
changes to application initialization and run-loop mechanics. These
ports once again compile cleanly, and the programs run. (The only
exception is that programs which utilize the 3D renderer crash with a
BUS error on address 0x0 when the 3D renderer tries to load the 2D
canvas. I will look into this problem shortly.)
82 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Added the new function csDefaultRunLoop(). This function replaces
csInitializer::MainLoop(), which was non-portable. This function
should be called by applications which do not otherwise implement
their own run-loop. The run-loop implemented by this function is
guaranteed to be portable across all application (since each platform
is given the opportunity to provide an appropriate platform-specific
implementation). Each time through the run-loop, it advances the
virtual clock and processes the Crystal Space event queue.
csDefaultRunLoop() only returns when a csevBroadcast event is posted
to the Crystal Space event queue with command code cscmdQuit. Note,
that if your application already implements its own run-loop, then you
should _not_ call this function, since it would more-or-less
permanently interrupt your own run-loop and prevent it from doing its
work. For instance, if you are adding Crystal Space to an existing
Microsoft Windows application, which already has its own run-loop to
process the Windows event queue, then do _not_ call this function.
-*- csDefaultRunLoop() is intended to be implemented by each platform in a
fashion which is appropriate for implementing run-loops on the given
platform. For instance, with Apple's Cocoa frameworks,
csDefaultRunLoop() should arrange to have the NSApplication class
implement the run-loop; with BeOS's Application Kit,
csDefaultRunLoop() should arrange to have the BApplication class
implement the run-loop; etc.
-*- A default implementation of csDefaultRunLoop() is provided in
CS/libs/cssys/general/runloop.cpp for platforms which do not otherwise
have any special run-loop needs. The default implementation, however,
is very simple-minded in that it merely advances the virtual clock and
processes the event queue until cscmdQuit is received. It is not
particularly platform-friendly since it makes no attempt to yield the
CPU, nor does it make any attempt to interact nicely with a platform's
native GUI.
-*- Implemented a platform-specific csDefaultRunLoop() for the Apple/NeXT
ports. This function is essentially a one-liner which merely asks the
NeXTAssistant (from the object registry) to invoke the
platform-specific run-loop, which is implemented by Cocoa's
NSApplication class.
-*- All other platforms currently employ the default implementation of
csDefaultRunLoop() from runloop.cpp. In the future, however, some
platforms, such as BeOS, will implement their own versions of
csDefaultRunLoop().
-*- Added new functions csPlatformStartup() and csPlatformShutdown().
These functions are called by csInitializer::Initialize() and
csInitializer::DestroyApplication(), respectively, though they can
also be called manually in cases where csInitializer is not utilized.
These functions provide hooks for platform-specific initialization and
shutdown. csPlatformStartup() and csPlatformShutdown() are intended
to be implemented by each platform in some appropriate fashion. One
common use for these functions is to publish platform-specific
"helper" objects via the shared-object registry (iObjectRegistry).
-*- Created default implementations of csPlatformStartup() and
csPlatformShutdown() in CS/libs/cssys/general/sysinit.cpp. The
default implementations of these functions do nothing.
-*- Implemented platform-specific csPlatformStartup() and
csPlatformShutdown() for the Apple/NeXT ports. These functions
publish an iNeXTAssistant with the shared-object registry.
-*- All other platforms currently employ the default implementations of
csPlatformStartup() and csPlatformShutdown() from sysinit.cpp. In the
future, however, some platforms, such as BeOS, Windows, etc., will
implement their own versions of these functions in order to publish
their platform-specific "helper" objects.
-*- The functional version of csInitializer::SetupEventHandler() now
accepts an event mask, just like the object-oriented version. It also
provides a default event mask, which includes all event types in which
the typical application is interested.
-*- With the introduction of csDefaultRunLoop(), csPlatformStartup(), and
csPlatformShutdown(), it become possible to remove _all_ code from the
Apple/NeXT csSystemDriver subclass, thus the system driver for the
Apple/NeXT ports is now _completely_ empty and can be removed (though
this will not happen until all remaining code is removed from the
csSystemDriver subclasses of the other ports, as well).
-*- Adjusted the Apple/NeXT ports to take into account all of the recent
changes to application initialization and run-loop mechanics. These
ports once again compile cleanly, and the programs run. (The only
exception is that programs which utilize the 3D renderer crash with a
BUS error on address 0x0 when the 3D renderer tries to load the 2D
canvas. I will look into this problem shortly.)
10 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Added the new function csDefaultRunLoop(). This function replaces
csInitializer::MainLoop(), which was non-portable. This function
should be called by applications which do not otherwise implement
their own run-loop. The run-loop implemented by this function is
guaranteed to be portable across all application (since each platform
is given the opportunity to provide an appropriate platform-specific
implementation). Each time through the run-loop, it advances the
virtual clock and processes the Crystal Space event queue.
csDefaultRunLoop() only returns when a csevBroadcast event is posted
to the Crystal Space event queue with command code cscmdQuit. Note,
that if your application already implements its own run-loop, then you
should _not_ call this function, since it would more-or-less
permanently interrupt your own run-loop and prevent it from doing its
work. For instance, if you are adding Crystal Space to an existing
Microsoft Windows application, which already has its own run-loop to
process the Windows event queue, then do _not_ call this function.
-*- csDefaultRunLoop() is intended to be implemented by each platform in a
fashion which is appropriate for implementing run-loops on the given
platform. For instance, with Apple's Cocoa frameworks,
csDefaultRunLoop() should arrange to have the NSApplication class
implement the run-loop; with BeOS's Application Kit,
csDefaultRunLoop() should arrange to have the BApplication class
implement the run-loop; etc.
-*- A default implementation of csDefaultRunLoop() is provided in
CS/libs/cssys/general/runloop.cpp for platforms which do not otherwise
have any special run-loop needs. The default implementation, however,
is very simple-minded in that it merely advances the virtual clock and
processes the event queue until cscmdQuit is received. It is not
particularly platform-friendly since it makes no attempt to yield the
CPU, nor does it make any attempt to interact nicely with a platform's
native GUI.
-*- Implemented a platform-specific csDefaultRunLoop() for the Apple/NeXT
ports. This function is essentially a one-liner which merely asks the
NeXTAssistant (from the object registry) to invoke the
platform-specific run-loop, which is implemented by Cocoa's
NSApplication class.
-*- All other platforms currently employ the default implementation of
csDefaultRunLoop() from runloop.cpp. In the future, however, some
platforms, such as BeOS, will implement their own versions of
csDefaultRunLoop().
-*- Added new functions csPlatformStartup() and csPlatformShutdown().
These functions are called by csInitializer::Initialize() and
csInitializer::DestroyApplication(), respectively, though they can
also be called manually in cases where csInitializer is not utilized.
These functions provide hooks for platform-specific initialization and
shutdown. csPlatformStartup() and csPlatformShutdown() are intended
to be implemented by each platform in some appropriate fashion. One
common use for these functions is to publish platform-specific
"helper" objects via the shared-object registry (iObjectRegistry).
-*- Created default implementations of csPlatformStartup() and
csPlatformShutdown() in CS/libs/cssys/general/sysinit.cpp. The
default implementations of these functions do nothing.
-*- Implemented platform-specific csPlatformStartup() and
csPlatformShutdown() for the Apple/NeXT ports. These functions
publish an iNeXTAssistant with the shared-object registry.
-*- All other platforms currently employ the default implementations of
csPlatformStartup() and csPlatformShutdown() from sysinit.cpp. In the
future, however, some platforms, such as BeOS, Windows, etc., will
implement their own versions of these functions in order to publish
their platform-specific "helper" objects.
-*- The functional version of csInitializer::SetupEventHandler() now
accepts an event mask, just like the object-oriented version. It also
provides a default event mask, which includes all event types in which
the typical application is interested.
-*- With the introduction of csDefaultRunLoop(), csPlatformStartup(), and
csPlatformShutdown(), it become possible to remove _all_ code from the
Apple/NeXT csSystemDriver subclass, thus the system driver for the
Apple/NeXT ports is now _completely_ empty and can be removed (though
this will not happen until all remaining code is removed from the
csSystemDriver subclasses of the other ports, as well).
-*- Adjusted the Apple/NeXT ports to take into account all of the recent
changes to application initialization and run-loop mechanics. These
ports once again compile cleanly, and the programs run. (The only
exception is that programs which utilize the 3D renderer crash with a
BUS error on address 0x0 when the 3D renderer tries to load the 2D
canvas. I will look into this problem shortly.)
268 lines of code changed in:
Christopher:
+ Made copy constructor use a const reference to fix no-compile bug in csws.
1 lines of code changed in:
csMeshFactoryWrapper instances are now also added to the current
region. iCurveTemplate and iPolyTxtPlane instances are now correctly
deleted from regions. Thanks to Thiago Ramon for mentioning this.
27 lines of code changed in:
Pages: << Previous 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 Next >>
Generated by StatCvs v0.2-dev