adam/cobm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

updated

Browse Source 
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@391 8092fc87-c524-0410-9efc-e669fe64eaf9
This commit is contained in:
gewlitys
2002-12-10 17:46:12 +00:00
parent 69afc0541c
commit 8596a3d757
2 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
sc2/ChangeLog
+6
View File
@@ -1,4 +1,10 @@
0.2: 0.2:
- Fixed planet stuff when leaving surface with lander, from PhracturedBlue
- RotatePlanet now holds GraphicsSem a shorter time, from PhracturedBlue
- Added proper mutex usage to 3do_getbody.c, from PhracturedBlue
- Scan uses now additive blit instead of transparency, from PhracturedBlue
- Loading game saved while in orbit fixed (bg correct), from PhracturedBlue
- Changed SDL_Delay to SleepThread in TFB_FlushGraphics
- Rendering thread now broadcasts to a condition variable, stopping most - Rendering thread now broadcasts to a condition variable, stopping most
of the problems we were having where a fast thread spams the DCQ with of the problems we were having where a fast thread spams the DCQ with
too many requests to handle in a timely manner too many requests to handle in a timely manner
sc2/TODO
+4 -10
View File
@@ -80,10 +80,6 @@ Glitches (don't crash the game, medium priority):
selecting a destination, crashes selecting a destination, crashes
- Under some conditions, the direction the ship is facing in Hyperspace - Under some conditions, the direction the ship is facing in Hyperspace
isn't restored when loading. isn't restored when loading.
- When exiting from planet surface with lander, the 3d planet isn't updated
for a little moment which causes black track on planet to be seen
- Or, perhaps more probably, the background image isn't drawn properly
(and thus the planet there is some old buffer remains for that moment)
- Moving crosshair in planet screen leaves a light trace to the image - Moving crosshair in planet screen leaves a light trace to the image
in OpenGL mode (SDL surface format conversion problem) in OpenGL mode (SDL surface format conversion problem)
- You seem to be able to do certain things before you're supposed to - You seem to be able to do certain things before you're supposed to
@@ -92,7 +88,6 @@ Glitches (don't crash the game, medium priority):
- This always happens, regardless of game state. This is a bug in - This always happens, regardless of game state. This is a bug in
both predecessors as well. both predecessors as well.
Probably the negative shift for GET_STATE and SET_STATE Probably the negative shift for GET_STATE and SET_STATE
- comm.c color transform speed is too fast when compared to PC version
Implementation bugs (low priority): Implementation bugs (low priority):
- Scaling code problems: - Scaling code problems:
@@ -104,12 +99,11 @@ Implementation bugs (low priority):
- 3D planet view when entering orbit is now done, but there's some things - 3D planet view when entering orbit is now done, but there's some things
which could make it look nicer, like better lighting, better slave shield which could make it look nicer, like better lighting, better slave shield
and removing occasional pops/discontinuities and removing occasional pops/discontinuities
- Rotation and zooming isn't now as smooth as before after condition
variable DCQ patch
- DrawCommandQueue is gratuitously dynamically allocated, should be static - DrawCommandQueue is gratuitously dynamically allocated, should be static
- Lines and colouring of planet surface display when scanning are now done, - Transitions (crossfades) aren't perhaps correctly done always, syncing
but seem to be little different (darker) than in 3do lander videoclip. might be wrong etc.
And is the speed correct?
- Transitions aren't synced always; there should be a way to ensure everything
so far queued is drawn before the transition starts
Stuff still to do (large): Stuff still to do (large):
- add a Key Jamming program - add a Key Jamming program