Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
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 ... 25
1  Java Game APIs & Engines / Xith3D Forums / Re: DEBUG flags on: 2006-10-30 12:44:17
Hi,

With assertions, you can enable assertions on package level and will only have debugging on for that package.

Yuri
2  Java Game APIs & Engines / Xith3D Forums / Using assertions for debugging and profiling calls on: 2006-10-29 13:07:05
Hi,

Guys, don't you think that it would be good to wrap all profiling, logging and debugging calls into assert statements?

I made a simple test: wrapped all profiling callse with assert - it added 3% FPS for nothing! OK, just 3%, but that's only profiling - what will be with debugging and logging that makes more checks !?

For developers it does not make nay inconvenience - just enable assertions and you have all of debugging/logging functionality back, while game developers who normally do not tune the core will be able to run full speed because of assertions are off by default.

Comment on this, and if there is no objections, I will commit the cnages.

Yuri
3  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-29 12:42:15
Hi,

Fix committed to CVS.

Yuri
4  Java Game APIs & Engines / Xith3D Forums / Re: Quake3D level loader... where is it? on: 2006-10-29 12:41:28
Hi,

renanse, I just recognized that JavaWebStart benchmarks on your page use different canvas resolution - Java3D runs 640x480, while Xith3D runs 800x600. Can you check please or I am doing something completely wrong?

Yuri

P.S. My desktop resolution is 1600x1200, so I just did Alt+PrintScreen to check the actual window size.
5  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-29 03:48:25
Hi,

After really long and complicated debugging I finally found a REAL reason for object flashing in Q3 Benchmark. It was... attempt to access texture unit states higher than allowed by OpenG: implementation. This means that for cards that support >= 4 texture unit states for multitexturing, the problem did not appear, but other implementations are silently clamping texture unit state number to maximum allowed if it is too big.

This caused highest texture to be turned off after the core was trying to switch off non-existing not-used texture (states 2 and 3 in case of Q3 Benchmark).

To fix this, stricter checks against implementation limitations added. I will commit the fix after removing all debugging stuff.

Yuri
6  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 22:58:26
Hi,

We can easily experiment with disabling the state caching. There is only one method affected, so we can try to build complete appearance in display list.

On the other hand, I believe that higher efficiency of jME is in different area than display lists. For complicated scenegraphs numerous display lists may become an issue - it is even highlighted in some application notes for VBO extension.

BTW, I am still checking what is wrong with multitexture. Currently implemented architecture seem to be correct, but due to some reason it does not set up proper texture states if only one of textures changed.

Yuri
7  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 19:26:05
Hi,

The fix in CVS is definitely suboptimal. There is a problem with state caching of texture unit states for multitexture. This is still under deep investigation by me.

Yuri
8  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 17:30:34
Hi,

OK, I localized the problem - texture unit state was not set in setupTextureUnit(...).

Sorry, but I had to make setTextureState method in TextureShaderPeer no-modifier - otherwise there will be no access from ShapeAtomPeer. Otherwise we had to make it public, which is even worser.

Maybe we have to review the architecture for mutitexture and texture states to eliminate different codepaths for single-textured and multi-textured shapes.

Yuri
9  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 17:20:08
Hi,

After taking a short look at the current implementation renderAtom(...) I got a question:

 As of renderAtom(...) code, STATIC_APPEARANCE means static texture coordinates. Maybe it should be called like this?

Yuri
10  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 16:31:45
Hi,

Quote
The GIMP says

GIMP lies, sorry.

JPEG can hold arbitrary number of bands, AFAIK. And meaning of the bands is completely application-specific. For example, Photoshop uses 4-band JPEGs for storing CMYK images.

Take a look at com.sun.image.codec.jpeg.JPEGDecodeParam JavaDoc for more details. I have somewhere more detalied description of how it works, but I believe it is internal doc... I can not remember exacly...

Another point is that ImageIO JPEG decoding is native-code-accelerated in Java. Not the fastest one, but...

I am not a proponent of neither JPEG nor ImageIO, but for me ImageIO is most compatible image loading mechanism for a moment. If you consider porting another image loading lib, then it should be (I think) A) compatible with ImageIO; B) be Pure Java - I believe we should TRY to keep Xith3D Pure Java, otherwise it has no advantage of being used in Applets without purchasing VeriSign certificate (remember that JOGL comes signed by Sun already).

Yuri
11  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 16:09:39
Hi,

Quote
Then you have to think of the amount of RAM that uncompressed JPEG is going to take, all in all, JPEG is a horrible solution for games, no matter which way you look at it.

Yes, you are right in some extent, but at the end compressed textures can also be downloaded (uploaded - you nearly converted me to this term) using PBOs, which [may] save some RAM on startup.

Yuri
12  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 16:06:11
Hi,

Quote
JPEG dont have alpha channels

False. It is tricky to produce, but it does. I use "custom build JRE" to be able to save such a jpegs, and it even lets me to create textures where quality and subsampling of alpha and color channels are different.

Yuri
13  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 16:03:59
Hi,

Take a look at the screenshots: S1.jpg is how it is looking in most cases; S2.jpg is how the same object looks after moving camera a bit (rotate right).
S1.jpg is how it should look (and as it looks most of time), S2.jpg shows it is much brighter and no shadow.

I checked already that it has nothing to do with Color, Transparency and Lighting. My guess for a moment that something is wrong with Multitexturing.

Yuri
14  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 15:42:56
Hi,

Quote
Also, you might be interested to know, that a 512x512 DXT1A texture with all its mipmaps takes less space (and that correlates to transfers too) than mipmap level 0 of the same 512x512 texture in RGBA format...

Yes, I agree, and even more - we have support for comprssed texture formats already implemented and functional. But if you consider also Internet-downloadable applications, then you should also consider the transport size and - as you can guess - JPEG or JPEG2000 images will be way smaller than DXT1 compressed ones. But, yes, use of DXT1 compressed images saves you from doing decompression - it all is done by hardware, and it is efinitely the best choice. Even for smaller textures DXT1 image may be smaller than JPEG, and this saves A LOT of performance.

...as always, there should be a balance...

Yuri
15  Java Game APIs & Engines / Xith3D Forums / Re: Renderer - information hiding on: 2006-10-28 15:37:27
Hi,

We can also use no-modifier classes, fields and methods that will be visible inside package only but not visible from outside.

Yuri
16  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 15:14:37
Hi,

I agree with one minor comment: I easily believe that this unpacking procedure made by glTexImage2D may perform quite different if there is no real data transformation changed (they call this "swizzling" in that paper), so if you observe 7800GT performance for 8-bit Fixed Point RGBA and BGRA (columns 1 and 2 on 7800 GT line on Download), you will find quite big difference - 483 MB/s for RGBA vs 2238 MB/s for BGRA, which is, say, a kind of difference.

Yuri
17  Java Game APIs & Engines / Xith3D Forums / Re: Scenegraph regression. on: 2006-10-28 14:29:28
Hi,

Looks like we again have the same problem with flashing objects in Q3 Benchmark. Few days ago the problem gone, but now again it is here. I don't know after which changes it re-appeared.

Yuri

18  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 13:56:09
Hi,

Quote
Texture download? I think you mean texture upload ? (since the graphics driver is the server and the application is the client).

I meant transferring texture from the encoded state (jpeg/png/*** image or stream) to the ready-to-render state (in video memory).

OK, depending from which side to look. "Texture Download" wording taken directly from NVidia's "Fast Texture Downloads and Readbacks using Pixel Buffer Objects in OpenGL" technical brief, so I just re-used the term (OK, this brief is around one year old, but I was checking this topic way earlier). So if you don't mind I will continue to use the same term, besides I agree 100% that from the Application Side it looks like "Upload Textures To The Driver/Video Memory".

Yes, you are right about PBOs, but I can not 100% agree ok that they will not help. With faster texture download I target not only the FPS reached, but faster application startup and lower memory usage during startup. And the latter is a point where PBOs may help I think.

Another application of PBOs I am targeting personally is a video streaming to texture - I intensively use this feature, and if I can parallelize decoding and texture streaming plus utilize DMA transfers using, say, PDR (Pixel Data Range) (which I personally don't like too much), then I can reduce CPU load for video playback by avoiding at least one memory-to-memory transfer.

Yuri
19  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 13:13:30
Hi,

I would like to get images that produce these errors for further investigation.

I had only a problem with bands when was trying to load RBG texture into RGBA destination, and Grayscale texture in RGB/RGBA destination.

Yuri
20  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-28 10:02:26
Hi,

Quote
Okay, I guess this issue is assigned to you? (understand : I won't work on it anymore)

Not really, I just explain how things work.

What I can (and probably will) do is to change DirectBufferedImage implementation so it is using DirectByteBuffers. Integration with TextureLoader is your part.

A4 step acceleration is tricky, but it after may make use of DMA transfers directly from user space to AGP/PCI/PCI-e memory or even decode image data directly there.

I am not so sure if we should use this because of side effect is neccesity to put all textures in single DirectByteBuffer (i.e. implement a kind of texture memory allocation ourself).

Yuri
21  Java Game APIs & Engines / Xith3D Forums / Re: Sound on: 2006-10-27 17:09:51
Hi,

Quote
Isn't it better to include it into the existing TextureLoader?

I guess he is intergating it with existing texture loader.

But in the meantime I plan to play a bit with even better loading which may theoretically utilize some features of the driver.

...but for this I guess we will need something like a "lazy texture loading" which will run on Rendering thread (i.e. within the context of GLCanvas.display(...)

Yuri
22  Java Game APIs & Engines / Xith3D Forums / Re: Quake3D level loader... where is it? on: 2006-10-27 17:06:17
Hi,

I agree with Marvin, especially that there are some things in mind.

Yuri
23  Java Game APIs & Engines / Xith3D Forums / Re: com.xith3d.render.lwjgl.CanvasPeerImpl.jbx??? on: 2006-10-27 17:04:34
Hi,

I believe yes - this is a rudiment from very very very very old time. I guess it is a JBuilder meta-information file.

Yuri
24  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-27 14:27:18
Hi,

Quote
Step A4 we can not avoid anyway... (there are some ideas on that, but I am not so sure they will work).

I just checked the state-of-the-art OpenGL extensions, and there are ways how to avoid this and make texture download to the driver even faster.

Yuri
25  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-27 13:57:36
Hi,

In general, you should support images of up to 4 bands:

1-band (grayscale) - for Alpha or Luminance textures
2-band - For Luminance+Alpha textures
3-band for RGB
4-band for RGBA.

There are methods for creating DirectBufferedImage for cases of 1, 3 and 4 bands. We probably should also support 2-band. Check com.xith3d.image.DirectBufferedImage for details.

Yuri
26  Java Game APIs & Engines / Xith3D Forums / Re: Core stability on: 2006-10-27 13:51:31
Hi,

After reviewing the code in texture shader, ImageComponent2D and DirectBufferedImage, I believe that we sould introduce some changes also there.

The general point on loading textures is that we copy them way too much - at least 3 times when DirectBufferedImage is used, and 4 times when using plain BufferedImage. Textures often are big, so this consumes memory and increases the startup time.

For regular BufferedImage, procedure is following:

A1. Read image and store it to data array allocated internally by ImageIO
A2. Allocate new byte[] in ImageComponent2D and pull data out of BufferedImage from step A1 using pixel processor
A3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step A2 into it
A4. Pass a reference to DirectByteBuffer created at A3 to OpenGL context, which will allocate one more array to hold texture data in driver space

Step A4 we can not avoid anyway... (there are some ideas on that, but I am not so sure they will work).

Now what is happening with DirectBufferedImage.

B1. Create new DirectBufferedImage of appropriate type - it will create the byte[] (the Backing Store) similar to one created on A2 and hold reference to it
B2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Store byte[] and will avoid of extra byte[] allocation inside ImageIO
B3. Allocate DirectByteBuffer in ImageComponent2D and put data from byte[] from step B1 into it
B4. Pass a reference to DirectByteBuffer created at B3 to OpenGL context,

...and how it should be at the end:

C1. Create new DirectBufferedImage of appropriate type - it will create the DirectByteBuffer (the Backing Buffer) similar to one created on B3 and hold reference to it
C2. Read image DIRECTLY into DirectBufferedImage - this will store pixel data into Backing Buffer DirectByteBuffer. This is way more tricky, but I have few implementations of this which are fast enough (I did that for progress-trackable texture loading which shows the progress of ImageIO decoding the image.
C3. Create ImageComponent2D such a way that no new DirectByteBuffer is created but one from step C1 used
C4. Pass a reference to DirectByteBuffer created at C1 to OpenGL context

You can see that we can get rid of a lot of pixel processing this way, but this only fits Power-Of-Two-sized textures, and others have to be loaded conventional way.

Yuri
27  Java Game APIs & Engines / Xith3D Forums / Re: Improving compatibility with older Xith3D codebase on: 2006-10-26 12:03:18
Hi,

Looks like my chapter to XIN should come... Or so... For those who feel fit to read heavy technical stuff.

Yuri
28  Java Game APIs & Engines / Xith3D Forums / Re: GLSelect Picking and Shader State Update fixes on: 2006-10-26 12:01:41
Hi,

There is a check in Group anyway, but I would like to have a switch that turns warnings of (should be ON by default, or even can throw Runtime Exception).

Yuri
29  Java Game APIs & Engines / Xith3D Forums / Re: Quake3D level loader... where is it? on: 2006-10-26 11:59:07
Hi,

Quote
some wrong textures flash as Yuri mentioned

As I mentioned also, it is already fixed in current CVS.

Yuri
30  Java Game APIs & Engines / Xith3D Forums / Re: HUD regression on: 2006-10-26 02:13:29
Hi,

Please describe a problem in a bit more details - I believe I will find some time to look at it over the weekend.

[You should consider I am not an user of HUD, but know how the core works in deep details and how to debug it [the core], so if you feel we can use it let's do so].

Yuri
Pages: [1] 2 3 ... 25
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (12 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (24 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org 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‑gaming.org
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!