# Thread: Possibility 3D on series 40/60

1. Hiya,

I'm planning for my university honours project and I've been toying with the idea of trying for some 3D graphics rendering on my little 6100.

I don't know the real specifications of what these phones can do, it's kinda hard to find the real stuff I need to know. This one's to the people with the experience on the phones - is there enough power in there to do the math and get even a spinning cube?

As you probably worked out, I haven't had time to look through the docs thoroughly yet (bogged down in work) so I may have asked one too many stupid questions already,

Thanks in advance for any input all the same

2. doing a spinning cube will be possible on the 6100. be it flat shaded or wireframe. i did a test with a 30/40 polygon object. flat shaded with some pretty basic polygon sorting.it was qutie slow to draw,but if you use yuo keep your polygons tripled and use filltriangle then i guess it is ok.

3. are you optimising anywhere or is this a quick and dirty effort? If it's running slow optimised there might not be a lot of scope for me to work in - on the other hand if there's room for improvement it could make my project really interesting!

thanks very much for your input btw, very much appreciated!

4. Could you possibly post the code (or mail it to me) you wrote for that spinning cube? I am interested to see it. I actually have a cube (only 8 polygons though, 12 vertices) which spins quickly enough, but at certain angles, it "tears".

5. one thing to remember is that J2ME midp 1.0 doesn't support floating point numbers. Therefore to properly do the trigonometry involved you'll need to write your own floating point class.

good luck
Giles B

6. look at flipcode and gamedev, they've got lots of tutorials based on the old DOS demo days. This kind of basic 3D has been done to death, all though it's interesting if you've never done it before

7. Giles

>>Therefore to properly do the trigonometry involved you'll need
>>to write your own floating point class.

No, you don't.

Fixed point math is the "secret" - easy to implement, fast and enough precision, if done properly.

8. if you use the Nokia UI API it's trivial to do with drawPolygon and fillPolygon. the math has been done a million times so you can get a ton of examples for that. you can convert to fixed point math for the floats and precalculate sin/cos with your calculator and put the values in a table. i did a version first with shift operations for fast math until i discovered that the kvm is actaully pretty fast at math -- no need to do that. what i'd like to know is how to get callSerially to work so you don't have to use a separated thread -- i guess i'm too stupid but i went over the examples and it didn't work for me. also since midp 2.0 doesn't have the polygon functions it'd be interesting to get it to work with fiillTriangle. also, if anyone has done anything along the lines of isometric tiling it'd be interesting to read about those experiences too.

9. >>precalculate sin/cos with your calculator and put the values in a table
Correct - we are using a single sine table with 128 entries (shorts) for degrees 0 - 90. All other angles can be easily derived from that table, as well as the cosine values.

>>drawPolygon, fillPolygon, fillTriangle
These are amazingly awfully slow, taking into account what they are actually supposed to do.
And flat filled polys are a bit outdated - I don't think there's much market for such games.

>>isometric tiling
We have such a game in the making currently.
You have two options here for displaying the tiles:
a) blit the tiles via drawPixels (transparently) to the graphics context each frame
b) have an offscreen display (larger than the screen), where you draw the tiles into once (software blit) and then blit the whole buffer back (drawPixels, non-transparent) each frame

(Of course, you can do some sort of dirty rect update when the screen does not scroll... )

While method a) uses less memory, we are using b) because it is much, much faster. Since the offscreen buffer is larger than the display area, all you need to do is to blit the strip of tiles coming into view. And you can optimize the tile blitter, so you can avoid transparency testing at all.

10. >>these are amazingly awfully slow, taking into account what they are actually supposed to do.
And flat filled polys are a bit outdated - I don't think there's much market for such games.

wasn't done for a game -- was done for one of the labs for a developer training course for beginning J2ME programmers. actaully even drawPixels is relatively slow as is any call that makes a native system call -- write to Symbian in C++ if you need that sort of speed! however things that can be done in the kvm -- e.g. crunching numbers -- is pretty decent.

11. >>wasn't done for a game

point taken

>>actaully even drawPixels is relatively slow as is any call that makes a native system call

Don't agree - drawPixels() is pretty decent if used properly.
There sure are situations where hand-made software blits outperform drawPixels().

>>write to Symbian in C++ if you need that sort of speed!

Symbian...yuk!

what exactly is of interest for you?

12. >> what exactly is of interest for you?

any assumptions that you made and anything that turned out to be less than obvious from when you started also what physical devices you're testing on and the perfromances thereof would be interesting too.

13. Physical Devices:
We have one of each individual model (3510i to 3650), you simply need that when developing commercial games.
The best device currently imho is the 7210 (stable, compatible, good performance), the 3650 is pretty disappointing...
Be sure to lock your game to a fixed frame rate, then you have (almost) the same performance with the emulator.

Assumptions vs. Reality (I am talking about game dev.):
I could write a book about that...
I think one of the most important things is to avoid the MIDP API whenever possible.
While the Nokia API is very decent compared to other vendor's APIs, try to do things yourself to get the functionality and performance you need. Roll up your own timing, software blitters, fixed point math, polygon engine, etc.
Break down the functionality you need to the bare minimum and go for maximum performance and small memory footprint.
This breaks design patterns, makes Java devotees cry, but at the end of the day, gamers don't care about how super-elegant a game was written, they care about the experience.

just my 2 cents

14. >> the 3650 is pretty disappointing...
yeah i noticed that too. we use the 7210 and 3650 for testing and i thought that the same vendor -- telica -- implemented the kvms for nokia phones -- maybe nokia changed vendors?

>> I think one of the most important things is to avoid the MIDP API whenever possible.
interesting how much of an impact did you have with JAR size? the network operator we use for ota testing is pretty stingy about jars.

>> This breaks design patterns, makes Java devotees cry,
LOL!

thanks for your input. since i'm writing training courses for programmers that covers the entire midp 1.0/2.0 and Nokia UI, i don't get a lot of oportunity to deviate -- it's pretty boring and not that fun. maybe i'll take your tips and experiment with something fun

15. >>interesting how much of an impact did you have with JAR size? >>the network operator we use for ota testing is pretty stingy >>about jars.

Surprisingly (well, not really - the code is very tight and optimized) not too much.
To give you an idea, the entire software blitter (8 different blitters, plus animation, plus zoomed sprites) lives in around 2,5 K.
Our polygon engine (n-gons, color, texture mapped) uses 2 K.
We can live with that.

>> This breaks design patterns, makes Java devotees cry,
>>LOL!

Yes, listening to extreme C++ and Java fetishists is one of my big hobbies...

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•
Nokia Developer aims to help you create apps and publish them so you can connect with users around the world.