Sonic X-treme Textures and Defs

Hey, yeah it always seems to be the smallest things that help out the most.
I'm in the process of buying a house right now , so our project could slow down for a few weeks, at least.

 

Got the weird PCX texture loading (bar at the top of levels) issue fixed... wanna see the code that was so difficult to figure out?

After loading the PCX image dimensions from the file header:
height++;
width++;

Yeah... spent hours rewriting that thing yesterday...

Just gotta get RGB based files loading now, then it's just easy boring coding assigning stuff to stuff. I got the palette loading properly aswell, so that's cool. I was actually looking through the palette, and it seems that the first palette entry is the empty block color, the second palette color is the first NEW_CUBE entry, the third palette color is the second NEW_CUBE entry, seriously, it's looking like it's gonna be that easy. If I figure out the RGB loading thing, I'm maybe a few days work from getting a working viewer. Unfortunately, not sure how much time I'm gonna have over the next week either.

Edit: Verrry close to getting RGB based PCXs loading now:
Screenie.

Edit 2: All PCXs now load completely flawlessly.

PS I now have all textures and palettes loading in the background. Once I get Cube definitions loading (slightly time consuming and really boring), this thing is gonna start looking a whole lot like Sonic Xtreme.

 

Sorry about double post, but I kinda wanna bump the thread for a minute.

Anyone know how the scales work in the DEF files? They're labelled Size/Offset, so do I move them or scale them, quite confusing. I'll probably figure it out eventually but it's freezing here (17°C inside, -5°C outside) and it's distracting me from programming, so I figured maybe someone else might have some insight. This is what the scales look like:

Code (Text):

1.     Value   016,-64                             //X Size/Offset
2.     Value   017,-64                             //Y Size/Offset
3.     Value   018,-2097264                    //Z Size/Offset

The first value is an identifier to let the executable know what variable is being given, and the second is the actual scale, but I can't exactly scale the cubes by -64... usually scaling works by multiplying an objects size by an variable, so if you want something half the size, you multiply by 0.5, but with this, it's got me all confused. I mean, 64/256 is 0.25 which sounds like a sane answer (256 is the max 8bit number). Hell, this is the DEF entry for a ring, so it even makes sense to make the cubes super small on the Z axis, but it doesn't look like it would work for the rest of the cubes...

PS Has anyone visited this site on a PS3? There's an... odd forum background. I thought the site had been hacked but it's been the same for a while now.
PPS Screen of working PCX loading.

 

I'd thought it'd be the offset of the block, going by your comment there. I mean, -2097264 doesn't exactly make sense for a scale, anyway (aside from the obvious negative scale issues, it doesn't appear to be especially related to any number).

How are those numbers stored? I'm assuming they weren't naive enough to store them as a string. 32-bit signed integer? Floating point? (Unlikely floating point; big-endian for that bit sequence produces NaN, little-endian produces -1.0092488604318212e-28, which is a little silly.)

 

Yeah, they've got to be offsets... otherwise it's gonna take a little figuring out. Though, now I take a look at the newest version of SANiKs viewer, it does look like those values control scale somehow.

The little bit I copied into my last post is actually directly copied and pasted from the level files, but it does seem like they were using signed ints.

Edit: I seem to have hijacked this thread. I'm gonna make a project topic I think.