Show Posts
|
|
Pages: [1]
|
|
1
|
Java Game APIs & Engines / Java 3D / Re: performance of own SDK 3D engine
|
on: 2004-06-02 11:37:06
|
|
I see what you're getting at - but in that argument it's the frame rate that is the important thing - if the polygon fill the frame, you'll only need to draw 50-something of them a second...
In my case - I'm modeling terrain contours with arbitrary view perspective - the relevant perspectives are with hundreds to tens of thousands of polygons. The rasterization is around 30%-50% of the processing per frame, and the number of polygons is what drives the rest (the projection, culling and depth-sorting). Hence my measuring on number of polys.
|
|
|
|
|
3
|
Java Game APIs & Engines / Java 3D / Re: performance of own SDK 3D engine
|
on: 2004-06-01 16:13:12
|
|
If by alpha-colored you mean blended, it doesn't do that, or any other blending/shading/lighting, all polygons are simply rasterized with the color specified by the model. I may be adding lighting later on, but more advanced stuff I'm not going to spend time on at this stage.
It does do proper depth sorting though (instead of Z-buffering).
Forgot to mention - the hardware for this number is a 800MHz laptop with no 3D acceleration in it.
|
|
|
|
|
4
|
Java Game APIs & Engines / Java 3D / performance of own SDK 3D engine
|
on: 2004-06-01 15:24:10
|
|
Has anybody else written a 3D-engine using plain old Java SDK? I'm approaching completion on a simplistic but generally designed one and am curious about how it's performance compares.
I haven't done thorough benchmarks yet but currently estimate mine to render around 100,000 monochrome polygons per second.
|
|
|
|
|
5
|
Game Development / Performance Tuning / auto-optimization of small, known loops
|
on: 2004-06-01 14:07:27
|
|
I have a generically written geometry tree class, which can be instantiated for 1 or more dimensions (2 yields a quadtree, 3 a octtree, ...).
The number of dimensions is specified in the constructor, and assigned to a final instance variable.
Obviously, most geometry manipulations need to loop over the number of dimensions. These loops are mostly tight and straight-forward, and also straight-forward for me to override and optimize in an octtree subclass later on.
I'm curious though regarding the intelligence of today's dynamically optimizing VMs.. Are they able to unwind loops over small, final variables? Especially when the loops contain straight-forward, easily inlineable code?
/ Chris
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|