Sven Goethel wrote:
> On Friday 16 February 2001 18:31, Artiste on the Web wrote:
> > Sven Goethel wrote:
> > > On Tuesday 19 December 2000 15:38, Artiste on the Web wrote:
> > > > Arkanae is a 3D game, developped with Java and GL4Java.
> > > > The 0.2.1 version of Arkanae is available here :
> > > > http://perso.club-internet.fr/b_lamy
> > > >
> > > > This new version includes bugfixes, graphic settings, german
> > > > translation, and spellcasting with incredible 3D particle system
> > > > effects
> > > >
> > > > :-)
> > > >
> > > > PS to Sven : In the game, I use by default a the yield() method to
> > > > suspend the rendering thread; an option allows to use a sleep(1).
> > > >
> > > > A11W
> > >
> > > Dear A11W ;-),
> > >
> > > i checked out arkanae - it is getting greater and greater,
> > > with gl4java 2-5-2-0-test2 prerelease !
> > >
> > > well, the rendering acts cool (with a sleep or not),
> > > but i got not keyboard action :-(
> >
> > Yes, i have had the same problem but now it's OK !
> >
> > I have forgotten a "gljFree()" after the code that dump the OpenGL
> > version/vendor/... (that call "gljMakeCurrent()" before dumping).
>
> hu .. thanxs, I got into coold sweating ..
>
> > > i would love to see you testing the new gl4java,
> > > to make it more stable ..
> >
> > Now 2.5.2.0 runs very well.
> > But i still get this printed on the console :
> >
> > GLContext.loadNativeLibraries ...
> > GLContext.loadNativeLibraries will do it !
> >
> > ???
>
> ;-) it is a test release ;-)
> i missed this .. I delete it now, thanxs !
>
> > > well, i guess the usage of no-repaint with usesleep
> > > should be the default for now, it is quiet stable and thread safe.
> >
> > But what about speed ??? Yield is quickier than sleep, no ?
> >
> see below .. the quickness of yield is, that YOU USE the
> cpu at max .. see below.
>
> > > the use sleep fps with about 25fps may be importent,
> > > if you do not want to give all the cpu power to the renderer ...
> >
> > Hey !? That's what i want : to give the maximum of the cpu time to the
> > 3D ! And only as few as possible for handling events,...
>
> oh sorry, your eyes are better than mine - or guess what ;-)) ?
>
> fps - addicted ?
>
> well, you can not see the difference of a fps 30 - infinitve .., I guess so,
> may be it will start just at about 40 fps ..
> But why spend all the power of the cpu, just to achieve 100 fps (thats what I got ...).
> Just to have a new heating system :-) or spending energy ?
>
> Well, in the future, you may add some intelligence AI to the enemies,
> so theire AI needs cpu either (may be much more than the dumb rendering ..).
>
> So .. setting a convinent maximum grants you power for other tasks.
> Also .. the player may own just one linux-box,
> and wants to play the game but wants to compile other things also ..
>
> So why stealing the cpu power if unneccessary from the global ressources ?
>
> .. well just my 5 cents :-)
>
> > Do you kwow about this class : java.lang.ThreadLocal ?
> > I've just discovered it today, it is used to create thread-local
> > property (=with a different value for each thread). What about making
> > the current GL context of a thread a thread-local property ?
> > Just an idea...
>
> because you may want to share the context between NATIVE THREADS !
>
> it is about, that the ctx can be used for one native thread at a time !
>
> of yourse, you are able to lock the ctx to one thread,
> you can do this today, just do not call gljFree() :-),
> than nobody else will get this ctx while trying it with MakeCurrent !!
>
> you allready know these .. (the keyboard - AWT lock, the AWT thread was
> set on the waiting state, while requesting the locked - never be freed ctx) !
>
> > And maybe a suggestion : don't free the context at the end of display()
> > (= after we have done with it) but before another thread use it. So if
> > only one thread use the context, it is never freed => speed boost.
>
> see above: you do not have to call gljFree() ;-),
> then nobody will get the ctx ;-)
> may be it is about the easy design ...
>
> the OpenGL definition says, that the implementation of:
> glXMakeCurrent(display, drawable, ctx) // our native part of gljMakeCurrent
> and
> glXMakeCurrent(display, None, NULL) // our native part of gljFree
> should not use much ressources (-> cpu) !
> So it must be safe to use it for thread safety !
>
> Well, for Win32 and others this MUST be the same !
>
> So my Idea: Only call gljFree, if you really want to use OpenGL in one
> special thread ! Then just call gljFree() only if this thread is it's creator thread.
> The creator thread is the thread who calls init(), usually the AWT thread !
>
> The other problem:
> One thread can not unlock the ressources (monitor) of another thread
> in java, and native (e.g. OpenGL's threads restrictions) !
>
> So: How it is is the way it goes ..
>
> - --
> mailto:sgo...@ja...
>
> www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/
>
> voice : +49-521-2399440; fax: +49-521-2399442; icq-uin: 108264795
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE6jyHzHdOA30NoFAARAr/sAJ0YxuEdOccAev0Fk0P8oIbMvtw2PgCfQ2yv
> dIwg77qoKN4tCU8FgsYrSIs=
> =F0Ej
> -----END PGP SIGNATURE-----
|
