gl4java-usergroup

RE: FW: [gl4java-usergroup] animation stutters

[Peter <kaf...@xt...>]

> 
> > One definite difference between my code and JCanyon is that I'm not
> > using the NIO direct buffers, though OTOH I'm using display lists,
so
> > that shouldn't matter beyond the initial access.
> >
> 
> no, that is not correct. Java can move your vertex/normal/whatever
arrays
> around underneath you before your get the chance to call
glArrayElement
> (or
> similar). 


As I said in my post, I'm using *Display Lists*.  It doesn't matter what
happens to the arrays after the lists are made (altering the arrays has
no effect on the data stored in the list whatsoever)


>NIO direct (allocated through ByteBuffer.allocateDirect) buffers
> is
> the only safe way to use arrays that must remain at the same address.
So
> in a
> way you're lucky your display lists work.

Why?  The display list is made once, after which the address of the
original source data is irrelevant because the source values are stored
in the list.


> None of this applies to your problem with stuttering though.


Sorry, but as far as I can tell, unless you have a special version of
openGL with mutable display lists, then I don't think any of it applies
at all.

Cheers,

Peter.

RE: FW: [gl4java-usergroup] animation stutters

[Peter <kaf...@xt...>]

> Hi Peter,
> 
> Reading your posts on the list over the last few days, I've become
rather
> interested in what you are developing with GL4Java.
> 
> Would you care to share?

At the moment I'm just investigating gl4java.  I had some code in c++
which did landscape generation and rendering with some billboarded units
on it (like Myth).  It hasn't come too far - basic terrain, units on
terrain, selection of units and keyboard and mouse manipulation of the
world.

Ultimately I'd like to finish it - ending up with a game very much like
Myth with some extras - but at the moment I'm just investigating whether
it would be possible to do it in Java. I hope it is, because I really
think that Java in an inherently better language than C++, but my first
priority is to complete my game and not be a language bigot :o)  Hence
the investigations.

> I'm relativly new to software engineering, but am trying to spend all
my
> time reading all the latest articles at the mo...
> 
> I'm currently in the process of creating two applications based on
gl4java
> (both for final year uni course):
>     1) An edutainment application to teach a user how to build a
modern pc
> system (using 3ds max models).
>     2) An application involving the use of genetic algorithms to
create
> self-replicating, evolving biocreatures. [planning stages at the mo
> though].

#2 sounds like fun - genetic algorithms are really great fun to work
with.

Cheers,

Peter.



> 
> ----- Original Message -----
> From: "Peter" <kaf...@xt...>
> To: <gl4...@li...>
> Sent: Wednesday, October 30, 2002 7:08 PM
> Subject: RE: FW: [gl4java-usergroup] animation stutters
> 
> 
> >
> > >
> > > > One definite difference between my code and JCanyon is that I'm
not
> > > > using the NIO direct buffers, though OTOH I'm using display
lists,
> > so
> > > > that shouldn't matter beyond the initial access.
> > > >
> > >
> > > no, that is not correct. Java can move your vertex/normal/whatever
> > arrays
> > > around underneath you before your get the chance to call
> > glArrayElement
> > > (or
> > > similar).
> >
> >
> > As I said in my post, I'm using *Display Lists*.  It doesn't matter
what
> > happens to the arrays after the lists are made (altering the arrays
has
> > no effect on the data stored in the list whatsoever)
> >
> >
> > >NIO direct (allocated through ByteBuffer.allocateDirect) buffers
> > > is
> > > the only safe way to use arrays that must remain at the same
address.
> > So
> > > in a
> > > way you're lucky your display lists work.
> >
> > Why?  The display list is made once, after which the address of the
> > original source data is irrelevant because the source values are
stored
> > in the list.
> >
> >
> > > None of this applies to your problem with stuttering though.
> >
> >
> > Sorry, but as far as I can tell, unless you have a special version
of
> > openGL with mutable display lists, then I don't think any of it
applies
> > at all.
> >
> > Cheers,
> >
> > Peter.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Influence the future
> > of Java(TM) technology. Join the Java Community
> > Process(SM) (JCP(SM)) program now.
> > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
> > _______________________________________________
> > gl4java-usergroup mailing list
> > gl4...@li...
> > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup

RE: FW: [gl4java-usergroup] animation stutters

[Peter <kaf...@xt...>]

> thanks for the reply!
> 
> do you have a personal website with information regarding developments
> with
> your Myth game?  Any screenshots?

Sorry, no.  It's not much to look at now anyway.

 
> I too hope that it's possible to create a professional
game/application
> using gl4java (I really don't want to touch C++)  :)

C++ is okay if you use it like an OO language and avoid its zillion and
one unnecessary and inconsistent features (unfortunately, very few C++
programmers do).  My main reason for wanting to use Java is that I can
develop faster in it. 

> So have you played around with genetic algorithms before?
>

Yes - I did GAs in C a long time ago.


Peter.

RE: FW: [gl4java-usergroup] animation stutters

[Peter <kaf...@xt...>]

> On Wednesday 30 October 2002 20:08, Peter wrote:
> > > > One definite difference between my code and JCanyon is that I'm
not
> > > > using the NIO direct buffers, though OTOH I'm using display
lists,
> >
> > so
> >
> > > > that shouldn't matter beyond the initial access.
> > >
> > > no, that is not correct. Java can move your vertex/normal/whatever
> >
> > arrays
> >
> > > around underneath you before your get the chance to call
> >
> > glArrayElement
> >
> > > (or
> > > similar).
> >
> > As I said in my post, I'm using *Display Lists*.  It doesn't matter
what
> > happens to the arrays after the lists are made (altering the arrays
has
> > no effect on the data stored in the list whatsoever)
> >
> 
> Your arrays can be moved around *before* you create the display list,
and
> after you specify the array. To create a display list your would do
> something
> like this:
> 
> float[] vertex_array;
> int[] indices;
> 
> ...
> 
> glVertexPointer(..., vertex_array);
> 
> ...  <- It it here, between the array call, and the draw call that
your
> vertex
> data arrays can move around.
> 
> glDrawElements(...., indices);
> 
> And yes, that gap between glVertexPointer and glDrawElements is
normally
> very
> small, but believe me, it can happen.
> 

Oh, ok - I see your point.  Sorry - I misunderstood what you were
getting at. ;-)

Thanks for the feedback.

Peter.

Re: FW: [gl4java-usergroup] animation stutters

[Elias N. <na...@od...>]

On Wednesday 30 October 2002 20:08, Peter wrote:
> > > One definite difference between my code and JCanyon is that I'm not
> > > using the NIO direct buffers, though OTOH I'm using display lists,
>
> so
>
> > > that shouldn't matter beyond the initial access.
> >
> > no, that is not correct. Java can move your vertex/normal/whatever
>
> arrays
>
> > around underneath you before your get the chance to call
>
> glArrayElement
>
> > (or
> > similar).
>
> As I said in my post, I'm using *Display Lists*.  It doesn't matter wha=
t
> happens to the arrays after the lists are made (altering the arrays has
> no effect on the data stored in the list whatsoever)
>

Your arrays can be moved around *before* you create the display list, and=
=20
after you specify the array. To create a display list your would do somet=
hing=20
like this:

float[] vertex_array;
int[] indices;

=2E..

glVertexPointer(..., vertex_array);

=2E..  <- It it here, between the array call, and the draw call that your=
 vertex=20
data arrays can move around.

glDrawElements(...., indices);

And yes, that gap between glVertexPointer and glDrawElements is normally =
very=20
small, but believe me, it can happen.

 - elias