You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Jun 29, 2014 9:25 PM
- Ulfbjörn
- Member
- From: Sweden
- Registered: Sep 18, 2013
- Posts: 54
- Gems: 0
Spyro Nostalgia
A few weeks back I found a document detailing the format that Spyro 1 stored its "level geometry" in and set about trying to extract some scenes.
After a lot of messing about I managed and was of course greatly pleased. I had originally planned on making a small, "playable" Artisans home level but as things usually are with these things, life got in the way with other obligations.
Here are some screens of what I did get out of it though:
The gems are randomly spawned by raycasting down along the Y axis. This causes them to appear on water and hills as well as on the sides of towers. In a proper release the gems would obviously be manually placed or randomly spawned in a small designated area around a chest or similar as it breaks.
The waterfalls are animated and look quite decent considering the cheap particle textures used at their bases.
Animated whirlwinds and glares on the gems using the same, almost overly simplistic texture.
As in the original game, textures fade away to ambient colours in the distance. While this was probably born out of necessity to save processing power on the PS1, I always found it a really appealing visual effect.
A video would perhaps have been better but there really isn't that much to show; the Spyro model used is a slightly modified version of the one made by this guy. Unfortunately I'm pretty worthless at modelling so I cannot really do it myself. The model isn't animated and while I tried, trying to apply rigging to geometry which didn't account for it when it was made seems quite hard (again that isn't something I normally do so it may be it's a breeze for those more knowledgeable in the field). So all that really isn't static in the portrayed world are the waterfalls (which are animated through scrolling their texture coordinates and some cheap, homemade particle effects at their bases), the whirlwind particles in the tower (which looks surprisingly good considering my photoshop skills) and the gems rotating and having specular per-vertex highlights to create that original Spyro feel.
I wouldn't mind continuing with this project once I get the time, but for it to turn out somewhat decent I would most definately need some modelling and animation help, so if anybody feels inclined to do that feel free to shoot me a message 
Last edited by Ulfbjörn (Jun 29, 2014 9:30 PM)
Offline
#2 Jul 01, 2014 12:41 AM
- Breaking Bad
- Member
- From: Denver, Colorado
- Registered: Dec 15, 2012
- Posts: 266
- Gems: 73
- Birthday: 20 January
- Age: 27 years old
- Gender: Male
Re: Spyro Nostalgia
Too nice!
DDR, so your sis hogs all the games? LOL
Skype: BigMeth007, feel free to add me.
Offline
#3 Jul 01, 2014 3:58 AM
- spyroyo
- Member
- Registered: Nov 24, 2013
- Posts: 16
- Gems: 0
Re: Spyro Nostalgia
Wow this is really awesome. Good job on finding out the level geometry btw.
If you need any help on this I'll be more than glad to give it a shot. I probably can't help you that much in modeling seeing I only have brief experience in that department, but I could help you out with other aspects associated, (programming, story-line, etc).
Good luck.
Offline
#4 Jul 03, 2014 4:44 PM
- Ulfbjörn
- Member
- From: Sweden
- Registered: Sep 18, 2013
- Posts: 54
- Gems: 0
Re: Spyro Nostalgia
Thanks
The really cool part is that since the textures are available and what with the geometry being as low-poly as it is, it shouldn't be too hard to add things to them or extend them while still making them look authentic.
It would be quite something to pull that off.
Offline
#5 Jul 03, 2014 5:27 PM
- CuttingEdge
- Member
- From: Straight Outta Poland
- Registered: May 04, 2014
- Posts: 1,038
- Gems: -27
- Birthday: 11 November
- Age: 24 years old
- Gender: Male
Re: Spyro Nostalgia
This is too good to exist. But why are you placing gems at the mountains, where the player doesn't have any access? ._. Or are they generated randomly?
Never ask what I'd do for a klondike bar. No one wants to go down that road.
Offline
#6 Jul 03, 2014 6:12 PM
- Stormy
- Administrator
- From: Illinois
- Registered: Jun 01, 2006
- Posts: 10,385
- Gems: 542
- Birthday: 3 April
- Gender: Female
- Website
Re: Spyro Nostalgia
It says under the first screenshot that they are randomly placed.
This is awesome; great work. If you ever have this completed to your satisfaction, I'm sure we'd all like to try it out.
That document you found might be interesting as well, if you wanted to share that.
Offline
#7 Jul 11, 2014 6:23 PM
- Ulfbjörn
- Member
- From: Sweden
- Registered: Sep 18, 2013
- Posts: 54
- Gems: 0
Re: Spyro Nostalgia
Thanks for the appreciation.
That document you found might be interesting as well, if you wanted to share that.
Sure, I can do that. It is a bit hard to follow at times though and there were at least a couple of instances where it seems to have gotten the order of things and / or offsets wrong, but this may be because it describes a different regional version of the game than the one I used.
Basically all graphics media seems to be stored in the file WAD.WAD on the Spyro 1 disc. This file is just a large, uncompressed archive containing sub files one after another. The sub files may in turn contain other sub files and so on in a recursive manner.
It would be interesting to muck around a bit with the different files contained here since some of them will most likely contain other model data than the ones described by the documentation; chances are their formats will be very similar if this is the case.
The documentation (that I believe may be of russian origin seeing to where I found it, but I cannot identify its author since it doesn't seem to say anywhere - chances are it is just parts of data copied and pasted from somewhere) outlines the WAD header and the "level" sub file structure like so (posted with a code tag to retain monospacing):
WAD.WAD:
____16_bytes___
| |
0: f1 - s1 = f2 - s2 // f* = subfile offset * (4 bytes)
f3 - s3 = f4 - s4 // s* = subfile size * (4 bytes)
.. .. .. ..
.. .. .. ..
.. - .. = fn - sn // end of header
00000000000000000
00000000000000000
.. .. .. ..
// nulls
.. .. .. ..
00000000000000000
f1: ................. // first subfile
................. :f1+s1
f2: ................. // second subfile
................. :f2+s2
.. .. .. ..
// subfiles...
.. .. .. ..
fn: ................. // last subfile
................. :fn+sn
// end of WAD.WAD
For Spyro1 some of subfiles (11, 13, 15 ... 77, 79) are `level` subfiles; `cutscenes` subfiles = 4,5,6,7; `starring` subfiles = 83,84 .. 101,102
/\
`level` subfile X: __||__
offset = fx, size = sx
0: o1 - s1 = o2 - s2 // o* = offset * (4 bytes)
o3 - s3 = o4 - s4 // s* = size * (4 bytes)
.. .. .. ..
// kind of `wad` header
................. (Vram zone)
o1: ................. // first sub-subfile (See below)
................. :o1+s1
o2: !!!!!!!!!!!!!!!!! // second sub-subfile
!!!!!!!!!!!!!!!!! :o2+s2 <--_
\
o3: ................. |
................. :o3+s3 |
|
.. .. .. .. // data |
/
/\
Second sub-subfile: ||
offset = o2, size = s2 (`!!!!!!!` block)
0: j1 - .. = .. - .. // j1 - jump offset (4 bytes)
.. - .. = .. - ..
.. .. .. .. (texture list, see below)
.................
j1: j2 - !! = !! - !! // j2 - second jump offset (4 bytes)
!!!!!!!!!!!!!!!!!
!! !! !! !!
// `ground` model binary data (size = j2-4)
!! !! !! !!
j1+ !!!!!!!!!!!!!!!!!
+j2: j3 - .. = .. - ..
................. // j3 - next jump offset (4 bytes)
j1+ // if j3=0 then offset (of) = j1+j2, goto --_
+j2+ ................. | | \
+j3: j4 - .. = .. - .. \ ___/ |
................. // new jump | |
j1+ | /
+j2+ \ | / /
+j3+ ................. // jump again \|/ /
+j4: j5 - .. = .. - .. | | /
................. | | /
/ |/____
of = offset = j1 + j2 + j3 + j4 + j5 : <<-_/
of: ss - cc = !! - !!
!!!!!!!!!!!!!!!!! // ss = size of `sky`-4 or 0 (4 bytes)
!! !! !! !! // cc = background color (4 bytes)
!! !! !! !! // `sky 1` model binary data
of+ !!!!!!!!!!!!!!!!!
+ss: .. - .. = .. - ..
................. // space between `sky 1` and `sky 2`
.. .. .. ..
.. .. .. ..
.................
.. - ff = .. - .. // FF = 0xFFFFFFFF (4 byte)
.................
.. .. .. ..
.. .. .. ..
.. - 00 = 00 - 00 // nulls
00000000000000000
00 00 00 00
00 00 00 00
00000000000000000
ss - cc = !! - !! // start of `sky 2`...
!!!!!!!!!!!!!!!!!
!! !! !! !!
~~~~~!!!!...FF...00!!!!...FF...00!!!!~~~~~ // `sky 3`, `sky 4` ...
// until FF (-1) or 00 not found (end of file)
`Vram` is the first sub-subfile of a `level` (marked `Vram zone` above)
Size = 524288
`Model` is a beginning of second sub-subfile,
Size = `j1` (just before first `sky`, see `Second sub-subfile`)As is described here we are mainly interested in the first and second sub files of the level files contained in the archive, which contain texture and "model" data; the "model" data includes both the actual level geometry and the skies, which interestingly enough turn out only used vertex colouring and interpolation instead of actual textures. There may also follow further data as part of the "model" sub file; a fair guess is that this contains geometry and (if applicable) animation data for other objects and characters occuring in the given level. I haven't made any attempts to determine this but it would be intriguing to try.
The documentation goes on to describe the texture sub file like so:
Screen buffer of PS : (Vram)
Every pixel has 16 bits:
0 ---------------- 511 ---------------- 1023 1024*512*2 = 1 Mb.
| . . . . . . . . . ! |
| . . . . . . . . . ! | Left half (`. . .`) used
| . . . . . . . . . ! | for output to screen.
255 - - - - - - - - - + - - - - - - - - - -+
| . . . . . . . . . ! | Right half stores all
| . . . . . . . . . ! | textures and palettes:
| . . . . . . . . . ! | 512*512*2 = 524288 bytes
511 ------------------+--------------------+
There are three mode for colors: 4 bpp, 8 bpp and 15 bpp (default).
In 15 bpp every 2 bytes used to make 1 pixel: "gggr-rrrr = 0bbb-bbgg"
Size of screen = 1024*512 (right area = 512*512)
In 8 bpp every 2 bytes making 2 pixels with indexed color:
there are a `palette` line with 512<=X<=768, 0<=Y<=511, height=1, width=256.
Palette colors used like in 15 bpp.
So size of screen = 2048*512 (right area = 1024*512)
In 4 bpp every 2 bytes used to make 4 pixels in 16-colors indexed mode:
"2222-1111 = 4444-3333". Now palette can have 512<=X<=1008, width = 16.
(Almost like 8 bpp)
And size of screen = 4096*512 (right area = 2048*512)
Vram textures in game:
They all are in first sub-subfile of a `level` subfile
Beginning - array of 524288 bytes to load in right half of Vram.
Mapping and coordinates:
List of X,Y and palettes - beginning of second sub-subfile of the same level.
Second sub-subfile:
offset = o2, size = s2
____16_bytes___
| |
0: j1 - tc = lodtex1 // j1 - size of texture list (4 bytes)
mintex1 = lodtex2
mintex2 = lodtex3 // tc = tile count 0<tc<128 (4 bytes)
mintex3 .......
....... ....... // *tex* and *tx* - `texture` definition (8 bytes)
....... .......
....... lodtexn // lodtex* - tiles for long distance from camera
mintexn = sprtex1 // mintex* - tiles for middle distance;
cor1tx1 = cor2tx1 // sprtex* - ?? , But always:
cor3tx1 = cor4tx1
sm01tx1 = sm02tx1 // lodtex# = mintex# = sprtex# ! (32*32 px)
sm03tx1 = sm04tx1
sm05tx1 .......
....... ....... // cor#tx1* - tiles for short distance to camera,
// every poly divided by 4 corners: (32*32 px)
....... .......
....... sm14tx1 0 ------------- 32 0 ------+------ 64
sm15tx1 = sm16tx1 | | \ | 1 | 2 |
sprtex2 = cor1tx2 | lod | \ | cor | cor |
cor2tx2 = cor3tx2 | | ------+ +------+------+
cor4tx2 = sm01tx2 | min | / | 3 | 4 |
sm02tx2 = sm03tx2 | | / | cor | cor |
sm04tx2 ....... 32 -------------+ 64 ------+------+
....... ....... _
// sm##tx* - tiles for |
....... ....... // closer distance, \|/
....... sm13tx2 // every corner divided
sm14tx2 = sm15tx2 // again: (16*16 px) 0 ------+------ 64
sm16tx2 = sprtex3 |01 02|03 04|
cor1tx3 = cor2tx3 |05 06|07 08|
cor3tx3 = cor4tx3 // offsets: +------+------+
sm01tx3 = sm02tx3 // lodtex1 = 8 |09 10|11 12|
sm03tx3 ....... // lodtex# = 8+(#-1)*8*2 |13 14|15 16|
....... ....... // sprtex1 = 8+tc*8*2 64 ------+------+
// cor1tx1 = 8+tc*8*2+8
....... ....... // cor1tx# = 8+tc*8*2+(#-1)*8*(1+4+16)+8
....... = sprtexn // cor2tx# = 8+tc*8*2+(#-1)*8*(1+4+16)+(8*2)
cor1txn = cor2txn // j1 = 8+tc*8*2+tc*8*(1+4+16)
cor3txn = cor4txn
sm01txn = .......
....... .......
....... .......
sm15txn = sm16txn
j1: j2 - .. = .. - .. // j2 - second jump offset (4 bytes)
.................
.. .. .. ..
// `ground` model binary data (size = j2-4)
.. .. .. ..
j1+ .................
+j2: j3 - .. = .. - ..
.................
Tile `texture` definition format : (8 bytes)
________________4_bytes_________________
| | Square in Vram:
_
XXXXXXXX - YYYYYYYY = yy1xxxxx - yyyy-yyyy 4 ----.--(3)
// Main_X Main_Y Pal_1 Pal_2 | ./ |
| / .
XXXXXXXX - YYYYYYYY = c00y1xxx - brrraaat | / |
// Vert_X Vert_Y Sector Flags | / |
1 ------- 2 ____
Color mode: |\
Flags.t = 1 -> 15 bpp | \
Coordinates of palette: Flags.t = 0 and Sector.c = 1 -> 8 bpp | |
X = Pal_1.x*16+512 Flags.t = 0 and Sector.c = 0 -> 4 bpp _/
Y = Pal_2.y*4+Pal_1.y /
___________/
Coordinates of square corners (4 and 3) _/
x4,y4: x3,y3:
Flags.t = 1 Sector.x*64+Main_X+512 Sector.x*64+Vert_X+512 <- X
Sector.y*256+Main_Y Sector.y*256+Vert_Y <- Y
Flags.c = 1 (Sector.x*128+Main_X+1024)/2 (Sector.x*128+Vert_X+1024)/2 <- X
Sector.y*256+Main_Y Sector.y*256+Vert_Y <- Y
Flags.c = 0 (Sector.x*256+Main_X+2048)/4 (Sector.x*256+Vert_X+2048)/4 <- X
Sector.y*256+Main_Y Sector.y*256+Vert_Y <- Y
x1 = x4, x2 = x4+16*Flags.b+16 ___\ x2-x1 =
y1 = y4+16*Flags.b+16, y2 = y4+16*Flags.b+16, / = y1-y4
_____ Flags.r = Meaning:
Flags.a - if nonzero then wrong... / 0 = normal
/ 1 = rotate 90 left
/ 2 = rotate 180
Flags.r - rotate/mirror setting: / 3 = rotate 90 right
\ 4 = mirror + 90 left
\ 5 = mirror
\ 6 = mirror + 90 right
\______ 7 = mirror + 180Furthermore the "level" files are described like so:
____16_bytes___
| |
pc - p1 = p2 - p3 // pc = part count (4 bytes)
p4 - p5 = p6 - p7 // p* = pointer to part * (4 bytes)
p8 p9 .. ..
.. .. .. ..
// pointers...
.. .. .. ..
.. - pn = ?? - ?? :pc*4+12 // last pointer and 8 other bytes
p1+8: .................
................. // first part
p2+8: .................
................. // second part
.. .. .. ..
// parts...
.. .. .. ..
pn+8: ................. // last part
.................
__4_bytes__
| |
_lod_ , _mdl_ => v - c = p - i
| ___| __________
Part X of `ground` model: | / _/ |
| / // v = vertex count For |
|_/ // c = color count lod or |
_________16_bytes__________ | // p = poly count __ mdl |
| | | \__________|
_/
px-8: gy_gx - ii_gz = _lod_ - _mdl_
ff_ff - lodv1 = lodv2 - lodv3 // i - ignored (1 byte)
lodv4 - lodv5 = lodv6 - lodv7 // g* - global coordinates (2 bytes)
lodv8 lodv9 ..... ..... // ff = 0xFFFF (2 bytes)
..... ..... ..... .....
..... ..... ..... ..... // o1 = (px-8)+20+(_lod_.v)*4
o1: lodc1 - lodc2 = lodc3 - lodc4 // o2 = o1+(_lod_.c)*4
lodc5 lodc6 lodc7 ..... // o3 = o2+(_lod_.p)*8
..... ..... ..... ..... // o4 = o3+(_mdl_.v)*4
// o5 = o4+(_mdl_.c)*4
..... ..... ..... ..... // o6 = o5+(_mdl_.c)*4 = o4+(_mdl_.c)*4*2
o2: __lod_poly1__ - __lod_poly2__ // o7 = o+6(_mdl_.p)*16
__lod_poly3__ - __lod_poly3__
__lod_poly5__ .............
............. .............
// lodv* - `vertex` #* for lod (4 bytes)
............. ............. // lodc* - `color` #* for lod (4 bytes)
o3: mdlv1 - mdlv2 = mdlv3 - mdlv4 // __lod_poly*__ - `lodpoly` #*
mdlv5 mdlv6 mdlv7 ..... for lod (8 bytes)
..... ..... ..... .....
..... ..... ..... .....
o4: mdlc1 - mdlc2 = mdlc3 - mdlc4
mdlc5 mdlc6 mdlc7 .....
..... ..... ..... ..... // mdlv* - `vertex` #* for mdl (4 bytes)
// mdlc* - `color` #* for mdl (4 bytes)
..... ..... ..... ..... // farc* - `color` #* for far (4 bytes)
o5: farc1 - farc2 = farc3 - farc4
farc5 farc6 farc7 ..... // _________mdl__poly_*_________ -
..... ..... ..... ..... `mdlpoly` for mdl (16 bytes)
o6: _________mdl__poly_1_________
_________mdl__poly_2_________
_________mdl__poly_3_________ // far = mdl with second colors
............................. // tex = far with texture coords
.............................
_______last__mdl__poly________ :o7
Any `vertex`:
_______________4_bytes_________________
| |
zzzzzzzz - yyyyyyzz = xxxyyyyy - xxxxxxxx
|_______|___________|_______ |____
Full Swap: |________ | | |
______|__| | |
xxxxxxxx xxxyyyyy yyyyyyzz zzzzzzzz |
|_____________________________________|
In one line:
xxxxxxxxxxxyyyyyyyyyyyzzzzzzzzzz
Cut:
xxxxxxxxxxx yyyyyyyyyyy zzzzzzzzzz
As 2-bytes:
00000xxx-xxxxxxxx = 00000yyy-yyyyyyyy = 000000zz-zzzzzzzz
Any `color`:
__4_bytes__ // R = red (0..255)
| | // G = green (0..255)
// B = blue (0..255)
R - G = B - I // I - ignored (0x00, 0x30 ...)
Any `lodpoly` :
____4_bytes____
| | // 00 = nulls
// v* = vertex indexes
00 - v1 = v2 - v3 // c* = color indexes
fl - c1 = c2 - c3 | // fl = blend & depth
/ |
vertex and color indexes: | / |
| / |
__________3_bytes___________ |/_____ |
| | |
v1/c1 v2/c2 v3/c3 |
22111111 - 33332222 - 44444433 /
/
<=> (See `vertex` above) /
| /
00444444 - 00333333 = 00222222 - 00111111 | /
fourth third second first |/_____
blend & depth flag:
d = depth, not used \\ _1byte_
t = transparent flag \\ | |
b = blend type if transparent \\ dddd-dtbb
Any `mdlpoly` :
____4_bytes____ // v* = vertex * index (1 byte)
| | // c* = color * index (1 byte)
// tt = texture index, 7 bit (1 byte)
v1 - v2 = v3 - v4 // d* = depth, not used (1 byte)
c1 - c2 = c3 - c4 // rr = texture rotate & depth (1 byte) --_
tt - rr = d1 - d2 // ii = inverse or both sides (1 byte) \
ii - d3 = d4 - d5 / |
| / |
|/___ /
ii -> dddd-dbid | /
// b = both sides |/___
// i = inverse side
// d = depth, not used rr -> dddd-ddrr
(if v1=v2 then v2,c2 ignored) // rr = rotate if v1=v2 (triangle poly)
// d = depth, not used
How texture work:
For triangle poly:
for quad poly: rr = 0 rr = 1 rr = 2 rr = 3
4----3 4---3 3 1 1---4
|../.| |../ |.\ /.| \..|
|./..| |./ |..\ /..| \.|
1----2 1 4---1 3---4 3
(As on Vram) (Only for texture coords, but colors the same)
Vertex order and triangulation:
Obj, Mdl, Far, Tex: Inversed: | For lodpoly:
|
2----1 4----1 | 1----2
.../.. .../.. | .../..
../... ../... | ../...
3----4 3----2 | 3----4And finally there's the sky sub file structure:
____16_bytes___
| |
0: cc - .. = p1 - p2 // cc = background `color` (4 bytes)
p3 - p4 = p5 - p6
p7 p8 p9 .. // p* = pointer to part * (4 bytes)
.. .. .. ..
.. .. .. .. // all pointers
.. - .. = .. - pn
p1: ................. // first part
.................
p2: ................. // second part
.................
.. .. .. ..
// parts...
.. .. .. ..
pn: .................
................. // last part
part X of `sky` model:
_________16_bytes__________
| |
// i* - ignored (2 bytes)
px: i1_i2 - i3_i4 = gy_gz - vc_gx // g* - global coordinates (2 bytes)
pc_cc - ff_ff = vert1 - vert2 // *c - number of * (2 bytes)
vert3 - vert4 = vert5 - vert6 // ff = 0xFFFF (2 bytes)
vert7 vert8 vert9 ..... // vert* - `vertex` #* (4 bytes)
..... ..... ..... .....
// o1 = px+24+vc*4
..... ..... ..... .....
o1: colr1 - colr2 = colr3 - colr4 // colr* - `color` #* (4 bytes)
colr5 colr6 colr7 .....
..... ..... ..... .....
// o2 = o1+cc*4
..... ..... ..... .....
o2: ____poly1____ - ____poly2____
____poly3____ - ____poly4____ // poly* - `poly` #* (8 bytes)
____poly5____ .............
............. .............
............. .............
............. __last_poly__ : o2+pc*8
Any `vertex`:
_______________4_bytes_________________
| |
zzzzzzzz - yyyyyyzz = xxxyyyyy - xxxxxxxx
|_______|___________|_______ |____
Full Swap: |________ | | |
______|__| | |
xxxxxxxx xxxyyyyy yyyyyyzz zzzzzzzz |
|_____________________________________|
In one line:
xxxxxxxxxxxyyyyyyyyyyyzzzzzzzzzz
Cut:
xxxxxxxxxxx yyyyyyyyyyy zzzzzzzzzz
As 2-bytes:
00000xxx-xxxxxxxx = 00000yyy-yyyyyyyy = 000000zz-zzzzzzzz
Any `color`:
__4_bytes__ // R = red (0..255)
| | // G = green (0..255)
// B = blue (0..255)
R - G = B - I // I - ignored (0x00, 0x30 ...)
Any `poly`:
______8_bytes______
| | // VertIndex - indexes of three vertexes (4 bytes)
// ColrIndex - indexes of three colors (4 bytes)
VertIndex - ColrIndex // see `index`
/
| /
| /
|/____
Any `index`:
11111100 - 22221111 = 33222222 - 33333333
// see `vertex` for method:
11111100 22221111 33222222 33333333
33333333 33222222 22221111 11111100
33333333332222222222111111111100
3333333333 2222222222 1111111111 00 // 00 ignored
00000033-33333333 = 00000022-22222222 = 00000011-11111111
third second firstThat is a straight copy & paste of the mentioned documentation I found, separated for slightly easier reference (the original is a single text file). As said, it can be a bit hard to follow but there you have it. Sorry to whoever the author is for not being able to give him / her the proper credit.
Offline
#8 Sep 23, 2014 3:18 PM
- JayTurns
- New Member
- Registered: Aug 08, 2014
- Posts: 1
- Gems: 0
Re: Spyro Nostalgia
What is this being rendered in?
Offline
#9 Sep 30, 2014 8:33 AM
- Ulfbjörn
- Member
- From: Sweden
- Registered: Sep 18, 2013
- Posts: 54
- Gems: 0
Re: Spyro Nostalgia
DirectX 9.
Offline
#10 Jun 14, 2015 8:07 PM
- 1jn14r
- New Member
- Registered: Jun 14, 2015
- Posts: 1
- Gems: 0
Re: Spyro Nostalgia
Hey dude do you still have this documentation for Spyro? I would like a copy
Offline
Pages: 1