Some treadmill glitch video (where it seems like repeated sideways position shifting of the character while technically one is staying in place appears to still affect the game and where it might think is the character's relative position to the room, to eventually trigger a stage exit):
https://www.youtube.com/watch?v=qZ-Kl6CTbzc
A video of some audio glitch:
https://www.youtube.com/watch?v=gKbPwZgDkdw
Here is a text file with a list of reference points that I made for comparison purposes, from the current Super Turrican TAS:
https://cdn.discordapp.com/attachments/396448200447361024/707810296810569808/current_Super_Turrican_TAS_reference_point_timestamps.txt
Here is some experimentation movie files that I made a while ago when I was doing some tests (and very short input files for the first part of first attempts at the first stage) in case anything may be useful:
https://cdn.discordapp.com/attachments/396448200447361024/707811597556514936/Super_Turrican_lsnes_experimentation_movie_files.zip
And here is a little program that total/Tewtal made for converting Bizhawk movie files into lsnes movie files and vice versa (though I cannot guarantee that it will generally work flawlessly):
https://cdn.discordapp.com/attachments/396448200447361024/707810833756848148/TASConverter.exe
- - - - -
I have done very little testing for this game, and to my knowledge, the ''full-screen attack'' can be used to shake the environment (including platforms that spawn when they are shot), which can make the difference between barely landing on (the corner of) a platform or missing it, but since it seems to be a rather powerful attack, it may be more useful for damaging purposes rather than helping for stage traversal. But besides that, here is some stage tilemap content (regarding which memory address determines the look and behavior of what tile in a given stage) that may help (although it does not contain information about the locations of initially invisible platforms that can be shot so that they appear):
Dan made an adaptive lua script for SNES9X 1.51 rr (rerecording) which can be changed to work for various games (such as Super Ghouls'n Ghosts, Spanky's Quest, Alien 3, Sutte Hakkun, Plok, Hagane, Krusty's Super Fun House, for which I have found the corresponding memory address ranges) including Super Turrican:
https://cdn.discordapp.com/attachments/396448200447361024/706544105047588864/snes9x-loop-over-memory-region_mapper_Super_Turrican.lua
To use it one just adds the lua script while playing, and once running it for a given moment, it will output the room's (or stage's) tilemap data for the way it is set up in the frame (and from there one can copy that over into e.g. a txt file). Note that tilemap data changes that occur to a room at different frames may be possible; sometimes just due to straight forward direct changes that one may have caused to it, but sometimes possibly more obscure and/or larger changes due to room/stage events.
Quick explanation on how to adapt it:
Right at the top of it (if one opens it in notepad++) one will find the following variables:
local ADDR_FIRST = 0x7E6360;
local ADDR_FINISH = 0x7EA81F;
local ADDR_INCREMENT = 2;
local ADDR_ENDLINE = 0xC8;
The ''local ADDR_FIRST'' variable refers to the first (smallest) memory address at which the lua script will start to output values of memory addresses from which follow after it (including the memory address that one chooses for it to start with, by setting the ''local ADDR_FIRST'' to it).
The ''local ADDR_FINISH'' variable refers to the last (largest) memory address from which the lua script will pull the value from that is carried by it and will output it into the console.
The ''local ADDR_INCREMENT'' variable refers to the step size in which the lua script should go to pick or check memory addresses after the initial one in order to paste their value into the lua script console (and this step size typically is 1 or 2, though I think it was 4 for Super Ghouls'n Ghosts, for different games and depending on if 1 byte or 2 bytes are used for determining a tile's behavior).
Finally, the ''local ADDR_ENDLINE'' tells the lua script (in hex values) how many outputs it should paste in 1 line/row, or when to start the next row, and this typically would correspond to the width of the room in terms of the number of tiles are used per row.
The memory addresses carry information like tile behavior and graphics of tiles, but in some games there can be different completely separate memory address ranges for carrying the values that determine the tile graphics and the tile behavior, and (if they exist) for moving layers there can be another separate memory address range that can carry the corresponding graphics data for that aswell sometimes (like in Alien 3).
Changing memory address values via memory cheats for a room (or stage) for memory addresses in a range of memory addresses that one suspects of carrying the relevant tile behavior determining data (if one's searching for that) can help finding suitable memory addresses for that matter.
There's surely other and better ways to find these memory addresses or to make more out of it in terms of visualizing the outputs (possibly in real time with a lua script during gameplay), but that is one way I know of.
Typically the memory address value for air or empty tiles that one can move through is 00 (it has been so consistently for many games that I checked out).
Typically the tilemap data is structured in such a way that some memory address (which can be in 1 byte or 2 bytes form, depending on the game) holds the value that's relevant for the behavior of the top left tile in a stage or room, and then the following addresses (either with unrelated memory addresses inbetween or without gaps) will hold the data for all tiles to its right in the same tile row, until at some point the tile row ends and the next memory address holds the data for the left most tile 1 row beneath the top left corner's tile, and so on, tile row by tile row downwards (and one may sometimes even want to check what previous memory addresses would hold in terms of tilemap data for the case that there is tiles above the highest point of a room, and the same for memory addresses that may follow after all the memory addresses have been gone through that are meant to carry tilemap data, since they may carry data for tiles beneath a room or stage) and for each tile row the order goes from the left to the right with increasing memory addresses.
Typically the origin of the coordinate system used for the tile grid is in the top left corner, with increasing y-axis values the further one moves downwards, and increasing x-axis values the further one moves to the right.
Another relevant parameter is the size of tiles which is typically 16 by 16 pixels or 8 by 8 pixels (like e.g. in Hagane and Super Ghouls'n Ghosts), and figuring out which it is can help finding where the game holds the tilemap data.
Sometimes though (like in Super Ghouls'n Ghosts), the tilemap data is structured differently, namely by still assigning memory addresses to tiles, starting at the top left and going to the right and row by row downwards (just how text in books typically is organized), except ending the rows before the stage ends, and then continuing with the next screen part to the right in the same manner but with memory addresses that are further down in the list of memory addresses.
The tile graphics are typically carried in an analogous structure/manner, and it can happen that if one changes the value of a memory address (that holds tilemap data) using cheats, one may not see any change happening for any tile while one's playing in a given room or stage until one moves the screen away and back to the tile that may be affected by this change, if the tile was on screen initially. But it can also be the case that one will not get any visual feedback at all when one changes the tilemap data with cheats (especially when the graphics for tiles are held elsewhere), so that one may have to blindly run around a room or stage until one stumbles over a block that e.g. wasn't solid before and is now solid or was solid before and now one can go past it or fall through it.
- - -
Here's a ZIP file that shows the tilemaps of the individual stages in their initial states (except for the stages 3, 11 which is the autoscroller stage and probably is handled separately, 12 which seems to have two separate tilemap width used, 13):
https://cdn.discordapp.com/attachments/396448200447361024/706568768054362153/Super_Turrican_Stage_Tilemaps_except_stages_3_11_12_13.zip
Some of them are also given in form of an Excel file though (since the stages were too wide to be properly displayed in a txt file).
I guess with some more finesse one could use that information to make hitbox viewer lua scripts aswell (which would make viewing the output more easily rather than having all the digits provided).
The values beneath in brackets refer to the difference of any vertically neighboured memory addresses (for example, 7E6427 +C8 = 7E64EF in hex).
Stage 1:
The stage loops once every exactly 12 + 1/2 screens. The rows don't extend past the level boundaries so that the memory address that comes after the memory address for a tile at the far right boundary determines the leftmost tile in the next row (which generally for other games doesn't always have to hold as tile rows can continue further into off-screen areas).
-------------------------
|7E6360 ... 7E6427|
|7E6428 ... 7E64EF| (+C8)
| ........ ......... ........ | (...)
|7EA758 ... 7EA81F|
-------------------------
- - -
Stage 2:
-------------------------
|7E6360 ... 7E63E3|
|7E63E4 ... 7E6467| (+84)
| ........ ......... ........ |
|7E966B ... 7E96EF|
-------------------------
- - -
Stage 3: (Unknown, but for most cases the memory address 7E6360 seems to be the starting place.)
In this stage apparently, memory addresses 7E65E0 and 7E65E1 change the appearance of all tiles with a given tile graphic (at every spot in which that is used), depending on their value. And memory address 7E605E changes multiple tiles in some pattern aswell.
- - -
Stage 4:
-------------------------
|7E6360 ... 7E63D7|
|7E63D8 ... 7E64FF| (+78)
| ........ ......... ........ | (...)
|7E7A58 ... 7E7BCF|
-------------------------
Apparently, the same tile values can cause differently looking tiles in different stages.
- - -
Stage 5:
-------------------------
|7E6360 ... 7E63C4|
|7E63C5 ... 7E6429| (+65)
| ........ ......... ........ | (...)
|7E83BA ... 7E841E|
-------------------------
- - -
Stage 6:
-------------------------
|7E6360 ... 7E63A5|
|7E63A6 ... 7E63EB| (+46)
| ........ ......... ........ | (...)
|7E8C64 ... 7E8CA9|
--------------------------
- - -
Stage 7:
-------------------------
|7E6360 ... 7E64D4|
|7E64D5 ... 7E6649| (+175)
| ........ ......... ........ | (...)
|7E793B ... 7E7AAF|
-------------------------
- - -
Stage 8:
-------------------------
|7E6360 ... 7E6503|
|7E6504 ... 7E66A7| (+1A4)
| ........ ......... ........ | (...)
|7E9150 ... 7E92F3|
-------------------------
- - -
Stage 9:
------------------------
|7E6360 ... 7E63F5|
|7E63F6 ... 7E648B| (+96)
| ........ ......... ........ | (...)
|7E8CFA ... 7E8D8F|
-------------------------
- - -
Stage 10:
------------------------
|7E6360 ... 7E6413|
|7E6414 ... 7E64C7| (+B4)
| ........ ......... ........ | (...)
|7E87F0 ... 7E88A3|
------------------------
- - -
Stage 11: (Unknown for this autoscroller stage.)
- - -
Stage 12:
For this stage I suspected that it would look as follows, but at some points the memory addresses and tile positions didn't seem to match up anymore.
-------------------------
|7E6360 ... 7E63C2|
|7E63C3 ... 7E6425| (+63)
| ......... ........ ........ | (...)
| ? ..................... ? |
------------------------
- - -
Stage 13: (Unknown.)
- - - - -
That should be essentially everything I have for this game up to this point. Good luck.
