I've had no experience with macs, but did you try removing the -static flag?

See, I'm trying to figure that out, but for the life of me, I can't find the option that removes it! I figured out how to add the -dynamic tag, but not remove the -static one. I need the -dynamic tag.

So, I'm trying to compile IOUSBFamily-343.4.3.  It's difficult. I've almost got it, but it gives me this message that says that it can't be both -dynamic and -static. I don't have a clue what that means, but I know it needs to be dynamic.

So, I'm wondering how many xcode/mac users there are, and if anyone can help me with this?

No, I can't post code. It's the driver for USB on macs. It's available at opensource.apple.com.

Also, if you are an apple-hater, don't hate on me. ;-)

EDIT: For the record, the reason I'm doing this is because I'm adding data-logging to the usb device. If you know of a mac usb logger that is free, please tell me.

graphmastur, I did read your entire post

oh, okay. I just thought that you meant that you were worried your system was going to get destroyed. It's fine, either way.  Well, 23 days till KOS...

I'm sure he is busy with KOS and such. The only algorithm I know is that recursive fill program that he used. To prevent that wonderful stack overflow, what you could do is essentially find the points that haven't been filled in, and go back and do the algorithm on those.  The only problem is how you would find which places still need to be filled in. I guess you could go through the stack, and delete (set to FF or something) the points that have pixels in the 4 directions (left, right, up, and down) and have their pixel filled in.  Then "collapse" the stack by going through and basically skipping over any FF data and moving the other points down.  So, if Data A is at location 1, B at location 2, and C at location 3. B is deleted, so when "collapsing", go through and copy C into B, and turn C into FF.

Basically, this clears the stack up. If it's really complicated, then not many of your points are going to get cleared, and it's going to loop forever because it can't delete anything on the stack, nor can it draw any more points. The main problem with this algorithm, though, are two-fold.

1) I haven't tested it completely. I made something like it, but I'm not sure if it was that part of the algorithm that worked.
2) Considering you are doing sub( a lot, you basically have to delete both the point and pointer off of the stack. It's quite complicated.

Not sure what else to do, though.

That .gif file almost crashed my browser. (It doesn't handle huge .gifs well, and at 1678 frames, well, it's kinda huge) Otherwise, though, I think that's one of the best 3d engines I've ever seen. I can never seem to do 3d from a first person view. Only looking at a model or something.

Slower?

But will there at least be some much faster routines that will be practical in game dev like sprites or will it be like Bitmap in Axe? If it's too slow, maybe people will just continue writing their own routines.

You mention that SMC will make them faster the second time they run, though. Could you elaborate more on this?

IIRC, each program is designed to work starting at $0000, or the very first memory location, and all subsequent data is based off of this instead of $9D95 like in TIOS.  So, what Sir is doing, is finding the offset when the program is first run, and changing all the addresses to suite.  That's why it's slower the first time, but much faster other times.

What I want to know, though, is how SirCmpwn managed to do multithreading with l_calls that do SMC.

Yeah, I know Newton's method is slow to converge, but I figured with 3-4 byte numbers that it wouldn't be that bad. I don't know of any algorithms for square roots of BCD numbers, though.

sort of on/off topic, but Axe apps get erased after 16 runs? That's (sort of) a pain...(but it gets fixed after they've been signed on-comp, right?)

Essentially, yes. In reality, it's more that they get erased after a "trial period". The signature, IIRC, is only checked when the os is being sent.