Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

EgonOlsen

[java] Software 3D API - testers needed

This topic is 5817 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, i just finished a first preview version of jPCT, an API for doing software-rendered 3D graphics in JAVA (1.1 or higher). I''m now looking for some people who want to have a look at it, play a little bit with it and give me some feedback (what''s good (prefered!), what''s bad, wishes for future versions...that kind of stuff). The current preview version includes a jar-file with all API-classes (the source itself is NOT included), the documentation for the API in its current state and a simple example with source. So if you are interested in it, here is the URL: http://home.t-online.de/home/helge.foerster/pre/jpct.zip Other stuff made with jPCT (using an earlier version of the API) can be found here: http://jpct.de Any kind of feedback will be appreciated.

Share this post


Link to post
Share on other sites
Advertisement
I checked it out this afternoon-

The demo ran at ~10 fps on my P3 866 jre 1.4.0 ie 5.5

Tearing and flicker was incredibly bad; I noticed the demo wasn't double buffered though, why not? I was also impressed that entire library wieghs in at a fly wieght 102kb. I'm guessing with environment mapping turned of on the spheres you would get a BIG increase in fps? Haven't read over the documentation yet though but looks very impressive even more so since its jdk 1.1!

EDIT:
I reran the demo and this time I got around 20 fps; I also looked at the code alot more closely and yes, its is double buffered if you consider that the FrameBuffer is the first buffer; maybe a third buffer would eliminate tearing?

[edited by - nonnus29 on June 28, 2002 10:30:45 PM]

Share this post


Link to post
Share on other sites
I don't think that a third buffer would help here. To eliminate tearing, i would have to use a kind of syncronization with the monitor's refresh rate and i honestly don't know how to do that in Java (i don't think that it's possible...maybe when going fullscreen...) :-)
At the moment, the image is rendered into a backbuffer and then displayed on the component of your choice using drawImage(). I never noticed a problem with tearing on any machine i've tried.
What will flicker for sure are the counters in the upper right corner and the version info text in the lower right. This is because they are simply drawn over the displayed image and not into the backbuffer. If anyone tells me how to get the Graphics-object of a memoryimagesource, this could be changed.

Edit: I retested the applet on a Win98 machine using SUN's Java plugin 1.4.0 and i now know what you mean by "flickering"...it looks really awfull using this combination. But i don't know why...it looks fine when running the same setup under Win2K...strange...i'll have to investigate, but many thanx for the information.



[edited by - EgonOlsen on June 29, 2002 5:43:03 AM]

Share this post


Link to post
Share on other sites
You could be right about the third buffer fixing this problem albeit it's not what i would call "tearing". It's just that an unfinished frame is displayed when update() is called by anyone but the applet-code itself. This is no problem under Win2K (it simply doesn't happen) but under Win98 using the JAVA-plugin, update() seems to be called like there is no tomorrow (i really would like to know why....???). I uploaded a "fixed" version where i've overwritten update() with nothing and putted the drawing-stuff in my own method. Anyway...i'll have to look for a better solution (i really don't want to use another buffer because of the memory that would eat up).

Edit: The problem with the flickering using the JAVA-plugin under Win9x resulted from the fact that calling repaint() and putting the actual drawing in the update()-method just scheduled the repaint to be executed if other tasks permit it. This seemed to happen more or less immediatly under Win2K...but not under Win9x. So sometimes (quite often...) a framebuffer was painted that was already used in the process of rendering another frame. In addition, update() seems to be called under Win9x quite often with no need by the VM (or by whatever). I tried to use an additional buffer as you suggested. That worked, i.e. it helped to avoid the flickering, but (a big but..:-)) it didn't fix the strange update()-calling under Win9x. update() was called everytime i moved the mousepointer over the applet and repainting the image from the frontbuffer everytime caused the applet to come to a complete halt. So i'm still using my own update()-method called myUpdate() in the demo-applet and paint() and update() are empty. So far, so good...but why in hell is update() called if the mouse moves over the applet (only under Win9x, not under Win2K). The mousepointer is hardware accelerated...there is no need for the OS or the VM to update the pixels underneath it "by hand" when it moves. This is ridiculous...

[edited by - EgonOlsen on June 29, 2002 4:05:41 PM]

Share this post


Link to post
Share on other sites
I''ve noticed some very eratic behavior from the jre 1.4 in the past. As far as performance of your library under 1.4 maybe all the old deprecated 1.1 stuff is becoming corrupted in the new jre.

Share this post


Link to post
Share on other sites
Well, who knows...but the library itself doesn't use much "deprecated stuff" at all and if run in applications (there is one available for download on my page) it performs great under Java1.4. The applet used to use the standard repaint()/update()-overwrite-mechanism, but because i'm not using any GUI-elements from AWT or Swing in it, it's not a great loss that i'm not using these methods any more in the newest version. Anyway, a bad feeling remains...
Any comments other than these (but thanx again for discovering this problem even if it's more related to the demo-applet and not to the API itself)?

[edited by - EgonOlsen on June 29, 2002 5:30:58 PM]

Share this post


Link to post
Share on other sites
Really nice work!
I get about 20 fps on a 733MHz PIII, 384Mb ram, WinNT 4.0sp6a, jre 1.4.0, IE 5.5. The number goes down to 7~8 if I turn on all the options.
And no "tearing".

Really a good job

D-

-----------
Érdely!

Share this post


Link to post
Share on other sites
quote:
Original post by princec
very impressive!
Er, please can you implement a mini-GL as well?

Cas

Cas


Doesn''t GL4Java do that already?

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!