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:44:38 +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:44:38 +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:44:38 +00:00
|
|
|
*
|
2006-02-09 15:12:44 +00:00
|
|
|
* $URL$
|
|
|
|
* $Id$
|
2003-07-28 01:44:38 +00:00
|
|
|
*/
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// ---------------------------------------------------------------------------
|
2003-07-28 01:44:38 +00:00
|
|
|
// BUILD_DISPLAY.CPP like the old spr_engi but slightly more aptly named
|
2003-09-02 09:54:42 +00:00
|
|
|
// ---------------------------------------------------------------------------
|
|
|
|
|
2007-09-19 08:40:12 +00:00
|
|
|
|
2005-01-10 22:06:49 +00:00
|
|
|
#include "common/system.h"
|
2007-06-21 19:33:05 +00:00
|
|
|
#include "common/events.h"
|
2005-02-19 14:02:16 +00:00
|
|
|
|
2003-10-28 19:51:30 +00:00
|
|
|
#include "sword2/sword2.h"
|
|
|
|
#include "sword2/defs.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/header.h"
|
|
|
|
#include "sword2/console.h"
|
2004-02-05 14:19:07 +00:00
|
|
|
#include "sword2/logic.h"
|
|
|
|
#include "sword2/maketext.h"
|
2005-02-19 14:02:16 +00:00
|
|
|
#include "sword2/mouse.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/object.h"
|
2004-02-05 14:19:07 +00:00
|
|
|
#include "sword2/resman.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/screen.h"
|
2005-05-02 05:41:01 +00:00
|
|
|
#include "sword2/sound.h"
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-04 00:52:27 +00:00
|
|
|
namespace Sword2 {
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
Screen::Screen(Sword2Engine *vm, int16 width, int16 height) {
|
|
|
|
_vm = vm;
|
|
|
|
|
|
|
|
_dirtyGrid = _buffer = NULL;
|
|
|
|
|
|
|
|
_screenWide = width;
|
|
|
|
_screenDeep = height;
|
|
|
|
|
|
|
|
_gridWide = width / CELLWIDE;
|
|
|
|
_gridDeep = height / CELLDEEP;
|
|
|
|
|
|
|
|
if ((width % CELLWIDE) || (height % CELLDEEP))
|
|
|
|
error("Bad cell size");
|
|
|
|
|
2005-05-12 13:12:15 +00:00
|
|
|
_dirtyGrid = (byte *)calloc(_gridWide, _gridDeep);
|
2005-02-19 14:02:16 +00:00
|
|
|
if (!_dirtyGrid)
|
|
|
|
error("Could not initialise dirty grid");
|
|
|
|
|
2005-05-12 13:12:15 +00:00
|
|
|
_buffer = (byte *)malloc(width * height);
|
2005-02-19 14:02:16 +00:00
|
|
|
if (!_buffer)
|
|
|
|
error("Could not initialise display");
|
|
|
|
|
|
|
|
for (int i = 0; i < ARRAYSIZE(_blockSurfaces); i++)
|
|
|
|
_blockSurfaces[i] = NULL;
|
|
|
|
|
|
|
|
_lightMask = NULL;
|
|
|
|
_needFullRedraw = false;
|
|
|
|
|
|
|
|
memset(&_thisScreen, 0, sizeof(_thisScreen));
|
2009-05-24 15:17:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
_fps = 0;
|
|
|
|
_frameCount = 0;
|
|
|
|
_cycleTime = 0;
|
|
|
|
|
|
|
|
_lastPaletteRes = 0;
|
|
|
|
|
|
|
|
_scrollFraction = 16;
|
|
|
|
|
|
|
|
_largestLayerArea = 0;
|
|
|
|
_largestSpriteArea = 0;
|
|
|
|
|
|
|
|
strcpy(_largestLayerInfo, "largest layer: none registered");
|
|
|
|
strcpy(_largestSpriteInfo, "largest sprite: none registered");
|
|
|
|
|
|
|
|
_fadeStatus = RDFADE_NONE;
|
|
|
|
_renderAverageTime = 60;
|
|
|
|
|
|
|
|
_layer = 0;
|
2008-05-29 20:32:27 +00:00
|
|
|
|
|
|
|
_dimPalette = false;
|
2008-11-09 13:50:41 +00:00
|
|
|
|
|
|
|
_pauseTicks = 0;
|
|
|
|
_pauseStartTick = 0;
|
2009-04-07 19:52:46 +00:00
|
|
|
|
2009-05-24 15:17:42 +00:00
|
|
|
// Clean the cache for PSX version SCREENS.CLU
|
2009-04-07 19:52:46 +00:00
|
|
|
_psxScrCache[0] = NULL;
|
|
|
|
_psxScrCache[1] = NULL;
|
|
|
|
_psxScrCache[2] = NULL;
|
|
|
|
_psxCacheEnabled[0] = true;
|
|
|
|
_psxCacheEnabled[1] = true;
|
|
|
|
_psxCacheEnabled[2] = true;
|
2005-02-19 14:02:16 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Screen::~Screen() {
|
2009-04-07 19:52:46 +00:00
|
|
|
flushPsxScrCache();
|
2005-02-19 14:02:16 +00:00
|
|
|
free(_buffer);
|
|
|
|
free(_dirtyGrid);
|
|
|
|
closeBackgroundLayer();
|
|
|
|
free(_lightMask);
|
|
|
|
}
|
|
|
|
|
2008-11-09 14:32:24 +00:00
|
|
|
uint32 Screen::getTick() {
|
|
|
|
return _vm->getMillis() - _pauseTicks;
|
|
|
|
}
|
|
|
|
|
2008-11-09 13:50:41 +00:00
|
|
|
void Screen::pauseScreen(bool pause) {
|
|
|
|
if (pause) {
|
|
|
|
_pauseStartTick = _vm->_system->getMillis();
|
|
|
|
} else {
|
|
|
|
_pauseTicks += (_vm->_system->getMillis() - _pauseStartTick);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2006-04-03 09:54:05 +00:00
|
|
|
/**
|
|
|
|
* @return the graphics detail setting
|
|
|
|
*/
|
|
|
|
|
|
|
|
int8 Screen::getRenderLevel() {
|
|
|
|
return _renderLevel;
|
|
|
|
}
|
|
|
|
|
|
|
|
void Screen::setRenderLevel(int8 level) {
|
|
|
|
_renderLevel = level;
|
|
|
|
|
|
|
|
switch (_renderLevel) {
|
|
|
|
case 0:
|
|
|
|
// Lowest setting: no fancy stuff
|
|
|
|
_renderCaps = 0;
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
// Medium-low setting: transparency-blending
|
|
|
|
_renderCaps = RDBLTFX_SPRITEBLEND;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
// Medium-high setting: transparency-blending + shading
|
|
|
|
_renderCaps = RDBLTFX_SPRITEBLEND | RDBLTFX_SHADOWBLEND;
|
|
|
|
break;
|
|
|
|
case 3:
|
|
|
|
// Highest setting: transparency-blending + shading +
|
|
|
|
// edge-blending + improved stretching
|
|
|
|
_renderCaps = RDBLTFX_SPRITEBLEND | RDBLTFX_SHADOWBLEND | RDBLTFX_EDGEBLEND;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Tell updateDisplay() that the scene needs to be completely updated.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Screen::setNeedFullRedraw() {
|
|
|
|
_needFullRedraw = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Mark an area of the screen as dirty, first generation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Screen::markAsDirty(int16 x0, int16 y0, int16 x1, int16 y1) {
|
|
|
|
int16 gridX0 = x0 / CELLWIDE;
|
|
|
|
int16 gridY0 = y0 / CELLDEEP;
|
|
|
|
int16 gridX1 = x1 / CELLWIDE;
|
|
|
|
int16 gridY1 = y1 / CELLDEEP;
|
|
|
|
|
|
|
|
for (int16 i = gridY0; i <= gridY1; i++)
|
|
|
|
for (int16 j = gridX0; j <= gridX1; j++)
|
|
|
|
_dirtyGrid[i * _gridWide + j] = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This function has two purposes: It redraws the scene, and it handles input
|
|
|
|
* events, palette fading, etc. It should be called at a high rate (> 20 per
|
|
|
|
* second), but the scene is usually only redrawn about 12 times per second,
|
|
|
|
* except when then screen is scrolling.
|
|
|
|
*
|
|
|
|
* @param redrawScene If true, redraw the scene.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Screen::updateDisplay(bool redrawScene) {
|
|
|
|
_vm->parseInputEvents();
|
|
|
|
fadeServer();
|
|
|
|
|
|
|
|
if (redrawScene) {
|
|
|
|
int i;
|
|
|
|
|
|
|
|
// Note that the entire scene is always rendered, which is less
|
|
|
|
// than optimal, but at least we can try to be intelligent
|
|
|
|
// about updating the screen afterwards.
|
|
|
|
|
|
|
|
if (_needFullRedraw) {
|
|
|
|
// Update the entire screen. This is necessary when
|
|
|
|
// scrolling, fading, etc.
|
|
|
|
|
|
|
|
_vm->_system->copyRectToScreen(_buffer + MENUDEEP * _screenWide, _screenWide, 0, MENUDEEP, _screenWide, _screenDeep - 2 * MENUDEEP);
|
|
|
|
_needFullRedraw = false;
|
|
|
|
} else {
|
|
|
|
// Update only the dirty areas of the screen
|
|
|
|
|
|
|
|
int j, x, y;
|
|
|
|
int stripWide;
|
|
|
|
|
|
|
|
for (i = 0; i < _gridDeep; i++) {
|
|
|
|
stripWide = 0;
|
|
|
|
|
|
|
|
for (j = 0; j < _gridWide; j++) {
|
|
|
|
if (_dirtyGrid[i * _gridWide + j]) {
|
|
|
|
stripWide++;
|
|
|
|
} else if (stripWide) {
|
|
|
|
x = CELLWIDE * (j - stripWide);
|
|
|
|
y = CELLDEEP * i;
|
|
|
|
_vm->_system->copyRectToScreen(_buffer + y * _screenWide + x, _screenWide, x, y, stripWide * CELLWIDE, CELLDEEP);
|
|
|
|
stripWide = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (stripWide) {
|
|
|
|
x = CELLWIDE * (j - stripWide);
|
|
|
|
y = CELLDEEP * i;
|
|
|
|
_vm->_system->copyRectToScreen(_buffer + y * _screenWide + x, _screenWide, x, y, stripWide * CELLWIDE, CELLDEEP);
|
|
|
|
stripWide = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Age the dirty cells one generation. This way we keep track
|
|
|
|
// of both the cells that were updated this time, and the ones
|
|
|
|
// that were updated the last time.
|
|
|
|
|
|
|
|
for (i = 0; i < _gridWide * _gridDeep; i++)
|
|
|
|
_dirtyGrid[i] >>= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We always need to update because of fades, menu animations, etc.
|
|
|
|
_vm->_system->updateScreen();
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Fill the screen buffer with palette colour zero. Note that it does not
|
|
|
|
* touch the menu areas of the screen.
|
|
|
|
*/
|
|
|
|
|
|
|
|
void Screen::clearScene() {
|
|
|
|
memset(_buffer + MENUDEEP * _screenWide, 0, _screenWide * RENDERDEEP);
|
|
|
|
_needFullRedraw = true;
|
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::buildDisplay() {
|
2003-11-02 17:17:10 +00:00
|
|
|
if (_thisScreen.new_palette) {
|
2003-09-02 09:54:42 +00:00
|
|
|
// start the layer palette fading up
|
2003-11-01 16:55:20 +00:00
|
|
|
startNewPalette();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-11-01 16:55:20 +00:00
|
|
|
// should be reset to zero at start of each screen change
|
|
|
|
_largestLayerArea = 0;
|
|
|
|
_largestSpriteArea = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// Does this ever happen?
|
|
|
|
if (!_thisScreen.background_layer_id)
|
|
|
|
return;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// there is a valid screen to run
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
setScrollTarget(_thisScreen.scroll_offset_x, _thisScreen.scroll_offset_y);
|
|
|
|
_vm->_mouse->animateMouse();
|
|
|
|
startRenderCycle();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
byte *file = _vm->_resman->openResource(_thisScreen.background_layer_id);
|
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
|
|
|
|
|
|
|
MultiScreenHeader screenLayerTable;
|
2009-05-13 18:12:17 +00:00
|
|
|
memset(&screenLayerTable, 0, sizeof(screenLayerTable));
|
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
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
if (!Sword2Engine::isPsx()) // On PSX version, there would be nothing to read here
|
|
|
|
screenLayerTable.read(file + ResHeader::size());
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// Render at least one frame, but if the screen is scrolling, and if
|
|
|
|
// there is time left, we will render extra frames to smooth out the
|
|
|
|
// scrolling.
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
do {
|
|
|
|
// first background parallax + related anims
|
2009-04-07 19:52:46 +00:00
|
|
|
if (Sword2Engine::isPsx() || screenLayerTable.bg_parallax[0]) { // No need to check on PSX version
|
2005-02-19 14:02:16 +00:00
|
|
|
renderParallax(_vm->fetchBackgroundParallaxLayer(file, 0), 0);
|
2004-03-28 13:16:01 +00:00
|
|
|
drawBackPar0Frames();
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// second background parallax + related anims
|
2009-04-07 19:52:46 +00:00
|
|
|
if (!Sword2Engine::isPsx() && screenLayerTable.bg_parallax[1]) { // Nothing here in PSX version
|
2005-02-19 14:02:16 +00:00
|
|
|
renderParallax(_vm->fetchBackgroundParallaxLayer(file, 1), 1);
|
2004-03-28 13:16:01 +00:00
|
|
|
drawBackPar1Frames();
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// normal backround layer (just the one!)
|
2005-02-19 14:02:16 +00:00
|
|
|
renderParallax(_vm->fetchBackgroundLayer(file), 2);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// sprites & layers
|
|
|
|
drawBackFrames(); // background sprites
|
|
|
|
drawSortFrames(file); // sorted sprites & layers
|
|
|
|
drawForeFrames(); // foreground sprites
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// first foreground parallax + related anims
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
if (Sword2Engine::isPsx() || screenLayerTable.fg_parallax[0]) {
|
2005-02-19 14:02:16 +00:00
|
|
|
renderParallax(_vm->fetchForegroundParallaxLayer(file, 0), 3);
|
2004-03-28 13:16:01 +00:00
|
|
|
drawForePar0Frames();
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// second foreground parallax + related anims
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
if (!Sword2Engine::isPsx() && screenLayerTable.fg_parallax[1]) {
|
2005-02-19 14:02:16 +00:00
|
|
|
renderParallax(_vm->fetchForegroundParallaxLayer(file, 1), 4);
|
2004-03-28 13:16:01 +00:00
|
|
|
drawForePar1Frames();
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_debugger->drawDebugGraphics();
|
|
|
|
_vm->_fontRenderer->printTextBlocs();
|
|
|
|
_vm->_mouse->processMenu();
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
updateDisplay();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
_frameCount++;
|
2008-11-09 14:32:24 +00:00
|
|
|
if (getTick() > _cycleTime) {
|
2004-03-28 13:16:01 +00:00
|
|
|
_fps = _frameCount;
|
|
|
|
_frameCount = 0;
|
2008-11-09 14:32:24 +00:00
|
|
|
_cycleTime = getTick() + 1000;
|
2003-10-15 06:40:31 +00:00
|
|
|
}
|
2005-02-19 14:02:16 +00:00
|
|
|
} while (!endRenderCycle());
|
2004-03-28 13:16:01 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_resman->closeResource(_thisScreen.background_layer_id);
|
2009-04-07 19:52:46 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
/**
|
|
|
|
* Fades down and displays a message on the screen.
|
|
|
|
* @param text The message
|
2004-06-10 06:48:50 +00:00
|
|
|
* @param time The number of seconds to display the message, or 0 to display it
|
|
|
|
* until the user clicks the mouse or presses a key.
|
2004-03-28 13:16:01 +00:00
|
|
|
*/
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::displayMsg(byte *text, int time) {
|
2004-06-09 06:33:29 +00:00
|
|
|
byte pal[256 * 4];
|
|
|
|
byte oldPal[256 * 4];
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
debug(2, "DisplayMsg: %s", text);
|
2005-07-30 21:11:48 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
if (getFadeStatus() != RDFADE_BLACK) {
|
|
|
|
fadeDown();
|
|
|
|
waitForFade();
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_mouse->setMouse(0);
|
|
|
|
_vm->_mouse->setLuggage(0);
|
|
|
|
_vm->_mouse->closeMenuImmediately();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
clearScene();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
byte *text_spr = _vm->_fontRenderer->makeTextSprite(text, 640, 187, _vm->_speechFontId);
|
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
|
|
|
|
|
|
|
FrameHeader frame;
|
|
|
|
|
|
|
|
frame.read(text_spr);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
SpriteInfo spriteInfo;
|
2003-07-28 01:44:38 +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
|
|
|
spriteInfo.x = _screenWide / 2 - frame.width / 2;
|
2003-07-28 01:44:38 +00:00
|
|
|
if (!time)
|
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
|
|
|
spriteInfo.y = _screenDeep / 2 - frame.height / 2 - MENUDEEP;
|
2003-07-28 01:44:38 +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
|
|
|
spriteInfo.y = 400 - frame.height;
|
|
|
|
spriteInfo.w = frame.width;
|
|
|
|
spriteInfo.h = frame.height;
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.scale = 0;
|
|
|
|
spriteInfo.scaledWidth = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
spriteInfo.scaledHeight = 0;
|
2003-10-11 12:26:53 +00:00
|
|
|
spriteInfo.type = RDSPR_DISPLAYALIGN | RDSPR_NOCOMPRESSION | RDSPR_TRANS;
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.blend = 0;
|
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
|
|
|
spriteInfo.data = text_spr + FrameHeader::size();
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.colourTable = 0;
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.isText = true;
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
uint32 rv = drawSprite(&spriteInfo);
|
2003-07-28 01:44:38 +00:00
|
|
|
if (rv)
|
2003-09-27 11:02:58 +00:00
|
|
|
error("Driver Error %.8x (in DisplayMsg)", rv);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
memcpy(oldPal, _palette, sizeof(oldPal));
|
2004-06-09 06:33:29 +00:00
|
|
|
memset(pal, 0, sizeof(pal));
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-06-09 06:33:29 +00:00
|
|
|
pal[187 * 4 + 0] = 255;
|
|
|
|
pal[187 * 4 + 1] = 255;
|
|
|
|
pal[187 * 4 + 2] = 255;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
setPalette(0, 256, pal, RDPAL_FADE);
|
|
|
|
fadeUp();
|
2004-04-23 07:02:11 +00:00
|
|
|
free(text_spr);
|
2005-02-19 14:02:16 +00:00
|
|
|
waitForFade();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-06-10 06:48:50 +00:00
|
|
|
if (time > 0) {
|
2008-11-09 14:32:24 +00:00
|
|
|
uint32 targetTime = _vm->_system->getMillis() + (time * 1000);
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->sleepUntil(targetTime);
|
2004-06-10 06:48:50 +00:00
|
|
|
} else {
|
2008-09-30 12:27:38 +00:00
|
|
|
while (!_vm->shouldQuit()) {
|
2005-02-19 14:02:16 +00:00
|
|
|
MouseEvent *me = _vm->mouseEvent();
|
2004-06-10 06:48:50 +00:00
|
|
|
if (me && (me->buttons & (RD_LEFTBUTTONDOWN | RD_RIGHTBUTTONDOWN)))
|
|
|
|
break;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
if (_vm->keyboardEvent())
|
2004-06-10 06:48:50 +00:00
|
|
|
break;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
updateDisplay();
|
|
|
|
_vm->_system->delayMillis(50);
|
2004-06-10 06:48:50 +00:00
|
|
|
}
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
fadeDown();
|
|
|
|
waitForFade();
|
|
|
|
clearScene();
|
|
|
|
setPalette(0, 256, oldPal, RDPAL_FADE);
|
|
|
|
fadeUp();
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawBackPar0Frames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// frame attached to 1st background parallax
|
|
|
|
for (uint i = 0; i < _curBgp0; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_bgp0List[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawBackPar1Frames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// frame attached to 2nd background parallax
|
|
|
|
for (uint i = 0; i < _curBgp1; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_bgp1List[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawBackFrames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// background sprite, fixed to main background
|
|
|
|
for (uint i = 0; i < _curBack; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_backList[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawSortFrames(byte *file) {
|
2004-03-28 13:16:01 +00:00
|
|
|
uint i, j;
|
|
|
|
|
|
|
|
// Sort the sort list. Used to be a separate function, but it was only
|
|
|
|
// called once, right before calling drawSortFrames().
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
if (_curSort > 1) {
|
|
|
|
for (i = 0; i < _curSort - 1; i++) {
|
|
|
|
for (j = 0; j < _curSort - 1; j++) {
|
|
|
|
if (_sortList[_sortOrder[j]].sort_y > _sortList[_sortOrder[j + 1]].sort_y) {
|
|
|
|
SWAP(_sortOrder[j], _sortOrder[j + 1]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Draw the sorted frames - layers, shrinkers & normal flat sprites
|
|
|
|
|
|
|
|
for (i = 0; i < _curSort; i++) {
|
2003-11-01 16:55:20 +00:00
|
|
|
if (_sortList[_sortOrder[i]].layer_number) {
|
2003-12-28 15:08:12 +00:00
|
|
|
// it's a layer - minus 1 for true layer number
|
|
|
|
// we need to know from the BuildUnit because the
|
|
|
|
// layers will have been sorted in random order
|
2004-03-28 13:16:01 +00:00
|
|
|
processLayer(file, _sortList[_sortOrder[i]].layer_number - 1);
|
2003-09-02 09:54:42 +00:00
|
|
|
} else {
|
2004-03-28 13:16:01 +00:00
|
|
|
// it's a sprite
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_sortList[_sortOrder[i]]);
|
2003-09-02 09:54:42 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawForeFrames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// foreground sprite, fixed to main background
|
|
|
|
for (uint i = 0; i < _curFore; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_foreList[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawForePar0Frames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// frame attached to 1st foreground parallax
|
|
|
|
for (uint i = 0; i < _curFgp0; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_fgp0List[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::drawForePar1Frames() {
|
2004-03-28 13:16:01 +00:00
|
|
|
// frame attached to 2nd foreground parallax
|
|
|
|
for (uint i = 0; i < _curFgp1; i++)
|
2003-11-01 16:55:20 +00:00
|
|
|
processImage(&_fgp1List[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::processLayer(byte *file, uint32 layer_number) {
|
2009-04-07 19:52:46 +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
|
|
|
LayerHeader layer_head;
|
|
|
|
|
|
|
|
layer_head.read(_vm->fetchLayerHeader(file, layer_number));
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2008-01-28 00:14:17 +00:00
|
|
|
SpriteInfo spriteInfo;
|
2003-07-28 01:44:38 +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
|
|
|
spriteInfo.x = layer_head.x;
|
|
|
|
spriteInfo.y = layer_head.y;
|
|
|
|
spriteInfo.w = layer_head.width;
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.scale = 0;
|
|
|
|
spriteInfo.scaledWidth = 0;
|
|
|
|
spriteInfo.scaledHeight = 0;
|
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
|
|
|
spriteInfo.h = layer_head.height;
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.isText = false;
|
|
|
|
|
|
|
|
// Layers are uncompressed in PSX version, RLE256 compressed
|
|
|
|
// in PC version.
|
2009-05-24 15:17:42 +00:00
|
|
|
if (Sword2Engine::isPsx()) {
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.type = RDSPR_TRANS | RDSPR_NOCOMPRESSION;
|
|
|
|
spriteInfo.data = file + layer_head.offset;
|
|
|
|
} else {
|
|
|
|
spriteInfo.type = RDSPR_TRANS | RDSPR_RLE256FAST;
|
|
|
|
spriteInfo.data = file + ResHeader::size() + layer_head.offset;
|
|
|
|
}
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.blend = 0;
|
|
|
|
spriteInfo.colourTable = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// check for largest layer for debug info
|
2003-09-02 09:54:42 +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
|
|
|
uint32 current_layer_area = layer_head.width * layer_head.height;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-11-01 16:55:20 +00:00
|
|
|
if (current_layer_area > _largestLayerArea) {
|
|
|
|
_largestLayerArea = current_layer_area;
|
|
|
|
sprintf(_largestLayerInfo,
|
2003-09-02 09:54:42 +00:00
|
|
|
"largest layer: %s layer(%d) is %dx%d",
|
2006-07-08 20:45:01 +00:00
|
|
|
_vm->_resman->fetchName(_thisScreen.background_layer_id),
|
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
|
|
|
layer_number, layer_head.width, layer_head.height);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-26 15:42:49 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
uint32 rv = drawSprite(&spriteInfo);
|
2003-07-28 01:44:38 +00:00
|
|
|
if (rv)
|
2004-03-28 13:16:01 +00:00
|
|
|
error("Driver Error %.8x in processLayer(%d)", rv, layer_number);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::processImage(BuildUnit *build_unit) {
|
2009-04-18 08:37:22 +00:00
|
|
|
|
|
|
|
// We have some problematic animation frames in PSX demo (looks like there is missing data),
|
|
|
|
// so we just skip them.
|
|
|
|
if ( (Sword2Engine::isPsx() && _vm->_logic->readVar(DEMO)) &&
|
2009-05-24 15:17:42 +00:00
|
|
|
((build_unit->anim_resource == 369 && build_unit->anim_pc == 0) ||
|
2009-04-18 08:37:22 +00:00
|
|
|
(build_unit->anim_resource == 296 && build_unit->anim_pc == 5) ||
|
2009-05-24 15:17:42 +00:00
|
|
|
(build_unit->anim_resource == 534 && build_unit->anim_pc == 13)) )
|
2009-04-18 08:37:22 +00:00
|
|
|
return;
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
byte *file = _vm->_resman->openResource(build_unit->anim_resource);
|
2004-04-23 07:02:11 +00:00
|
|
|
byte *colTablePtr = NULL;
|
2003-07-28 01:44:38 +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
|
|
|
byte *frame = _vm->fetchFrameHeader(file, build_unit->anim_pc);
|
|
|
|
|
|
|
|
AnimHeader anim_head;
|
|
|
|
CdtEntry cdt_entry;
|
|
|
|
FrameHeader frame_head;
|
|
|
|
|
|
|
|
anim_head.read(_vm->fetchAnimHeader(file));
|
|
|
|
cdt_entry.read(_vm->fetchCdtEntry(file, build_unit->anim_pc));
|
|
|
|
frame_head.read(frame);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// so that 0-colour is transparent
|
2004-03-28 13:16:01 +00:00
|
|
|
uint32 spriteType = RDSPR_TRANS;
|
2003-07-28 01:44:38 +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
|
|
|
if (anim_head.blend)
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_BLEND;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// if the frame is to be flipped (only really applicable to frames
|
|
|
|
// using offsets)
|
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 (cdt_entry.frameType & FRAME_FLIPPED)
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_FLIP;
|
2003-07-28 01:44:38 +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
|
|
|
if (cdt_entry.frameType & FRAME_256_FAST) {
|
2003-09-02 09:54:42 +00:00
|
|
|
// scaling, shading & blending don't work with RLE256FAST
|
|
|
|
// but the same compression can be decompressed using the
|
|
|
|
// RLE256 routines!
|
|
|
|
|
2003-10-15 06:40:31 +00:00
|
|
|
// NOTE: If this restriction refers to drawSprite(), I don't
|
2003-09-02 09:54:42 +00:00
|
|
|
// think we have it any more. But I'm not sure.
|
|
|
|
|
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 (build_unit->scale || anim_head.blend || build_unit->shadingFlag)
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_RLE256;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_RLE256FAST;
|
2003-09-02 09:54:42 +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
|
|
|
switch (anim_head.runTimeComp) {
|
2003-09-21 16:11:26 +00:00
|
|
|
case NONE:
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_NOCOMPRESSION;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case RLE256:
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_RLE256;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case RLE16:
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_RLE16;
|
2003-09-21 16:11:26 +00:00
|
|
|
// points to just after last cdt_entry, ie.
|
|
|
|
// start of colour table
|
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
|
|
|
colTablePtr = _vm->fetchAnimHeader(file) + AnimHeader::size() + anim_head.noAnimFrames * CdtEntry::size();
|
2009-04-07 19:52:46 +00:00
|
|
|
if (Sword2Engine::isPsx())
|
|
|
|
colTablePtr++; // There is one additional byte to skip before the table in psx version
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// if we want this frame to be affected by the shading mask,
|
|
|
|
// add the status bit
|
2003-11-01 16:55:20 +00:00
|
|
|
if (build_unit->shadingFlag)
|
2003-09-26 10:07:18 +00:00
|
|
|
spriteType |= RDSPR_SHADOW;
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
SpriteInfo spriteInfo;
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.x = build_unit->x;
|
|
|
|
spriteInfo.y = build_unit->y;
|
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
|
|
|
spriteInfo.w = frame_head.width;
|
|
|
|
spriteInfo.h = frame_head.height;
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.scale = build_unit->scale;
|
|
|
|
spriteInfo.scaledWidth = build_unit->scaled_width;
|
2003-07-28 01:44:38 +00:00
|
|
|
spriteInfo.scaledHeight = build_unit->scaled_height;
|
2003-09-02 09:54:42 +00:00
|
|
|
spriteInfo.type = spriteType;
|
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
|
|
|
spriteInfo.blend = anim_head.blend;
|
2003-09-02 09:54:42 +00:00
|
|
|
// points to just after frame header, ie. start of sprite data
|
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
|
|
|
spriteInfo.data = frame + FrameHeader::size();
|
|
|
|
spriteInfo.colourTable = colTablePtr;
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.isText = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// check for largest layer for debug info
|
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
|
|
|
uint32 current_sprite_area = frame_head.width * frame_head.height;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-11-01 16:55:20 +00:00
|
|
|
if (current_sprite_area > _largestSpriteArea) {
|
|
|
|
_largestSpriteArea = current_sprite_area;
|
|
|
|
sprintf(_largestSpriteInfo,
|
2003-09-02 09:54:42 +00:00
|
|
|
"largest sprite: %s frame(%d) is %dx%d",
|
2006-07-08 20:45:01 +00:00
|
|
|
_vm->_resman->fetchName(build_unit->anim_resource),
|
2003-09-02 09:54:42 +00:00
|
|
|
build_unit->anim_pc,
|
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
|
|
|
frame_head.width,
|
|
|
|
frame_head.height);
|
2003-07-28 01:44:38 +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
|
|
|
if (_vm->_logic->readVar(SYSTEM_TESTING_ANIMS)) { // see anims.cpp
|
2003-09-02 09:54:42 +00:00
|
|
|
// bring the anim into the visible screen
|
|
|
|
// but leave extra pixel at edge for box
|
|
|
|
if (spriteInfo.x + spriteInfo.scaledWidth >= 639)
|
|
|
|
spriteInfo.x = 639 - spriteInfo.scaledWidth;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
if (spriteInfo.y + spriteInfo.scaledHeight >= 399)
|
|
|
|
spriteInfo.y = 399 - spriteInfo.scaledHeight;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (spriteInfo.x < 1)
|
|
|
|
spriteInfo.x = 1;
|
|
|
|
|
|
|
|
if (spriteInfo.y < 1)
|
|
|
|
spriteInfo.y = 1;
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// create box to surround sprite - just outside sprite box
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_debugger->_rectX1 = spriteInfo.x - 1;
|
|
|
|
_vm->_debugger->_rectY1 = spriteInfo.y - 1;
|
|
|
|
_vm->_debugger->_rectX2 = spriteInfo.x + spriteInfo.scaledWidth;
|
|
|
|
_vm->_debugger->_rectY2 = spriteInfo.y + spriteInfo.scaledHeight;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
uint32 rv = drawSprite(&spriteInfo);
|
2004-04-24 12:29:35 +00:00
|
|
|
if (rv) {
|
2009-04-18 08:37:22 +00:00
|
|
|
error("Driver Error %.8x with sprite %s (%d, %d) in processImage",
|
2005-02-19 14:02:16 +00:00
|
|
|
rv,
|
2006-07-08 20:45:01 +00:00
|
|
|
_vm->_resman->fetchName(build_unit->anim_resource),
|
2009-04-18 08:37:22 +00:00
|
|
|
build_unit->anim_resource, build_unit->anim_pc);
|
2004-04-24 12:29:35 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// release the anim resource
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_resman->closeResource(build_unit->anim_resource);
|
2003-09-02 09:54:42 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
void Screen::resetRenderLists() {
|
2003-09-02 09:54:42 +00:00
|
|
|
// reset the sort lists - do this before a logic loop
|
|
|
|
// takes into account the fact that the start of the list is pre-built
|
|
|
|
// with the special sortable layers
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-11-01 16:55:20 +00:00
|
|
|
_curBgp0 = 0;
|
|
|
|
_curBgp1 = 0;
|
|
|
|
_curBack = 0;
|
2003-09-02 09:54:42 +00:00
|
|
|
// beginning of sort list is setup with the special sort layers
|
2003-11-02 17:17:10 +00:00
|
|
|
_curSort = _thisScreen.number_of_layers;
|
2003-11-01 16:55:20 +00:00
|
|
|
_curFore = 0;
|
|
|
|
_curFgp0 = 0;
|
|
|
|
_curFgp1 = 0;
|
2003-09-02 09:54:42 +00:00
|
|
|
|
2003-11-01 16:55:20 +00:00
|
|
|
if (_curSort) {
|
2004-03-28 13:16:01 +00:00
|
|
|
// there are some layers - so rebuild the sort order list
|
2003-11-01 16:55:20 +00:00
|
|
|
for (uint i = 0; i < _curSort; i++)
|
2004-03-28 13:16:01 +00:00
|
|
|
_sortOrder[i] = i;
|
2003-09-02 09:54:42 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +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
|
|
|
void Screen::registerFrame(byte *ob_mouse, byte *ob_graph, byte *ob_mega, BuildUnit *build_unit) {
|
|
|
|
ObjectGraphic obGraph(ob_graph);
|
|
|
|
ObjectMega obMega(ob_mega);
|
2003-07-28 01:44:38 +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
|
|
|
assert(obGraph.getAnimResource());
|
2003-07-28 01:44:38 +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
|
|
|
byte *file = _vm->_resman->openResource(obGraph.getAnimResource());
|
|
|
|
|
|
|
|
AnimHeader anim_head;
|
|
|
|
CdtEntry cdt_entry;
|
|
|
|
FrameHeader frame_head;
|
|
|
|
|
|
|
|
anim_head.read(_vm->fetchAnimHeader(file));
|
|
|
|
cdt_entry.read(_vm->fetchCdtEntry(file, obGraph.getAnimPc()));
|
|
|
|
frame_head.read(_vm->fetchFrameHeader(file, obGraph.getAnimPc()));
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// update player graphic details for on-screen debug info
|
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(ID) == CUR_PLAYER_ID) {
|
|
|
|
_vm->_debugger->_graphType = obGraph.getType();
|
|
|
|
_vm->_debugger->_graphAnimRes = obGraph.getAnimResource();
|
2003-09-02 09:54:42 +00:00
|
|
|
// counting 1st frame as 'frame 1'
|
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
|
|
|
_vm->_debugger->_graphAnimPc = obGraph.getAnimPc() + 1;
|
|
|
|
_vm->_debugger->_graphNoFrames = anim_head.noAnimFrames;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-28 15:08:12 +00:00
|
|
|
// fill in the BuildUnit structure for this frame
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2008-01-28 00:14:17 +00:00
|
|
|
build_unit->anim_resource = obGraph.getAnimResource();
|
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
|
|
|
build_unit->anim_pc = obGraph.getAnimPc();
|
2003-09-02 09:54:42 +00:00
|
|
|
build_unit->layer_number = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// Affected by shading mask?
|
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 (obGraph.getType() & SHADED_SPRITE)
|
2003-11-01 16:55:20 +00:00
|
|
|
build_unit->shadingFlag = true;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-11-01 16:55:20 +00:00
|
|
|
build_unit->shadingFlag = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// Check if this frame has offsets ie. this is a scalable mega frame
|
|
|
|
|
|
|
|
int scale = 0;
|
2003-07-28 01:44:38 +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
|
|
|
if (cdt_entry.frameType & FRAME_OFFSET) {
|
|
|
|
scale = obMega.calcScale();
|
2003-09-02 09:54:42 +00:00
|
|
|
|
|
|
|
// calc final render coordinates (top-left of sprite), based
|
|
|
|
// on feet coords & scaled offsets
|
|
|
|
|
|
|
|
// add scaled offsets to feet coords
|
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
|
|
|
build_unit->x = obMega.getFeetX() + (cdt_entry.x * scale) / 256;
|
|
|
|
build_unit->y = obMega.getFeetY() + (cdt_entry.y * scale) / 256;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// Work out new width and height. Always divide by 256 after
|
|
|
|
// everything else, to maintain accurary
|
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
|
|
|
build_unit->scaled_width = ((scale * frame_head.width) / 256);
|
|
|
|
build_unit->scaled_height = ((scale * frame_head.height) / 256);
|
2003-09-02 09:54:42 +00:00
|
|
|
} else {
|
2004-03-28 13:16:01 +00:00
|
|
|
// It's a non-scaling anim. Get render coords for sprite, from cdt
|
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
|
|
|
build_unit->x = cdt_entry.x;
|
|
|
|
build_unit->y = cdt_entry.y;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-03-28 13:16:01 +00:00
|
|
|
// Get width and height
|
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
|
|
|
build_unit->scaled_width = frame_head.width;
|
|
|
|
build_unit->scaled_height = frame_head.height;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// either 0 or required scale, depending on whether 'scale' computed
|
|
|
|
build_unit->scale = scale;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// calc the bottom y-coord for sorting purposes
|
2003-09-02 09:54:42 +00:00
|
|
|
build_unit->sort_y = build_unit->y + build_unit->scaled_height - 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-02-19 14:02:16 +00:00
|
|
|
if (ob_mouse) {
|
2003-11-02 18:50:09 +00:00
|
|
|
// passed a mouse structure, so add to the _mouseList
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_mouse->registerMouse(ob_mouse, build_unit);
|
2003-07-28 01:44:38 +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
|
|
|
_vm->_resman->closeResource(obGraph.getAnimResource());
|
2003-07-28 01:44:38 +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
|
|
|
void Screen::registerFrame(byte *ob_mouse, byte *ob_graph, byte *ob_mega) {
|
|
|
|
ObjectGraphic obGraph(ob_graph);
|
|
|
|
|
2003-09-02 09:54:42 +00:00
|
|
|
// check low word for sprite type
|
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
|
|
|
switch (obGraph.getType() & 0x0000ffff) {
|
2003-09-21 16:11:26 +00:00
|
|
|
case BGP0_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curBgp0 < MAX_bgp0_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_bgp0List[_curBgp0]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curBgp0++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case BGP1_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curBgp1 < MAX_bgp1_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_bgp1List[_curBgp1]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curBgp1++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case BACK_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curBack < MAX_back_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_backList[_curBack]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curBack++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case SORT_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curSort < MAX_sort_sprites);
|
|
|
|
_sortOrder[_curSort] = _curSort;
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_sortList[_curSort]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curSort++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case FORE_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curFore < MAX_fore_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_foreList[_curFore]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curFore++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case FGP0_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curFgp0 < MAX_fgp0_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_fgp0List[_curFgp0]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curFgp0++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case FGP1_SPRITE:
|
2003-11-01 16:55:20 +00:00
|
|
|
assert(_curFgp1 < MAX_fgp1_sprites);
|
2005-02-19 14:02:16 +00:00
|
|
|
registerFrame(ob_mouse, ob_graph, ob_mega, &_fgp1List[_curFgp1]);
|
2003-11-01 16:55:20 +00:00
|
|
|
_curFgp1++;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// NO_SPRITE no registering!
|
|
|
|
break;
|
2003-09-02 09:54:42 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// FIXME:
|
|
|
|
//
|
|
|
|
// The original credits used a different font. I think it's stored in the
|
|
|
|
// font.clu file, but I don't know how to interpret it.
|
|
|
|
//
|
|
|
|
// The original used the entire screen. This version cuts off the top and
|
|
|
|
// bottom of the screen, because that's where the menus would usually be.
|
|
|
|
//
|
|
|
|
// The original had some sort of smoke effect at the bottom of the screen.
|
|
|
|
|
|
|
|
enum {
|
|
|
|
LINE_LEFT,
|
|
|
|
LINE_CENTER,
|
|
|
|
LINE_RIGHT
|
|
|
|
};
|
|
|
|
|
|
|
|
struct CreditsLine {
|
|
|
|
char *str;
|
|
|
|
byte type;
|
|
|
|
int top;
|
|
|
|
int height;
|
|
|
|
byte *sprite;
|
2005-11-02 17:04:44 +00:00
|
|
|
|
|
|
|
CreditsLine() {
|
|
|
|
str = NULL;
|
|
|
|
sprite = NULL;
|
2007-04-25 19:31:23 +00:00
|
|
|
}
|
2005-11-03 09:47:19 +00:00
|
|
|
|
|
|
|
~CreditsLine() {
|
|
|
|
free(str);
|
|
|
|
free(sprite);
|
|
|
|
str = NULL;
|
|
|
|
sprite = NULL;
|
|
|
|
}
|
2005-05-02 05:41:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
#define CREDITS_FONT_HEIGHT 25
|
|
|
|
#define CREDITS_LINE_SPACING 20
|
|
|
|
|
|
|
|
void Screen::rollCredits() {
|
|
|
|
uint32 loopingMusicId = _vm->_sound->getLoopingMusicId();
|
|
|
|
|
|
|
|
// Prepare for the credits by fading down, stoping the music, etc.
|
|
|
|
|
|
|
|
_vm->_mouse->setMouse(0);
|
|
|
|
|
|
|
|
_vm->_sound->muteFx(true);
|
|
|
|
_vm->_sound->muteSpeech(true);
|
|
|
|
|
|
|
|
waitForFade();
|
|
|
|
fadeDown();
|
|
|
|
waitForFade();
|
|
|
|
|
|
|
|
_vm->_mouse->closeMenuImmediately();
|
|
|
|
|
|
|
|
// There are three files which I believe are involved in showing the
|
|
|
|
// credits:
|
|
|
|
//
|
|
|
|
// credits.bmp - The "Smacker" logo, stored as follows:
|
|
|
|
//
|
|
|
|
// width 2 bytes, little endian
|
|
|
|
// height 2 bytes, little endian
|
|
|
|
// palette 3 * 256 bytes
|
|
|
|
// data width * height bytes
|
|
|
|
//
|
|
|
|
// Note that the maximum colour component in the palette is 0x3F.
|
|
|
|
// This is the same resolution as the _paletteMatch table. I doubt
|
|
|
|
// that this is a coincidence, but let's use the image palette
|
|
|
|
// directly anyway, just to be safe.
|
|
|
|
//
|
2009-04-07 19:52:46 +00:00
|
|
|
// credits.clu - The credits text (credits.txt in PSX version)
|
2005-05-02 05:41:01 +00:00
|
|
|
//
|
|
|
|
// This is simply a text file with CRLF line endings.
|
|
|
|
// '^' is not shown, but used to mark the center of the line.
|
|
|
|
// '@' is used as a placeholder for the "Smacker" logo. At least
|
|
|
|
// when it appears alone.
|
|
|
|
// Remaining lines are centered.
|
2005-11-05 15:21:28 +00:00
|
|
|
// The German version also contains character code 9 for no
|
|
|
|
// apparent reason. We ignore them.
|
2005-05-02 05:41:01 +00:00
|
|
|
//
|
|
|
|
// fonts.clu - The credits font?
|
|
|
|
//
|
|
|
|
// FIXME: At this time I don't know how to interpret fonts.clu. For
|
|
|
|
// now, let's just the standard speech font instead.
|
|
|
|
|
|
|
|
SpriteInfo spriteInfo;
|
2005-05-10 22:56:25 +00:00
|
|
|
Common::File f;
|
2005-05-02 05:41:01 +00:00
|
|
|
int i;
|
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.isText = false;
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// Read the "Smacker" logo
|
|
|
|
|
|
|
|
uint16 logoWidth = 0;
|
|
|
|
uint16 logoHeight = 0;
|
|
|
|
byte *logoData = NULL;
|
|
|
|
byte palette[256 * 4];
|
|
|
|
|
|
|
|
if (f.open("credits.bmp")) {
|
|
|
|
logoWidth = f.readUint16LE();
|
|
|
|
logoHeight = f.readUint16LE();
|
|
|
|
|
|
|
|
for (i = 0; i < 256; i++) {
|
|
|
|
palette[i * 4 + 0] = f.readByte() << 2;
|
|
|
|
palette[i * 4 + 1] = f.readByte() << 2;
|
|
|
|
palette[i * 4 + 2] = f.readByte() << 2;
|
|
|
|
palette[i * 4 + 3] = 0;
|
|
|
|
}
|
|
|
|
|
2005-05-12 13:12:15 +00:00
|
|
|
logoData = (byte *)malloc(logoWidth * logoHeight);
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
f.read(logoData, logoWidth * logoHeight);
|
|
|
|
f.close();
|
|
|
|
} else {
|
|
|
|
warning("Can't find credits.bmp");
|
|
|
|
memset(palette, 0, sizeof(palette));
|
|
|
|
palette[14 * 4 + 0] = 252;
|
|
|
|
palette[14 * 4 + 1] = 252;
|
|
|
|
palette[14 * 4 + 2] = 252;
|
|
|
|
palette[14 * 4 + 3] = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
setPalette(0, 256, palette, RDPAL_INSTANT);
|
|
|
|
|
|
|
|
// Read the credits text
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
Common::Array<CreditsLine *> creditsLines;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
int lineCount = 0;
|
|
|
|
int lineTop = 400;
|
|
|
|
int paragraphStart = 0;
|
|
|
|
bool hasCenterMark = false;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
if (Sword2Engine::isPsx()) {
|
|
|
|
if (!f.open("credits.txt")) {
|
|
|
|
warning("Can't find credits.txt");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (!f.open("credits.clu")) {
|
|
|
|
warning("Can't find credits.clu");
|
|
|
|
return;
|
|
|
|
}
|
2005-05-02 05:41:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
char buffer[80];
|
2009-12-30 23:00:55 +00:00
|
|
|
char *line = f.readLine(buffer, sizeof(buffer));
|
2008-12-03 21:30:41 +00:00
|
|
|
|
|
|
|
if (line) {
|
|
|
|
// Replace invalid character codes prevent the 'dud'
|
|
|
|
// symbol from showing up in the credits.
|
|
|
|
|
|
|
|
for (byte *ptr = (byte *)line; *ptr; ptr++) {
|
|
|
|
switch (*ptr) {
|
|
|
|
case 9:
|
|
|
|
// The German credits contain these.
|
|
|
|
// Convert them to spaces.
|
|
|
|
*ptr = 32;
|
|
|
|
break;
|
|
|
|
case 10:
|
|
|
|
// LF is treated as end of line.
|
|
|
|
*ptr = 0;
|
|
|
|
break;
|
|
|
|
case 170:
|
|
|
|
// The Spanish credits contain these.
|
|
|
|
// Convert them to periods.
|
|
|
|
*ptr = '.';
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
if (!line || *line == 0) {
|
|
|
|
if (!hasCenterMark) {
|
|
|
|
for (i = paragraphStart; i < lineCount; i++)
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[i]->type = LINE_CENTER;
|
2005-05-02 05:41:01 +00:00
|
|
|
}
|
|
|
|
paragraphStart = lineCount;
|
|
|
|
hasCenterMark = false;
|
|
|
|
if (paragraphStart == lineCount)
|
|
|
|
lineTop += CREDITS_LINE_SPACING;
|
|
|
|
|
|
|
|
if (!line)
|
|
|
|
break;
|
|
|
|
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
char *center_mark = strchr(line, '^');
|
|
|
|
|
|
|
|
if (center_mark) {
|
|
|
|
// The current paragraph has at least one center mark.
|
|
|
|
hasCenterMark = true;
|
|
|
|
|
|
|
|
if (center_mark != line) {
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines.push_back(new CreditsLine);
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// The center mark is somewhere inside the
|
|
|
|
// line. Split it into left and right side.
|
|
|
|
*center_mark = 0;
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->top = lineTop;
|
|
|
|
creditsLines[lineCount]->height = CREDITS_FONT_HEIGHT;
|
|
|
|
creditsLines[lineCount]->type = LINE_LEFT;
|
|
|
|
creditsLines[lineCount]->str = strdup(line);
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
lineCount++;
|
|
|
|
*center_mark = '^';
|
|
|
|
}
|
|
|
|
|
|
|
|
line = center_mark;
|
|
|
|
}
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines.push_back(new CreditsLine);
|
|
|
|
|
|
|
|
creditsLines[lineCount]->top = lineTop;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
if (*line == '^') {
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->type = LINE_RIGHT;
|
2005-05-02 05:41:01 +00:00
|
|
|
line++;
|
|
|
|
} else
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->type = LINE_LEFT;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
if (strcmp(line, "@") == 0) {
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->height = logoHeight;
|
2005-05-02 05:41:01 +00:00
|
|
|
lineTop += logoHeight;
|
|
|
|
} else {
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->height = CREDITS_FONT_HEIGHT;
|
2005-05-02 05:41:01 +00:00
|
|
|
lineTop += CREDITS_LINE_SPACING;
|
|
|
|
}
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[lineCount]->str = strdup(line);
|
2005-05-02 05:41:01 +00:00
|
|
|
lineCount++;
|
|
|
|
}
|
|
|
|
|
|
|
|
f.close();
|
|
|
|
|
|
|
|
// We could easily add some ScummVM stuff to the credits, if we wanted
|
|
|
|
// to. On the other hand, anyone with the attention span to actually
|
|
|
|
// read all the credits probably already knows. :-)
|
|
|
|
|
|
|
|
// Start the music and roll the credits
|
|
|
|
|
|
|
|
// The credits music (which can also be heard briefly in the "carib"
|
|
|
|
// cutscene) is played once.
|
|
|
|
|
|
|
|
_vm->_sound->streamCompMusic(309, false);
|
|
|
|
|
|
|
|
clearScene();
|
|
|
|
fadeUp(0);
|
|
|
|
|
|
|
|
spriteInfo.scale = 0;
|
|
|
|
spriteInfo.scaledWidth = 0;
|
|
|
|
spriteInfo.scaledHeight = 0;
|
|
|
|
spriteInfo.type = RDSPR_DISPLAYALIGN | RDSPR_NOCOMPRESSION | RDSPR_TRANS;
|
|
|
|
spriteInfo.blend = 0;
|
|
|
|
|
|
|
|
int startLine = 0;
|
|
|
|
int scrollPos = 0;
|
|
|
|
|
|
|
|
bool abortCredits = false;
|
|
|
|
|
|
|
|
int scrollSteps = lineTop + CREDITS_FONT_HEIGHT;
|
2008-11-09 14:32:24 +00:00
|
|
|
uint32 musicStart = getTick();
|
2008-11-09 13:50:41 +00:00
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// Ideally the music should last just a tiny bit longer than the
|
|
|
|
// credits. Note that musicTimeRemaining() will return 0 if the music
|
|
|
|
// is muted, so we need a sensible fallback for that case.
|
|
|
|
|
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
|
|
|
uint32 musicLength = MAX((int32)(1000 * (_vm->_sound->musicTimeRemaining() - 3)), 25 * (int32)scrollSteps);
|
2005-05-02 05:41:01 +00:00
|
|
|
|
2008-09-30 12:27:38 +00:00
|
|
|
while (scrollPos < scrollSteps && !_vm->shouldQuit()) {
|
2005-05-02 05:41:01 +00:00
|
|
|
clearScene();
|
|
|
|
|
|
|
|
for (i = startLine; i < lineCount; i++) {
|
2005-11-03 09:47:19 +00:00
|
|
|
if (!creditsLines[i])
|
|
|
|
continue;
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// Free any sprites that have scrolled off the screen
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
if (creditsLines[i]->top + creditsLines[i]->height < scrollPos) {
|
2005-11-03 09:47:19 +00:00
|
|
|
debug(2, "Freeing line %d: '%s'", i, creditsLines[i]->str);
|
2005-11-02 17:04:44 +00:00
|
|
|
|
2005-11-03 09:47:19 +00:00
|
|
|
delete creditsLines[i];
|
|
|
|
creditsLines[i] = NULL;
|
2005-11-02 17:04:44 +00:00
|
|
|
|
2005-11-03 09:47:19 +00:00
|
|
|
startLine = i + 1;
|
2005-11-02 17:04:44 +00:00
|
|
|
} else if (creditsLines[i]->top < scrollPos + 400) {
|
|
|
|
if (!creditsLines[i]->sprite) {
|
2005-11-03 09:47:19 +00:00
|
|
|
debug(2, "Creating line %d: '%s'", i, creditsLines[i]->str);
|
2005-11-02 17:04:44 +00:00
|
|
|
creditsLines[i]->sprite = _vm->_fontRenderer->makeTextSprite((byte *)creditsLines[i]->str, 600, 14, _vm->_speechFontId, 0);
|
2005-05-02 05:41:01 +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
|
|
|
FrameHeader frame;
|
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
frame.read(creditsLines[i]->sprite);
|
2005-05-02 05:41:01 +00:00
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
spriteInfo.y = creditsLines[i]->top - scrollPos;
|
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
|
|
|
spriteInfo.w = frame.width;
|
|
|
|
spriteInfo.h = frame.height;
|
2005-11-02 17:04:44 +00:00
|
|
|
spriteInfo.data = creditsLines[i]->sprite + FrameHeader::size();
|
2009-04-07 19:52:46 +00:00
|
|
|
spriteInfo.isText = true;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
2005-11-02 17:04:44 +00:00
|
|
|
switch (creditsLines[i]->type) {
|
2005-05-02 05:41:01 +00:00
|
|
|
case LINE_LEFT:
|
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
|
|
|
spriteInfo.x = RENDERWIDE / 2 - 5 - frame.width;
|
2005-05-02 05:41:01 +00:00
|
|
|
break;
|
|
|
|
case LINE_RIGHT:
|
|
|
|
spriteInfo.x = RENDERWIDE / 2 + 5;
|
|
|
|
break;
|
|
|
|
case LINE_CENTER:
|
2005-11-02 17:04:44 +00:00
|
|
|
if (strcmp(creditsLines[i]->str, "@") == 0) {
|
2005-05-02 05:41:01 +00:00
|
|
|
spriteInfo.data = logoData;
|
|
|
|
spriteInfo.x = (RENDERWIDE - logoWidth) / 2;
|
|
|
|
spriteInfo.w = logoWidth;
|
|
|
|
spriteInfo.h = logoHeight;
|
|
|
|
} 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
|
|
|
spriteInfo.x = (RENDERWIDE - frame.width) / 2;
|
2005-05-02 05:41:01 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (spriteInfo.data)
|
|
|
|
drawSprite(&spriteInfo);
|
|
|
|
} else
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
updateDisplay();
|
|
|
|
|
|
|
|
KeyboardEvent *ke = _vm->keyboardEvent();
|
|
|
|
|
2007-06-22 23:03:12 +00:00
|
|
|
if (ke && ke->kbd.keycode == Common::KEYCODE_ESCAPE) {
|
2005-05-02 05:41:01 +00:00
|
|
|
if (!abortCredits) {
|
|
|
|
abortCredits = true;
|
|
|
|
fadeDown();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (abortCredits && getFadeStatus() == RDFADE_BLACK)
|
|
|
|
break;
|
|
|
|
|
2008-11-09 13:50:41 +00:00
|
|
|
_vm->sleepUntil(musicStart + (musicLength * scrollPos) / scrollSteps + _pauseTicks);
|
2005-05-02 05:41:01 +00:00
|
|
|
scrollPos++;
|
|
|
|
}
|
|
|
|
|
|
|
|
// We're done. Clean up and try to put everything back where it was
|
|
|
|
// before the credits.
|
|
|
|
|
|
|
|
for (i = 0; i < lineCount; i++) {
|
2005-11-02 17:04:44 +00:00
|
|
|
delete creditsLines[i];
|
2005-05-02 05:41:01 +00:00
|
|
|
}
|
|
|
|
|
2005-11-03 09:47:19 +00:00
|
|
|
free(logoData);
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
if (!abortCredits) {
|
2005-10-30 16:21:54 +00:00
|
|
|
fadeDown();
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
// The music should either have stopped or be about to stop, so
|
|
|
|
// wait for it to really happen.
|
|
|
|
|
2008-09-30 12:27:38 +00:00
|
|
|
while (_vm->_sound->musicTimeRemaining() && !_vm->shouldQuit()) {
|
2005-05-02 05:41:01 +00:00
|
|
|
updateDisplay(false);
|
|
|
|
_vm->_system->delayMillis(100);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-09-30 12:27:38 +00:00
|
|
|
if (_vm->shouldQuit())
|
2005-05-02 05:41:01 +00:00
|
|
|
return;
|
|
|
|
|
2005-10-30 16:21:54 +00:00
|
|
|
waitForFade();
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
_vm->_sound->muteFx(false);
|
|
|
|
_vm->_sound->muteSpeech(false);
|
|
|
|
|
|
|
|
if (loopingMusicId)
|
|
|
|
_vm->_sound->streamCompMusic(loopingMusicId, true);
|
|
|
|
else
|
|
|
|
_vm->_sound->stopMusic(false);
|
|
|
|
|
|
|
|
if (!_vm->_mouse->getMouseStatus() || _vm->_mouse->isChoosing())
|
|
|
|
_vm->_mouse->setMouse(NORMAL_MOUSE_ID);
|
|
|
|
|
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(DEAD))
|
2005-05-02 05:41:01 +00:00
|
|
|
_vm->_mouse->buildSystemMenu();
|
|
|
|
}
|
|
|
|
|
|
|
|
// This image used to be shown by CacheNewCluster() while copying a data file
|
|
|
|
// from the CD to the hard disk. ScummVM doesn't do that, so the image is never
|
|
|
|
// shown. It'd be nice if we could do something useful with it some day...
|
|
|
|
|
|
|
|
void Screen::splashScreen() {
|
|
|
|
byte *bgfile = _vm->_resman->openResource(2950);
|
|
|
|
|
|
|
|
initialiseBackgroundLayer(NULL);
|
|
|
|
initialiseBackgroundLayer(NULL);
|
|
|
|
initialiseBackgroundLayer(_vm->fetchBackgroundLayer(bgfile));
|
|
|
|
initialiseBackgroundLayer(NULL);
|
|
|
|
initialiseBackgroundLayer(NULL);
|
|
|
|
|
|
|
|
setPalette(0, 256, _vm->fetchPalette(bgfile), RDPAL_FADE);
|
|
|
|
renderParallax(_vm->fetchBackgroundLayer(bgfile), 2);
|
|
|
|
|
|
|
|
closeBackgroundLayer();
|
|
|
|
|
|
|
|
byte *loadingBar = _vm->_resman->openResource(2951);
|
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
|
|
|
byte *frame = _vm->fetchFrameHeader(loadingBar, 0);
|
|
|
|
|
|
|
|
AnimHeader animHead;
|
|
|
|
CdtEntry cdt;
|
|
|
|
FrameHeader frame_head;
|
|
|
|
|
|
|
|
animHead.read(_vm->fetchAnimHeader(loadingBar));
|
|
|
|
cdt.read(_vm->fetchCdtEntry(loadingBar, 0));
|
|
|
|
frame_head.read(_vm->fetchFrameHeader(loadingBar, 0));
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
SpriteInfo barSprite;
|
|
|
|
|
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
|
|
|
barSprite.x = cdt.x;
|
|
|
|
barSprite.y = cdt.y;
|
|
|
|
barSprite.w = frame_head.width;
|
|
|
|
barSprite.h = frame_head.height;
|
2005-05-02 05:41:01 +00:00
|
|
|
barSprite.scale = 0;
|
|
|
|
barSprite.scaledWidth = 0;
|
|
|
|
barSprite.scaledHeight = 0;
|
|
|
|
barSprite.type = RDSPR_RLE256FAST | RDSPR_TRANS;
|
|
|
|
barSprite.blend = 0;
|
|
|
|
barSprite.colourTable = 0;
|
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
|
|
|
barSprite.data = frame + FrameHeader::size();
|
2009-04-07 19:52:46 +00:00
|
|
|
barSprite.isText = false;
|
2005-05-02 05:41:01 +00:00
|
|
|
|
|
|
|
drawSprite(&barSprite);
|
|
|
|
|
|
|
|
fadeUp();
|
|
|
|
waitForFade();
|
|
|
|
|
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
|
|
|
for (int i = 0; i < animHead.noAnimFrames; i++) {
|
2005-05-02 05:41:01 +00:00
|
|
|
frame = _vm->fetchFrameHeader(loadingBar, i);
|
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
|
|
|
barSprite.data = frame + FrameHeader::size();
|
2005-05-02 05:41:01 +00:00
|
|
|
drawSprite(&barSprite);
|
|
|
|
updateDisplay();
|
|
|
|
_vm->_system->delayMillis(30);
|
|
|
|
}
|
|
|
|
|
|
|
|
_vm->_resman->closeResource(2951);
|
|
|
|
|
|
|
|
fadeDown();
|
|
|
|
waitForFade();
|
|
|
|
}
|
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
// Following functions are used to manage screen cache for psx version.
|
|
|
|
|
|
|
|
void Screen::setPsxScrCache(byte *psxScrCache, uint8 level) {
|
|
|
|
if (level < 3) {
|
|
|
|
if (psxScrCache)
|
|
|
|
_psxCacheEnabled[level] = true;
|
|
|
|
else
|
|
|
|
_psxCacheEnabled[level] = false;
|
|
|
|
|
|
|
|
_psxScrCache[level] = psxScrCache;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
byte *Screen::getPsxScrCache(uint8 level) {
|
|
|
|
if (level > 3) {
|
|
|
|
level = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (_psxCacheEnabled[level])
|
|
|
|
return _psxScrCache[level];
|
|
|
|
else
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool Screen::getPsxScrCacheStatus(uint8 level) {
|
|
|
|
if (level > 3) {
|
|
|
|
level = 0;
|
|
|
|
}
|
2009-05-24 15:17:42 +00:00
|
|
|
|
2009-04-07 19:52:46 +00:00
|
|
|
return _psxCacheEnabled[level];
|
|
|
|
}
|
|
|
|
|
|
|
|
void Screen::flushPsxScrCache() {
|
|
|
|
for (uint8 i = 0; i < 3; i++) {
|
|
|
|
free(_psxScrCache[i]);
|
|
|
|
_psxScrCache[i] = NULL;
|
|
|
|
_psxCacheEnabled[i] = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-10-04 00:52:27 +00:00
|
|
|
} // End of namespace Sword2
|