2005-01-17 10:57:15 +00:00
|
|
|
/* Copyright (C) 1994-1998 Revolution Software Ltd.
|
2006-02-09 15:12:44 +00:00
|
|
|
* Copyright (C) 2003-2006 The ScummVM project
|
|
|
|
*
|
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
|
|
|
*/
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
#include "common/stdafx.h"
|
|
|
|
#include "common/stream.h"
|
|
|
|
|
|
|
|
#include "sword2/sword2.h"
|
|
|
|
#include "sword2/defs.h"
|
|
|
|
#include "sword2/header.h"
|
|
|
|
#include "sword2/logic.h"
|
|
|
|
#include "sword2/resman.h"
|
|
|
|
#include "sword2/router.h"
|
|
|
|
#include "sword2/screen.h"
|
|
|
|
|
|
|
|
namespace Sword2 {
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// ---------------------------------------------------------------------------
|
2003-07-28 01:44:38 +00:00
|
|
|
// ROUTER.CPP by James
|
2003-09-20 15:34:53 +00:00
|
|
|
//
|
|
|
|
// A rehash of Jeremy's original jrouter.c, containing low-level system
|
|
|
|
// routines for calculating routes between points inside a walk-grid, and
|
|
|
|
// constructing walk animations from mega-sets.
|
|
|
|
//
|
|
|
|
// jrouter.c underwent 2 major reworks from the original:
|
|
|
|
// (1) Restructured to allow more flexibility in the mega-sets, ie. more info
|
|
|
|
// taken from the walk-data
|
|
|
|
// - the new George & Nico mega-sets & walk-data were then tested &
|
|
|
|
// tweaked in the Sword1 system
|
2003-07-28 01:44:38 +00:00
|
|
|
// (2) Updated for the new Sword2 system, ie. new object structures
|
2003-09-20 15:34:53 +00:00
|
|
|
// - now compatible with Sword2, the essential code already having been
|
|
|
|
// tested
|
|
|
|
//
|
|
|
|
// ---------------------------------------------------------------------------
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
/****************************************************************************
|
|
|
|
* JROUTER.C polygon router with modular walks
|
|
|
|
* using a tree of modules
|
2005-07-30 21:11:48 +00:00
|
|
|
* 21 july 94
|
|
|
|
* 3 november 94
|
2003-07-28 01:44:38 +00:00
|
|
|
* System currently works by scanning grid data and coming up with a ROUTE
|
|
|
|
* as a series of way points(nodes), the smoothest eight directional PATH
|
|
|
|
* through these nodes is then found, and a WALK created to fit the PATH.
|
|
|
|
*
|
|
|
|
* Two funtions are called by the user, RouteFinder creates a route as a
|
|
|
|
* module list, HardWalk creates an animation list from the module list.
|
|
|
|
* The split is only provided to allow the possibility of turning the
|
2005-07-30 21:11:48 +00:00
|
|
|
* autorouter over two game cycles.
|
2003-07-28 01:44:38 +00:00
|
|
|
****************************************************************************
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-07-28 01:44:38 +00:00
|
|
|
* Routine timings on osborne 486
|
|
|
|
*
|
|
|
|
* Read floor resource (file already loaded) 112 pixels
|
|
|
|
*
|
|
|
|
* Read mega resource (file already loaded) 112 pixels
|
|
|
|
*
|
|
|
|
*
|
|
|
|
*
|
|
|
|
****************************************************************************
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-07-28 01:44:38 +00:00
|
|
|
* Modified 12 Oct 95
|
|
|
|
*
|
|
|
|
* Target Points within 1 pixel of a line are ignored ???
|
|
|
|
*
|
|
|
|
* Modules split into Points within 1 pixel of a line are ignored ???
|
|
|
|
*
|
|
|
|
****************************************************************************
|
|
|
|
*
|
|
|
|
* TOTALLY REHASHED BY JAMES FOR NEW MEGAS USING OLD SYSTEM
|
|
|
|
* THEN REINCARNATED BY JAMES FOR NEW MEGAS USING NEW SYSTEM
|
|
|
|
*
|
|
|
|
****************************************************************************/
|
|
|
|
|
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
|
|
|
//----------------------------------------------------------
|
|
|
|
// (4) WALK-GRID FILES
|
|
|
|
//----------------------------------------------------------
|
|
|
|
// a walk-grid file consists of:
|
|
|
|
//
|
|
|
|
// standard file header
|
|
|
|
// walk-grid file header
|
|
|
|
// walk-grid data
|
|
|
|
|
|
|
|
// Walk-Grid Header - taken directly from old "header.h" in STD_INC
|
|
|
|
|
|
|
|
struct WalkGridHeader {
|
|
|
|
int32 numBars; // number of bars on the floor
|
|
|
|
int32 numNodes; // number of nodes
|
|
|
|
};
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
uint8 Router::returnSlotNo(uint32 megaId) {
|
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) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// George (8)
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
// One of Nico's mega id's
|
|
|
|
return 1;
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::allocateRouteMem() {
|
2003-07-28 01:44:38 +00:00
|
|
|
uint8 slotNo;
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// Player character always always slot 0, while the other mega
|
|
|
|
// (normally Nico) always uses slot 1
|
|
|
|
// Better this way, so that if mega object removed from memory while
|
|
|
|
// in middle of route, the old route will be safely cleared from
|
|
|
|
// memory just before they create a new one
|
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
|
|
|
slotNo = returnSlotNo(_vm->_logic->readVar(ID));
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// if this slot is already used, then it can't be needed any more
|
|
|
|
// because this id is creating a new route!
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_routeSlots[slotNo])
|
|
|
|
freeRouteMem();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-05-12 13:12:15 +00:00
|
|
|
_routeSlots[slotNo] = (WalkData *)malloc(sizeof(WalkData) * O_WALKANIM_SIZE);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// 12000 bytes were used for this in Sword1 mega compacts, based on
|
2003-12-17 08:01:59 +00:00
|
|
|
// 20 bytes per 'WalkData' frame
|
2003-07-28 01:44:38 +00:00
|
|
|
// ie. allowing for 600 frames including end-marker
|
2003-12-17 08:01:59 +00:00
|
|
|
// Now 'WalkData' is 8 bytes, so 8*600 = 4800 bytes.
|
2003-09-20 15:34:53 +00:00
|
|
|
// Note that a 600 frame walk lasts about 48 seconds!
|
|
|
|
// (600fps / 12.5s = 48s)
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// mega keeps note of which slot contains the pointer to it's walk
|
|
|
|
// animation mem block
|
|
|
|
// +1 so that '0' can mean "not walking"
|
|
|
|
// megaObject->route_slot_id = slotNo + 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
WalkData *Router::getRouteMem() {
|
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
|
|
|
uint8 slotNo = returnSlotNo(_vm->_logic->readVar(ID));
|
2005-07-30 21:11:48 +00:00
|
|
|
|
2005-05-12 13:12:15 +00:00
|
|
|
return (WalkData *)_routeSlots[slotNo];
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::freeRouteMem() {
|
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
|
|
|
uint8 slotNo = returnSlotNo(_vm->_logic->readVar(ID));
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-04-23 07:02:11 +00:00
|
|
|
free(_routeSlots[slotNo]);
|
2003-10-12 14:40:04 +00:00
|
|
|
_routeSlots[slotNo] = NULL;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::freeAllRouteMem() {
|
2003-10-12 14:40:04 +00:00
|
|
|
for (int i = 0; i < TOTAL_ROUTE_SLOTS; i++) {
|
2004-04-23 07:02:11 +00:00
|
|
|
free(_routeSlots[i]);
|
|
|
|
_routeSlots[i] = 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
|
|
|
int32 Router::routeFinder(byte *ob_mega, byte *ob_walkdata, int32 x, int32 y, int32 dir) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* RouteFinder.C polygon router with modular walks
|
2005-07-30 21:11:48 +00:00
|
|
|
* 21 august 94
|
|
|
|
* 3 november 94
|
2003-10-12 14:40:04 +00:00
|
|
|
* routeFinder creates a list of modules that enables HardWalk to
|
2003-09-20 15:34:53 +00:00
|
|
|
* create an animation list.
|
|
|
|
*
|
2003-10-12 14:40:04 +00:00
|
|
|
* routeFinder currently works by scanning grid data and coming up
|
2003-09-20 15:34:53 +00:00
|
|
|
* with a ROUTE as a series of way points(nodes), the smoothest eight
|
|
|
|
* directional PATH through these nodes is then found, this
|
|
|
|
* information is made available to HardWalk for a WALK to be created
|
|
|
|
* to fit the PATH.
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
* 30 november 94 return values modified
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
* return 0 = failed to find a route
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
* 1 = found a route
|
|
|
|
*
|
|
|
|
* 2 = mega already at target
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
int32 routeFlag = 0;
|
|
|
|
int32 solidFlag = 0;
|
2003-12-17 08:01:59 +00:00
|
|
|
WalkData *walkAnim;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// megaId = id;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
setUpWalkGrid(ob_mega, x, y, dir);
|
|
|
|
loadWalkData(ob_walkdata);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-04-23 07:02:11 +00:00
|
|
|
walkAnim = getRouteMem();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// All route data now loaded start finding a route
|
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
// Check if we can get a route through the floor. changed 12 Oct95 JPS
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
routeFlag = getRoute();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
switch (routeFlag) {
|
|
|
|
case 2:
|
2003-09-20 15:34:53 +00:00
|
|
|
// special case for zero length route
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// if target direction specified as any
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_targetDir > 7)
|
|
|
|
_targetDir = _startDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// just a turn on the spot is required set an end module for
|
|
|
|
// the route let the animator deal with it
|
2003-10-12 14:40:04 +00:00
|
|
|
// modularPath is normally set by extractRoute
|
|
|
|
|
|
|
|
_modularPath[0].dir = _startDir;
|
2006-04-01 12:47:09 +00:00
|
|
|
_modularPath[0].num = 0;
|
|
|
|
_modularPath[0].x = _startX;
|
|
|
|
_modularPath[0].y = _startY;
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[1].dir = _targetDir;
|
2006-04-01 12:47:09 +00:00
|
|
|
_modularPath[1].num = 0;
|
|
|
|
_modularPath[1].x = _startX;
|
|
|
|
_modularPath[1].y = _startY;
|
|
|
|
_modularPath[2].dir = 9;
|
|
|
|
_modularPath[2].num = ROUTE_END_FLAG;
|
2003-10-12 14:40:04 +00:00
|
|
|
|
|
|
|
slidyWalkAnimator(walkAnim);
|
2006-04-01 12:47:09 +00:00
|
|
|
routeFlag = 2;
|
2003-12-17 08:01:59 +00:00
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
// A normal route. Convert the route to an exact path
|
2003-10-12 14:40:04 +00:00
|
|
|
smoothestPath();
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// The Route had waypoints and direction options
|
|
|
|
|
|
|
|
// The Path is an exact set of lines in 8 directions that
|
|
|
|
// reach the target.
|
|
|
|
|
|
|
|
// The path is in module format, but steps taken in each
|
|
|
|
// direction are not accurate
|
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
// if target dir = 8 then the walk isn't linked to an anim so
|
2003-09-20 15:34:53 +00:00
|
|
|
// we can create a route without sliding and miss the exact
|
|
|
|
// target
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
#ifndef FORCE_SLIDY
|
|
|
|
if (_targetDir == 8) {
|
|
|
|
// can end facing ANY direction (ie. exact end
|
|
|
|
// position not vital) - so use SOLID walk to
|
|
|
|
// avoid sliding to exact position
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
solidPath();
|
|
|
|
solidFlag = solidWalkAnimator(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
#endif
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (!solidFlag) {
|
|
|
|
// if we failed to create a SOLID route, do a SLIDY
|
|
|
|
// one instead
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
slidyPath();
|
|
|
|
slidyWalkAnimator(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
default:
|
2003-09-20 15:34:53 +00:00
|
|
|
// Route didn't reach target so assume point was off the floor
|
|
|
|
// routeFlag = 0;
|
2003-12-17 08:01:59 +00:00
|
|
|
break;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return routeFlag; // send back null route
|
|
|
|
}
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
int32 Router::getRoute() {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* GetRoute.C extract a path from walk grid
|
2003-10-01 10:00:35 +00:00
|
|
|
* 12 october 94
|
2003-09-20 15:34:53 +00:00
|
|
|
*
|
|
|
|
* GetRoute currently works by scanning grid data and coming up with
|
|
|
|
* a ROUTE as a series of way points(nodes).
|
|
|
|
*
|
2003-12-17 08:01:59 +00:00
|
|
|
* static routeData _route[O_ROUTE_SIZE];
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
* return 0 = failed to find a route
|
2005-07-30 21:11:48 +00:00
|
|
|
*
|
2003-09-20 15:34:53 +00:00
|
|
|
* 1 = found a route
|
|
|
|
*
|
|
|
|
* 2 = mega already at target
|
|
|
|
*
|
|
|
|
* 3 = failed to find a route because target was on a line
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
int32 routeGot = 0;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_startX == _targetX && _startY == _targetY)
|
2003-07-28 01:44:38 +00:00
|
|
|
routeGot = 2;
|
2003-09-20 15:34:53 +00:00
|
|
|
else {
|
|
|
|
// 'else' added by JEL (23jan96) otherwise 'routeGot' affected
|
|
|
|
// even when already set to '2' above - causing some 'turns'
|
|
|
|
// to walk downwards on the spot
|
|
|
|
|
|
|
|
// returns 3 if target on a line ( +- 1 pixel )
|
2003-10-12 14:40:04 +00:00
|
|
|
routeGot = checkTarget(_targetX, _targetY);
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (routeGot == 0) {
|
|
|
|
// still looking for a route check if target is within a pixel
|
2005-07-30 21:11:48 +00:00
|
|
|
// of a line
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// scan through the nodes linking each node to its nearest
|
|
|
|
// neighbour until no more nodes change
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
// This is the routine that finds a route using scan()
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 level = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
while (scan(level))
|
2003-09-20 15:34:53 +00:00
|
|
|
level++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// Check to see if the route reached the target
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
if (_node[_nNodes].dist < 9999) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// it did so extract the route as nodes and the
|
|
|
|
// directions to go between each node
|
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
routeGot = 1;
|
2003-10-12 14:40:04 +00:00
|
|
|
extractRoute();
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// route.X,route.Y and route.Dir now hold all the
|
|
|
|
// route infomation with the target dir or route
|
|
|
|
// continuation
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return routeGot;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SLIDY PATH ROUTINES
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
int32 Router::smoothestPath() {
|
2003-09-20 15:34:53 +00:00
|
|
|
// This is the second big part of the route finder and the the only
|
|
|
|
// bit that tries to be clever (the other bits are clever).
|
|
|
|
//
|
|
|
|
// This part of the autorouter creates a list of modules from a set of
|
|
|
|
// lines running across the screen. The task is complicated by two
|
|
|
|
// things:
|
|
|
|
//
|
|
|
|
// Firstly in choosing a route through the maze of nodes the routine
|
|
|
|
// tries to minimise the amount of each individual turn avoiding 90
|
|
|
|
// degree and greater turns (where possible) and reduces the total
|
|
|
|
// number of turns (subject to two 45 degree turns being better than
|
|
|
|
// one 90 degree turn).
|
|
|
|
//
|
|
|
|
// Secondly when walking in a given direction the number of steps
|
|
|
|
// required to reach the end of that run is not calculated accurately.
|
|
|
|
// This is because I was unable to derive a function to relate number
|
2005-07-30 21:11:48 +00:00
|
|
|
// of steps taken between two points to the shrunken step size
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:36:09 +00:00
|
|
|
int i;
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 steps = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
int32 lastDir;
|
2003-10-01 10:00:35 +00:00
|
|
|
int32 tempturns[4];
|
|
|
|
int32 turns[4];
|
2006-04-01 12:47:09 +00:00
|
|
|
const int32 turntable[NO_DIRECTIONS] = { 0, 1, 3, 5, 7, 5, 3, 1 };
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// route.X route.Y and route.Dir start at far end
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[0].x = _startX;
|
|
|
|
_smoothPath[0].y = _startY;
|
|
|
|
_smoothPath[0].dir = _startDir;
|
|
|
|
_smoothPath[0].num = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _startDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// for each section of the route
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int p = 0; p < _routeLength; p++) {
|
|
|
|
int32 dirS = _route[p].dirS;
|
|
|
|
int32 dirD = _route[p].dirD;
|
|
|
|
int32 nextDirS = _route[p + 1].dirS;
|
|
|
|
int32 nextDirD = _route[p + 1].dirD;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// Check directions into and out of a pair of nodes going in
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dS = dirS - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dS < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dS = dS + NO_DIRECTIONS;
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dD = dirD - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dD < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dD = dD + NO_DIRECTIONS;
|
|
|
|
|
|
|
|
// coming out
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dSS = dirS - nextDirS;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dSS < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dSS = dSS + NO_DIRECTIONS;
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dDD = dirD - nextDirD;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dDD < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dDD = dDD + NO_DIRECTIONS;
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dSD = dirS - nextDirD;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dSD < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dSD = dSD + NO_DIRECTIONS;
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dDS = dirD - nextDirS;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (dDS < 0)
|
2003-07-28 01:44:38 +00:00
|
|
|
dDS = dDS + NO_DIRECTIONS;
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// Determine the amount of turning involved in each possible path
|
2003-09-20 15:34:53 +00:00
|
|
|
dS = turntable[dS];
|
|
|
|
dD = turntable[dD];
|
2003-07-28 01:44:38 +00:00
|
|
|
dSS = turntable[dSS];
|
|
|
|
dDD = turntable[dDD];
|
2003-09-20 15:34:53 +00:00
|
|
|
dSD = turntable[dSD];
|
|
|
|
dDS = turntable[dDS];
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// get the best path out ie assume next section uses best direction
|
2003-07-28 01:44:38 +00:00
|
|
|
if (dSD < dSS)
|
|
|
|
dSS = dSD;
|
|
|
|
if (dDS < dDD)
|
|
|
|
dDD = dDS;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// Rate each option. Split routes look crap so weight against them
|
2006-02-20 14:18:30 +00:00
|
|
|
tempturns[0] = dS + dSS + 3;
|
2003-07-28 01:44:38 +00:00
|
|
|
turns[0] = 0;
|
2006-02-20 14:18:30 +00:00
|
|
|
tempturns[1] = dS + dDD;
|
2003-07-28 01:44:38 +00:00
|
|
|
turns[1] = 1;
|
2006-02-20 14:18:30 +00:00
|
|
|
tempturns[2] = dD + dSS;
|
2003-07-28 01:44:38 +00:00
|
|
|
turns[2] = 2;
|
2006-02-20 14:18:30 +00:00
|
|
|
tempturns[3] = dD + dDD + 3;
|
2003-07-28 01:44:38 +00:00
|
|
|
turns[3] = 3;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2006-02-20 14:18:30 +00:00
|
|
|
// set up turns as a sorted array of the turn values
|
2003-12-17 08:36:09 +00:00
|
|
|
for (i = 0; i < 3; i++) {
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int j = 0; j < 3; j++) {
|
2003-09-20 15:34:53 +00:00
|
|
|
if (tempturns[j] > tempturns[j + 1]) {
|
2003-10-12 14:40:04 +00:00
|
|
|
SWAP(turns[j], turns[j + 1]);
|
|
|
|
SWAP(tempturns[j], tempturns[j + 1]);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// best option matched in order of the priority we would like
|
|
|
|
// to see on the screen but each option must be checked to see
|
|
|
|
// if it can be walked
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 options = newCheck(1, _route[p].x, _route[p].y, _route[p + 1].x, _route[p + 1].y);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
assert(options);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
i = 0;
|
|
|
|
steps = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 opt = 1 << turns[i];
|
|
|
|
if (options & opt)
|
2003-10-12 14:40:04 +00:00
|
|
|
steps = smoothCheck(turns[i], p, dirS, dirD);
|
2003-09-20 15:34:53 +00:00
|
|
|
i++;
|
|
|
|
} while (steps == 0 && i < 4);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
assert(steps);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// route.X route.Y route.dir and bestTurns start at far end
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// best turns will end heading as near as possible to target dir rest
|
|
|
|
// is down to anim for now
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[steps].dir = 9;
|
|
|
|
_smoothPath[steps].num = ROUTE_END_FLAG;
|
2005-07-30 21:11:48 +00:00
|
|
|
return 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
int32 Router::smoothCheck(int32 best, int32 p, int32 dirS, int32 dirD) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* Slip sliding away
|
|
|
|
* This path checker checks to see if a walk that exactly follows the
|
|
|
|
* path would be valid. This should be inherently true for atleast one
|
|
|
|
* of the turn options.
|
|
|
|
* No longer checks the data it only creates the smoothPath array JPS
|
|
|
|
*********************************************************************/
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// FIXME: Using 'static' vars in a method is evil -- they should almost
|
|
|
|
// always be turned into member variables instead.
|
2003-10-01 10:00:35 +00:00
|
|
|
static int32 k;
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dsx, dsy;
|
|
|
|
int32 ddx, ddy;
|
|
|
|
int32 ss0, ss1, ss2;
|
|
|
|
int32 sd0, sd1, sd2;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (p == 0)
|
|
|
|
k = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 x = _route[p].x;
|
|
|
|
int32 y = _route[p].y;
|
|
|
|
int32 x2 = _route[p + 1].x;
|
|
|
|
int32 y2 = _route[p + 1].y;
|
|
|
|
int32 ldx = x2 - x;
|
|
|
|
int32 ldy = y2 - y;
|
|
|
|
int32 dirX = 1;
|
|
|
|
int32 dirY = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (ldx < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldx = -ldx;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirX = -1;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (ldy < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldy = -ldy;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirY = -1;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// set up sd0-ss2 to reflect possible movement in each direction
|
|
|
|
|
|
|
|
if (dirS == 0 || dirS == 4) { // vert and diag
|
2003-09-19 15:01:49 +00:00
|
|
|
ddx = ldx;
|
2003-10-12 14:40:04 +00:00
|
|
|
ddy = (ldx * _diagonaly) / _diagonalx;
|
2003-09-19 15:01:49 +00:00
|
|
|
dsy = ldy - ddy;
|
|
|
|
ddx = ddx * dirX;
|
|
|
|
ddy = ddy * dirY;
|
|
|
|
dsy = dsy * dirY;
|
|
|
|
dsx = 0;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
sd0 = (ddx + _modX[dirD] / 2) / _modX[dirD];
|
|
|
|
ss0 = (dsy + _modY[dirS] / 2) / _modY[dirS];
|
2003-09-20 15:34:53 +00:00
|
|
|
sd1 = sd0 / 2;
|
|
|
|
ss1 = ss0 / 2;
|
2003-09-19 15:01:49 +00:00
|
|
|
sd2 = sd0 - sd1;
|
|
|
|
ss2 = ss0 - ss1;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
2003-09-19 15:01:49 +00:00
|
|
|
ddy = ldy;
|
2003-10-12 14:40:04 +00:00
|
|
|
ddx = (ldy * _diagonalx) / _diagonaly;
|
2003-09-19 15:01:49 +00:00
|
|
|
dsx = ldx - ddx;
|
|
|
|
ddy = ddy * dirY;
|
|
|
|
ddx = ddx * dirX;
|
|
|
|
dsx = dsx * dirX;
|
|
|
|
dsy = 0;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
sd0 = (ddy + _modY[dirD] / 2) / _modY[dirD];
|
|
|
|
ss0 = (dsx + _modX[dirS] / 2) / _modX[dirS];
|
2003-09-20 15:34:53 +00:00
|
|
|
sd1 = sd0 / 2;
|
|
|
|
ss1 = ss0 / 2;
|
2003-09-19 15:01:49 +00:00
|
|
|
sd2 = sd0 - sd1;
|
|
|
|
ss2 = ss0 - ss1;
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
switch (best) {
|
|
|
|
case 0: // halfsquare, diagonal, halfsquare
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + dsx / 2;
|
|
|
|
_smoothPath[k].y = y + dsy / 2;
|
|
|
|
_smoothPath[k].dir = dirS;
|
|
|
|
_smoothPath[k].num = ss1;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + dsx / 2 + ddx;
|
|
|
|
_smoothPath[k].y = y + dsy / 2 + ddy;
|
|
|
|
_smoothPath[k].dir = dirD;
|
|
|
|
_smoothPath[k].num = sd0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + dsx + ddx;
|
|
|
|
_smoothPath[k].y = y + dsy + ddy;
|
|
|
|
_smoothPath[k].dir = dirS;
|
|
|
|
_smoothPath[k].num = ss2;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
case 1: // square, diagonal
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + dsx;
|
|
|
|
_smoothPath[k].y = y + dsy;
|
|
|
|
_smoothPath[k].dir = dirS;
|
|
|
|
_smoothPath[k].num = ss0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x2;
|
|
|
|
_smoothPath[k].y = y2;
|
|
|
|
_smoothPath[k].dir = dirD;
|
|
|
|
_smoothPath[k].num = sd0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
case 2: // diagonal square
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + ddx;
|
|
|
|
_smoothPath[k].y = y + ddy;
|
|
|
|
_smoothPath[k].dir = dirD;
|
|
|
|
_smoothPath[k].num = sd0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x2;
|
|
|
|
_smoothPath[k].y = y2;
|
|
|
|
_smoothPath[k].dir = dirS;
|
|
|
|
_smoothPath[k].num = ss0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
default: // halfdiagonal, square, halfdiagonal
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + ddx / 2;
|
|
|
|
_smoothPath[k].y = y + ddy / 2;
|
|
|
|
_smoothPath[k].dir = dirD;
|
|
|
|
_smoothPath[k].num = sd1;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x + dsx + ddx / 2;
|
|
|
|
_smoothPath[k].y = y + dsy + ddy / 2;
|
|
|
|
_smoothPath[k].dir = dirS;
|
|
|
|
_smoothPath[k].num = ss0;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_smoothPath[k].x = x2;
|
|
|
|
_smoothPath[k].y = y2;
|
|
|
|
_smoothPath[k].dir = dirD;
|
|
|
|
_smoothPath[k].num = sd2;
|
2003-09-19 15:01:49 +00:00
|
|
|
k++;
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
break;
|
2003-09-19 15:01:49 +00:00
|
|
|
}
|
2005-07-30 21:11:48 +00:00
|
|
|
|
|
|
|
return k;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
void Router::slidyPath() {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
2003-10-12 14:40:04 +00:00
|
|
|
* slidyPath creates a path based on part steps with no sliding to get
|
2003-09-20 15:34:53 +00:00
|
|
|
* as near as possible to the target without any sliding this routine
|
2003-12-17 08:01:59 +00:00
|
|
|
* is intended for use when just clicking about.
|
2003-09-20 15:34:53 +00:00
|
|
|
*
|
|
|
|
* produce a module list from the line data
|
|
|
|
*********************************************************************/
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 smooth = 1;
|
|
|
|
int32 slidy = 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// strip out the short sections
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[0].x = _smoothPath[0].x;
|
|
|
|
_modularPath[0].y = _smoothPath[0].y;
|
|
|
|
_modularPath[0].dir = _smoothPath[0].dir;
|
|
|
|
_modularPath[0].num = 0;
|
|
|
|
|
|
|
|
while (_smoothPath[smooth].num < ROUTE_END_FLAG) {
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 scale = _scaleA * _smoothPath[smooth].y + _scaleB;
|
|
|
|
int32 deltaX = _smoothPath[smooth].x - _modularPath[slidy - 1].x;
|
|
|
|
int32 deltaY = _smoothPath[smooth].y - _modularPath[slidy - 1].y;
|
|
|
|
// quarter a step minimum
|
|
|
|
int32 stepX = (scale * _modX[_smoothPath[smooth].dir]) >> 19;
|
|
|
|
int32 stepY = (scale * _modY[_smoothPath[smooth].dir]) >> 19;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-24 06:40:23 +00:00
|
|
|
if (ABS(deltaX) >= ABS(stepX) && ABS(deltaY) >= ABS(stepY)) {
|
2003-12-17 08:01:59 +00:00
|
|
|
_modularPath[slidy].x = _smoothPath[smooth].x;
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[slidy].y = _smoothPath[smooth].y;
|
|
|
|
_modularPath[slidy].dir = _smoothPath[smooth].dir;
|
|
|
|
_modularPath[slidy].num = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
slidy++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
smooth++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// in case the last bit had no steps
|
|
|
|
|
|
|
|
if (slidy > 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[slidy - 1].x = _smoothPath[smooth - 1].x;
|
|
|
|
_modularPath[slidy - 1].y = _smoothPath[smooth - 1].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// set up the end of the walk
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[slidy].x = _smoothPath[smooth - 1].x;
|
|
|
|
_modularPath[slidy].y = _smoothPath[smooth - 1].y;
|
|
|
|
_modularPath[slidy].dir = _targetDir;
|
|
|
|
_modularPath[slidy].num = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
slidy++;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[slidy].x = _smoothPath[smooth - 1].x;
|
|
|
|
_modularPath[slidy].y = _smoothPath[smooth - 1].y;
|
|
|
|
_modularPath[slidy].dir = 9;
|
|
|
|
_modularPath[slidy].num = ROUTE_END_FLAG;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// SLOW IN
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::addSlowInFrames(WalkData *walkAnim) {
|
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 (_walkData.usingSlowInFrames && _modularPath[1].num > 0) {
|
|
|
|
for (int slowInFrameNo = 0; slowInFrameNo < _walkData.nSlowInFrames[_currentDir]; slowInFrameNo++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = _firstSlowInFrame[_currentDir] + slowInFrameNo;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = _currentDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
return true;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
return false;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +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 Router::earlySlowOut(byte *ob_mega, byte *ob_walkdata) {
|
2003-07-28 01:44:38 +00:00
|
|
|
int32 slowOutFrameNo;
|
|
|
|
int32 walk_pc;
|
2003-12-17 08:01:59 +00:00
|
|
|
WalkData *walkAnim;
|
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
|
|
|
ObjectMega obMega(ob_mega);
|
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "EARLY SLOW-OUT");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
loadWalkData(ob_walkdata);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "********************************");
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "_framesPerStep = %d", _framesPerStep);
|
|
|
|
debug(5, "_numberOfSlowOutFrames = %d", _numberOfSlowOutFrames);
|
|
|
|
debug(5, "_firstWalkingTurnLeftFrame = %d", _firstWalkingTurnLeftFrame);
|
|
|
|
debug(5, "_firstWalkingTurnRightFrame = %d", _firstWalkingTurnRightFrame);
|
|
|
|
debug(5, "_firstSlowOutFrame = %d", _firstSlowOutFrame);
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "********************************");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
walk_pc = obMega.getWalkPc();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-04-23 07:02:11 +00:00
|
|
|
walkAnim = getRouteMem();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// if this mega does actually have slow-out frames
|
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 (_walkData.usingSlowOutFrames) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// overwrite the next step (half a cycle) of the walk
|
2003-09-20 15:34:53 +00:00
|
|
|
// (ie .step - 0..5)
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "STEP NUMBER: walkAnim[%d].step = %d", walk_pc, walkAnim[walk_pc].step);
|
|
|
|
debug(5, "ORIGINAL FRAME: walkAnim[%d].frame = %d", walk_pc, walkAnim[walk_pc].frame);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// map from existing walk frame across to correct
|
|
|
|
// frame number of slow-out - remember, there may be
|
|
|
|
// more slow-out frames than walk-frames!
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (walkAnim[walk_pc].frame >= _firstWalkingTurnRightFrame) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// if it's a walking turn-right, rather than a
|
|
|
|
// normal step, then map it to a normal step
|
|
|
|
// frame first
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[walk_pc].frame -= _firstWalkingTurnRightFrame;
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "MAPPED TO WALK: walkAnim[%d].frame = %d (walking turn-right frame --> walk frame)", walk_pc, walkAnim[walk_pc].frame);
|
2003-10-12 14:40:04 +00:00
|
|
|
} else if (walkAnim[walk_pc].frame >= _firstWalkingTurnLeftFrame) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// if it's a walking turn-left, rather than a
|
|
|
|
// normal step, then map it to a normal step
|
|
|
|
// frame first
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[walk_pc].frame -= _firstWalkingTurnLeftFrame;
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "MAPPED TO WALK: walkAnim[%d].frame = %d (walking turn-left frame --> walk frame)", walk_pc, walkAnim[walk_pc].frame);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[walk_pc].frame += _firstSlowOutFrame + ((walkAnim[walk_pc].frame / _framesPerStep) * (_numberOfSlowOutFrames - _framesPerStep));
|
2003-07-28 01:44:38 +00:00
|
|
|
walkAnim[walk_pc].step = 0;
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SLOW-OUT FRAME: walkAnim[%d].frame = %d",walk_pc, walkAnim[walk_pc].frame);
|
2003-09-20 15:34:53 +00:00
|
|
|
walk_pc++;
|
2003-10-05 15:28:15 +00:00
|
|
|
} while (walkAnim[walk_pc].step > 0);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// add stationary frame(s) (OPTIONAL)
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
for (slowOutFrameNo = _framesPerStep; slowOutFrameNo < _numberOfSlowOutFrames; slowOutFrameNo++) {
|
2003-09-20 15:34:53 +00:00
|
|
|
walkAnim[walk_pc].frame = walkAnim[walk_pc - 1].frame + 1;
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "EXTRA FRAME: walkAnim[%d].frame = %d", walk_pc, walkAnim[walk_pc].frame);
|
2003-07-28 01:44:38 +00:00
|
|
|
walkAnim[walk_pc].step = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
walkAnim[walk_pc].dir = walkAnim[walk_pc - 1].dir;
|
|
|
|
walkAnim[walk_pc].x = walkAnim[walk_pc - 1].x;
|
|
|
|
walkAnim[walk_pc].y = walkAnim[walk_pc - 1].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
walk_pc++;
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
|
|
|
// this mega doesn't have slow-out frames
|
|
|
|
// stand in current direction
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[walk_pc].frame = _firstStandFrame + walkAnim[walk_pc - 1].dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
walkAnim[walk_pc].step = 0;
|
|
|
|
walkAnim[walk_pc].dir = walkAnim[walk_pc - 1].dir;
|
|
|
|
walkAnim[walk_pc].x = walkAnim[walk_pc - 1].x;
|
|
|
|
walkAnim[walk_pc].y = walkAnim[walk_pc - 1].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
walk_pc++;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// end of sequence
|
|
|
|
walkAnim[walk_pc].frame = 512;
|
|
|
|
|
|
|
|
// so that this doesn't happen again while 'george_walking' is still
|
|
|
|
// '2'
|
|
|
|
walkAnim[walk_pc].step = 99;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// SLOW OUT
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
void Router::addSlowOutFrames(WalkData *walkAnim) {
|
2003-07-28 01:44:38 +00:00
|
|
|
int32 slowOutFrameNo;
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// if the mega did actually walk, we overwrite the last step (half a
|
|
|
|
// cycle) with slow-out frames + add any necessary stationary frames
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
if (_walkData.usingSlowOutFrames && _lastCount >= _framesPerStep) {
|
2003-07-28 01:44:38 +00:00
|
|
|
// place stop frames here
|
|
|
|
// slowdown at the end of the last walk
|
2005-07-30 21:11:48 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
slowOutFrameNo = _lastCount - _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "SLOW OUT: slowOutFrameNo(%d) = _lastCount(%d) - _framesPerStep(%d)", slowOutFrameNo, _lastCount, _framesPerStep);
|
2005-07-30 21:11:48 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// overwrite the last step (half a cycle) of the walk
|
|
|
|
|
|
|
|
do {
|
|
|
|
// map from existing walk frame across to correct
|
|
|
|
// frame number of slow-out - remember, there may be
|
|
|
|
// more slow-out frames than walk-frames!
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[slowOutFrameNo].frame += _firstSlowOutFrame + ((walkAnim[slowOutFrameNo].frame / _framesPerStep) * (_numberOfSlowOutFrames - _framesPerStep));
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// because no longer a normal walk-step
|
|
|
|
walkAnim[slowOutFrameNo].step = 0;
|
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "walkAnim[%d].frame = %d",slowOutFrameNo,walkAnim[slowOutFrameNo].frame);
|
2003-09-20 15:34:53 +00:00
|
|
|
slowOutFrameNo++;
|
2003-10-12 14:40:04 +00:00
|
|
|
} while (slowOutFrameNo < _lastCount);
|
2005-07-30 21:11:48 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// add stationary frame(s) (OPTIONAL)
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
for (slowOutFrameNo = _framesPerStep; slowOutFrameNo < _numberOfSlowOutFrames; slowOutFrameNo++) {
|
|
|
|
walkAnim[_stepCount].frame = walkAnim[_stepCount - 1].frame + 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "EXTRA FRAMES: walkAnim[%d].frame = %d", _stepCount, walkAnim[_stepCount].frame);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = walkAnim[_stepCount - 1].dir;
|
|
|
|
walkAnim[_stepCount].x = walkAnim[_stepCount - 1].x;
|
|
|
|
walkAnim[_stepCount].y = walkAnim[_stepCount - 1].y;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
void Router::slidyWalkAnimator(WalkData *walkAnim) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* Skidding every where HardWalk creates an animation that exactly
|
|
|
|
* fits the smoothPath and uses foot slipping to fit whole steps into
|
|
|
|
* the route
|
|
|
|
*
|
|
|
|
* Parameters: georgeg, mouseg
|
2005-07-30 21:11:48 +00:00
|
|
|
* Returns: rout
|
2003-09-20 15:34:53 +00:00
|
|
|
*
|
|
|
|
* produce a module list from the line data
|
|
|
|
*********************************************************************/
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// FIXME: Using 'static' vars in a method is evil -- they should almost
|
|
|
|
// always be turned into member variables instead.
|
2003-07-28 01:44:38 +00:00
|
|
|
static int32 left = 0;
|
|
|
|
int32 p;
|
|
|
|
int32 lastDir;
|
|
|
|
int32 lastRealDir;
|
|
|
|
int32 turnDir;
|
|
|
|
int32 scale;
|
|
|
|
int32 step;
|
|
|
|
int32 module;
|
|
|
|
int32 moduleEnd;
|
|
|
|
int32 module16X;
|
|
|
|
int32 module16Y;
|
|
|
|
int32 stepX;
|
|
|
|
int32 stepY;
|
|
|
|
int32 errorX;
|
|
|
|
int32 errorY;
|
|
|
|
int32 lastErrorX;
|
|
|
|
int32 lastErrorY;
|
|
|
|
int32 frameCount;
|
|
|
|
int32 frames;
|
|
|
|
|
|
|
|
p = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _modularPath[0].dir;
|
|
|
|
_currentDir = _modularPath[1].dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_currentDir == NO_DIRECTIONS)
|
|
|
|
_currentDir = lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_moduleX = _startX;
|
|
|
|
_moduleY = _startY;
|
|
|
|
module16X = _moduleX << 16;
|
|
|
|
module16Y = _moduleY << 16;
|
|
|
|
_stepCount = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// START THE WALK WITH THE FIRST STANDFRAME THIS MAY CAUSE A DELAY
|
|
|
|
// BUT IT STOPS THE PLAYER MOVING FOR COLLISIONS ARE DETECTED
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SLIDY: STARTING THE WALK");
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _framesPerChar + lastDir;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// TURN TO START THE WALK
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SLIDY: TURNING TO START THE WALK");
|
2003-07-28 01:44:38 +00:00
|
|
|
// rotate if we need to
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (lastDir != _currentDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
// get the direction to turn
|
2003-10-12 14:40:04 +00:00
|
|
|
turnDir = _currentDir - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (turnDir < 0)
|
|
|
|
turnDir += NO_DIRECTIONS;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (turnDir > 4)
|
|
|
|
turnDir = -1;
|
|
|
|
else if (turnDir > 0)
|
|
|
|
turnDir = 1;
|
|
|
|
|
|
|
|
// rotate to new walk direction
|
|
|
|
// for george and nico put in a head turn at the start
|
2003-09-20 15:34:53 +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 (_walkData.usingStandingTurnFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// new frames for turn frames 29oct95jps
|
|
|
|
if (turnDir < 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastDir;
|
|
|
|
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// rotate till were facing new dir then go back 45 degrees
|
2003-10-12 14:40:04 +00:00
|
|
|
while (lastDir != _currentDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
lastDir += turnDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// new frames for turn frames 29oct95jps
|
|
|
|
if (turnDir < 0) {
|
2003-07-28 01:44:38 +00:00
|
|
|
if ( lastDir < 0)
|
2003-09-19 15:01:49 +00:00
|
|
|
lastDir += NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
2003-07-28 01:44:38 +00:00
|
|
|
if ( lastDir > 7)
|
2003-09-19 15:01:49 +00:00
|
|
|
lastDir -= NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// the back 45 degrees bit
|
2003-09-20 15:34:53 +00:00
|
|
|
// step back one because new head turn for george takes us
|
|
|
|
// past the new dir
|
2003-10-12 14:40:04 +00:00
|
|
|
_stepCount--;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// his head is in the right direction
|
2003-10-12 14:40:04 +00:00
|
|
|
lastRealDir = _currentDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// SLIDY: THE SLOW IN
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
addSlowInFrames(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// THE WALK
|
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SLIDY: THE WALK");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// start the walk on the left or right leg, depending on how the
|
|
|
|
// slow-in frames were drawn
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// (0 = left; 1 = right)
|
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 (_walkData.leadingLeg[_currentDir] == 0) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// start the walk on the left leg (ie. at beginning of the
|
|
|
|
// first step of the walk cycle)
|
|
|
|
left = 0;
|
|
|
|
} else {
|
|
|
|
// start the walk on the right leg (ie. at beginning of the
|
|
|
|
// second step of the walk cycle)
|
2003-10-12 14:40:04 +00:00
|
|
|
left = _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_lastCount = _stepCount;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// this ensures that we don't put in turn frames for the start
|
|
|
|
lastDir = 99;
|
|
|
|
|
|
|
|
// this ensures that we don't put in turn frames for the start
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = 99;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
2003-10-12 14:40:04 +00:00
|
|
|
assert(_stepCount < O_WALKANIM_SIZE);
|
|
|
|
while (_modularPath[p].num == 0) {
|
2003-09-20 15:34:53 +00:00
|
|
|
p++;
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_currentDir != 99)
|
|
|
|
lastRealDir = _currentDir;
|
|
|
|
lastDir = _currentDir;
|
|
|
|
_lastCount = _stepCount;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// calculate average amount to lose in each step on the way
|
|
|
|
// to the next node
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = _modularPath[p].dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_currentDir < NO_DIRECTIONS) {
|
|
|
|
module = _currentDir * _framesPerStep * 2 + left;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
if (left == 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
left = _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-09-20 15:34:53 +00:00
|
|
|
left = 0;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
moduleEnd = module + _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
step = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
scale = (_scaleA * _moduleY + _scaleB);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
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
|
|
|
module16X += _walkData.dx[module] * scale;
|
|
|
|
module16Y += _walkData.dy[module] * scale;
|
2003-10-12 14:40:04 +00:00
|
|
|
_moduleX = module16X >> 16;
|
|
|
|
_moduleY = module16Y >> 16;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = step; // normally 0,1,2,3,4,5,0,1,2,etc
|
|
|
|
walkAnim[_stepCount].dir = _currentDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-09-20 15:34:53 +00:00
|
|
|
step++;
|
|
|
|
module++;
|
2003-10-05 15:28:15 +00:00
|
|
|
} while (module < moduleEnd);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
stepX = _modX[_modularPath[p].dir];
|
|
|
|
stepY = _modY[_modularPath[p].dir];
|
|
|
|
errorX = _modularPath[p].x - _moduleX;
|
2003-07-28 01:44:38 +00:00
|
|
|
errorX = errorX * stepX;
|
2003-10-12 14:40:04 +00:00
|
|
|
errorY = _modularPath[p].y - _moduleY;
|
2003-07-28 01:44:38 +00:00
|
|
|
errorY = errorY * stepY;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (errorX < 0 || errorY < 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[p].num = 0; // the end of the path
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// okay those last steps took us past our
|
|
|
|
// target but do we want to scoot or moonwalk
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
frames = _stepCount - _lastCount;
|
|
|
|
errorX = _modularPath[p].x - walkAnim[_stepCount - 1].x;
|
|
|
|
errorY = _modularPath[p].y - walkAnim[_stepCount - 1].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (frames > _framesPerStep) {
|
|
|
|
lastErrorX = _modularPath[p].x - walkAnim[_stepCount - 7].x;
|
|
|
|
lastErrorY = _modularPath[p].y - walkAnim[_stepCount - 7].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (stepX == 0) {
|
2003-09-24 06:40:23 +00:00
|
|
|
if (3 * ABS(lastErrorY) < ABS(errorY)) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// the last stop was
|
|
|
|
// closest
|
2003-10-12 14:40:04 +00:00
|
|
|
_stepCount -= _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
if (left == 0)
|
2006-04-01 12:47:09 +00:00
|
|
|
left = _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2006-04-01 12:47:09 +00:00
|
|
|
left = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
2003-09-24 06:40:23 +00:00
|
|
|
if (3 * ABS(lastErrorX) < ABS(errorX)) {
|
2003-09-20 15:34:53 +00:00
|
|
|
//the last stop was
|
|
|
|
// closest
|
2003-10-12 14:40:04 +00:00
|
|
|
_stepCount -= _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
if (left == 0)
|
2006-04-01 12:47:09 +00:00
|
|
|
left = _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2006-04-01 12:47:09 +00:00
|
|
|
left = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
errorX = _modularPath[p].x - walkAnim[_stepCount-1].x;
|
|
|
|
errorY = _modularPath[p].y - walkAnim[_stepCount-1].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// okay we've reached the end but we still
|
|
|
|
// have an error
|
|
|
|
|
|
|
|
if (errorX != 0) {
|
2003-07-28 01:44:38 +00:00
|
|
|
frameCount = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
frames = _stepCount - _lastCount;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
frameCount++;
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_lastCount + frameCount - 1].x += errorX * frameCount / frames;
|
2005-07-30 21:11:48 +00:00
|
|
|
} while (frameCount < frames);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (errorY != 0) {
|
2003-07-28 01:44:38 +00:00
|
|
|
frameCount = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
frames = _stepCount - _lastCount;
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
|
|
|
frameCount++;
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_lastCount + frameCount - 1].y += errorY * frameCount / frames;
|
2005-07-30 21:11:48 +00:00
|
|
|
} while (frameCount < frames);
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Now is the time to put in the turn frames
|
|
|
|
// for the last turn
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (frames < _framesPerStep) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// this ensures that we don't put in
|
|
|
|
// turn frames for this walk or the
|
2005-07-30 21:11:48 +00:00
|
|
|
// next
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = 99;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_currentDir != 99)
|
|
|
|
lastRealDir = _currentDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// check each turn condition in turn
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// only for george
|
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 (lastDir != 99 && _currentDir != 99 && _walkData.usingWalkingTurnFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// 1 and -7 going right -1 and 7 going
|
|
|
|
// left
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _currentDir - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (lastDir == -1 || lastDir == 7 || lastDir == -2 || lastDir == 6) {
|
|
|
|
// turn at the end of the last
|
|
|
|
// walk
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_frame = _lastCount - _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
2005-07-30 21:11:48 +00:00
|
|
|
// turning left
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_frame].frame += _firstWalkingTurnLeftFrame;
|
|
|
|
_frame++;
|
|
|
|
} while (_frame < _lastCount);
|
2005-07-30 21:11:48 +00:00
|
|
|
} else if (lastDir == 1 || lastDir == -7 || lastDir == 2 || lastDir == -6) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// turn at the end of the
|
|
|
|
// current walk
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_frame = _lastCount - _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
|
|
|
// turning right
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_frame].frame += _firstWalkingTurnRightFrame;
|
|
|
|
_frame++;
|
|
|
|
} while (_frame < _lastCount);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _currentDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// all turns checked
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_lastCount = _stepCount;
|
|
|
|
_moduleX = walkAnim[_stepCount - 1].x;
|
|
|
|
_moduleY = walkAnim[_stepCount - 1].y;
|
|
|
|
module16X = _moduleX << 16;
|
|
|
|
module16Y = _moduleY << 16;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
} while (_modularPath[p].dir < NO_DIRECTIONS);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-11-16 09:15:25 +00:00
|
|
|
#ifdef SWORD2_DEBUG
|
2003-07-28 01:44:38 +00:00
|
|
|
if (lastRealDir == 99)
|
2003-10-26 15:42:49 +00:00
|
|
|
error("slidyWalkAnimatorlast direction error");
|
2003-07-28 01:44:38 +00:00
|
|
|
#endif
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SLOW OUT
|
2003-10-12 14:40:04 +00:00
|
|
|
addSlowOutFrames(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// TURNS TO END THE WALK ?
|
|
|
|
|
|
|
|
// We've done the walk now put in any turns at the end
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_targetDir == 8) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// ANY direction -> stand in the last direction
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandFrame + lastRealDir;
|
|
|
|
_targetDir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_targetDir == 9) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// 'stance' was non-zero
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_stepCount == 0) {
|
|
|
|
module = _framesPerChar + lastRealDir;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
} else if (_targetDir != lastRealDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
// rotate to target direction
|
2003-10-12 14:40:04 +00:00
|
|
|
turnDir = _targetDir - lastRealDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
if ( turnDir < 0)
|
2003-09-20 15:34:53 +00:00
|
|
|
turnDir += NO_DIRECTIONS;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (turnDir > 4)
|
|
|
|
turnDir = -1;
|
|
|
|
else if (turnDir > 0)
|
|
|
|
turnDir = 1;
|
|
|
|
|
|
|
|
// rotate to target direction
|
|
|
|
// for george and nico put in a head turn at the start
|
2003-09-20 15:34:53 +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 (_walkData.usingStandingTurnFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// new frames for turn frames 29oct95jps
|
|
|
|
if (turnDir < 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastDir;
|
|
|
|
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// rotate if we need to
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
while (lastRealDir != _targetDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
lastRealDir += turnDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// new frames for turn frames 29oct95jps
|
|
|
|
if (turnDir < 0) {
|
|
|
|
if (lastRealDir < 0)
|
2003-09-19 15:01:49 +00:00
|
|
|
lastRealDir += NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastRealDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
|
|
|
if (lastRealDir > 7)
|
2003-09-19 15:01:49 +00:00
|
|
|
lastRealDir -= NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastRealDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandFrame + lastRealDir;
|
|
|
|
walkAnim[_stepCount - 1].frame = module;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
|
|
|
// just stand at the end
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandFrame + lastRealDir;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastRealDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// write all the frames to "debug.txt"
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "THE WALKDATA:");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
for (_frame = 0; _frame <= _stepCount; _frame++)
|
|
|
|
debug(5, "walkAnim[%d].frame=%d", _frame, walkAnim[_frame].frame);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "routeFinder RouteSize is %d", _stepCount);
|
2003-07-28 01:44:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
#ifndef FORCE_SLIDY
|
2003-10-12 14:40:04 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SOLID PATH ROUTINES
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
void Router::solidPath() {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* SolidPath creates a path based on whole steps with no sliding to
|
|
|
|
* get as near as possible to the target without any sliding this
|
|
|
|
* routine is currently unused, but is intended for use when just
|
|
|
|
* clicking about.
|
|
|
|
*
|
|
|
|
* produce a module list from the line data
|
|
|
|
*********************************************************************/
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
int32 smooth;
|
|
|
|
int32 solid;
|
|
|
|
int32 scale;
|
|
|
|
int32 stepX;
|
|
|
|
int32 stepY;
|
|
|
|
int32 deltaX;
|
|
|
|
int32 deltaY;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// strip out the short sections
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
solid = 1;
|
|
|
|
smooth = 1;
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[0].x = _smoothPath[0].x;
|
|
|
|
_modularPath[0].y = _smoothPath[0].y;
|
|
|
|
_modularPath[0].dir = _smoothPath[0].dir;
|
|
|
|
_modularPath[0].num = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
2003-10-12 14:40:04 +00:00
|
|
|
scale = _scaleA * _smoothPath[smooth].y + _scaleB;
|
|
|
|
deltaX = _smoothPath[smooth].x - _modularPath[solid - 1].x;
|
|
|
|
deltaY = _smoothPath[smooth].y - _modularPath[solid - 1].y;
|
|
|
|
stepX = _modX[_smoothPath[smooth].dir];
|
|
|
|
stepY = _modY[_smoothPath[smooth].dir];
|
2003-07-28 01:44:38 +00:00
|
|
|
stepX = stepX * scale;
|
|
|
|
stepY = stepY * scale;
|
|
|
|
stepX = stepX >> 16;
|
|
|
|
stepY = stepY >> 16;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-24 06:40:23 +00:00
|
|
|
if (ABS(deltaX) >= ABS(stepX) && ABS(deltaY) >= ABS(stepY)) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[solid].x = _smoothPath[smooth].x;
|
|
|
|
_modularPath[solid].y = _smoothPath[smooth].y;
|
2006-04-01 12:47:09 +00:00
|
|
|
_modularPath[solid].dir = _smoothPath[smooth].dir;
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[solid].num = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
solid++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
smooth++;
|
2003-10-12 14:40:04 +00:00
|
|
|
} while (_smoothPath[smooth].num < ROUTE_END_FLAG);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// in case the last bit had no steps
|
|
|
|
|
|
|
|
if (solid == 1) {
|
|
|
|
// there were no paths so put in a dummy end
|
|
|
|
solid = 2;
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[1].dir = _smoothPath[0].dir;
|
|
|
|
_modularPath[1].num = 0;
|
2005-07-30 21:11:48 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[solid - 1].x = _smoothPath[smooth - 1].x;
|
|
|
|
_modularPath[solid - 1].y = _smoothPath[smooth - 1].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// set up the end of the walk
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[solid].x = _smoothPath[smooth - 1].x;
|
|
|
|
_modularPath[solid].y = _smoothPath[smooth - 1].y;
|
|
|
|
_modularPath[solid].dir = 9;
|
|
|
|
_modularPath[solid].num = ROUTE_END_FLAG;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 Router::solidWalkAnimator(WalkData *walkAnim) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
|
|
|
* SolidWalk creates an animation based on whole steps with no sliding
|
|
|
|
* to get as near as possible to the target without any sliding. This
|
|
|
|
* routine is is intended for use when just clicking about.
|
|
|
|
*
|
|
|
|
* produce a module list from the line data
|
|
|
|
*
|
|
|
|
* returns 0 if solid route not found
|
|
|
|
*********************************************************************/
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
int32 left;
|
|
|
|
int32 turnDir;
|
|
|
|
int32 scale;
|
|
|
|
int32 step;
|
|
|
|
int32 errorX;
|
|
|
|
int32 errorY;
|
|
|
|
int32 moduleEnd;
|
2003-12-17 08:01:59 +00:00
|
|
|
bool slowStart = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// start at the beginning for a change
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 lastDir = _modularPath[0].dir;
|
|
|
|
int32 module = _framesPerChar + lastDir;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = _modularPath[1].dir;
|
|
|
|
_moduleX = _startX;
|
|
|
|
_moduleY = _startY;
|
|
|
|
_stepCount = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 module16X = _moduleX << 16;
|
|
|
|
int32 module16Y = _moduleY << 16;
|
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// START THE WALK WITH THE FIRST STANDFRAME THIS MAY CAUSE A DELAY
|
|
|
|
// BUT IT STOPS THE PLAYER MOVING FOR COLLISIONS ARE DETECTED
|
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SOLID: STARTING THE WALK");
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// TURN TO START THE WALK
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SOLID: TURNING TO START THE WALK");
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// rotate if we need to
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (lastDir != _currentDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
// get the direction to turn
|
2003-10-12 14:40:04 +00:00
|
|
|
turnDir = _currentDir - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
if (turnDir < 0)
|
|
|
|
turnDir += NO_DIRECTIONS;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (turnDir > 4)
|
|
|
|
turnDir = -1;
|
|
|
|
else if (turnDir > 0)
|
|
|
|
turnDir = 1;
|
|
|
|
|
|
|
|
// rotate to new walk direction
|
|
|
|
// for george and nico put in a head turn at the start
|
2003-09-20 15:34:53 +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 (_walkData.usingStandingTurnFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// new frames for turn frames 29oct95jps
|
|
|
|
if (turnDir < 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastDir;
|
|
|
|
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// rotate till were facing new dir then go back 45 degrees
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
while (lastDir != _currentDir) {
|
2003-07-28 01:44:38 +00:00
|
|
|
lastDir += turnDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2004-03-17 09:03:15 +00:00
|
|
|
// new frames for turn frames
|
2003-09-20 15:34:53 +00:00
|
|
|
if (turnDir < 0) {
|
|
|
|
if (lastDir < 0)
|
|
|
|
lastDir += NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnLeftFrame + lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
2004-03-17 09:03:15 +00:00
|
|
|
if (lastDir > 7)
|
2003-09-20 15:34:53 +00:00
|
|
|
lastDir -= NO_DIRECTIONS;
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _firstStandingTurnRightFrame + lastDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = lastDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// the back 45 degrees bit
|
2003-09-20 15:34:53 +00:00
|
|
|
// step back one because new head turn for george takes us
|
|
|
|
// past the new dir
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_stepCount--;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SLOW IN
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
slowStart = addSlowInFrames(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// THE WALK
|
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "SOLID: THE WALK");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// start the walk on the left or right leg, depending on how the
|
|
|
|
// slow-in frames were drawn
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// (0 = left; 1 = right)
|
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 (_walkData.leadingLeg[_currentDir] == 0) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// start the walk on the left leg (ie. at beginning of the
|
|
|
|
// first step of the walk cycle)
|
|
|
|
left = 0;
|
|
|
|
} else {
|
|
|
|
// start the walk on the right leg (ie. at beginning of the
|
|
|
|
// second step of the walk cycle)
|
2003-10-12 14:40:04 +00:00
|
|
|
left = _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_lastCount = _stepCount;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// this ensures that we don't put in turn frames for the start
|
|
|
|
lastDir = 99;
|
|
|
|
|
|
|
|
// this ensures that we don't put in turn frames for the start
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = 99;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
int32 p;
|
2003-12-17 08:01:59 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
for (p = 1; _modularPath[p].dir < NO_DIRECTIONS; ++p) {
|
2003-10-12 14:40:04 +00:00
|
|
|
while (_modularPath[p].num > 0) {
|
|
|
|
_currentDir = _modularPath[p].dir;
|
|
|
|
if (_currentDir < NO_DIRECTIONS) {
|
|
|
|
module = _currentDir * _framesPerStep * 2 + left;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
if (left == 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
left = _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
|
|
|
left = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
moduleEnd = module + _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
step = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
scale = (_scaleA * _moduleY + _scaleB);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
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
|
|
|
module16X += _walkData.dx[module] * scale;
|
|
|
|
module16Y += _walkData.dy[module] * scale;
|
2003-10-12 14:40:04 +00:00
|
|
|
_moduleX = module16X >> 16;
|
|
|
|
_moduleY = module16Y >> 16;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = step; // normally 0,1,2,3,4,5,0,1,2,etc
|
|
|
|
walkAnim[_stepCount].dir = _currentDir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-09-20 15:34:53 +00:00
|
|
|
module++;
|
|
|
|
step++;
|
2003-10-05 15:28:15 +00:00
|
|
|
} while (module < moduleEnd);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
errorX = _modularPath[p].x - _moduleX;
|
|
|
|
errorX = errorX * _modX[_modularPath[p].dir];
|
|
|
|
errorY = _modularPath[p].y - _moduleY;
|
|
|
|
errorY = errorY * _modY[_modularPath[p].dir];
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (errorX < 0 || errorY < 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_modularPath[p].num = 0;
|
|
|
|
_stepCount -= _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
if (left == 0)
|
2003-10-12 14:40:04 +00:00
|
|
|
left = _framesPerStep;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
|
|
|
left = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// Okay this is the end of a section
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_moduleX = walkAnim[_stepCount - 1].x;
|
|
|
|
_moduleY = walkAnim[_stepCount - 1].y;
|
|
|
|
module16X = _moduleX << 16;
|
|
|
|
module16Y = _moduleY << 16;
|
|
|
|
_modularPath[p].x = _moduleX;
|
|
|
|
_modularPath[p].y = _moduleY;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// Now is the time to put in the turn
|
|
|
|
// frames for the last turn
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_stepCount - _lastCount < _framesPerStep) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// no step taken
|
|
|
|
|
|
|
|
// clean up if a slow in but no
|
|
|
|
// walk
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
if (slowStart) {
|
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
|
|
|
_stepCount -= _walkData.nSlowInFrames[_currentDir];
|
|
|
|
_lastCount -= _walkData.nSlowInFrames[_currentDir];
|
2003-12-17 08:01:59 +00:00
|
|
|
slowStart = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// this ensures that we don't
|
|
|
|
// put in turn frames for this
|
|
|
|
// walk or the next
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_currentDir = 99;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// check each turn condition in turn
|
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 (lastDir != 99 && _currentDir != 99 && _walkData.usingWalkingTurnFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// only for george
|
|
|
|
// 1 and -7 going right -1 and
|
|
|
|
// 7 going left
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _currentDir - lastDir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (lastDir == -1 || lastDir == 7 || lastDir == -2 || lastDir == 6) {
|
|
|
|
// turn at the end of
|
|
|
|
// the last walk
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_frame = _lastCount - _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
// turning left
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_frame].frame += _firstWalkingTurnLeftFrame;
|
|
|
|
_frame++;
|
|
|
|
} while (_frame < _lastCount);
|
2005-07-30 21:11:48 +00:00
|
|
|
} else if (lastDir == 1 || lastDir == -7 || lastDir == 2 || lastDir == -6) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// turn at the end of
|
|
|
|
// the current walk
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_frame = _lastCount - _framesPerStep;
|
2003-09-20 15:34:53 +00:00
|
|
|
do {
|
|
|
|
// turning right
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_frame].frame += _firstWalkingTurnRightFrame;
|
|
|
|
_frame++;
|
|
|
|
} while (_frame < _lastCount);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// all turns checked
|
2003-10-12 14:40:04 +00:00
|
|
|
_lastCount = _stepCount;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
lastDir = _currentDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
// can only be valid first time round
|
2003-12-17 08:01:59 +00:00
|
|
|
slowStart = false;
|
2006-04-01 12:47:09 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SLOW OUT
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
addSlowOutFrames(walkAnim);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
module = _framesPerChar + _modularPath[p - 1].dir;
|
|
|
|
walkAnim[_stepCount].frame = module;
|
|
|
|
walkAnim[_stepCount].step = 0;
|
|
|
|
walkAnim[_stepCount].dir = _modularPath[p - 1].dir;
|
|
|
|
walkAnim[_stepCount].x = _moduleX;
|
|
|
|
walkAnim[_stepCount].y = _moduleY;
|
|
|
|
_stepCount++;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
|
|
|
_stepCount++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
|
|
|
_stepCount++;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
walkAnim[_stepCount].frame = 512;
|
|
|
|
walkAnim[_stepCount].step = 99;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "THE WALKDATA:");
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
for (_frame = 0; _frame <= _stepCount; _frame++)
|
|
|
|
debug(5, "walkAnim[%d].frame=%d", _frame, walkAnim[_frame].frame);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// NO END TURNS
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "routeFinder RouteSize is %d", _stepCount);
|
2003-09-20 15:34:53 +00:00
|
|
|
// now check the route
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
for (int i = 0; i < p - 1; ++i) {
|
2003-10-12 14:40:04 +00:00
|
|
|
if (!check(_modularPath[i].x, _modularPath[i].y, _modularPath[i + 1].x, _modularPath[i + 1].y))
|
2003-09-20 15:34:53 +00:00
|
|
|
p = 0;
|
2006-04-01 12:47:09 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (p != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_targetDir = _modularPath[p - 1].dir;
|
|
|
|
if (checkTarget(_moduleX, _moduleY) == 3) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// new target on a line
|
|
|
|
p = 0;
|
2003-10-12 14:40:04 +00:00
|
|
|
debug(5, "Solid walk target was on a line %d %d", _moduleX, _moduleY);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
return p;
|
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
#endif
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SCAN ROUTINES
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::scan(int32 level) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
2003-10-12 14:40:04 +00:00
|
|
|
* Called successively from routeFinder until no more changes take
|
2003-09-20 15:34:53 +00:00
|
|
|
* place in the grid array, ie he best path has been found
|
|
|
|
*
|
|
|
|
* Scans through every point in the node array and checks if there is
|
|
|
|
* a route between each point and if this route gives a new route.
|
|
|
|
*
|
|
|
|
* This routine could probably halve its processing time if it doubled
|
|
|
|
* up on the checks after each route check
|
|
|
|
*
|
|
|
|
*********************************************************************/
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 x1, y1, x2, y2;
|
2003-09-20 15:34:53 +00:00
|
|
|
int32 distance;
|
2003-12-17 08:01:59 +00:00
|
|
|
bool changed = false;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// For all the nodes that have new values and a distance less than
|
2003-09-20 15:34:53 +00:00
|
|
|
// enddist, ie dont check for new routes from a point we checked
|
|
|
|
// before or from a point that is already further away than the best
|
2005-07-30 21:11:48 +00:00
|
|
|
// route so far.
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 0; i < _nNodes; i++) {
|
|
|
|
if (_node[i].dist < _node[_nNodes].dist && _node[i].level == level) {
|
2003-10-12 14:40:04 +00:00
|
|
|
x1 = _node[i].x;
|
|
|
|
y1 = _node[i].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int j = _nNodes; j > 0; j--) {
|
|
|
|
if (_node[j].dist > _node[i].dist) {
|
|
|
|
x2 = _node[j].x;
|
|
|
|
y2 = _node[j].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
if (ABS(x2 - x1) > 4.5 * ABS(y2 - y1))
|
2003-09-24 06:40:23 +00:00
|
|
|
distance = (8 * ABS(x2 - x1) + 18 * ABS(y2 - y1)) / (54 * 8) + 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
else
|
2003-09-24 06:40:23 +00:00
|
|
|
distance = (6 * ABS(x2 - x1) + 36 * ABS(y2 - y1)) / (36 * 14) + 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
if (distance + _node[i].dist < _node[_nNodes].dist && distance + _node[i].dist < _node[j].dist) {
|
2003-10-12 14:40:04 +00:00
|
|
|
if (newCheck(0, x1, y1, x2, y2)) {
|
2003-12-17 08:01:59 +00:00
|
|
|
_node[j].level = level + 1;
|
|
|
|
_node[j].dist = distance + _node[i].dist;
|
|
|
|
_node[j].prev = i;
|
|
|
|
changed = true;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
int32 Router::newCheck(int32 status, int32 x1, int32 y1, int32 x2, int32 y2) {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
2003-10-12 14:40:04 +00:00
|
|
|
* newCheck routine checks if the route between two points can be
|
2005-07-30 21:11:48 +00:00
|
|
|
* achieved without crossing any of the bars in the Bars array.
|
2003-09-20 15:34:53 +00:00
|
|
|
*
|
2003-10-12 14:40:04 +00:00
|
|
|
* newCheck differs from check in that that 4 route options are
|
2003-09-20 15:34:53 +00:00
|
|
|
* considered corresponding to actual walked routes.
|
|
|
|
*
|
2005-07-30 21:11:48 +00:00
|
|
|
* Note distance doesnt take account of shrinking ???
|
2003-09-20 15:34:53 +00:00
|
|
|
*
|
|
|
|
* Note Bars array must be properly calculated ie min max dx dy co
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
int32 ldx;
|
|
|
|
int32 ldy;
|
|
|
|
int32 dlx;
|
|
|
|
int32 dly;
|
|
|
|
int32 dirX;
|
|
|
|
int32 dirY;
|
2003-10-01 10:00:35 +00:00
|
|
|
int32 step1;
|
|
|
|
int32 step2;
|
|
|
|
int32 step3;
|
|
|
|
int32 steps;
|
|
|
|
int32 options;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
steps = 0;
|
|
|
|
options = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
ldx = x2 - x1;
|
|
|
|
ldy = y2 - y1;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirX = 1;
|
|
|
|
dirY = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (ldx < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldx = -ldx;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirX = -1;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (ldy < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldy = -ldy;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirY = -1;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// make the route options
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_diagonaly * ldx > _diagonalx * ldy) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// dir = 1,2 or 2,3 or 5,6 or 6,7
|
|
|
|
|
|
|
|
dly = ldy;
|
2003-10-12 14:40:04 +00:00
|
|
|
dlx = (ldy * _diagonalx) / _diagonaly;
|
2003-07-28 12:24:13 +00:00
|
|
|
ldx = ldx - dlx;
|
2003-07-28 01:44:38 +00:00
|
|
|
dlx = dlx * dirX;
|
|
|
|
dly = dly * dirY;
|
2003-07-28 12:24:13 +00:00
|
|
|
ldx = ldx * dirX;
|
|
|
|
ldy = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// options are square, diagonal a code 1 route
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1 + ldx, y1);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1 + ldx, y1, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
|
|
|
steps = step1 + step2;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 2;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// diagonal, square a code 2 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1 + dlx, y1 + dly);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1 + dlx, y2, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
|
|
|
steps = step1 + step2;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 4;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// halfsquare, diagonal, halfsquare a code 0 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1 + ldx / 2, y1);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1 + ldx / 2, y1, x1 + ldx / 2 + dlx, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step3 = check(x1 + ldx / 2 + dlx, y2, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step3 != 0) {
|
|
|
|
steps = step1 + step2 + step3;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// halfdiagonal, square, halfdiagonal a code 3 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1 + dlx / 2, y1 + dly / 2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1 + dlx / 2, y1 + dly / 2, x1 + ldx + dlx / 2, y1 + dly / 2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step3 = check(x1 + ldx + dlx / 2, y1 + dly / 2, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step3 != 0) {
|
|
|
|
steps = step1 + step2 + step3;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 8;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
|
|
|
// dir = 7,0 or 0,1 or 3,4 or 4,5
|
|
|
|
|
|
|
|
dlx = ldx;
|
2003-10-12 14:40:04 +00:00
|
|
|
dly = (ldx * _diagonaly) / _diagonalx;
|
2003-07-28 12:24:13 +00:00
|
|
|
ldy = ldy - dly;
|
2003-07-28 01:44:38 +00:00
|
|
|
dlx = dlx * dirX;
|
|
|
|
dly = dly * dirY;
|
2003-07-28 12:24:13 +00:00
|
|
|
ldy = ldy * dirY;
|
|
|
|
ldx = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// options are square, diagonal a code 1 route
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1 ,y1, x1, y1 + ldy);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1, y1 + ldy, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
|
|
|
steps = step1 + step2;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 2;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// diagonal, square a code 2 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x2, y1 + dly);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x2, y1 + dly, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
|
|
|
steps = step1 + step2;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 4;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// halfsquare, diagonal, halfsquare a code 0 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1, y1 + ldy / 2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1, y1 + ldy / 2, x2, y1 + ldy / 2 + dly);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step3 = check(x2, y1 + ldy / 2 + dly, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step3 != 0) {
|
|
|
|
steps = step1 + step2 + step3;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// halfdiagonal, square, halfdiagonal a code 3 route
|
2003-09-20 15:34:53 +00:00
|
|
|
if (steps == 0 || status == 1) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step1 = check(x1, y1, x1 + dlx / 2, y1 + dly / 2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step1 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step2 = check(x1 + dlx / 2, y1 + dly / 2, x1 + dlx / 2, y1 + ldy + dly / 2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step2 != 0) {
|
2003-10-12 14:40:04 +00:00
|
|
|
step3 = check(x1 + dlx / 2, y1 + ldy + dly / 2, x2, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
if (step3 != 0) {
|
|
|
|
steps = step1 + step2 + step3;
|
2003-12-17 08:01:59 +00:00
|
|
|
options |= 8;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
if (status == 0)
|
|
|
|
status = steps;
|
|
|
|
else
|
|
|
|
status = options;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// CHECK ROUTINES
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::check(int32 x1, int32 y1, int32 x2, int32 y2) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// call the fastest line check for the given line
|
2003-12-17 08:01:59 +00:00
|
|
|
// returns true if line didn't cross any bars
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (x1 == x2 && y1 == y2)
|
2003-12-17 08:01:59 +00:00
|
|
|
return true;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (x1 == x2)
|
2003-10-12 14:40:04 +00:00
|
|
|
return vertCheck(x1, y1, y2);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
if (y1 == y2)
|
2003-10-12 14:40:04 +00:00
|
|
|
return horizCheck(x1, y1, x2);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
return lineCheck(x1, y1, x2, y2);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::lineCheck(int32 x1, int32 y1, int32 x2, int32 y2) {
|
|
|
|
bool linesCrossed = true;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 xmin = MIN(x1, x2);
|
|
|
|
int32 xmax = MAX(x1, x2);
|
|
|
|
int32 ymin = MIN(y1, y2);
|
|
|
|
int32 ymax = MAX(y1, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// Line set to go one step in chosen direction so ignore if it hits
|
|
|
|
// anything
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 dirx = x2 - x1;
|
|
|
|
int32 diry = y2 - y1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 co = (y1 * dirx) - (x1 * diry); // new line equation
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 0; i < _nBars && linesCrossed; i++) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on module
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xmax >= _bars[i].xmin && xmin <= _bars[i].xmax && ymax >= _bars[i].ymin && ymin <= _bars[i].ymax) {
|
|
|
|
// Okay, it's a valid line. Calculate an intercept. Wow
|
|
|
|
// but all this arithmetic we must have loads of time
|
|
|
|
|
|
|
|
// slope it he slope between the two lines
|
|
|
|
int32 slope = (_bars[i].dx * diry) - (_bars[i].dy *dirx);
|
|
|
|
// assuming parallel lines don't cross
|
|
|
|
if (slope != 0) {
|
|
|
|
// calculate x intercept and check its on both
|
|
|
|
// lines
|
|
|
|
int32 xc = ((_bars[i].co * dirx) - (co * _bars[i].dx)) / slope;
|
|
|
|
|
|
|
|
// skip if not on module
|
|
|
|
if (xc >= xmin - 1 && xc <= xmax + 1) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on line
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xc >= _bars[i].xmin - 1 && xc <= _bars[i].xmax + 1) {
|
|
|
|
int32 yc = ((_bars[i].co * diry) - (co * _bars[i].dy)) / slope;
|
|
|
|
|
|
|
|
// skip if not on module
|
|
|
|
if (yc >= ymin - 1 && yc <= ymax + 1) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on line
|
2003-12-17 08:01:59 +00:00
|
|
|
if (yc >= _bars[i].ymin - 1 && yc <= _bars[i].ymax + 1) {
|
|
|
|
linesCrossed = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
return linesCrossed;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::horizCheck(int32 x1, int32 y, int32 x2) {
|
|
|
|
bool linesCrossed = true;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 xmin = MIN(x1, x2);
|
|
|
|
int32 xmax = MAX(x1, x2);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// line set to go one step in chosen direction so ignore if it hits
|
|
|
|
// anything
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 0; i < _nBars && linesCrossed; i++) {
|
2003-10-01 10:00:35 +00:00
|
|
|
// skip if not on module
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xmax >= _bars[i].xmin && xmin <= _bars[i].xmax && y >= _bars[i].ymin && y <= _bars[i].ymax) {
|
|
|
|
// Okay, it's a valid line calculate an intercept. Wow
|
|
|
|
// but all this arithmetic we must have loads of time
|
|
|
|
|
|
|
|
if (_bars[i].dy == 0)
|
|
|
|
linesCrossed = false;
|
|
|
|
else {
|
|
|
|
int32 ldy = y - _bars[i].y1;
|
|
|
|
int32 xc = _bars[i].x1 + (_bars[i].dx * ldy) / _bars[i].dy;
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on module
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xc >= xmin - 1 && xc <= xmax + 1)
|
|
|
|
linesCrossed = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
return linesCrossed;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
bool Router::vertCheck(int32 x, int32 y1, int32 y2) {
|
|
|
|
bool linesCrossed = true;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 ymin = MIN(y1, y2);
|
|
|
|
int32 ymax = MAX(y1, y2);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
// Line set to go one step in chosen direction so ignore if it hits
|
|
|
|
// anything
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 0; i < _nBars && linesCrossed; i++) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on module
|
2003-12-17 08:01:59 +00:00
|
|
|
if (x >= _bars[i].xmin && x <= _bars[i].xmax && ymax >= _bars[i].ymin && ymin <= _bars[i].ymax) {
|
|
|
|
// Okay, it's a valid line calculate an intercept. Wow
|
|
|
|
// but all this arithmetic we must have loads of time
|
|
|
|
|
|
|
|
// both lines vertical and overlap in x and y so they
|
|
|
|
// cross
|
|
|
|
|
|
|
|
if (_bars[i].dx == 0)
|
|
|
|
linesCrossed = false;
|
|
|
|
else {
|
|
|
|
int32 ldx = x - _bars[i].x1;
|
|
|
|
int32 yc = _bars[i].y1 + (_bars[i].dy * ldx) / _bars[i].dx;
|
2005-07-30 21:11:48 +00:00
|
|
|
// the intercept overlaps
|
2003-12-17 08:01:59 +00:00
|
|
|
if (yc >= ymin - 1 && yc <= ymax + 1)
|
|
|
|
linesCrossed = false;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
return linesCrossed;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
int32 Router::checkTarget(int32 x, int32 y) {
|
2003-10-01 10:00:35 +00:00
|
|
|
int32 onLine = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 xmin = x - 1;
|
|
|
|
int32 xmax = x + 1;
|
|
|
|
int32 ymin = y - 1;
|
|
|
|
int32 ymax = y + 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// check if point +- 1 is on the line
|
2003-12-17 08:01:59 +00:00
|
|
|
// so ignore if it hits anything
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 0; i < _nBars && onLine == 0; i++) {
|
2005-07-30 21:11:48 +00:00
|
|
|
// overlapping line
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xmax >= _bars[i].xmin && xmin <= _bars[i].xmax && ymax >= _bars[i].ymin && ymin <= _bars[i].ymax) {
|
|
|
|
int32 xc, yc;
|
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// okay this line overlaps the target calculate an y intercept for x
|
2003-12-17 08:01:59 +00:00
|
|
|
|
|
|
|
// vertical line so we know it overlaps y
|
|
|
|
if (_bars[i].dx == 0)
|
2005-07-30 21:11:48 +00:00
|
|
|
yc = 0;
|
2003-12-17 08:01:59 +00:00
|
|
|
else {
|
|
|
|
int ldx = x - _bars[i].x1;
|
|
|
|
yc = _bars[i].y1 + (_bars[i].dy * ldx) / _bars[i].dx;
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
// overlapping point for y
|
2003-12-17 08:01:59 +00:00
|
|
|
if (yc >= ymin && yc <= ymax) {
|
|
|
|
// target on a line so drop out
|
|
|
|
onLine = 3;
|
|
|
|
debug(5, "RouteFail due to target on a line %d %d", x, y);
|
|
|
|
} else {
|
2003-09-20 15:34:53 +00:00
|
|
|
// vertical line so we know it overlaps y
|
2003-12-17 08:01:59 +00:00
|
|
|
if (_bars[i].dy == 0)
|
|
|
|
xc = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
else {
|
2003-12-17 08:01:59 +00:00
|
|
|
int32 ldy = y - _bars[i].y1;
|
|
|
|
xc = _bars[i].x1 + (_bars[i].dx * ldy) / _bars[i].dy;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-07-30 21:11:48 +00:00
|
|
|
// skip if not on module
|
2003-12-17 08:01:59 +00:00
|
|
|
if (xc >= xmin && xc <= xmax) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// target on a line so drop out
|
|
|
|
onLine = 3;
|
2003-09-27 11:02:58 +00:00
|
|
|
debug(5, "RouteFail due to target on a line %d %d", x, y);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
}
|
|
|
|
}
|
2003-12-17 08:01:59 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
return onLine;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE SETUP ROUTINES
|
|
|
|
|
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 Router::loadWalkData(byte *ob_walkdata) {
|
2003-09-20 15:34:53 +00:00
|
|
|
uint16 firstFrameOfDirection;
|
|
|
|
uint16 walkFrameNo;
|
2003-10-12 14:40:04 +00:00
|
|
|
uint32 frameCounter = 0; // starts at frame 0 of mega set
|
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
|
|
|
int i;
|
2003-10-01 10:00:35 +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
|
|
|
_walkData.read(ob_walkdata);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// 0 = not using slow out frames; non-zero = using that many frames
|
|
|
|
// for each leading leg for each direction
|
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
|
|
|
_numberOfSlowOutFrames = _walkData.usingSlowOutFrames;
|
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
|
|
|
for (i = 0; i < NO_DIRECTIONS; i++) {
|
|
|
|
firstFrameOfDirection = i * _walkData.nWalkFrames;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_modX[i] = 0;
|
|
|
|
_modY[i] = 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
|
|
|
for (walkFrameNo = firstFrameOfDirection; walkFrameNo < firstFrameOfDirection + _walkData.nWalkFrames / 2; walkFrameNo++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
// eg. _modX[0] is the sum of the x-step sizes for the
|
2003-09-20 15:34:53 +00:00
|
|
|
// first half of the walk cycle for direction 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
|
|
|
_modX[i] += _walkData.dx[walkFrameNo];
|
|
|
|
_modY[i] += _walkData.dy[walkFrameNo];
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_diagonalx = _modX[3];
|
|
|
|
_diagonaly = _modY[3];
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// interpret the walk 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
|
|
|
_framesPerStep = _walkData.nWalkFrames / 2;
|
|
|
|
_framesPerChar = _walkData.nWalkFrames * NO_DIRECTIONS;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// offset pointers added Oct 30 95 JPS
|
|
|
|
// mega id references removed 16sep96 by JEL
|
|
|
|
|
|
|
|
// WALK FRAMES
|
|
|
|
// start on frame 0
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
frameCounter += _framesPerChar;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// STAND FRAMES
|
2003-09-20 15:34:53 +00:00
|
|
|
// stand frames come after the walk frames
|
|
|
|
// one stand frame for each direction
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstStandFrame = frameCounter;
|
2003-09-20 15:34:53 +00:00
|
|
|
frameCounter += NO_DIRECTIONS;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// STANDING TURN FRAMES - OPTIONAL!
|
2003-09-20 15:34:53 +00:00
|
|
|
// standing turn-left frames come after the slow-out frames
|
|
|
|
// one for each direction
|
|
|
|
// standing turn-left frames come after the standing turn-right frames
|
|
|
|
// one for each direction
|
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 (_walkData.usingStandingTurnFrames) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstStandingTurnLeftFrame = frameCounter;
|
2003-09-20 15:34:53 +00:00
|
|
|
frameCounter += NO_DIRECTIONS;
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstStandingTurnRightFrame = frameCounter;
|
2003-09-20 15:34:53 +00:00
|
|
|
frameCounter += NO_DIRECTIONS;
|
|
|
|
} else {
|
|
|
|
// refer instead to the normal stand frames
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstStandingTurnLeftFrame = _firstStandFrame;
|
|
|
|
_firstStandingTurnRightFrame = _firstStandFrame;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// WALKING TURN FRAMES - OPTIONAL!
|
2003-09-20 15:34:53 +00:00
|
|
|
// walking left-turn frames come after the stand frames
|
|
|
|
// walking right-turn frames come after the walking left-turn frames
|
|
|
|
|
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 (_walkData.usingWalkingTurnFrames) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstWalkingTurnLeftFrame = frameCounter;
|
|
|
|
frameCounter += _framesPerChar;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstWalkingTurnRightFrame = frameCounter;
|
|
|
|
frameCounter += _framesPerChar;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstWalkingTurnLeftFrame = 0;
|
|
|
|
_firstWalkingTurnRightFrame = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// SLOW-IN FRAMES - OPTIONAL!
|
2003-09-20 15:34:53 +00:00
|
|
|
// slow-in frames come after the walking right-turn frames
|
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 (_walkData.usingSlowInFrames) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// Make note of frame number of first slow-in frame for each
|
|
|
|
// direction. There may be a different number of slow-in
|
|
|
|
// frames in each direction
|
|
|
|
|
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 (i = 0; i < NO_DIRECTIONS; i++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstSlowInFrame[i] = frameCounter;
|
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
|
|
|
frameCounter += _walkData.nSlowInFrames[i];
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// SLOW-OUT FRAMES - OPTIONAL!
|
2003-09-20 15:34:53 +00:00
|
|
|
// slow-out frames come after the slow-in frames
|
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 (_walkData.usingSlowOutFrames)
|
2003-10-12 14:40:04 +00:00
|
|
|
_firstSlowOutFrame = frameCounter;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// THE ROUTE EXTRACTOR
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
void Router::extractRoute() {
|
2003-09-20 15:34:53 +00:00
|
|
|
/*********************************************************************
|
2003-10-12 14:40:04 +00:00
|
|
|
* extractRoute gets route from the node data after a full scan, route
|
2003-09-20 15:34:53 +00:00
|
|
|
* is written with just the basic way points and direction options for
|
2005-07-30 21:11:48 +00:00
|
|
|
* heading to the next point.
|
2003-09-20 15:34:53 +00:00
|
|
|
*********************************************************************/
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
int32 prev;
|
|
|
|
int32 prevx;
|
|
|
|
int32 prevy;
|
|
|
|
int32 last;
|
|
|
|
int32 point;
|
|
|
|
int32 dirx;
|
|
|
|
int32 diry;
|
|
|
|
int32 dir;
|
|
|
|
int32 ldx;
|
|
|
|
int32 ldy;
|
2006-04-01 12:47:09 +00:00
|
|
|
int32 p;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2006-04-01 12:47:09 +00:00
|
|
|
// extract the route from the node data
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
prev = _nNodes;
|
2003-07-28 01:44:38 +00:00
|
|
|
last = prev;
|
|
|
|
point = O_ROUTE_SIZE - 1;
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[point].x = _node[last].x;
|
|
|
|
_route[point].y = _node[last].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
|
|
|
point--;
|
2003-10-12 14:40:04 +00:00
|
|
|
prev = _node[last].prev;
|
|
|
|
prevx = _node[prev].x;
|
|
|
|
prevy = _node[prev].y;
|
|
|
|
_route[point].x = prevx;
|
|
|
|
_route[point].y = prevy;
|
2003-07-28 01:44:38 +00:00
|
|
|
last = prev;
|
2003-09-20 15:34:53 +00:00
|
|
|
} while (prev > 0);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// now shuffle route down in the buffer
|
2003-10-12 14:40:04 +00:00
|
|
|
_routeLength = 0;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
do {
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[_routeLength].x = _route[point].x;
|
|
|
|
_route[_routeLength].y = _route[point].y;
|
2003-09-20 15:34:53 +00:00
|
|
|
point++;
|
2003-10-12 14:40:04 +00:00
|
|
|
_routeLength++;
|
2003-09-20 15:34:53 +00:00
|
|
|
} while (point < O_ROUTE_SIZE);
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_routeLength--;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// okay the route exists as a series point now put in some directions
|
2006-04-01 12:47:09 +00:00
|
|
|
for (p = 0; p < _routeLength; ++p) {
|
2003-10-12 14:40:04 +00:00
|
|
|
ldx = _route[p + 1].x - _route[p].x;
|
|
|
|
ldy = _route[p + 1].y - _route[p].y;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirx = 1;
|
|
|
|
diry = 1;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (ldx < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldx = -ldx;
|
2003-07-28 01:44:38 +00:00
|
|
|
dirx = -1;
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
if (ldy < 0) {
|
2003-07-28 12:24:13 +00:00
|
|
|
ldy = -ldy;
|
2003-07-28 01:44:38 +00:00
|
|
|
diry = -1;
|
|
|
|
}
|
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_diagonaly * ldx > _diagonalx * ldy) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// dir = 1,2 or 2,3 or 5,6 or 6,7
|
|
|
|
|
|
|
|
// 2 or 6
|
|
|
|
dir = 4 - 2 * dirx;
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirS = dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// 1, 3, 5 or 7
|
|
|
|
dir = dir + diry * dirx;
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirD = dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
} else {
|
|
|
|
// dir = 7,0 or 0,1 or 3,4 or 4,5
|
|
|
|
|
|
|
|
// 0 or 4
|
|
|
|
dir = 2 + 2 * diry;
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirS = dir;
|
2003-09-20 15:34:53 +00:00
|
|
|
|
|
|
|
// 2 or 6
|
|
|
|
dir = 4 - 2 * dirx;
|
|
|
|
|
|
|
|
// 1, 3, 5 or 7
|
|
|
|
dir = dir + diry * dirx;
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirD = dir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2006-04-01 12:47:09 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// set the last dir to continue previous route unless specified
|
2006-04-01 12:47:09 +00:00
|
|
|
if (_targetDir == NO_DIRECTIONS) {
|
2003-09-20 15:34:53 +00:00
|
|
|
// ANY direction
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirS = _route[p - 1].dirS;
|
|
|
|
_route[p].dirD = _route[p - 1].dirD;
|
2005-07-30 21:11:48 +00:00
|
|
|
} else {
|
2003-10-12 14:40:04 +00:00
|
|
|
_route[p].dirS = _targetDir;
|
|
|
|
_route[p].dirD = _targetDir;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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 Router::setUpWalkGrid(byte *ob_mega, int32 x, int32 y, int32 dir) {
|
|
|
|
ObjectMega obMega(ob_mega);
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// get walk grid file + extra grid into 'bars' & 'node' arrays
|
2003-10-12 14:40:04 +00:00
|
|
|
loadWalkGrid();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// copy the mega structure into the local variables for use in all
|
|
|
|
// subroutines
|
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
|
|
|
_startX = obMega.getFeetX();
|
|
|
|
_startY = obMega.getFeetY();
|
|
|
|
_startDir = obMega.getCurDir();
|
2003-10-12 14:40:04 +00:00
|
|
|
_targetX = x;
|
|
|
|
_targetY = y;
|
|
|
|
_targetDir = dir;
|
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
|
|
|
_scaleA = obMega.getScaleA();
|
|
|
|
_scaleB = obMega.getScaleB();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// mega's current position goes into first node
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
_node[0].x = _startX;
|
|
|
|
_node[0].y = _startY;
|
|
|
|
_node[0].level = 1;
|
|
|
|
_node[0].prev = 0;
|
|
|
|
_node[0].dist = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// reset other nodes
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (int i = 1; i < _nNodes; i++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
_node[i].level = 0;
|
|
|
|
_node[i].prev = 0;
|
|
|
|
_node[i].dist = 9999;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// target position goes into final node
|
2003-12-17 08:01:59 +00:00
|
|
|
_node[_nNodes].x = _targetX;
|
|
|
|
_node[_nNodes].y = _targetY;
|
|
|
|
_node[_nNodes].level = 0;
|
|
|
|
_node[_nNodes].prev = 0;
|
|
|
|
_node[_nNodes].dist = 9999;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::plotWalkGrid() {
|
2003-10-12 14:40:04 +00:00
|
|
|
int32 i;
|
2003-10-01 10:00:35 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// get walk grid file + extra grid into 'bars' & 'node' arrays
|
2003-10-12 14:40:04 +00:00
|
|
|
loadWalkGrid();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// lines
|
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
for (i = 0; i < _nBars; i++)
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_screen->drawLine(_bars[i].x1, _bars[i].y1, _bars[i].x2, _bars[i].y2, 254);
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-07-28 01:44:38 +00:00
|
|
|
// nodes
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// leave node 0 for start node
|
2003-12-17 08:01:59 +00:00
|
|
|
for (i = 1; i < _nNodes; i++)
|
2003-10-12 14:40:04 +00:00
|
|
|
plotCross(_node[i].x, _node[i].y, 184);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
void Router::plotCross(int16 x, int16 y, uint8 colour) {
|
2005-02-19 14:02:16 +00:00
|
|
|
_vm->_screen->drawLine(x - 1, y - 1, x + 1, y + 1, colour);
|
2005-07-30 21:11:48 +00:00
|
|
|
_vm->_screen->drawLine(x + 1, y - 1, x - 1, y + 1, colour);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::loadWalkGrid() {
|
2003-12-28 15:08:12 +00:00
|
|
|
WalkGridHeader floorHeader;
|
2004-04-23 07:02:11 +00:00
|
|
|
byte *fPolygrid;
|
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
|
|
|
uint16 fPolygridLen;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-17 08:01:59 +00:00
|
|
|
_nBars = 0; // reset counts
|
|
|
|
_nNodes = 1; // leave node 0 for start-node
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// STATIC GRIDS (added/removed by object logics)
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// go through walkgrid list
|
2003-10-12 14:40:04 +00:00
|
|
|
for (int i = 0; i < MAX_WALKGRIDS; i++) {
|
|
|
|
if (_walkGridList[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
|
|
|
int j;
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// open walk grid file
|
2003-11-16 14:18:29 +00:00
|
|
|
fPolygrid = _vm->_resman->openResource(_walkGridList[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
|
|
|
fPolygridLen = _vm->_resman->fetchLen(_walkGridList[i]);
|
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
|
|
|
Common::MemoryReadStream readS(fPolygrid, fPolygridLen);
|
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
|
|
|
readS.seek(ResHeader::size());
|
|
|
|
|
|
|
|
floorHeader.numBars = readS.readSint32LE();
|
|
|
|
floorHeader.numNodes = readS.readSint32LE();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// check that we're not going to exceed the max
|
|
|
|
// allowed in the complete walkgrid arrays
|
|
|
|
|
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(_nBars + floorHeader.numBars < O_GRID_SIZE);
|
|
|
|
assert(_nNodes + floorHeader.numNodes < O_GRID_SIZE);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// lines
|
|
|
|
|
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 (j = 0; j < floorHeader.numBars; j++) {
|
|
|
|
_bars[_nBars + j].x1 = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].y1 = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].x2 = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].y2 = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].xmin = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].ymin = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].xmax = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].ymax = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].dx = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].dy = readS.readSint16LE();
|
|
|
|
_bars[_nBars + j].co = readS.readSint32LE();
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// nodes
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// leave node 0 for start node
|
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 (j = 0; j < floorHeader.numNodes; j++) {
|
|
|
|
_node[_nNodes + j].x = readS.readSint16LE();
|
|
|
|
_node[_nNodes + j].y = readS.readSint16LE();
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// close walk grid file
|
2003-11-16 14:18:29 +00:00
|
|
|
_vm->_resman->closeResource(_walkGridList[i]);
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 15:34:53 +00:00
|
|
|
// increment counts of total bars & nodes in whole
|
|
|
|
// walkgrid
|
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
|
|
|
_nBars += floorHeader.numBars;
|
|
|
|
_nNodes += floorHeader.numNodes;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-05-02 05:41:01 +00:00
|
|
|
void Router::clearWalkGridList() {
|
2004-01-05 11:09:33 +00:00
|
|
|
memset(_walkGridList, 0, sizeof(_walkGridList));
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-18 08:11:50 +00:00
|
|
|
// called from fnAddWalkGrid
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
void Router::addWalkGrid(int32 gridResource) {
|
2003-12-20 01:17:02 +00:00
|
|
|
int i;
|
2003-10-12 14:40:04 +00:00
|
|
|
// First, scan the list to see if this grid is already included
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-12-20 01:17:02 +00:00
|
|
|
for (i = 0; i < MAX_WALKGRIDS; i++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_walkGridList[i] == gridResource)
|
|
|
|
return;
|
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
// Scan the list for a free slot
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-20 01:17:02 +00:00
|
|
|
for (i = 0; i < MAX_WALKGRIDS; i++) {
|
2003-10-12 14:40:04 +00:00
|
|
|
if (_walkGridList[i] == 0) {
|
|
|
|
_walkGridList[i] = gridResource;
|
|
|
|
return;
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-12 14:40:04 +00:00
|
|
|
|
2004-01-05 11:09:33 +00:00
|
|
|
error("_walkGridList[] full");
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-18 08:11:50 +00:00
|
|
|
// called from fnRemoveWalkGrid
|
2003-09-20 15:34:53 +00:00
|
|
|
|
2003-10-12 14:40:04 +00:00
|
|
|
void Router::removeWalkGrid(int32 gridResource) {
|
|
|
|
for (int i = 0; i < MAX_WALKGRIDS; i++) {
|
|
|
|
if (_walkGridList[i] == gridResource) {
|
|
|
|
// If we've found it in the list, reset entry to zero.
|
|
|
|
// Otherwise just ignore the request.
|
|
|
|
_walkGridList[i] = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-04 00:52:27 +00:00
|
|
|
|
|
|
|
} // End of namespace Sword2
|