Hey Trembovetski - Thanks 

I will definately give that a try... at the moment I am quite busy with learning, so that will have to wait a little. Big thanks, that you asked somebody for it 

@Linuxhippy: 800mb/s seems impressive first but it is not so if you divide that value by the fps-count. Lets say by 40 - then we will have 20MB per frame. For 2D Animation like video etc. one has send data constantly to the gpu (I am not sure that I want to do THAT  ). Things like this will keep adding up if one does not care. I am not a hardcore optimizer and i would always prefer simplicity rather than speed - but needless copying is something one really should avoid, I think.

Hi trembovetski 

I heard that auto-vectorization is really a hard problem and that actually no existing compiler is good at it at the moment. Good to hear that there is work done on it. Personally I wouldn´t mind to write that code by myself, maybe for a particle simulation, skinning or something like that. Maybe java performance is just good enough - time will show - I haven´t pushed my machine to the limit up to now 
But when time has come it would be cool to have the opportunity.
Then there is always the tradeoff between speedup and native calling overhead, caused by JNI, to be considered. I suppose SIMD matrix multiplication wouldn´t  be  much faster than a java version because of that !?

What I really would appreciate is some improved capability to talk to native code, it would be COOL when java could at least partially have memory layout compatible to c++, maybe using structs or something like that. I had to do some workarounds in that area. But I understand  that this is not the main application area of java.

Thank you for your nice comments !

Ahh okay I see 

I had always thought that rasterization algorithms were written in java, because people
referred to swing as a pure java solution and being therefore more sluggish than SWT, which
has native drawing code.
So that is not entirely true.

Good to hear that Java2D uses native code  I also believe that native code is superior for that
kind of things, because one can use SIMD, which is cool, one can care for memory alignment and
cache utilization and of course graphics hardware acceleration.

So thank you all - you are awesome
wish me luck, so that I actually get something done 
Frederick 

[EDIT: major orthographic corrections  ]

Implemented the method with "getPrimitiveArrayCritical" - works fine so far, but of course I can´t check if an internal copy is made - lets hope the best 

Okay that´s too much work then. I had thought, because the raster has a pluggable DataBuffer it would suffice to exchange it.


 I really hope the JVM will inline getter/setter methods ?


I would really appreciate stack allocation too, but i don´t understand how it could help in this case. 

...I think I will stick with toms suggestion - everything else seems to be too complicated...

Hey!


I wouldn´t really like that, because I switched to Java because I want to program nice and cleanly 
That way I would inherit an array data structure and methods I don´t need - kind of a mess.


Thanks for the link, I might give that a try. I plan to use only modern VMs so no problem with pinning I hope. Still I would like to use the buffers, but...

Maybe I should file this as a bug report ? I would tend to call it a bug, because it is definetly not a feature *lol* Also it would please me to know, that I can render to any surface I like and the jdk supports this functionality - unfortunately only theoretically.

Hey Tom I am trying to do that 

But I believe the only way to access *ANYTHING*  via JNI is to put
it into direct buffers. I would never pass java objects down to c++, for
perfomance reasons. I believe it was a wrong decision from sun
(at least for my purposes) design JNI like it is now. It would have been
better if C++ could directly access java class fields and methods, even
if that would mean recompiling the dll if a new java version comes
around.

If I remember correctly the issue with accessing java arrays from c++
is that the arrays gets copied or something. I will have a look at that later.
Have to go to uni,

Thanks
Frederick

Okay I am a bit frustrated by now !

I found a way to solve that problem.

Sun engineers have nicely abstracted all properties of a graphics surface.

The key class is WritableRaster which uses a DataBuffer. A DataBuffer is an encapsulation of the actual data representation. For example the most used implementation of DataBuffer is the DataBufferByte which is implemented by a byte array. So the way to go is implement an own version of Data Buffer:


Very Easy uh ? 
Afterwards one has to wade through lots of other classes, there need to be surfaceformats and colormodels defined before it is finally possible to build an ImageBuffer.

This looks like this:
The BufferUtils class was written by me.

But then happens the big #!$5$!*

A class somewhere inside the jdk jungle complains that our newly introduced DataBuffer is not of byte type. What the *!& ? We have defined it to be of byte type by calling the constructor of the superclass with the apropriate parameter;


The type might be queried then with the DataBuffer.getDataType method.

Then I have a look at the implementation of this "ByteComponentRasters" class and what do i find



That makes me wanna cry ! They actually confused their design ! They are checking the actual class types, instead they should
have been using:
switch(dataBuffer.getDataType);

Oh nooo! I actually think that this is a bug and was not meant this way. No point in abstracting everything, so the system may nicely be extended, and then to allow only one type.

 

No more motivation to continue...

What do you think about this ?

Hey!

This is a java2d - opengl related question.

Basically I want to draw into a BufferedImage and pass that image as OpenGL texture.
I know there is a method to create a ByteBuffer from BufferedImage - it looks like this:



However this won´t work for me, because I need the buffer to be direct, the buffer retrieved
by this method is not direct. Unfortunately my JNI methods (yes thats right - I rolled my own    )
won´t accept non direct buffers. A hacky and a performancewise not so optimal solution may
be to copy the non-direct buffer into a direct buffer, but I really wouldn´t like my little program
to spend time on copying 

So is there a way to wrap a BufferedImage around a direct buffer ? Technically that should be
no problem...

    Incredible wrong ... ouch

But I have something to say for my apology 

I tried to understand in a way, that Java itself could be used to script the actions, but that is not possible, that´s
what I have understood by now.


In my ears that sounds like a step into the direction of an own custom scripting language. The "Actions" could be understood like bytecode instructions. I wanted to avoid to use another scripting language beside java, because I thought that java is a great scripting language by itself.  Your answers have shown that this is not possible and some kind of a custom script language should be the way to go. I also assured myself that perfomance in this case is really not a problem, because actions of this custom language are evaluated which such a low frequency that it won´t matter. The only issue is that I have an additional language in my project then, and I will have to decide where to use this language and where to use java. Java only would really be more like KISS

Thank´s a lot fletchergames, i think i got it now due to your very understandable explanation.



My initial question was how scripting code could be assigned and applied to non-player-characters and cutscenes etc. and if it could be
done with the java language, or if the use separate scripting language is necessary.
 I plan to execute the scripts single threaded, so there should be no problem. But you have a definite point there, if NPC´s were running
in different hardware threads bad things could happen because they all share the same world and may simultaneous remove the same object from
the world or the like.


Hi, i am not sure what you mean by state function, I know the term "state transition function" but I suppose you mean something different.


I am not sure what you are saying there, but you seem to have some kind of AI algorithm in mind, which is more complicated than what I want to do, for the beginning I will be very happy when I am able to realize simple scripted scenes.

I want to say thank you for all the answers - this is really a friendly and helpful forum !

Thanks that might be useful =) But I´d rather prefer not to include 3rd party code I haven´t written myself,
that´s what holding me back from Javaflow.


Hi fletchergames,

I think I didn´t get the idea with the flag quite right:


That´s not what you described !? Basically the method is called every timestep and already executed commands would be skipped. This would
become ugly when loops are involved -I woudn´t like that too much...

The problem with that is - I need the "slow-motion" execution. The VM does only execute the next command, when the action described by the previous one is completed - that may be several seconds. So I need to control the execution which is not possible to do with the JavaVM, which is the reason why I would have to come up with my own.

Maybe something not too complicated... just branches loops and commands - no highlevel features like expressions blocks etc.

Yes I see, I had a thinking error there, I thought that Java being a VM is similar to a scripting language VM, which can happily process on several scripts in one system thread. But Java is a jitted VM and that makes the case different so every JVM thread will require a system thread also, because when invoking jitted code the JVM looses control and can´t interrupt the execution - this can only done by the processor itself, so it has to use real OS-Threads. So I suppose those "virtual" JavaVM Threads, I thought of,  do not exist.
So using Java threads is not a solution.


That sounds like the first step into the implementation of an own virtual machine.
The problem is that a list of tasks may not suffice - one would like loops, branches and tasks build up from smaller tasks.

This could all be done with this approach - like



Phew... I would LOVE my own custom language at this point... even this example is exhausting :-)

At the moment I am tending towards the development of a custom language... maybe one without compiler - assembler only first :-)

Hi,

at the moment I am thinking about how I would breath live into my game objects. I am at an early stage of my project
but try to take these issues into account as early as possible.

I chose Java as a development language primarily because of the great benefits I hope the language holds in account
for content creation/level scripting. I plan to achieve that by loading classes at runtime.

Lately i ran into a problem, while thinking about AI scripting. I want to do NPC animation and interaction as well as
the GUI cutscenes etc. with the scripting.

I found that, what I really would like is to assign scripts to objects and let them do their work concurrently.

roughly something like this:



Well this is really simple, an actual implementation would look different - but I have never done that before - so
excuse my lacking experience =)

What I realized is:
- the execution is delayed, after the invocation of headTo an animation is started which will take some time. The
script should be freezed till then. After the animation has finished, the game engine or player object will execute
the next statement of the script.

The only way I can think of to do this in java is: threads.
Would it be a good idea to have lets say 1000 threads running ? Is there a way to have 1000 JavaVM threads, if
there is such a thing ? Threads on operating system level may be too costly.

Then the second thing is: How do the freezing ? Something like "stepping the vm".

I am not sure if this is a showstopper and I would have to implement my own scripting system *cough*

I know that I could do the animation with a Finite State Machine, but I would prefer to use them not, because
they are not comfortable. The most pleasing would be to program each object with concurrently running scripts.

I apologize for the long post,
I would really appreciate if someone could give me some input on this,
thank's
Frederick

Hi Riven,

I checked it - I actually used "FloatBuffer.allocate" and it works. So I assume LWJGL does some
wrapping internally. Out of my memory, there are function calls in the jni code, which possibly serve
this purpose.

wow! wow whoaaaa! 

That was lightning speed ! Thanks !

I did not get that nio buffers may be direct or non-direct. I assumed them all as "direct" accessible. I was so confused
because I used lwjgl before, which works with buffers allocated by FloatBuffer.allocate(). The library seems to wrap them
internally.

Btw. there was one small typo:

So "order" instead of  "byteOrder".

Complicated stuff... I would have had a hard time figuring that out on my own... so big THANKS to you!

Hi!

I tried to use the Java NIO buffers in a real simple way and it didn´t work 

I am doing this on the c++ side:



and that on the java side:



This is MEANT to work, but it will always return "Error" because  matrix* is null.
All code examples I found on the net were not different to mine.

I am using java 1.6  and other libs like lwjgl work - so its not the runtime.

But where is my mistake ? I am puzzled - theres not much to do wrong.

Help is very appreciated,
Frederick

[EDIT: I am using MSVC++ Express Edition to compile the c++]

  Ohh noo, I am a poor CS Student, I can´t I am not a compiler engineer, and they won´t le me,
at least I hope so, this job is not for everyone.

What I mean by flexible is reflection, dynamic class loading, dynamic compilation, easy combination
with script languages (groovy etc). Java has all this already, at least all I can think of a the moment 

Modern means thinking into the future, java was a real inventive language when it came up (GC and the
like), which is now getting more and more standard. Java should stay inventive, that´s what i wanted to say.
C# has learned from java´s past, why shouldn´t java also ?

Well, that´s the Microsoft way 
I think they are still testing out the language and experimenting, but in a few years when dust has settled, this
will look a little different, as usual with Microsoft.
I won´t say this is good practice, but sometimes some cuts have to be taken, just as in real life 


Sadly that´s not true. Maybe the opengl/java2d interaction is superior to everything ManagedDX and XNA has
to offer. My first impression of jogl was horrible, because I saw a lightweight swing opengl canvas. The gears
example was so sluggish, that i wanted to run away. (Okay that´s fixed now, because of accelerated Java2D).
The both Java Games i like the most at the moment are Alien Flux (Hey Cas, thank´s for your advice  ) and
Tribal Trouble.
The fact is Microsoft cares a lot more about graphics and games, that´s the success of their platform, I think. Although
jogl/LWJGL is longer around, there are much more XNA/ManagedDX tutorials, even awesome Video tutorials, which
explain how to create a game like RocketCommander. Thats much smoother to start with. Although I wouldn´t recommend
XNA at the moment, because it is under heavy development, and you´re at the mery of microsoft. That´s the biggest downside.

These two alone are better than any tutorials for  java I have seen, and theres much more.
http://www.rocketcommander.com/
http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series1/Starting_a_project.php

Sad but true.
Microsoft knows that they have to do the fun things to attract programmers.

As java is open source, it is more a community thing. What I mean by "we",  is the
open source community, which needs more attractive demos to catch developers, at least
that is what I think. Microsoft is very progressive at the moment, and I want java to be an
attractive alternative.

I am just telling my struggles. Its likely that others have them too. I am not telling you anything, I just tell
what I would like. I won´t do anything on that because this is *way* above my head. I just want java to be competitive
and performant, that´s all.

So I will sit down and work on code, but not on javas 
Frederick

Hey, thanks for the answers 


Okay thanks ! I will use this then.


This is the kind of articles which gives me bad headaches. I want to be confident
of the language I use, and don´t want to doubt it.
In my opinion Sun should really break compatibilty, add support for other languages,
implement templates proberbly, and maybe introduce value types or better escape
analysis. They could provide a "deprecated" hotspot compatibility mode running all
the all old code. I think engineers at sun could figure something out to make this changes
totally transparent to any user.
I want a flexible and modern language, in my opinion Java should be at the cutting edge
in contrast to be conservative all the time. Thats why I left C++ there is not much going on,
maybe it will support introspection in 10 years. 2009 Stroustrup will come up with the
design of the next gen C++, then another 6 years to implement it. So we will see C+0x, or
what its called 2015. I don´t want java to be like that.
I think Microsoft does a better job a this. They are really quirky at the moment, and they
have really cool graphics demos for C#, just look at "Rocket Commander" for example,
absolutely awesome. We need show off projects like that for java.
I want to use java, because its OpenSource and Sun is much nicer than Microsoft imho,
and its platform independent.

Okay i am writing to much, but articles like that do always give me headaches, which is bad,
i have to get some work done now 
Frederick

Of course I could pass as float, but this is not really acceptable for me,
because in my opinion a computer language is whole about abstraction,
and I really like it - so I want to use my vectors

Maybe I will reuse Objects...
At least under Linux I have performance problems with my gl driver. Even
simple output, that means a rotating polygon, is stuttering every four seconds
or so. C++ as well as Java, has nothing to do with the GC.
Windows seems to be fine. Thats much more serious than the GC problem.

I think I will not worry about GC and hope for escape analysis to come

Okay,

sorry I should have digged more into this forum  Hope you don´t bother 
Of course this is a well know problem...

And there seems to be no solution at the moment. Escape Analysis is not there
in jdk1.6 that was mentioned in some earlier posts. What I really dislike is
that there are lots of papers from Ibm and Sun that tell about cheap allocation
and Escape Analysis. When I read that, I thought *wow* is that ADVANCED -
really cool, and i was happy.
After actually trying out and finding that this cool features don´t work I am a bit
disappointed. 

Maybe I should just continue and don´t care about the stack, or go back to c++ *cough*
thanks,
Frederick

Hi!

i am a former c++ programmer trying to be more productive with java 

But I really worry about the garbage collection. What I really miss is stack
allocation. I read about escape analysis, which would be a superior solution
to manual stack allocation - if it would work. I could not get it to work in a single
case.

I use a writing style like:

Matrix m = new Matrix();
m.translate(new Vector(0,0,0.1f));

and the translate method looks like:
public void translate(Vector d) {
        x4+= d.x;
        y4+= d.y;
        z4+= d.z;
    } // easy, huh ?

works fine, but everytime a Vektor is allocated on the heap. If I´d write in C++, I would allocate
the Vector on the stack, and everything is fine.

I checked this an other examples in the netbeans profiler, and i always see the "sawtooth" like curve
in the heap usage diagram. Heap memory gets allocated till a threshold is reached, and then freed.
I think this is horrible for realtime graphics. Why do I read so much about escape analysis, which is
my hope in this case - and it simply doesn´t work ?

Do I have to reuse the Vector every time ? That makes the code way more ugly.

Thanks a lot, if anybody could clear me up about this, I would really appreciate,
Frederick

Thanks Ken !

that´s what I was looking for. I wouldn´t have made this up by my own.
Oh, maybe I am a bit stubborn, but I don´t like the listener-model for now.
Maybe because i don´t have the main loop "under my control". Maybe the
day I grasp why the listener pattern applied to OGL is a good idea i will use it.
I am a friend of KISS, you know ? And a single threaded rendering loop is
what KISS means for me right now

I saw that XNA is a little similiar in that respect, there are render, update and
init methods to implement.

thanks a lot,
Frederick

Hi,

I am a former C++/SDL programmer, switching to java/jogl.

What i would like to have is:

-fullscreen exclusive mode
-a single rendering/polling thread

I get some headaches getting started with jogl. I looked
at the "Killer Games Programming" book. The author explains
the active and passive framework. I really get lost in this simple (?)
example, that explains the active framework. Thats way too complicated for me.
 I really don´t want to start a seperate rendering thread. Is it possbible to do single-threaded
active rendering in jogl ?

SDL Programming was so easy, so should be Java programming, but it is much more
complicated. Maybe I should look at LWJGL, but then I would loose all this nice
helper functions, and the great backing of the people at sun. Thanks for that !

I really want to concentrate on my games - please help !!!
thanks,
Frederick

Hey,

thank you very much ! I am getting excellent informed at this forum. Thumbs up.
Thanks to all of you, thanks for the slide Ken.

To say in in my own words: The problem with standard java objects is, that they may
change their position in memory, because of garbage collection. The garbage collector
is running in parallel to the program, and also running in parallel to the invoked c code.
During the execution of the C Program, the GC may move the java object to another place in memory -
the pointer gets invalid.
This may be solved by:
1) pinning down the java object - let the GC ignore it
2)Disable the GC during native invocation

1 is difficult to do,
2 has inacceptable restrictions:
Example: a GL_BindTexture may invoke
a copying process from RAM to the GPU, which is running
in parallel to the C Program, which may return to Java, before
the copying is finished, and the pointer is in danger again.

So NIO is introduced.
At the heart a NIO buffer is buffer in unmanaged space, and is not affected by the
gc. This is the way NIO solves the problem.

Did I get it right?


I am not  a pro, so maybe I am wrong, but I really would have preferred to introduce them
"unmanaged" memory, which must be newed and deleted by hand, like in c - for java.
Perhabs an "unmanaged_new" operator or something like this. This would allow for
structured data - like objects etc. But its not there 

Thanks for your awesome help,
Frederick

Hey!

I am looking into jogl and lwjgl at the moment, and i wonder why
they both need the use of nio buffers. I know opengl from c++ programming;
if I wanted to pass data to a function, I passed the pointer - very easy.
Now in java, I have to create a nio buffer... very unused to me, feels really
strange.
My question is: Why exactly are these buffers needed ? I suppose because
of different memory layouts of java arrays and c arrays, is that right ? If I put
an int into an IntBuffer, the format of the integer gets converted from java to c ?
I had a look into C# and the Tao framework, and it seems they don´t need it.
Tao allows to pass C# arrays directly to GL, which seems to be much more convenient.

Maybe I am to picky about these things, but I don´t really like these unstructured
primitive buffers... they feel a bit like a hack, but maybe I am wrong - tell me, please 

thanks,
Frederick