Castlevania: Resurrection Dreamcast
To read on a PC:
A lot of the game appears scriptable in plain text, including AI. Entities are also composed in a component style model in plain text, and adding new ones seems easy enough. Levels are entirely described in plain text, including entity placement and lighting data. Level geometry is in binary, however, and is referenced in these level scripts. In fact, everything seems to be oriented around the concept of a 'level', very much like how a scene works in Unity and such. Overall, it's a super modern impression that I got from this well over 20 year old prototype! Some examples
Item definitions:
Animation sets:
Entity investments:
Coded:
ITEM_DEF
UNK_ECandle_tallstand_candle
tallstand_candle
NULL
NULL
1
0 0 0 0
NULL
ITEM_DEF
ECandle_s2_01_Lght_item_glow01
tallstand_candle_glow
NULL
tallstand_candle_glow
1
1 0 0 0
s2_01_Lght_item_01
Coded:
ANIMSET_DEF
E06_GhostCardinalAnimSet
5
E06_GhstCardinal_Death
E06_GhstCardinal_Get_Hit
E06_GhstCardinal_Move
E06_GhstCardinal_Shield
E06_GhstCardinal_Strike
ANIMSET_DEF
E02_GhostAnimSet
2
E02_Ghost_Die_Blue
E02_Ghost_Float_Blue
Coded:
ENTITY_DEF
RigidModel
s2_01
0
2
0
-2174.27
-2167.98
3.0305
0
0
0
ENTITY_DEF
Actor
Sonia
0
3
0
-3094
-1445.29
68
0
0
90
ENTITY_DEF
Emitter
Ghost_Cardinal_Dist500_Max1
0
4
1
-1692.35
-2385.17
21,646
0
0
-135
AI script
Coded:
AI_DEF
Attack_FarRangeCorkscrew
TurnTowardTarget 0.0
FlyForwardUpLeft 50.0
FlyLeft 50.0
FlyForwardDownLeft 50.0
FlyDown 50.0
FlyForwardDownRight 50.0
FlyRight 50.0
FlyForwardUpRight 50.0
FlyUp 50.0
TurnTowardTarget 0.0
FlyTowardTarget 0.0
FlyForward 75.0
FlyUp 50.0
AI_ENDDEF
AI_DEF
Attack_FarRangeSawtooth
TurnTowardTarget 0.0
FlyForward 75.0
FlyUp 75.0
FlyForward 75.0
FlyDown 75.0
FlyForward 75.0
FlyUp 75.0
FlyForward 75.0
FlyDown 75.0
FlyForward 75.0
AI_ENDDEF
AI_DEF
Spawn_MedusaHeadRise
FlyUp 75.0
TurnTowardTarget 0.0
Death2 0.0
TurnTowardTarget 0.0
TurnRight 22.5
TurnLeft 45.0
TurnRight 45.0
TurnLeft 45.0
TurnRight 45.0
TurnLeft 45.0
TurnRight 45.0
TurnLeft 45.0
TurnRight 45.0
TurnLeft 22.5
Taunt 0.0
FlyDown 25.0
AI_ENDDEF
AI_DEF
Dying_DefaultRotInHell
Death1 0.0
Wait 5.0
AI_ENDDEF
Note that the entity placements reference level geometry with the RigidModel tag.
The AI script reminded me the original Quake, where AI routines were built up on small, generic atomic actions, but in form it reminded me more of Half Life, which regimented the Quake style into a more data-oriented style. See here for a comparison! It's not really surprising though, the game programmer world is pretty small. As an aside, if you've ever read DeLoura's book you've probably noticed the castlevania team really took it to heart!
Another fun curiosity is this script file for a font tool they were using, which was left on disk:
Coded:
/ * Font database. * /
/ * setdir: set the path for font textures for subsequent fonts * /
DIRSYS #basepath, (# subpath1, # subpath2, ...) - set path from dirpaths.txt * /
/ * DIRPATH #fullPath - set path directly; path must be a string (ie enclosed in double quotes, with '\' at end) * /
/ * type: 0 - fixed width, 1 - proportional * /
fontname Heading_White
type 1
asciirange 32 126
texturesize 256
numtextures 1
celldimension 21 17
texturefiles heading_white.pvr
sp 8
. 5
0 12
1 10
2 12
3 12
4 13
5 13
6 12
7 12
8 12
9 12
A 16
B 15
C 15
D 15
E 13
F 12
G 16
H 14
I 5
D 12
K 15
L 13
M 17
No. 14
O 16
P 13
Q 17
R 15
S 14
T 13
U 14
V 16
W 21
X 15
Y 14
Z 14
at 14
b 13
c 13
d 13
e 12
f 11
g 14
h 12
i 6
j 10
k 13
l 11
m 14
n 12
o 14
p 12
q 15
r 13
s 12
t 12
u 12
v 14
w 19
x 13
y 13
z 12
end
The actual file is quite a bit larger, but all follows this same format.
It's likely that all these files would have been converted into some binary form for production, but imagine how cool it would have been if the game had shipped with this system intact? we could have a very modifiable castlevania!
Moving on, there are no major surprises on disk from what I can tell. The other character is not present in any form, and some of the creatures seen in other screenshots are not here either. No extra levels seem to be left on disk either. It's unfortunate, but then again, we're very fortunate to have just this release as is! There are some neat trivia about the assets though:
All textures are 16 bit, encoded in either ARGB1555, ARGB4444 or RGB565 format. Larger textures use the VQ encoding, while smaller ones are just morton coded. None use the bump map format, though there are two textures, 'b_brick_01_bump' and 'b_brick_01_bump' which appear to be meant to be, and may possibly be used, as bump maps. Sonia is a single 512x512 texture, as well as Medusa and the Evil Cleric characters. Lesser ones are 256x256. Environmental textures run the gamut. Animated effects like the candle flames have each frame of animation stored in separate images, which are then referenced in a binary file that appears to describe the animation. The script dumps these into png format, in case anyone is wondering, and I've attached a few for those interested in art appreciation.
Characters all use skeletal animation. The skeletal hierarchies are described in separate binary files from the meshes. I'm unsure of the exact number of vertex weights at the moment, but it's likely to be a limit of one per vertex. If I have time I'll get the script to dump the assets in gltf so people can play around with them in Unity or whatever. The script itself should be available soon for anyone else interested in diving into the guts of this.
Okay, I've cleaned up the script for any one else who wishes to use it. it may be found here. I hope it helps in some small way. It requires python3 and pypng to work; run it with -h to see the help text, but really you just need to pass the .bin files to the script and it should do The Right Thing, but your mileage may vary as always.
Over the next few days I intend to document the file formats, and if anyone's interested, I'll publish that stuff too.
For the astute, you may have noticed there are no audio files. I believe they are stored in the .MLT file, but has a different structure so there's no way to pull anything out at the moment, or at least as far as I know. There's not really a lot of audio in the prototype though, so it's kind of a low priority for me.
Here's hoping someone finds a secret or two lurking on disk
I have the skeleton files part way figured out. these can be found in the .ssk directory that the script generates. For the most part they're pretty straight forward, but I've hit a bit of a snag with them. While the hierarchy was easy to figure out, the exact way it stores the bone transform (s) is kind of bizarre. I've worked with stranger stuff before though, so we'll see how it goes. For the technically inclined people, the problem is this:
typically each bone in a skeleton has a transform matrix used to deform the vertices that are assigned to it. this usually takes the form of one of the follow:
1. A 4x4 transform matrix (16 floats)
2. A 3x4 transform matrix (12 floats)
3. A versor and a vector (7 floats)
4. Euler angles and a vector (6 floats)
Sometimes there may be an extra value for scale (1-3 floats), but this is uncommon.
But here though, we have 21 floats worth of information, and none of it seems to fit any of the above patterns. It's quite a puzzle, so I decided to look at the .scf files, which is where character geometry is stored, and as far as I can tell, they are the same format as the .smf files used for static geometry, perhaps with some extra fields to weight vertices to their skeletons. This is good news, since it means once one format is known, then we know the other. More interesting, it appears that vectors may be stored as 4D, with an extra 1.0 padding the end, which makes them homogeneous. This is all subject to change though.
I've also loaded the code into ghidra to help get some more insight. I'd kill for IDA, but the free version does not support super H, unfortunately, but I digress. I poked around for some strings and found some fun things to share:
0008f374 "% s.bin"
000a10c8 "% s.scf"
000c7100 "% s.smt"
000a10d0 "% s.ssk"
000a10d8 "% s.ssn"
This appears to confirm some of the file extensions, which are not encoded in the .bin files.
0007bc40 "% s_actors.txt"
000af0c8 "% s_AIDefs.txt"
0006cc70 "% s_animsets.txt"
0008f37c "% s_e"
000dfdc8 "% s_emitters.txt"
00078320 "% s_entities.txt"
0007c3e4 "% s_fountain.txt"
0007bc50 "% s_items.txt"
0007c3f4 "% s_lightning"
00087c28 "% s_lightsets.txt"
00078330 "% s_nibillboards."
The engine seems to organize around the concept of a 'level', this appears to be broadly similar to a 'scene' in Unity or UDK. A level is composed of multiple text files, and these strings appear to confirm the naming scheme for them. Upon loading a level, the engine will look for the above text files and load their contents to produce the level. the% s is a place holder for a level name. These files may be found in the ramdisk directory, where there are ones like s2_01_items.txt, s2_01_lightsets.txt and so on. It appears not all files have to be present, as many levels are lacking a _fountain.txt.
00073eb0 ". \\\\ SOURCE / AISys. | 0 \ t"
000bb864 ". \\\\ SOURCE / AnimUtil.c"
00079e30 ". \\\\ SOURCE / canimt"
0006ab6c ". \\\\ SOURCE / cmesh.c"
00015e2c ". \\\\ SOURCE / CollSrvr.c"
000217ec ". \\\\ SOURCE / cskelsys.c"
000ec40c ". \\\\ SOURCE / cskinsys.c"
0009b824 ". \\\\ SOURCE / database.c"
000cc8e4 ". \\\\ SOURCE / dirsys.c"
000eb820 ". \\\\ SOURCE / Entity.c"
00076c34 ". \\\\ SOURCE / Fo"
00098ea0 ". \\\\ SOURCE / gameloader.c"
000a1c64 ". \\\\ SOURCE / GMain.c"
000d4654 ". \\\\ SOURCE / It"
00011828 ". \\\\ SOURCE / kc_light.c"
0008c760 ". \\\\ SOURCE / kc_vbuf.c"
0008d534 ". \\\\ SOURCE / kct exception in% s ()."
0001e0a0 ". \\\\ SOURCE / lightsys.c"
0009482c ". \\\\ SOURCE / msgsys.c"
000868a0 ". \\\\ SOURCE / NIBillboardSys.c"
0006c654 ". \\\\ SOURCE / nm"
00069fb4 ". \\\\ SOURCE / pa"
000c16e8 ". \\\\ SOURCE / pdfsys.c"
000a278c ". \\\\ SOURCE / smf.c"
000e4408 ". \\\\ SOURCE / smfuser.c"
000f1d04 ". \\\\ SOURCE / smt.c"
00076d34 ". \\\\ SOURCE / ss"
00076d20 ". \\\\ SOURCE / ssk.c"
00000e4c ". \\\\ SOURCE / stacksys.c"
000f2328 ". \\\\ SOURCE / stream.c"
00096e80 ". \\\\ SOURCE / strutil.c"
00080d68 ". \\\\ SOURCE / sttmachn.c"
0007a9f4 ". \\\\ SOURCE \\ OB"
000079f0 ". \\\\ SOURCE \\ OBJECT31: 35 \ n"
00098a64 ". \\\\ SOURCE \\ OBJECTS / camera.c"
00071ac4 ". \\\\ SOURCE \\ OBJECTS / E02_BlueGh"
000f8c2c ". \\\\ SOURCE \\ OBJECTS / E4"
00009d00 ". \\\\ SOURCE \\ OBJECTS / shield.c"
000d3440 ". \\\\ SOURCE \\ OBJECTS / SpecialBookOfPH"
00086c80 ". \\\\ SOURCE \\ OBJECTS / Whip.c"
There is also a list of source files, which appears to be partial. It appears the game was written in C, which was fairly common up until the early 2000s or so.
000fcf5d
"S37at motherfucker *****"
There was also this entry. No comment!
00081a00
00063120
"0.4 Build: Jul 23 1999 11:28:48 \ n"
"04 Build: Mar 01 1999 11: 57: 40 \ n"
There are a few build strings through out as well, which should help date it exactly.
There are also numerous references to other enemies:
Evil Cleric, Pirate Skeleton With Sword, Boomerang Skeleton, Blood Skeleton, Headless Zombie, Lantern Mummy, Ax Knight, Spear Knight, Zombie, Great Armor With Sword, Headless Knight, Ghost Musician, Aristocrat Ghost, Fishman, Hunchback, Succubus, Bat, Hell Hound, Raven, Flying Fish, Skull Pillar, Grasping Hand, Hydra, Gorgon, Medusa Head, Skeletal Dragon Head, Wyvern, Harpy, Spirit, Flying Furniture, Flying Book, Marionette, Lesser Demon, Beelzebub, Maggot, Werewolf, Frankenstein, Female Dracula, Death Horse, Death, and of course, Dracula.
You can't say they didn't have ambition!
There are references to 'Victor' as well, which I think was the second playable character?
For the technical people, there are lots of debug bits in the string list too. I've attached the string dump from ghidra to this post for others to look at. One interesting trivia bit is that the collision detection system appears to have at least two primitives: trimeshes and spheres. It's likely that they supported capsules as well.
More to come, hopefully!
Hey, great advice! I gave the NJA stuff a look over, and while the formats are different, there are definitely similarities in regard to how geometry is stored. It's unclear whether the castlevania files are derivative of or informed by the NJA format. The big question remaining is figuring out the framing that holds the data together, but once that's done I can start writing the static assets out into glTF or some other accessible format.
For the curiosity people:
The vertex data is decomposed and written out into banks, so in the file you have something that looks like:
Code :
point point point ...
normal normal normal ...
uv uv uv ...
... ... ...
The first vertex would then be described by the first point, the first normal, and the first uv. The second vertex described by the second point, normal and uv, and so on for the rest. ie: It's stored column major. The NJA format permits some extra attribute data as well, and it's safe to bet the castlevania SMF format stores it in a similar way.
Work on the model format is near completion now. All the static geometry exports fine, but the animated characters come out as a jumble. This is interesting, not because it means there's an error on my part, rather, it means the vertices are stored relative to their assigned bones, and without the skeleton, the character models will not render properly. The file formats for the characters and the static geometry are the exact same. It appears that the information binding the vertices to bones in the skeleton are stored in the files inside the ssn directory. I have already mapped these out, along with the ones in the tft directory.
All in all it's been a very productive day.
I need to finish up the export code. Right now the normals seem a bit weird, and there's no UV coordinates or texture references written, but I hope to publish the updates to the script soon.
EDIT:
Texture support is now functioning. Where things seem a bit off in the images below is because of Blender not doing The Right Thing. There's a separate problem where the texture coordinates rely on a mirror texture mode, which Blender doesn't support as far as I can tell, but these issues are outside the scope of this project.
I have discovered another interesting thing too, it appears there are multiple versions of some models written in the different .bin files, and at least some are different, varying in vertex count and such.
Now to get the skeleton and animation files figured out ...
Alright, I have the animation format figured out! All that remains is to finish up the skeleton definitions and I should be able to write out all the animated models into glTF or similar. As usual here are some technical bits for the interested:
The animation format used in Castlevania is pretty straight forward. It stores data key major, with data for every bone stored inside each frame; each frame is given a monotonic time code in seconds, which is stored as a uint! Conceptually the frame data is written column major, with rotations written first, then if a flag is set in the header, position data. Most animations do not have any position data written. Rotations are stored as versors, and positions as 4D vectors.
It appears that they may have wanted to do some sort of delta compression scheme judging by some flags in the header which are set, but don't actually do anything.
Aside from this, I realized there's a way that I can fake the mirrored texture mode by generating mirrored versions of the textures in the script, so I may do that time permitting.
Another day of progress!
And we're just about done now! I'm sorry for hijacking this thread and turning it into a kind of running blog, but I should be done in a post or two more, I promise. I've attached some pictures to make up for the transgression.
So the skeletons were actually a lot simpler than I thought. It appears most of the data on the bones is redundant. No rotations appear to be stored at all, in fact. Only their positions relative to their parent. This is very common pattern for this era of games, and I feel a bit silly for not thinking of it sooner - I've even used it before in my own work!
By combining the relative position with a rotation provided by an animation a frame of may be reproduced, or, as I have done here, supplying a identity matrix reproduces the bind pose.
I also realized there is some extra data in Sonia's skeleton. It's impossible to tell what it's used for, but if I had to hazard a guess, then it appears to be describing small IK chains, which would have been used to dynamically place Sonia's feet on the ground. This is common now in games, but back then it was quite rare! Her skeleton is the only one to have this extra data.
Next up is to write out the animations and everything into glTF!
I did a compare on all the files in each .bin file, and there are quite a few different versions of textures and models. for the most part the differences are small, but there are a couple of interesting ones that I have found:
There are two versions of the model though. in s2_06.bin and higher there is an unfinished looking version. the other files have a nicer version. I have included screenshots:
I've also attached two different versions of the holy water model. this one is interesting because both versions seem to be finished. most of the power ups have a less finished, earlier looking model, but they are not much to look at
also, here's the list of all the differences, in case you are interested:
DIFFERENCE: data / S2_01.BIN: "textures / ghost_smoke" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_01.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_01.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_01.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smt / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smt / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smf / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_02.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_03.BIN: "textures / pilar_bottom_cath" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_03.BIN: "textures / windowedge" varies from previous in data / S2_02.BIN
DIFFERENCE: data / S2_03.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_03.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_04.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_04.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_04.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_04.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_05.BIN: "textures / dirty_brick_01" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_05.BIN: "textures / dirty_brick_01" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_05.BIN: "textures / roof01" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_05.BIN: "textures / roof02" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_05.BIN: "textures / windowedge" varies from previous in data / S2_02.BIN
DIFFERENCE: data / S2_05.BIN: "textures / wall_side_01" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_05.BIN: "textures / yellobrk02" varies from previous in data / S2_03.BIN
DIFFERENCE: data / S2_05.BIN: "textures / yellobrk03" varies from previous in data / S2_03.BIN
DIFFERENCE: data / S2_05.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_05.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_05.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smt / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smt / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smt / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smt / i_portion" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smf / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smf / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_06.BIN: "smf / i_portion" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "textures / windowedge" varies from previous in data / S2_02.BIN
DIFFERENCE: data / S2_07.BIN: "textures / door_surround" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_07.BIN: "textures / pilar_bottom_cath" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_07.BIN: "textures / iron_tiki" varies from previous in data / S2_01.BIN
DIFFERENCE: data / S2_07.BIN: "smt / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smt / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smt / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smf / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smf / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_07.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smt / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smt / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smt / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smt / i_portion" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smf / i_heart" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smf / w_dagger" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smf / w_boomerang" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_08.BIN: "smf / i_portion" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_09.BIN: "smt / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_09.BIN: "smf / w_holywater" varies from previous in data / COMMON.BIN
DIFFERENCE: data / S2_09.BIN: "ramdisk / directional_light.lit" varies from previous in data / S2_02.BIN
Just thought I'd update you on what's happening. I have the character skeletons and animations loading in Blender now, and an extra bonus I managed to get the textures that use the repeat mode to display properly; you can see it on the medusa screenshot that I've included. It does look like there are a lot of extra animations for Sonia that aren't used in the prototype, but it'll be some more time before I can be certain. Right now the only problem is that Blender considers the animations separate objects instead of merging them with the models. It's a bit annoying!
I've included some video. It's only her skeleton animating still, but it's very interesting! There are definitely a lot of unused animations for her in the files. Some of them include ones for being pulled or grabbed, and escaping from it, there are animations for landing from a small and large fall, ones for look like what's jumping off edges (think Castlevania 64), and, the most interesting, some acrobatic jumps! There are at least three that I've found so far: one is a backflip, and the other two are these neat butterfly-somersault style jumps to the left and right. It kind of reminds me of Gunvalkyrie or something.
It looks like originally they wanted Sonia to be super agile and acrobatic. How cool this game would have been if they'd gotten to finish it! As far as I know there is no footage of these animations. I'm going to wait until I have the skeleton working properly with the models before I announce anything, but I just had to give you a preview.
the jumping animations that I recorded in the videos are all unused. another interesting thing to note is their filenames - rjmpleft, rjmpright, rjumpbak - each one begins with R, and in prototype R + analog stick makes sonia do crouch rolling - regardless of whether you hold L. This is odd behavior. I strongly suspect the jumping animations were meant to be used when standing R + analog stick, and the rolling animations when crouching with R + analog stick.
Compilation Unused Animation for Sonia (Youtube)
.png)
I also noticed the bone skeleton appears to have a damaged animation - e05_boneskel_throw_11 - the data abruptly cuts off. I might be able to recover part of it, but it will have to wait until later. It is the only damaged animation that I have encountered.
To download below:
Castlevania Resurrection Reverse Engeenering texture and animation video pack
The projets of research and Reverse Engineering undertaken on other games :
Feel free to look at " other canceled games " that I found. For the most curious of you, I have created a " list of all unreleased from theDdreamcast ".
Similar prototypes (Unreleased) : Agartha (DC) - Emulateur officiel Megadrive (DC) - Castlevania Resurrection (DC) - Half Life (DC) - Dalforce XOP (DC) - Flinstone (DC) - 4 x 4 Evolution PAL (DC) - Ring : L'Anneau des Nibelungen (DC) - Ecco 2 (DC) - Kyskrew (DC) - Propeller Arena (DC) - Geist Force (DC) - Scud Race Tech Demo Dreamcast - Shenmue 2 US (DC) - The Red Star (XBOX) - Heaven's Drive ( version japonaise de Burnout 1) pour PS2 - Jekyll and Hyde (DC) - The Grinch Jap (DC) - Worms Pinball (DC) - Quake 3 Arena version japonaise (DC) - Vectorman PS2
the information right now is subject to change