So, if Kirk can make a grapher that goes faster on the TI-83 than the TI-89, then should TI consider this and try to make theirs faster? It's not like the speed of the TI-89 version bothers me or anything, I'm still excited to see 3d objects, it's cool. Unfortunately, it's for a model I don't own (and I know it's not going to be ported to the *gasp* TI-82 *gasp*, so oh well, but I must say it looks nice)

Yah, I agree. I'm kind of pissed that a FLASH APP on a 2 MHz TI-83+, goes faster than a built in function on a 12 MHz TI-89. I hope TI looks into this. But in the meantime, now I have a 3D graphing program for my 83+ if in calculus my teacher says TI-89/92+/V200's are not allowed on tests.

Just FYI, a normal 83+ runs at 6mhz, not 2... so the comparison isn't quite as bad as you thought =)

The speed difference is most likely due to two things: TI's was written in C; and I'm pretty sure TI's uses floating point math for the polygon filling. The first they probably won't fix, but the second... they might. (Um, I doubt it.)

And the 83+ SE runs at 15 mhz, so it isn't a terrible suprise that it is faster on them. Yay for 83+ SE ;)

Yay for TI-83+SE! ;-)

Yay for TI-83+SE! ;-)
Yay for Kirk Meyer!
PARADE for EVERYONE ON TICALC.ORG!

great. I inadvertantly started something.

PARADE for inadvertantly starting things! jk

LOL... wonder if I should keep this going or not... ;-)

PARADE! TO KEEP THIS GOING!

0RDER! to st0p!

Actually this looks more like a PYRAMID! than a PARADE!... but that's just me thinking abstractly.

PARADE! FOR PYRAMIDS!

Wonder how long this is going to go... hope it doesn't take up too much bandwith, but it still looks neat

Oh no... *rolls eyes*... HEY! MY CONTACT FELL OUT! Guess I shouldn't roll my eyes (j/k, my contact won't come out even when I want them too... I should be quiet now)

PYRAMID!

PYRAMID!

You don't want Michael Vincent to scream at you. Eh Mike Vinny? jk

PYRAMID!

PYRAMID!

PYRAMID!
PARADE! FOR EVERYONE! (except for no_one [j/k] and ac [not j/k])

PYRAMID!

PYRAMID!

PYRAMID!

ya, it does run a 6mhz, but it is a different type of processor than the 89 and 92 and 92+ and v200, that isn't as powerful, so, technically, it is less than half as powreful as an 89.

correct me on any of this if i'm wrong...

there are more variables in the speed than just the speed of the graphing function, for example:

The amount of pixels that have to be calculated, which is also dependant on the xres= setting

There may be more technical reasons why a 3D graphing prog would go faster on the 83+ than on the 89, however... I don't know them :)

but thanks for the great program anyway ;) (I'm assuming it's great from everyone else's responses... I don't have an 83 to test it on...)

Yah, you're right, the TI-83+ only has to calulate for 88x64 pixels, while the TI-89 has to calculate for 160x77 pixels (the whole screen is 160x100, 33 pixels take up the menu and message bar)

64*96

Sorry, I sold my TI-83+ about a year ago and I don't access that nueron of my memory very often :)

Out of curiosity, is that supposed to say 'Chemoatotroph'? If so, what is that?

I believe it's something that makes its own food using chemicals instead of light ... most bacteria that live in extreme conditions (no light, high temperatures) do that.

Then how is he accessing ticalc.org? (j/k)

lol

Yes, it says chemoautotroph. A chemoautotroph is a proakaryote that makes it's food out of inorganic material. guiltyspark is correct, it does live in extreme temperatures.

Whre in the world did you learn that?!

Biology ... and I believe that either this month's or last month's issue of National Geographic had something about chemoautotrophes (I think I spelled it right).

Wow, that would be nasty in a spelling bee...

you actually read the National Geographics? I only use them for projects in school. Whatever more power to you.

Yep. I subscribe to National Geographic. The pictures are cool and so are most of the articles (I say most because I have no interest in the ones about the different ZIP code areas).

N0w, y0u're sm@rter th@n us.

Of course I could go on an ego trip and say yes, but I don't feel like it. Then again, my opinion has absolutely no effect on your's.

But, you're still probably smarter than me, because really the only subjects I'm good at in school are Math and Computers (that goes beyond the classroom too). But everything else, I really have to study at to get A's in.

It would still be much faster if the Z80 code had to draw to a screen the size of Voyage's. Also, my polygon filling routine would be even more suitable for the 68K processor, so if someone were going to make a new 3D grapher for the 68K calculators (no, it's not going to be me), I expect that it would be lightning fast.

How do you draw the filled polygons so fast? Do you work with triangles or quadrilaterals instead? I have a polygon routine which can draw up to 257-sided n-gons that are horizontally convex. For this, I use a virtual screen where I draw the outline first, then this information is used to draw the actual scanlines. The speed of the routine depends mostly on the vertical dimension of the polygon, but it's usually unbearably slow (you can see it working in the car selection screen of Death Rally)... It's still hard to believe that you can get around 300 polygons per second.

I'm full of questions today. :) What I'd really like to know is how time cost is shared among the various stages of rendering (I mean phases like 3d calculations, sorting, polygon drawing etc).

I employ the following method to fill quadrilaterals:
1) Calculate numerical (X,Y) coordinates for each scanline of the polygon (using Bresenham's line algorithm). This is very fast. Note that you're calculating 4 pixels for each scan line... one for start of line 1, one for stop; one for start of line 2, one for stop.
2) Fill between the (X,Y) coordinates in the list for each scan line appropriately. Using a lookup table and some optimization, this can be sped up a lot.

This same method could be used to fill triangles (filling triangles is a lot easier anyway). Could steps 1 and 2 be interleaved for even more speed? Yes. But my evaluation was that it wasn't worth the horrendous code that would've been required.

Currently time is about 50% rotation and 50% polygon filling (obviously different if you do wireframe). Sorting in this case is very very small because a 3D graph is sorted by nature... You just have to find the farthest corner.

A note about the speed: it's about 500 quadrilaterals per second, but they're usually pretty small; the speed decreases if you graph soemthing such as Z1=10-20*(X=10), which has really huge vertical polygons.

Oh, and how many bits do you calculate with? 16:8 fixed point...?

Wow, I think I wasn't too clear. To speed up your routine, use a point list rather than a virtual screen (*much* faster), and also be sure you've optimized it well.

Of course this is the right way. But laziness sometimes takes over when you have a ready made line routine to play around with. :) Actually in my PC projects I used simple one dimensional arrays to store edge information for quadrilaterals, and no temporary storage at all for triangles.

It seems odd though that you store Y coordinates as well. (What for?)

Nice job anyway.

I don't store Y coordinates actually. I was just explaining the generic concept =) I was going to use an XOR buffer at first (perhaps this is what you do), but it was rather slow. It does allow pretty patterns though.

The points themselves are 6-bit numbers, plus sign. The matrices are maintained as 14-bit numbers, plus sign. Only the upper 6 bits of the matrices are used when projecting points; the lower 8 bits are so that the matrices don't degenerate wildly.

BTW don't worry about clarity, I have quite a bit of experience with 3D programming. I just like to know how others prefer to do certain things. It freshens my mind, or how should I put it... :)

What did you program the application in? If it's the TI-FLASH SDK, I can port it easily to TI-89/92+/V200, if not, well, I know nothing about ASM and don't want to learn.

It's in ASM (TI does not support C for 83+). C on a Z80 is usually lethargic, but especially so for something like this.