Location ID numbersEdit

These can be derived either from the textures (TIX files on cd) or from the memory by inspecting the current_location variables.

Location ID Location name Japanese
00 Bright Moon Cottage 明月荘
01 Pit & Temple 寺院
02 Kyoto 京都
03 The Natural World 自然界
04 Happy Town HAPPY TOWN
05 Violence District バイオレンス街
06 Moonlight Tower 月光の塔
07 Temple Dojo 寺道場
08 Flesh Tunnels 有機廊下
09 Clockwork Machines ???
10 Long Hallway 長い廊下
11 Sun Faces Heave 太陽はヒーブ直面
12 Black Space ブラックスペース
13 Monument Park 記念碑公園

File StructureEdit


The root of the disc contains a folder called CDI where all of the game data is stored. jPSXdec can open the CD image file, and another tool that can open .TIM and .TIX files is PSicture 1.01 on Windows 8.1 (64 bit). The .TIX format is unrecognized by PSicture, but the files can still be accessed if the file is scanned.

CARD The bulk of the user interface assets in TIM format
ETC Non-dream videos, fonts and images.


FILM Dream videos and any "EVENT" videos triggered by interacting with the world such as the ferris wheel or the gear room
IMG1,IMG2 The pages of Kanji sometimes seen instead of a dream
SPDAY01C 0000


SND Sounds
STGxx A list of folders called STGxx, where xx is the Location ID. STG is likely a shortening of STAGE, as each STG folder appears to contain data for a specific room or area.

Also, the game has a ZDUMMY folder with a ZDUMMY.STR. This was created so that the game data was close to the center of the disc, making loading quicker.


The image that appears if you play ZDUMMY.STR

TIX FilesEdit

There are four .TIX files for each location containing the four different texture themes. The textures stored within these files are in the .TIM format.

File name Texture theme

SEQ FilesEdit

Each STGxx folder has five BGx.SEQ files, ranging from A to E (BGA.SEQ to BGE.SEQ). The SEQ files contain sequenced music (the PSX MIDI equivalent) which can be used together with the VB (sample) and VH (header) files in /CDI/SND/ to compile the tracks. seq2mid can convert the SEQ files into MID files. pSound can extract the VB file content. The mixes can be compiled to PSF using vgmtoolbox which can then be played using Winamp with the in_psf plugin or using foobar with the foo_psf plugin.

These files always begin with a "magic number" of "pQES" followed by "1" as a big-endian value. While the PS1 was little-endian as far as this dreamer knows, the dream journal mentions using a Macintosh, which was big-endian, and the tools used to create these scripts were likely on a Mac as a result. 1 could refer to a version number. Note that pQES is SEQp which backs this up.

VB/VH Files Edit

.VB contains a bank of sounds, always accompanied by a .VH header to describe what's inside. They are used for the in-game soundtrack's instrument sets (AMBIENT, CARTOON, etc.) and sound effects (SE). Awave Studio/VABTool can be used to open these files and access the individual .VAG sound effects inside each bank. Here's a key, as it's not immediately obvious at the default sample rate which VAG corresponds to which sounds in-game, and there is frequent reuse of sound effects for different purposes (ex. the astronaut and Happy Town trumpeters). Square brackets denote an unconfirmed or unknown sound.


01 [Jangling]
02 [Opera Singer?]
03 [Jiggling]
04 Grass, Sand, H.T. Footstep
05 Train
06 Astronaut, Trumpeters
07 H.T. Squeak Footstep, Pterodactyl, Kissing Lips
08 Flowing Water (Natural World)
09 [Unknown]
10 Link
11 H.T. Wood Footstep
12 Deep Rumbling
13 V.D. Dock Footstep
14 Wooden Bridge Footstep
15 [Tengu?]
16 Drumming (Kyoto)
17 H.T. Wet Footstep
18 [Tengu?]
19 BMC Wood Floor
20 [Clockwork Machine?]
21 Snarl (Lions, Dojo Dog)
22 Wings Flapping (Pterodactyl)
23 [Unknown]
24 Fetus Noise, Rocket Ship
25 Breathing (Sleeper in BMC)
26 [Squeak?]
27 [Long Hallway End?]
28 Horses Galloping (Natural World)
29 [UFO?]
30 Kyoto Grass Footstep

Generic Footstep (Tunnels, V.D., BMC Tile, NW Rock)

32 Water Footstep (NW River, Flesh Tunnel Slosh)

LBD FilesEdit

The .LBD files contain most of the models in the game. The models contained within these files are in .TMD format. They can be extracted with jPSXdec (uncheck raw) and further extracted with PSXMultiRip. Milkshape3D can import .TMD models which can be exported for editing in other modeling programs. LBD could also refer to Level Build Data.

In larger environments, these files are split into subfolders called Nx, which in the Natural World, for instance, span all the way from 1-9. The reasoning behind this is unclear, but perhaps it was just to keep the folder structure tidier. Maybe there were file system limitations or the map was split between developers.

Memory analysisEdit

One way to understand the underlying game mechanics is to perform memory analysis on an emulator running the game. Once the analyst know about a variable, the variable itself can be monitored for studies. A variable can be modified directly by changing the memory of the emulator process. The game behavior can also be modified if the instructions are changed.

How to analyse the memoryEdit

Cheat engine is a program made for game memory modification. LSD: Dream Emulator running on the emulator pSXfin v1.13 was tested and worked well together with Cheat engine. There is rar file containing a version of Cheat engine without (the potentially unwanted) OpenCandy on their official website download page. Be sure to read the guides available for free on various websites and to try Cheat engine with their demo tool before analyzing the game. Be sure to specify the memory region to scan from the address psxfin.exe+171A5C (2 MB game memory) and 0x200000 steps ahead instead of the entire emulator process memory (around 30 MB).

Step-by-step guideEdit

Before starting Cheat engine, start the emulator application, load the CD image and start a new dream. Once you have run the Cheat engine main application, open the Process List window and select the emulator process.

Locating a days variable


Day 110

In this example, we will modify the number of days that has passed in the game. This game screen show us that we are on day 110. The game stores this as current_day = 109 with two different 4 Byte variables. Enter 110 - 1 = 109 as Value and press First Scan. Some variables that contains the value 109 will appear in the window to the left. Some of these are unrelated but simply happen to contain the value 109.

Play through a dream and the day will change - along with the dependant variables. Now enter the next current day Value 111 - 1 = 110 in Cheat engine and press Next Scan. This will filter out all variables that are not equal to 110. This is a good thing as they are unrelated.


Two variables found

A finished scan should have two variables that are dependent as we already knew that there were exactly two variables that contains days - 1. These can now be monitored or modified. Try entering Flashback mode. The variables will change indicating which day the Flashback is from. Once your Flashback dream is over, try changing both variables to a high value (more than 365). This has been speculated to trigger more frequent The Gray Man visits.

Memory structureEdit

There are some variables that control textures and some that are affected by The Gray Man if you get too close to him but those are complicated to map. Huge parts of the memory are modified when bouncing into something, linking and with The Gray Man encounters.

Known variablesEdit

The offsets are measured from the beginning of the game memory. The variables are reached by adding the value found at psxfin.exe+171A5C. In Cheat engine, this is done by referring to psxfin.exe+171A5C as a pointer with the specified offset.


There are two 4-byte integers that both contain day-1. These can be modified.
SLPS 015.56 07122013 031053 0550

Skipped to day 999

Variable Speculated: current_day
Type 4 Bytes
Offset 916B0 & 8AC74 (2 copies)


You can get and set the amount of time you have spent on a location with this variable. It is stored close to the current_day variable, suggesting that they are used for seeding randomness or that they are key variables. Some memory locations nearby fluctuates a lot. This might suggest that the location is used for randomness. Modifying this does not influence gameplay directly.

Repeatedly setting location_time and game_time to 0 before and during linking is known to have caused a glitch similar to the glitch texture.

SLPS 015.56 09022014 081931 0458

Map corrupted by setting timers to 0

Variable Speculated: location_time Speculated: game_time
Type 4 Bytes 4 Bytes
Offset 8AC70 90b74


Each location has a unique ID which is the same one as files are indexed (including texture files). It is possible that setting the values to 4 (Happy Town) would trigger more The Gray Man visits and setting them to 0 (Bright Moon Cottage) would disable them. They are numbered by the order they change when linking. They keep the same value once linking is done. The value equals one of the location ID numbers. Invariant: 0 ≤ current_location ≤ 13. Changing them during a half-complete linking will corrupt maps and sometimes freeze the game. Changing just 8ABF8 will load just that map's object behaviors, producing strange results.

There is also a starting position variable that can be used to determine where on the location you will start. The value will change when walking the stairs in the Bright Moon Cottage where the four bytes tell you in which direction you walked and which floor (third byte) you are currently on. When exiting a tunnel, this value follows another pattern. If you save one of the correct pos_start values and enter them after linking, you will likely start at that position. It may also give you a strange starting positon.

SLPS 015.56 07122013 005528 0044

Map corrupted by garbling the location variables

Variable Speculated: current_location Speculated: pos_start
Type 4 Bytes 4 Bytes
Offset 91694, 8AC6C & 8ABF8 (3 copies) 9169c


The x, y and z values are stored separately as signed integers. Modifying them teleports the player. There are some copies which are kept in sync with the main variables.
SLPS 015.56 07122013 023024 0271

Teleported to below the bridge

Variable Speculated: x Speculated: y Speculated: z
Type 4 Bytes signed 4 Bytes signed 4 Bytes signed

Main: 91e74

Copies: 91e94 (display),

91dd8 & 91df8

Main: 91e7c

Copies: 91e9c (display), 

91de0 & 91e00

Main: 91e78

Copies: 91e98 (display),

91ddc & 91dfc


These variables are used when the chart is drawn on the screen. chart_draw_x and chart_draw_y are identical 4-byte versions of the mixed 4-byte copy containing chart_return_x and chart_return_y. This suggests that the latter two are taken from a return value. These variables are dynamic and have other meanings in other contexts.

The values are can be calculated as chart_draw_x = steps to the left(-) or the right(+) from the nose * 10 - 5. If we are 2 steps to the left, this gives us chart_draw_x = -25.

Variable Speculated: chart_draw_x Speculated: chart_draw_y Speculated: chart_return_x Speculated: chart_return_y
Type 4 Bytes signed 4 Bytes signed 2 Bytes signed 2 Bytes signed
Offset 94008 9400c 94014 94016


There is an event counter. This increases by one when linking and seems to increase when the player triggers events. This can be used to detect if something happens. There is also a variable that might hold the return value of the finished event. The final two bytes (offsets 91674 and 91675) holds the signed values added to the event_x and event_y respectively. This can be used to decide how the event affected the chart x and y values. x = event_x / events_triggered and y = event_y / events_triggered gives a rough approximation of the final chart x and y values.

Variable Speculated: events_triggered Speculated: event_return Speculated: animations_triggered
Type 4 Bytes 4 Bytes 4 Bytes
Offset 91680 91674 91690
Variable Speculated: event_x Speculated: event_y
Type 4 Bytes signed 4 Bytes signed
Offset 91678 9167c

Future memory analysisEdit


The texture filenames are stored as text strings. There seems to be pointers to them. They might explain how textures are swapped. Another possibility is that the text strings are only stored by the emulator software.


There are many different music tracks to distinguish from one another. Tracks are level specific. The track number and theme could be identified by comparing the in-game level music with extracted music tracks. Each level and theme identifies a track. The tracks can be identified using combinations such as AMBIENT_STG00_BGA.

Chart MechanicsEdit

The graph changes when the user first modifies the days variables and then enters the graph screen, suggesting that the positions are stored in arrays. Some unknown variables could also be correlated with the x and y positions on the graph screen you see after each dream. The linking screen colors might be correlated to the positions. One problem is that it is unknown how, not just where, those potential variables are stored. They could also be based on calculations with lots of data. It is also hard to know where zero is on the graph and how that should be interpreted.


Objects such as Greyman are dynamically allocated, which makes it difficult to find them. Using saved states, one might go back and forth within the same dream while the object remains at the same place in memory. It is not known how objects are pointed to (pointers) in the memory. The Grayman object, for example, contains its positon and flags to make him fly forward or disable the linking.