This is document describing proper use of the GraphicsLock when
extending code.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1270 8092fc87-c524-0410-9efc-e669fe64eaf9
The decoders are now virtualized, the high-level decoding code is unified
and any format is theoretically streamable.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1266 8092fc87-c524-0410-9efc-e669fe64eaf9
You *must* hold the GraphicsLock when calling SetFlashRect.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1265 8092fc87-c524-0410-9efc-e669fe64eaf9
Removed an unnecessary level of indirection;
decoder-specific data is kept together with general decoder data.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1261 8092fc87-c524-0410-9efc-e669fe64eaf9
This is a near-total reorganization. Full details will appear in
doc/devel/threads when that document is completed.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1257 8092fc87-c524-0410-9efc-e669fe64eaf9
All constructs, save Mutexes, can carry names. (Mutexes will carry them
once HMalloc doesn't require a Mutex.)
All constructs are now opaque to the game logic. Some limited upcalls
will be added in phase 2 so that the game logic can initialize some
thread-local data in a backend-independent way.
DEBUG_TRACK_SEM is gone. In its place are NAMED_SYNCHRO (which names
synchronization constructs) and TRACK_CONTENTION (which reports when
threads go to sleep because of synchronization constructs.) Again,
Mutexes are immune.
A lot of conditionally compiled code in the threadlib was collated,
dramatically reducing the number of preprocessing directives.
The exposed (threadlib.h) and backend (sdlthreads.h) APIs match one
another more closely now, further reducing the level of preprocessor
work required.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1255 8092fc87-c524-0410-9efc-e669fe64eaf9
Code will attempt playing intro and victory movies
(video playback support phase 2)
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1251 8092fc87-c524-0410-9efc-e669fe64eaf9
Code will attempt playing intro and victory movies
(video playback support phase 2)
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1250 8092fc87-c524-0410-9efc-e669fe64eaf9
1) The boxes and text is drawn in the same batch as the rest of the summary, so
the fade-in's now have the text and it doesn't appear a split second later.
2) Widens the rects to closer match the PC version (4 of 4 people polled
prefered the new look.
3) Adds a little bound check for when the SAVES_PER_PAGE doesn't divide evenly
into MAXED_SAVED_GAMES
4) Expands the black rect to cover the safe-x expanded bars.
5) When displaying more then 99 saves will display 3 digits.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1241 8092fc87-c524-0410-9efc-e669fe64eaf9
Trackplayer-specific code is separated from the streamer and
is done in callbacks; buffer-tagging is also callback-driven;
(movie playback support phase 1)
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1238 8092fc87-c524-0410-9efc-e669fe64eaf9
CrossThreadMutex has the semantics for locking that we actually want, as
opposed to Semaphores, which are "close enough" but fail dramatically on
double-unlocks. The clock and graphics locks have been shifted over to
CTMs, but a few still remain (and will be replaced later).
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1232 8092fc87-c524-0410-9efc-e669fe64eaf9
Like w_memlib, these are always unlocked at procedure boundaries, so
shifting to Mutexes is safe.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1226 8092fc87-c524-0410-9efc-e669fe64eaf9
Mutex locks, unlike semaphore locks, cannot fail, but they must stay
within their thread. The memory lock is unlocked at all procedure
boundaries; thus, it is safe to use a normal mutex.
git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@1225 8092fc87-c524-0410-9efc-e669fe64eaf9
avolkov
mcmartin
gewlitys
meep-eep