hi, i am having a lot of trouble trying to load 3ds files using cocoa. ive looked at many examples/tutorials, and i understand the file format, but cocoa seems to be messing everything up. does anyone have any cocoa source code for 3ds loading?
thanks

When you say 'cocoa is messing everything up,' be more specific. What's going wrong?

apparently it is having trouble getting the longs that denote chunk length from the file data. it always gets some incredibly large number, many times larger than the file size itself. it does however seem to read the chunk id shorts properly. i am completely clueless why cocoa is doing this.

How are you reading the longs? Using standard C calls or NSData or what?

It's probably not Cocoa screwing it up. It sounds like a big/little endian issue.

http://www.webopedia.com/TERM/b/big_endian.html

Oooh, good call Bachus! I second that...

this is the code i use to try to find the length of the file(it is stored as a long starting 2 bytes in):
totalLength = *(long *)(buffer+2);
buffer is a pointer to a char which contains the file data

i did take a look at the endians before posting, but it didnt seem to have much effect. although im fairly inexperienced with endians, so i may have been doing it wrong anyway.

if anyone could just give some source code for accessing that long, or even point me over to an open source cocoa 3ds loader i would greatly appreciate it.

That code will fall right into endian problems. What you'll have to do is swap the byte order around. Try this code for longs. Then convert it for use in shorts, etc.

I haven't tested this code, it's off the top of my head

I think that should do it. Good luck. Fiddle with it until it returns what you're expecting

Apple's Endian.h header contains macros for doing endian conversions (search for it or look in the CarbonCore headers folder).

They're a bit different to Steven's, although his may still be correct, I haven't checked.

Why does each say

Quote:Availability:
* Mac OS X: not available
* CarbonLib: not available
* Non-Carbon CFM: not available

then?

I saw that, but it doesn't really matter whether or not the API calls are in Carbon because the relevant macros are listed at the bottom of the file.

your code doesnt seem to work, it keeps returning 0. but wouldnt it reverse the endian if i just read in the long backwards from the file?

Yes, or try this (again, from Apple's Endian.h):


Unless I'm going blind, Steven's code appears to rearrange 0x1234 as 0x3412. It shouldn't return zero, though - are you sure you're not doing something else wrong?

Quote:Originally posted by NCarter
Yes, or try this (again, from Apple's Endian.h):

Code:

#define Endian32_Swap(value) \
    (((((UInt32)value)<<24) & 0xFF000000) | \
    ((((UInt32)value)<< 8) & 0x00FF0000) | \
    ((((UInt32)value)>> 8) & 0x0000FF00) | \
    ((((UInt32)value)>>24) & 0x000000FF))

Unless I'm going blind, Steven's code appears to rearrange 0x1234 as 0x3412. It shouldn't return zero, though - are you sure you're not doing something else wrong?

thanks, that seems to work perfectly

Well, I told you that it might not be right, but yeah it shouldn't return 0. Oh well, use Apple's code