Confussion

Hi.

I have started to learn more about 3D mobile developement, but I am a bit confused. Ive read about M3G (JSR 184) but that API isnt support many devices, the doubt is Ive seen some 3D games in devices that arent supported by M3G, how is it possible? Does exist another engine, or something like this?

Mascot 3

Also, using manufacturer extensions (such as Nokia’s) there is nothing stopping you writing your own - though it’ll be dog slow in comparison.

Some games use clever cheats in software to do basic 3D (eg Tomb Raider on the Nokia NGage).

Some games use 3D hardware on the phone from native code through vendor specific native APIs or emerging native standards like oglES

Some games use 3D hardware on the phone from Java through vendor specific Java APIs.

Note that a JSE for a Java binding to oglES is in progress.

Ive seen a 3D game running in old phones like 7210 (nokia), 3100(nokia), C650 (motorola), ... By chance do you know an engine that enable to develop application for old devices ? Ive found an engine called DIET3D, but I`m not able to use that. Have you ever head about that? Anyone can use that?

thanks

Had a quick glance @ the MIDP1 Diet3D implementation.
It won’t be very scalable for complex scenes (or for any rendering more complex than flat shaded triangles), as it uses Graphics.drawLine to perform the rasterization of triangles.

For MIDP1 devices a more scalable solution is to rasterize the scene to a byte[] (with the necessary png formatting wrapper).
This avoids the overhead of the many calls to Graphics.drawLine (replacing it with far cheaper array accesses), but adds a fixed cost of having to regenerate a png image every game frame. (and for phones that check the png’s CRC, the added cost of having to recalculate the CRC value every frame also)

Once you have eliminated the overhead of calling Graphics.drawLine to perform a single pixel change, you can consider adding better effects to your rendering engine. (lighting, gouraud shading, zbuffering etc etc)

Infact, using this approach is a great advantage from a development perspective also, because you can simply adapt code from software 3D renders designed for the Java1.1 J2SE platform. (as these are all designed to operate on pixels in int[]'s).
For example, it would not be a huge task to write a J2ME interface for the Anfy 3D Software Renderer. (This is just an example, as the Anfy Engine is ofcourse licensed. There are other Open Source Java1.1 3D engines.)