Sonic X-treme Textures and Defs

First @ TSSZ as usual I see :P

Ahem, needless to say the stuff here is indeed pretty awesome, but I also share the concern pissing of Senn may not have been the brightest idea. I don't remember any other developer being this nice with the community before - the amount of material he provided is just insane...

At least he didn't take it terribly bad, but still...

 

Not this time! =P

 

Oh, it's there.

I swear I didn't see that.

Well, you can kill my previous post, whoever feels like it. =)

(EDIT: Though I'll be happy to go FIRST@TSSZ EXCLUSIVE EXPOSE on it if you'll donate to the Ban Hammer )

 

Yeah... We're using custom Max models from made scratch. not using DEF in any way or form. only to look at and take refrence screen shots.
the game engine for this is Ult 3d.. a plug-in for game maker..
we are also going to do a build in C4 game engine. head back a few pages (page 13)
and u can see the HD redsands running realtime in C4. I just love all the nice effects C4 engine is capable of!

wish we could. but sadly I'm an artiest not a programmer lol, and I don't think Xeniczone has time to try anything of the nature.
maybe theres someone out there who could do this?

sure will. but I don't think theres anything new that everyone havn't seen yet if they have the models and viewer.
oh yeah u can open the files up with C++ and see variables like sonics maxspeed,wind resistance and acceleration, but nothing to compare these varables to.
or so I may think.

yeah we've caught the final room in JG where the water is recessed downward.'
thats not the only recessed stream , there are a few others as well. check back a few pages to see the comparison pics I set up.

and as for the blurry screenshot of crystal frost,
I've always thought that shot looked transparent sometime ago while attempting to model the level ( using that blurry shot) before this leak happened.
I was starting to think I was alone on that transparency thing.
in fact I modeled the level to be transparent in 3d studio, but it didn't carry over to our engine yet.

 

I think you missed the ":P" on the previous post :P

 

If I had any, I would =P. My pocket money is too short already (18- I know that sucks) xD

 

Does anyone know if the matrix.pcx file that every level calls for has any significance, I put another texture in for it and it doesn't show up in any level, but it complains about not having it in every level, so I'd expect a level to need it for something.

That as well as if any of the other textures the levels say they are missing exist in the files but are misnamed?

 

Why is it that when I change the appropriate layout PCX that is loaded as a qubix world, it's not reflected in the viewer SANiK wrote?

 

This is all some crazy amazing stuff you guys have here. I wish I knew half of what you guys are talking about. I really want to contribute to this somehow...
But I'd rather leave this to people who actually know what they're doing :P

 

has anyone else found any interesting controls on SANiK's viewer?
so far I've found:
1 - Turns antialising the textures on or off
2 - Turns texture transparency on or off
3 - Turns all textures on or off

Anyone found anything else?
Trying to work out this hexdump data still - but not done much in the last 24 hours. There's never enough time during the day!

 

You PMed me earlier asking about level layouts, right? Specifically how they're stored... I take it you figured it out? They're stored in PCX files where each cell is 1 block in size on the Y axis, up is Z+, down is Z-, Left is X-, and right is Y+. Each color corresponds to a cube definition defined in the def files.

I just can't figure out why if I change up a layout PCX, it doesn't get reflected in the viewer.

 

no I hadn't worked that out yet. so big thanks, I'll have a play.
Guessing you had a good night

 

Yeah figuring out the level format is easy.

If you want to see the problem I'm describing, go to act_02_1.def

You'll notice the floor has two squares missing in the back-left

if you open up act_02_1.pcx, you can see each layer of the level. The second cell shown is the ground object, and you can see the two pixels missing in the top-left. If you add them back in, and then go to the viewer, they don't show up in the level.

Anybody know why?

EDIT: And yes, I had an excellent night, haha

 

You mean the 'pink' block? Seems to work for me. I edited the PCX in gimp and it was fine Added the 2 blocks in and removed some from the middle, making it a doughnut shape. Seemed to work fine. hmmm...

Need to work out that hexdata so we can do paths now... lol... Least then we'd have levels that if you were a player you could explore...

 

LMAO, so I booted up the viewer again just to make sure I wasn't crazy, and I noticed I'd been loading files from the wrong directory. I have an original files directory, and a modified directory, and I was loading the original files instead.

So yeah, it's a snap to edit the levels this way, and they're stored in a really accessible format.

 

Glad I wasn't going crazy! Yeah I thought it was all to do with the 'QUBIX' data. Any idea what the heck that is if it's not level data??? The format is wonderfully simplistic, could quite easily create a level now. It would just be missing the actions (stored as hexdump data) and paths (similar)...

 

I'm not so sure that actions and paths are stored as hexdump data.

Actually, there should be a way to check this out. Which level videos show paths? Doesn't death egg zone? Which def file matches the zone in the video?

What I'm thinking is that I'll look at the video to see where the path object is supposed to be placed, then see what is in that spot on the layout PCX.

EDIT: Wait, was it you who posted that every hexdump begins with the same signature? Like an ID label or something?

EDIT AGAIN: Also, qubix data seems to be a moniker for the world data. Perhaps because the saturn only rendered with quads, which lead to the cube-design of the levels, which lead to the moniker? Just a guess.

The other data is stuff related to how the level is drawn. Perhaps its for surfaces which are Gouraud shaded or something?

matrix.pcx is a texture which is used to show the edges of each box, sort of like a ghetto wire-frame mode. Press 3 in SANiKs viewer to use it.

 

This is why I have been keeping an eye on the jade gully level (JADE.DEF) as I can watch the video and see what's missing in SANiK's viewer. I can't eaily pull everything up at the moment, but let's compare two paths:

Code (Text):

1. //======================
2. //  ACT_path                                        
3. //======================
4. NEW_PATH    "ACT_path"
5. {
6.     Value   001,5                               //Count
7.     Value   002,1638                            //dt
8.     Value   008,128                             //Radius
9.     Value   011,4096                            //ActorDt
10.     Value   014,65536
11.     HexDump "01000300460000000000013a800d0009800400c0b1130000800e0009800400c0e44600008010
12. 000a800400a0ffff00008013000e80010040ffff00008006001580010080ffff00008017000980000
13. 080ffff"
14. }
15.  
16. //======================
17. // FLOWER_path                                      
18. //======================
19. NEW_PATH    "FLOWER_path"
20. {
21.     Value   001,3                               //Count
22.     Value   002,2048                            //dt
23.     Value   008,128                             //Radius
24.     Value   011,3276                            //ActorDt
25.     Value   014,65536
26.     HexDump "010003002e000000000001528008000880060000ffff00008008000b80060000ffff00008008
27. 000c80060000ffff00008008000c80060000ffff"
28. }

It's at least data to make things move, considering there is an 'act_path' which would probably move the act image out the way, which happens in the video.

Some of the paths in JADE have textures, thickness, camera offsets, check TEMPLE_SQREW & BRIDGE_1 for examples.

The 'count' part I wonder if it states how many coordinates are stored in the hexdump. The higher the count, the larger the hexdump.

They all have radius values that would allow them to curve into loops for sonic...

In the JADE.DEF file all hexdump data starts '01000300' and all paths are like this, however the value changes on different files. An example being SCREEN1.DEF uses '01000100' instead. Similar but not the same etc...

So if we assume that is an ident then this is the coord data for flower path:

Code (Text):

1. 2e000000000001528008000880060000ffff00008008000b80060000ffff00008008000c80060000
2. ffff00008008000c80060000ffff

108 characters, the count is 3 so we split the data into 3:

Code (Text):

1. 2e000000000001528008000880060000ffff
2. 00008008000b80060000ffff00008008000c
3. 80060000ffff00008008000c80060000ffff

So if we assume that holds an x,y,z and nothing else... you end up with ridiculous numbers... lol. Maybe someone who is used to hex might have some ideas...

I maybe chasing up the wrong tree but who knows...

Maybe, the hexdata is commented as 'editor positions' and 'recording' at least for the actors generally the hexdata is render flag data, which would be hard to reproduce without a clue.

Be warned if the viewer can't find it though you end up with blue objects everywhere! :D

 

Just looking at the hex code, you can see repeated sections. The code you split, for example, has 80060000ffff repeated numerous times.

I suck at encryption, but that seems significant to me.

 

I agree - broken down so you can see the repition or similarities

Code (Text):

1. 010003002e
2. 0000000000
3. 01528008000
4. 880060000ffff
5. 00008008000
6. b80060000ffff
7. 00008008000
8. c80060000ffff
9. 00008008000
10. c80060000ffff

hmm now this is a 'flower_path' so maybe, this path just makes something go up and down around a stem or something?