Quote:Original post by McMcDonald
What do you mean with "fill-limited" and "vertex-limited" ?
McMc

Vertex-limited mean that frame rate dominated by number of all poligon nodes(vertices), that is in fact number of triangles(if you are rendering only triangles) on the screen. Fill-rate limited mean that frame rate dominated by number of of pixels drawn on the screen (how big is drawn area taking redraw into account). For example all early 3D videocards were fill-rate limited, and most of modern games on modern videocards are vertex-limited.

@ pkelly83:
in my expirience(Nokia 6600) drawing lines extremly slow. Anything else is faster. Of cause it's only if you are using API. With direct writing into memory it's all up to coder :) . However I may have explanation for you. It's possible that in Java fillRect not using native API function but instead use DrawPixel for each pixel in the rect. In this case fillRect should be slower. That can also explain why 6600/N-gage so slow in your benchmarcs - unfortunate Java implementation...

Quote:Original post by Woody FX
Abstract world you should know ?

Sorry I don't know. As I mentioned on the benchmark page, phone manufacturers aren't very informative about the inner workings of their hardware. I don't worry too much about series 60 performance, I spend most of my time worrying about the performance of the mass market Java phones in the bottom half of the benchmark results.

Quote:Original post by McMcDonald
My walls and sprites are textured

There have been a number of Java games that have taken this approach, 3D Adventure, StalkNShoot, The Infernal Gate, Hudson Blade, Mobile Force, Rogue Agent 3D, and I think that most of these games were only made possible by using Nokia extensions (e.g. direct pixel access), thus limiting the game to Nokia phones only. I think it would be difficult/impossible getting this feature working on all phones with standard MIDP 1.0. What mobile phones are you targeting?

Quote:Original post by pkelly83
which of these is slower

We opted for the fillrect over drawline, since it ran faster on some of the slower non-Nokia phones. It is very much implementation dependent, so you can either do it differently for different phones, decide at runtime with a small initial test, or go for a single solution that gives the best result across a range of phones. For our first game, which also had a MIDP 1.0 benchmark built-in, we opted for a single solution for fairer benchmark comparisons.

Quote:
There have been a number of Java games that have taken this approach, 3D Adventure, StalkNShoot, The Infernal Gate, Hudson Blade, Mobile Force, Rogue Agent 3D, and I think that most of these games were only made possible by using Nokia extensions (e.g. direct pixel access), thus limiting the game to Nokia phones only.

Not necesarilly. There's MIDP 2.0, the Motorola Game API, etc. that offer direct pixel access.

Doing it without direct pixel access isn't viable, that's for sure. I tried a triangle filler, with a variety of methods, and using drawLine()s or fillRect()'s to plot pixels is just waaaaay too slow (a few seconds per triangle).

shmoove

[edit]
the triangle rasterizer's if anyone wants to try (Nokia only) : http://www.brinkster32.com/shmoove/triangles.zip
[/edit]

I'll see if I can get sprites and textures working then. Should be fun! I've sorta got textures work already. Instead of using direct pixel access to images, I'm storing them in an array. Sprites are just going to be normal images.

on my 6600 it told "initializing graphics" and hangs...
Did you try to read from some hardcoded paths ? I installed on E:

You remember the sonic the craphog bonus levels in Sonic 2/3 on the Megadrive (Genesis)? Somthing like that might be easy for phone 3D games as it's all faked. Working away on a voxel engine now. :-).

Will post a texture mapping version of Raycaster in morning.