×

Discussion Board

Page 1 of 2 12 LastLast
Results 1 to 15 of 27
  1. #1
    Registered User
    Join Date
    Apr 2003
    Posts
    2

    Possibility 3D on series 40/60

    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. #2
    Regular Contributor
    Join Date
    Mar 2003
    Posts
    72
    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. #3
    Registered User
    Join Date
    Apr 2003
    Posts
    2
    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. #4
    Registered User
    Join Date
    Mar 2003
    Posts
    12

    Spinning Cube

    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. #5
    Registered User
    Join Date
    Apr 2003
    Posts
    2
    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. #6
    Registered User
    Join Date
    Jul 2003
    Posts
    3
    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. #7
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    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. #8
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    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. #9
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>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. #10
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    >>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.

    keep us posted with your iso engine -- reads really interesting

  11. #11
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>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!

    >>keep us posted with your iso engine -- reads really interesting

    what exactly is of interest for you?

  12. #12
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    >> 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. #13
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    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. #14
    Registered User
    Join Date
    Jul 2003
    Posts
    5
    >> 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. #15
    Regular Contributor
    Join Date
    Jul 2003
    Posts
    53
    >>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
  •  
×