Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 4
1  Java Game APIs & Engines / JOGL Development / Re: Problem with JUnit and TextureIO on: 2007-08-21 19:15:31
You need a GLContext, and call its makeCurrent() method.  I reckon you should be able to create a context through GLDrawableFactory() (either associated with a window, or a pbuffer).

As Saxer says it might be easier to use the event listener approach, although the above approach (immediate mode?) might be better suited for unit testing.
2  Java Game APIs & Engines / JOGL Development / Re: Matrix class and FloatBuffer on: 2007-07-20 16:12:13
I guess it depends - my suggestion is to use a FloatBuffer internally, and provide an accessor to it (such as 'asFloatBuffer() : FloatBuffer').

Maybe I'm missing something but personally I don't think that this class would ever pose a performance problem.  Are you quite sure this is worth worrying about?
3  Java Game APIs & Engines / JOGL Development / Re: re: gluLookAt oddity on: 2007-07-20 14:35:18
Just a guess, but nowhere in your code snippet do you set the matrix mode, so I wonder which matrix would be modified by your API calls?

4  Java Game APIs & Engines / JOGL Development / Re: TextureRenderer performance in OS X on: 2007-07-19 19:40:36
In any case, the time difference is gigantic, much too large to be just a swizzling issue. We are talking an order of magnitude +. And I tried doing it manually, experimenting with the different pixel types, but no luck.

That's what I thought, but re-read my earlier reply, it was an order of magnitude slower.  However, if I understand you correctly, you've also tried manually creating a BI using various formats - same poor performance?

I dunno but you might get better performance if you draw into a "compatible" (Component.createImage()) image and blit that into the BI owned by the TextureRenderer.  This would obviously incur an overhead (the extra blit) but might be offset by the faster image format.
5  Java Game APIs & Engines / JOGL Development / Re: TextureRenderer performance in OS X on: 2007-07-19 14:56:42
Sorry for jumping in, but I'd be curious to know how you create the BufferedImage?  What method did you use, and what format did you specify (if applicable).

The reason I'm asking is because I've noticed mediocre performance with drawing RGBA type BIs, at least in Java 5 (order of magnitude slower than BGRA).  I know this isn't quite what you're doing but maybe the underlying problem (swizzling) is the same?
6  Java Game APIs & Engines / JOGL Development / Re: PROBLEM on: 2007-07-12 21:25:46 - read this!  Actually, you may want to do some of the NeHe tutorials before you dive into the matter.  I believe someone ported these to JOGL but am too lazy to investigate just now - do your own research...  Tongue

EDIT: beware the link I gave you is to a pretty ancient edition of the red book (1.1).  If you are serious about this then you really ought to buy your own, latest is still the 5th edition I think.  Also I wouldn't bother with the blue book as most of its content is online (I love the new OpenGL 2.1 reference pages,
7  Java Game APIs & Engines / JOGL Development / Re: PROBLEM on: 2007-07-11 18:22:58
If however GLSL is not an option then you could still use automatic texture coordinate generation.  Have a look at the glTexGen() OpenGL API.  I just checked in the red book it says, when GL_OBJECT_LINEAR is used then the generation function is a linear combination of the object coordinates.  If you choose appropriate coefficients then you can generate texture coordinates that are simply a function of z.  With a 1-D texture of appropriate colors, you're set.

I hope this helps!
8  Java Game APIs & Engines / JOGL Development / Re: problem reading texture on: 2007-07-11 18:14:56
There's no chance your readDataFromGPU() would ever return a non-null value!  You obviously need to allocate the FloatBuffer yourself (there's a BufferUtil class that might come in handy).

9  Java Game APIs & Engines / JOGL Development / Re: How fast is fast? on: 2007-07-10 07:15:10
Am slightly puzzled that the ATI x1300 should be faster than an NVidia 8600.  Also I take it the CPU is an Intel Core 2 Duo @ 2.2GHz, this should be about on par with (or even better than) the AMD 4200X2.

I suppose the results on the MacBook were obtained from running on MacOSX?  Do you have boot camp i.e. could you re-run the benchmark on Windows XP?  Just curious...
10  Game Development / Performance Tuning / Re: immutable, cloned, or mix? on: 2007-07-09 20:49:35
I used that too, but in comparison to immutable types I think it's still too mutable. It works fine for types you create and return (which shouldn't be changed by clients), but it doesn't free you completely from making defensive copies and it doesn't make those objects threadsafe.
Correct.  If you receive an object the interface semantics of which indicate immutability then that doesn't say anything about what could happen in reality.  Which is why immutable types must be final.

There's certainly a case for either approach, but immutable objects are usually easier to live with and less problematic, whereas mutable objects are usually somewhat faster (and maybe a bit more convenient in some situations of limited scope).

A side note on value types in C#, they're probably kinda nice with regards to performance, but they're one reason why C# is quite a bit more complex to use than Java.
11  Java Game APIs & Engines / JOGL Development / Re: scaling/resizing an image to have power of two width and height on: 2007-07-04 20:50:24
If Java 5 is an option then you could save some code and use the Integer.highestOneBit() API instead of your powerOfTwoFloor().
12  Java Game APIs & Engines / JOGL Development / Re: multiple viewports on: 2007-07-03 23:11:47
I'm pretty sure that glClear() clears the entire buffer contents, regardless of what projection or viewport you've set up.  Therefore, to achieve what you want, for each viewport you need to draw a GL_QUAD or similar in order to "clear" the background.
13  Java Game APIs & Engines / JOGL Development / Re: speeding up texture creation on: 2007-07-01 19:00:18
Well you see, I pointed you in the right direction:
typedef struct tagRGBQUAD {
  BYTE    rgbBlue;
  BYTE    rgbGreen;
  BYTE    rgbRed;
  BYTE    rgbReserved;

The layout of this isn't compatible with GL_RGBA but GL_BGRA (hence uploading textures is faster, no swizzling involved with the latter).

And as for the image coming up upside down, just play with the coordinates of the primitive that you draw (swap y texture coords) and you're done.

Good luck, you're nearly there! Smiley
14  Java Game APIs & Engines / JOGL Development / Re: speeding up texture creation on: 2007-06-30 17:59:33
I'll hazard a guess that you use the Win32 CreateDIBitmap() API.  Are you quite sure that you don't create a 32-bit format bitmap?  I'm asking because the BITMAPINFO structure's bmiColors member is of type RGBQUAD:
typedef struct tagRGBQUAD {
  BYTE    rgbBlue;
  BYTE    rgbGreen;
  BYTE    rgbRed;
  BYTE    rgbReserved;

If I'm right then your texture format should (incidentally) be GL_BGRA.  Beware that this format requires a certain OpenGL version (1.4??) - there's also an EXT flavour for older versions...
15  Java Game APIs & Engines / JOGL Development / Re: speeding up texture creation on: 2007-06-29 18:52:53
First of all, you must set the texture filtering modes - this would explain why you see nothing.  The following sets nearest neighbour filtering for both magnification and minification:

Inside updateTexture(), use glTexSubImage2D() to update the texture image, (use glTexImage2D() only when you initially create the texture).  This may further improve performance.

Also, before calling glTexSubImage2D() you should set the unpack buffer alignment to 1 (the default is 4, but your samples are 3 bytes R-G-B).  Failure to do so will likely cause the JVM to crash, unless the width argument is always a multiple of 4.
gl.glPixelStorei( GL.GL_UNPACK_ALIGNMENT, 1 );

I hope this helps!

[EDIT] With your graphics card, I think you get somewhere near 500MB/sec texture upload speed (pretty much regardless of whether you use RGBA or BGRA on the Radeon 9000, and btw it does not support PBOs).  With that in mind, uploading a 1024x1024 32-bit image (4MB) shouldn't take more than 10ms!
[EDIT2] Turns out I was being a bit optimistic!  I just ran a quick test on my good old Dell D600 (pretty much the same spec as what you use), and I measure a bit less than 20ms for uploading a 1024x1024 BGRA texture.  So that's no more than 200MB/s - a bit disappointing really given that this is actually AGP4x.
16  Java Game APIs & Engines / JOGL Development / Re: speeding up texture creation on: 2007-06-28 19:08:23
My advice is to go with direct NIO buffers.

1. On the Java side, create the buffer of appropriate capacity:
final int width = 512;
final int height = 512;
IntBuffer bits = ByteBuffer.allocateDirect( 4 * width * height ).order( ByteOrder.nativeOrder() ).asIntBuffer();

2. On the C++ side, using JNI get the native address of the direct buffer:
jobject jbits = ...; // this really is a JNI method argument
jint width = ...; // ...
jint height = ...; // ...
jlong count = env->GetDirectBufferCapacity( jbits ); // might not need this other than for asserts
int * const bits = static_cast< int* >( env->GetDirectBufferAddress( jbits ) );
if ( bits == 0 )
   // TODO error handling
// fill the bits of the image...

3.  On the Java side, create the texture manually, using OpenGL API through JOGL.  Update the texture bits using glTexSubImage2D() - this allows you to pass the direct buffer!
4.  Make sure your texture format is ABGR this is what most gfx cards support natively and is a lot faster than standard RGBA.

I hope this helps!  Texture uploads on an NVIDIA G80 are well in excess of 2GB/sec.  If you want highest throughput then look into Pixel Buffer Objects (PBOs).

[EDIT] I just noticed your image width and height are not powers of 2 - you need to bear that in mind when using straight OpenGL API instead of TextureIO.  Maybe someone who knows TextureIO better than I could comment on whether this could be combined with my above suggestions...
17  Game Development / Performance Tuning / Re: Heap allocation/deallocation in Windows... what´s happening? on: 2007-06-28 18:37:27
I think that the VM column shows virtual address space that an application has reserved, not necessarily committed.  Committed address space is either mapped to physical memory or paged out.

Bear in mind that a JVM resizing its native heap all too frequently might lead to address space fragmentation - not good for applications that require large contiguous regions say for NIO buffers.  Obviously this is a concern for 32-bit platforms only.
18  Game Development / Performance Tuning / Re: Fastest Way to Load an Image? on: 2007-05-26 21:24:12
Certainly not a bad idea! Smiley  Although, personally I wouldn't worry about a 10ms lag in stopping a thread!  Might be a different story though if you're loading larger images...
19  Game Development / Performance Tuning / Re: Fastest Way to Load an Image? on: 2007-05-26 20:30:42
These are really poor timings.  I get 20 FPS with FileChannelImageInputStreams for loading images.

BB, you may want to reconsider this.  Surely, the figures stated by tarmo are overall timings.  This means the decoder works at ~6ms per frame, i.e. neglecting I/O this is well over 150fps.  I/O included (say we can do 20MB/sec), assuming the image is 32K large (2:1 compression), and no fancy overlapping I/O, adds another 1..2ms.  In other words, worst case should be around 10ms which is a good 100fps.
20  Java Game APIs & Engines / JOGL Development / Re: GL_OUT_OF_MEMORY on glTexImage3D() on: 2007-05-01 19:59:44
The Intel 32-bit architecture (x86) gives a process a 4GB flat address space.  However the upper 2GB are reserved by Windows for shared memory, system libraries, and address space mapped to PCI devices.  So you're pretty much stuck with 2GB unless... boot Windows with the /3GB flag (check your c:\boot.ini file, duplicate the existing entry and add the /3GB switch at the end).  Note however, for an executable to see 3GB it must be explicitly marked as capable of handling the extended address space (clever folks do pointer arithmetics using ints you see...).  This is a linker option in Visual C++ (/LARGEADDRESSAWARE).  Obviously, you don't want to rebuild the JVM from source (maybe you do), however you can alter this flag for java.exe (or javaw.exe, whichever you use to launch your application).  The Microsoft tool that does this is called 'editbin.exe' - I'm sure it's part of the latest Windows SDK or available elsewhere.  BEFORE YOU GO AHEAD and try this I should point out that /3GB is known to reduce system stability, the reduced address space for OS and PCI devices comes at a cost...

Another alternative is to use Intel PAE (Physical Address Extensions) which is like emm386.exe back in the old days Smiley - although I think that works only on Windows Server and I doubt the Sun Java VM would support it.

Last but not least, have you considered going 64-bit?  Even if you don't want to run a 64-bit JVM, the 32-bit JVM marked as LARGEADDRESSAWARE would see a 3GB address space...

Hope this helps,

PS: Maybe Ken or someone else from Sun would like to comment on how well tested the 32-bit JVM is for this scenario, and why it is not LARGEADDRESSAWARE by default...
21  Java Game APIs & Engines / JOGL Development / Re: JVM crash while running JOGL program on: 2007-04-21 20:39:07
Do you rewind the buffer before passing it into glDrawElements?
22  Game Development / Shared Code / Re: 3DzzD MathX class Accurate and Fast cos/sin on: 2007-04-21 13:24:42
I can't be bothered to profile but I'll wager to say that...

sign = sign==1?-1:1; //flip sign every time
this saves you an if which are damn expensive
sign *= -1; //flip sign every time

...modern CPUs should easily branch-predict this one...

and if you 'inline' the contents of Math.abs(), you will get very likely a significant speedup too

...calls to Math.abs() ought to be auto-inlined by the JVM provided your code runs often enough...
23  Game Development / Performance Tuning / Re: minimizing garbage collection on: 2007-04-21 13:11:43
If your ints are within the range [-128,+127] then Integer.valueOf( int ) should be used cos that's backed by a cache (looking at the code of a 1.7 JDK, dunno what the situation is with 1.5).

Can you give us more details, how many keys do you typically hold in the map, and what's the value range.  If performance is critical (you want real time) then you could resort to a big lookup table in the form of an Integer[] array with say 64K entries - again this depends on your value range.

And please don't use a WeakHashMap!  Tongue
24  Java Game APIs & Engines / JOGL Development / Re: JSR-231 1.1.0 Release Candidate 1 Released on: 2006-12-29 21:25:09
Lovely to see you decided to supply Windows x64 binaries that is a real time saver for us...  Smiley

25  Java Game APIs & Engines / Tools Discussion / Re: Creating my own 'pak' file creator on: 2006-11-24 10:56:16
Thx, but haven't you seen my questionmark behind the 4GB ?
Oh in that case please accept my sincerest apologies, I misinterpreted your posting as a statement!
26  Java Game APIs & Engines / Tools Discussion / Re: Creating my own 'pak' file creator on: 2006-11-18 18:30:32
Wouldn't  it better to split the data? I assume you don't need all the data at once or all the time.
Beside the fact only linux/unix with newest fileformats support such big files. NTFS for windows only allows 4GB? files.
That is plain wrong, NTFS certainly does support files >4G.

27  Java Game APIs & Engines / JOGL Development / Re: is jogl compatible with SIS Mirage Graphics? on: 2006-10-17 07:53:57
Maybe it's just the pbuffer support that's flakey?  Try using a GLCanvas instead of the GLJPanel if that is feasible for your project, i.e. if you don't rely on lightweight panels.
28  Java Game APIs & Engines / JOGL Development / Re: Preloading texture data on: 2006-10-06 15:31:55
I haven't tried this, but:
  • call getContext().setSynchronized( true )
  • launch a worker thread that essentially makes the context current, uploads the textures, and releases the context
  • be on the safe side, use synchronization to avoid any operations on the context from the EDT, while the worker thread is busy...
  • display a modal wait dialog from the EDT, a reference of which is passed down the worker thread, and is disposed when the worker is finished

That ought to work, good luck!
29  Java Game APIs & Engines / JOGL Development / Re: GLException lies? on: 2006-10-03 08:54:32
Glad it works. Smiley
I think that in JSR-231, EXT methods were removed pertaining to functionality that was merged into OpenGL up to version 1.3.  Yours is in 1.4 hence the two functions still coexist.

Anyway you should be thankful that you're not running a more decent gfx card  Tongue otherwise you might never have spotted the problem in your code!
30  Java Game APIs & Engines / JOGL Development / Re: GLException lies? on: 2006-10-02 08:16:28
I believe glBlendFuncSeparate() was introduced in OpenGL 1.4, and is not part of GL_EXT_blend_func_separate!  The Radeon Mobility 9000 supports OpenGL 1.3 only.  Refer to for a detailed specification of the extension you are trying to use.

You are in luck because the GL interface does provide an entry point to glBlendFuncSeparateEXT() (which is what you want to use, according to the link above).

Hope this helps,
Pages: [1] 2 3 4
Archive (165 views)
2017-02-27 19:41:49

numerical (508 views)
2017-02-21 07:32:16

numerical (510 views)
2017-02-21 07:31:46

theagentd (623 views)
2017-02-18 13:42:33

theagentd (618 views)
2017-02-18 13:35:16

h.pernpeintner (1790 views)
2017-01-24 22:39:11

h.pernpeintner (1731 views)
2017-01-24 22:38:32

Galdo (2299 views)
2017-01-12 13:44:09

Archive (2190 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2724 views)
2016-12-16 03:58:39
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!