2007-05-30 21:56:52 +00:00
|
|
|
/* ScummVM - Graphic Adventure Engine
|
|
|
|
*
|
|
|
|
* ScummVM is the legal property of its developers, whose names
|
|
|
|
* are too numerous to list here. Please refer to the COPYRIGHT
|
|
|
|
* file distributed with this source distribution.
|
2003-07-28 01:47:41 +00:00
|
|
|
*
|
2007-05-31 20:28:29 +00:00
|
|
|
* Additional copyright for this file:
|
|
|
|
* Copyright (C) 1994-1998 Revolution Software Ltd.
|
|
|
|
*
|
2003-07-28 01:47:41 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
2005-10-18 01:30:26 +00:00
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2003-07-28 01:47:41 +00:00
|
|
|
*/
|
|
|
|
|
2007-09-19 08:40:12 +00:00
|
|
|
|
2005-01-10 22:06:49 +00:00
|
|
|
#include "common/system.h"
|
2011-04-24 08:34:27 +00:00
|
|
|
#include "common/textconsole.h"
|
|
|
|
|
|
|
|
#include "graphics/palette.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
|
2003-10-28 19:51:30 +00:00
|
|
|
#include "sword2/sword2.h"
|
2005-02-19 14:02:16 +00:00
|
|
|
#include "sword2/defs.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/header.h"
|
2005-02-19 14:02:16 +00:00
|
|
|
#include "sword2/logic.h"
|
|
|
|
#include "sword2/resman.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/screen.h"
|
2003-10-04 00:52:27 +00:00
|
|
|
|
|
|
|
namespace Sword2 {
|
2003-07-28 01:47:41 +00:00
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
2005-02-19 14:02:16 +00:00
|
|
|
* Start layer palette fading up
|
2003-09-28 14:13:57 +00:00
|
|
|
*/
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::startNewPalette() {
|
|
|
|
// If the screen is still fading down then wait for black - could
|
|
|
|
// happen when everythings cached into a large memory model
|
|
|
|
waitForFade();
|
|
|
|
|
|
|
|
byte *screenFile = _vm->_resman->openResource(_thisScreen.background_layer_id);
|
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
// Don't fetch palette match table while using PSX version,
|
|
|
|
// because it is not present.
|
2009-09-30 16:16:53 +00:00
|
|
|
if (!Sword2Engine::isPsx())
|
2009-04-07 19:52:46 +00:00
|
|
|
memcpy(_paletteMatch, _vm->fetchPaletteMatchTable(screenFile), PALTABLESIZE);
|
2009-05-24 15:17:42 +00:00
|
|
|
|
2011-02-15 21:52:15 +00:00
|
|
|
_vm->fetchPalette(screenFile, _palette);
|
|
|
|
setPalette(0, 256, _palette, RDPAL_FADE);
|
2005-02-19 14:02:16 +00:00
|
|
|
|
|
|
|
// Indicating that it's a screen palette
|
|
|
|
_lastPaletteRes = 0;
|
|
|
|
|
|
|
|
_vm->_resman->closeResource(_thisScreen.background_layer_id);
|
|
|
|
fadeUp();
|
2008-01-28 00:14:17 +00:00
|
|
|
_thisScreen.new_palette = 0;
|
2005-02-19 14:02:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void Screen::setFullPalette(int32 palRes) {
|
|
|
|
// fudge for hut interior
|
|
|
|
// - unpausing should restore last palette as normal (could be screen
|
|
|
|
// palette or 'dark_palette_13')
|
|
|
|
// - but restoring the screen palette after 'dark_palette_13' should
|
|
|
|
// now work properly too!
|
|
|
|
|
|
|
|
// "Hut interior" refers to the watchman's hut in Marseille, and this
|
|
|
|
// is apparently needed for the palette to be restored properly when
|
|
|
|
// you turn the light off. (I didn't even notice the light switch!)
|
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (_vm->_logic->readVar(LOCATION) == 13) {
|
2005-02-19 14:02:16 +00:00
|
|
|
// unpausing
|
|
|
|
if (palRes == -1) {
|
|
|
|
// restore whatever palette was last set (screen
|
|
|
|
// palette or 'dark_palette_13')
|
|
|
|
palRes = _lastPaletteRes;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// check if we're just restoring the current screen palette
|
|
|
|
// because we might actually need to use a separate palette
|
|
|
|
// file anyway eg. for pausing & unpausing during the eclipse
|
|
|
|
|
|
|
|
// unpausing (fudged for location 13)
|
2008-01-28 00:14:17 +00:00
|
|
|
if (palRes == -1) {
|
2005-02-19 14:02:16 +00:00
|
|
|
// we really meant '0'
|
|
|
|
palRes = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (palRes == 0 && _lastPaletteRes)
|
|
|
|
palRes = _lastPaletteRes;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If non-zero, set palette to this separate palette file. Otherwise,
|
|
|
|
// set palette to current screen palette.
|
|
|
|
|
|
|
|
if (palRes) {
|
|
|
|
byte *pal = _vm->_resman->openResource(palRes);
|
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
assert(_vm->_resman->fetchType(pal) == PALETTE_FILE);
|
2005-02-19 14:02:16 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
pal += ResHeader::size();
|
2005-02-19 14:02:16 +00:00
|
|
|
|
2011-04-14 12:12:27 +00:00
|
|
|
// always set color 0 to black because most background screen
|
|
|
|
// palettes have a bright color 0 although it should come out
|
2005-02-19 14:02:16 +00:00
|
|
|
// as black in the game!
|
|
|
|
|
2011-02-15 21:52:15 +00:00
|
|
|
_palette[0] = 0;
|
|
|
|
_palette[1] = 0;
|
|
|
|
_palette[2] = 0;
|
2005-02-19 14:02:16 +00:00
|
|
|
|
2011-02-15 21:52:15 +00:00
|
|
|
for (uint i = 4, j = 3; i < 4 * 256; i += 4, j += 3) {
|
|
|
|
_palette[j + 0] = pal[i + 0];
|
|
|
|
_palette[j + 1] = pal[i + 1];
|
|
|
|
_palette[j + 2] = pal[i + 2];
|
|
|
|
}
|
|
|
|
|
|
|
|
setPalette(0, 256, _palette, RDPAL_INSTANT);
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_resman->closeResource(palRes);
|
|
|
|
} else {
|
|
|
|
if (_thisScreen.background_layer_id) {
|
|
|
|
byte *data = _vm->_resman->openResource(_thisScreen.background_layer_id);
|
2009-05-24 15:17:42 +00:00
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
// Do not fetch palette match table when using PSX version,
|
|
|
|
// because it is not present.
|
2009-05-24 15:17:42 +00:00
|
|
|
if (!Sword2Engine::isPsx())
|
2009-04-07 19:52:46 +00:00
|
|
|
memcpy(_paletteMatch, _vm->fetchPaletteMatchTable(data), PALTABLESIZE);
|
2009-05-24 15:17:42 +00:00
|
|
|
|
2011-02-15 21:52:15 +00:00
|
|
|
_vm->fetchPalette(data, _palette);
|
|
|
|
setPalette(0, 256, _palette, RDPAL_INSTANT);
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_resman->closeResource(_thisScreen.background_layer_id);
|
|
|
|
} else
|
2009-05-31 10:02:16 +00:00
|
|
|
error("setFullPalette(0) called, but no current screen available");
|
2005-02-19 14:02:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (palRes != CONTROL_PANEL_PALETTE)
|
|
|
|
_lastPaletteRes = palRes;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
2011-04-14 12:12:27 +00:00
|
|
|
* Matches a color triplet to a palette index.
|
|
|
|
* @param r red color component
|
|
|
|
* @param g green color component
|
|
|
|
* @param b blue color component
|
|
|
|
* @return the palette index of the closest matching color in the palette
|
2003-09-28 14:13:57 +00:00
|
|
|
*/
|
|
|
|
|
2003-08-22 07:04:50 +00:00
|
|
|
// FIXME: This used to be inlined - probably a good idea - but the
|
|
|
|
// linker complained when I tried to use it in sprite.cpp.
|
2003-07-28 01:47:41 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
uint8 Screen::quickMatch(uint8 r, uint8 g, uint8 b) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
return _paletteMatch[((int32)(r >> 2) << 12) + ((int32)(g >> 2) << 6) + (b >> 2)];
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
|
|
|
* Sets the palette.
|
2011-04-14 12:12:27 +00:00
|
|
|
* @param startEntry the first color entry to set
|
|
|
|
* @param noEntries the number of color entries to set
|
|
|
|
* @param colorTable the new color entries
|
2004-09-25 23:26:46 +00:00
|
|
|
* @param fadeNow whether to perform the change immediately or delayed
|
2003-09-28 14:13:57 +00:00
|
|
|
*/
|
|
|
|
|
2011-04-14 12:12:27 +00:00
|
|
|
void Screen::setPalette(int16 startEntry, int16 noEntries, byte *colorTable, uint8 fadeNow) {
|
2004-06-09 06:33:29 +00:00
|
|
|
assert(noEntries > 0);
|
|
|
|
|
2011-04-14 12:12:27 +00:00
|
|
|
memmove(&_palette[3 * startEntry], colorTable, noEntries * 3);
|
2004-06-09 06:33:29 +00:00
|
|
|
|
|
|
|
if (fadeNow == RDPAL_INSTANT) {
|
2008-05-29 20:32:27 +00:00
|
|
|
setSystemPalette(_palette, startEntry, noEntries);
|
2004-01-04 15:11:30 +00:00
|
|
|
setNeedFullRedraw();
|
|
|
|
}
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2008-05-29 20:32:27 +00:00
|
|
|
void Screen::dimPalette(bool dim) {
|
2010-11-01 11:25:11 +00:00
|
|
|
if (getFadeStatus() != RDFADE_NONE)
|
|
|
|
return;
|
|
|
|
|
2008-05-29 20:32:27 +00:00
|
|
|
if (dim != _dimPalette) {
|
|
|
|
_dimPalette = dim;
|
2008-11-09 14:35:45 +00:00
|
|
|
setSystemPalette(_palette, 0, 256);
|
|
|
|
setNeedFullRedraw();
|
2004-06-09 06:33:29 +00:00
|
|
|
}
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
|
|
|
* Fades the palette up from black to the current palette.
|
|
|
|
* @param time the time it will take the palette to fade up
|
|
|
|
*/
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
int32 Screen::fadeUp(float time) {
|
2003-10-15 06:40:31 +00:00
|
|
|
if (getFadeStatus() != RDFADE_BLACK && getFadeStatus() != RDFADE_NONE)
|
2003-08-27 07:01:05 +00:00
|
|
|
return RDERR_FADEINCOMPLETE;
|
2003-07-28 01:47:41 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
_fadeTotalTime = (int32)(time * 1000);
|
2003-10-15 06:40:31 +00:00
|
|
|
_fadeStatus = RDFADE_UP;
|
2008-11-09 14:32:24 +00:00
|
|
|
_fadeStartTime = getTick();
|
2003-07-28 01:47:41 +00:00
|
|
|
|
2003-07-28 07:22:40 +00:00
|
|
|
return RD_OK;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
|
|
|
* Fades the palette down to black from the current palette.
|
|
|
|
* @param time the time it will take the palette to fade down
|
|
|
|
*/
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
int32 Screen::fadeDown(float time) {
|
2003-10-15 06:40:31 +00:00
|
|
|
if (getFadeStatus() != RDFADE_BLACK && getFadeStatus() != RDFADE_NONE)
|
2003-08-27 07:01:05 +00:00
|
|
|
return RDERR_FADEINCOMPLETE;
|
2003-07-28 01:47:41 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
_fadeTotalTime = (int32)(time * 1000);
|
2003-10-15 06:40:31 +00:00
|
|
|
_fadeStatus = RDFADE_DOWN;
|
2008-11-09 14:32:24 +00:00
|
|
|
_fadeStartTime = getTick();
|
2003-07-28 01:47:41 +00:00
|
|
|
|
2003-07-28 07:22:40 +00:00
|
|
|
return RD_OK;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2003-09-28 14:13:57 +00:00
|
|
|
/**
|
|
|
|
* Get the current fade status
|
|
|
|
* @return RDFADE_UP (fading up), RDFADE_DOWN (fading down), RDFADE_NONE
|
|
|
|
* (not faded), or RDFADE_BLACK (completely faded down)
|
|
|
|
*/
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
uint8 Screen::getFadeStatus() {
|
2003-10-15 06:40:31 +00:00
|
|
|
return _fadeStatus;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::waitForFade() {
|
2008-09-30 12:27:38 +00:00
|
|
|
while (getFadeStatus() != RDFADE_NONE && getFadeStatus() != RDFADE_BLACK && !_vm->shouldQuit()) {
|
2003-10-15 06:40:31 +00:00
|
|
|
updateDisplay();
|
2004-09-28 20:19:37 +00:00
|
|
|
_vm->_system->delayMillis(20);
|
2003-09-09 12:14:08 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::fadeServer() {
|
2003-08-25 06:13:28 +00:00
|
|
|
static int32 previousTime = 0;
|
2011-02-15 21:52:15 +00:00
|
|
|
byte fadePalette[256 * 3];
|
2004-06-09 06:33:29 +00:00
|
|
|
byte *newPalette = fadePalette;
|
2003-07-31 14:51:02 +00:00
|
|
|
int32 currentTime;
|
|
|
|
int16 fadeMultiplier;
|
|
|
|
int16 i;
|
|
|
|
|
2003-08-25 06:13:28 +00:00
|
|
|
// If we're not in the process of fading, do nothing.
|
2003-10-15 06:40:31 +00:00
|
|
|
if (getFadeStatus() != RDFADE_UP && getFadeStatus() != RDFADE_DOWN)
|
2003-08-25 06:13:28 +00:00
|
|
|
return;
|
2003-07-28 01:47:41 +00:00
|
|
|
|
2003-08-25 06:13:28 +00:00
|
|
|
// I don't know if this is necessary, but let's limit how often the
|
|
|
|
// palette is updated, just to be safe.
|
2008-11-09 14:32:24 +00:00
|
|
|
currentTime = getTick();
|
2003-08-25 06:13:28 +00:00
|
|
|
if (currentTime - previousTime <= 25)
|
2003-07-28 01:47:41 +00:00
|
|
|
return;
|
|
|
|
|
2003-08-25 06:13:28 +00:00
|
|
|
previousTime = currentTime;
|
|
|
|
|
2003-10-15 06:40:31 +00:00
|
|
|
if (getFadeStatus() == RDFADE_UP) {
|
|
|
|
if (currentTime >= _fadeStartTime + _fadeTotalTime) {
|
|
|
|
_fadeStatus = RDFADE_NONE;
|
2004-06-09 06:33:29 +00:00
|
|
|
newPalette = _palette;
|
2003-08-25 06:13:28 +00:00
|
|
|
} else {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
fadeMultiplier = (int16)(((int32)(currentTime - _fadeStartTime) * 256) / _fadeTotalTime);
|
2003-08-25 06:13:28 +00:00
|
|
|
for (i = 0; i < 256; i++) {
|
2011-02-15 21:52:15 +00:00
|
|
|
newPalette[i * 3 + 0] = (_palette[i * 3 + 0] * fadeMultiplier) >> 8;
|
|
|
|
newPalette[i * 3 + 1] = (_palette[i * 3 + 1] * fadeMultiplier) >> 8;
|
|
|
|
newPalette[i * 3 + 2] = (_palette[i * 3 + 2] * fadeMultiplier) >> 8;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
}
|
2003-08-25 06:13:28 +00:00
|
|
|
} else {
|
2003-10-15 06:40:31 +00:00
|
|
|
if (currentTime >= _fadeStartTime + _fadeTotalTime) {
|
|
|
|
_fadeStatus = RDFADE_BLACK;
|
2004-06-09 06:33:29 +00:00
|
|
|
memset(newPalette, 0, sizeof(fadePalette));
|
2003-08-25 06:13:28 +00:00
|
|
|
} else {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
fadeMultiplier = (int16)(((int32)(_fadeTotalTime - (currentTime - _fadeStartTime)) * 256) / _fadeTotalTime);
|
2003-08-25 06:13:28 +00:00
|
|
|
for (i = 0; i < 256; i++) {
|
2011-02-15 21:52:15 +00:00
|
|
|
newPalette[i * 3 + 0] = (_palette[i * 3 + 0] * fadeMultiplier) >> 8;
|
|
|
|
newPalette[i * 3 + 1] = (_palette[i * 3 + 1] * fadeMultiplier) >> 8;
|
|
|
|
newPalette[i * 3 + 2] = (_palette[i * 3 + 2] * fadeMultiplier) >> 8;
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-08-25 06:13:28 +00:00
|
|
|
|
2008-05-29 20:32:27 +00:00
|
|
|
setSystemPalette(newPalette, 0, 256);
|
2004-01-04 15:11:30 +00:00
|
|
|
setNeedFullRedraw();
|
2003-07-28 01:47:41 +00:00
|
|
|
}
|
2003-10-04 00:52:27 +00:00
|
|
|
|
2008-05-29 20:32:27 +00:00
|
|
|
void Screen::setSystemPalette(const byte *colors, uint start, uint num) {
|
|
|
|
const byte *palette;
|
|
|
|
|
|
|
|
if (_dimPalette) {
|
2011-02-15 21:52:15 +00:00
|
|
|
byte pal[256 * 3];
|
2008-05-29 20:32:27 +00:00
|
|
|
|
2011-02-15 21:52:15 +00:00
|
|
|
for (uint i = start * 3; i < 3 * (start + num); i++)
|
2008-05-29 20:32:27 +00:00
|
|
|
pal[i] = colors[i] / 2;
|
|
|
|
|
|
|
|
palette = pal;
|
|
|
|
} else
|
|
|
|
palette = colors;
|
|
|
|
|
2011-02-07 17:52:38 +00:00
|
|
|
_vm->_system->getPaletteManager()->setPalette(palette, start, num);
|
2008-05-29 20:32:27 +00:00
|
|
|
}
|
|
|
|
|
2003-10-04 00:52:27 +00:00
|
|
|
} // End of namespace Sword2
|