Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (534)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Xith3D compressed texture support  (Read 1661 times)
0 Members and 1 Guest are viewing this topic.
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Posted 2005-03-25 13:53:07 »

I've added support for DXT1, DXT3 and DXT5 compressed texture support based on Xith3D_2005-02-08_cvs. Currently only for the JOGL renderer (LWJGL still works but doesn't support these formats).

For this I've made some changes in ImageComponent (new FORMAT_xxx flags) and many changes in TextureShaderPeer for JOGL (changed half of defineTexture() to make it easier to maintain).

I also think that TextureLoader needs a major overhaul. Java doesn't like custom BufferedImage formats. I get "Unable to transform image" on some file formats. The best way would be to move from BufferedImage to byte[]. This will need a bit of code to handle the common formats (R8G8B8, R8G8B8A8, R5G6B5, ...) and a generic code path that handles the other formats.

We still need entrypoints for BufferedImage but we should not base our internal processing (atleast for static textures) on it. With this I mean MipMap generation. My idea: Convert the BufferedImage to a BufferedImage with a 2^x size and a processable internal format (only when needed), then do simple box scaling for mip maps.

Also ImageComponentXX should only hold references to the passed byte[] or BufferedImage for dynamic textures.

TextureLoader should be changed so that one can add his own image loaders (e.g. DDS importer) or file sources (e.g. URL handling or custom archive files). It also should not quit the application when a texture could not be found (may be replace it with a hardcoded "404" image ?)

How is currently maintaining the texture handling stuff ?

Ciao Matthias Mann
Offline aNt

Senior Member




AFK


« Reply #1 - Posted 2005-03-25 16:08:04 »

that all sounds great Matthias- roll it all in mate Smiley
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #2 - Posted 2005-03-25 21:25:55 »

I know how to post patches and bugs - should I post it there ?

I think someone needs to check my changes to the texture code before it is checked in. I have run all tests and they still work, but they don't use all code paths.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #3 - Posted 2005-03-25 21:42:55 »

This all sounds really good.

I am worried about massive changed being made to the current TextureLoader as it is pretty hard to test all the different code paths as there are so many.

How about you start with a clean slate, perhaps call it "TextureLoader2".  That way there's no legacy crap you need to worry about.  Once it is up and running, we can provide migration advise and deprecate the entire old TextureLoader class.  This gives you far more freedom to do what you like and beta testers can then try out your class with their code at their lesure.  What do you think?

If you did go this way, we should open a discussion to find out what other people didn't like / did like about the current TextureLoader.

Please post your patches to Xith3D though IssueZilla.  If you want to provide testing builds and need somewhere to upload them, email me.

Thank you Smiley,

Will.

Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #4 - Posted 2005-03-26 00:27:29 »

I've filled a issue to track the compressed texture support part: https://xith3d.dev.java.net/issues/show_bug.cgi?id=92

I've not yet started with the TextureLoader stuff. The main goal that I have for TextureLoader2 are:
  • Does not depend on BufferedImage to do mip mapping
  • A TextureLocator interface that is responsible to get an Texture for an given texture name. This allows complete loading done by the application.
  • A TextureStreamLocator interface that is responsible to get an InputStream for a given texture name.
  • A TextureStreamLoader interface that is responsible to create a complete texture from an InputStream.
  • An ImageLoader interface that is responsible to create a single ImageComponent from an InputStream.
  • The above interfaces are tried in the order as listed.
  • If an InputStream was found, but could not be read from the above interfaces then ImageIO is tried.
  • An error handling mode that defines if null, an build in error texture ("404") or an exception should be returned when the texture name could not be resolved / loaded.
Offline Yuri Vl. Gushchin

Senior Member




Speak Java!


« Reply #5 - Posted 2005-03-26 05:10:58 »

Hi All,

Finally I got some time again to work on Xith3D.

I will review the changes to check if everything is OK.

I have already played with compressed textures, and in my case I changed only few lines to make it working - I did not use external texture compression (if you specify compressed format, OpenGL driver compresses the texture for you). Massive changes only needed when textures have to be stored in compressed format also in main memory...

Yuri

Yuri Vl. Gushchin
JProof Group
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #6 - Posted 2005-03-26 07:24:11 »

According to many papers (also some from NVidia) compressing textures while loading is very slow. Also there are many tools that can create DDS files (from NVidia, DirectX Texture Tool). One can even create a small program that uses OGL to compress the textures and stores them as DDS file.

While DDS is a M$ file format it is heavly used in PC games and reading it is very simple (a fixed size header directly followed by the compressed texture mipmaps). A standard java application has only 64MB (in the default settings of the JVM) memory, so loading compressed and mip-mapped textures saves a lot of processing time (for mip-mapping) and a lot of memory - about 170kb compared to 1M.

Maybe I'll include my very simple DDS loader with the new TextureLoader2 (this would be a TextureStreamLoader).
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2005-03-26 12:45:57 »

It's not an amazing article, but re: TL2, could you read this month's Game Developer, which has an article on writing texture locaters and loaders to be more intelligent, and roll in any good ideas from there? It's a C-perspective, but 90% applicable to java.

Personally, I wasn't impressed by the article. Seemed pretty mundane ideas that anyoen could come up with. However, its' about 3-4 pages IIRC and quite convenient as a reference point to read descriptions of approaches as a starting point. Also goes into some of the pros and cons. I suspect there's nothing that hasn't been mentioned at one time or another for X3D, but why not check? Smiley

PS: may not be this month's GD...I've left my copy in someone's house, so can't check, but I *think* this was in the issue that came out for free at GDC. If not, it's probably the previous month's issue (I read them both at the same time during GDC).

malloc will be first against the wall when the revolution comes...
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #8 - Posted 2005-03-26 14:29:11 »

I don't have access to gamasutra or the GD magazine. I also didn't find the article on their homepage.

Can you post a link to the article somewhere ?
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #9 - Posted 2005-03-26 15:43:50 »

Hello,

I've started with the implementation of TextureLoader2. For this I've created a set of classes that does low-level pixel processing (currently only mip-mapping and BufferedImage conversation). The ImageComponentXX will also need these classes because you can specify BufferedImage for byReference ImageComponents.

These classes are currently called PixelProcessorXXXX where XXXX is the pixel format (e.g. R8G8B8A8)

Should I add these to com.xith3d.utility.image ? Or should I add a new package (like com.xith3d.utility.pixelpipe) ?

I've changed the ImageComponent partially immutable (format, width, height, byRef, yUp) this will simplify the new implementation of update().  The new process of update() will be Image->byte[]->ByteBuffer->OGL. So the fastest dynamic textures will be updates to byte[] because a DirectByteBuffer has a native call for each put() call.

Maybe we can find a way to also remove the java copy of static images (these not byReference) ? I've already removed the byte[] and BufferedImage copies if byRef is false. This will cause getByteData() and getImage() throw an IllegalStateException.

Ciao Matthias Mann
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2005-03-27 16:31:59 »

Quote


Can you post a link to the article somewhere ?


I've only read it in the paper mag. You'll either have to find a newsagent and see if the copy they've got has it in or wait a month and see if it appears on GS.com

malloc will be first against the wall when the revolution comes...
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

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

The first screenshot will be displayed as a thumbnail.

pw (35 views)
2014-07-24 01:59:36

Riven (33 views)
2014-07-23 21:16:32

Riven (21 views)
2014-07-23 21:07:15

Riven (24 views)
2014-07-23 20:56:16

ctomni231 (55 views)
2014-07-18 06:55:21

Zero Volt (47 views)
2014-07-17 23:47:54

danieldean (38 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!