Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Core stability  (Read 9441 times)
0 Members and 1 Guest are viewing this topic.
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #30 - Posted 2006-10-28 11:26:13 »

Quote
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.

Texture download? I think you mean texture upload ? (since the graphics driver is the server and the application is the client). In anycase, im wondering what that "state of the art" extension is? If its PBOs, i dont think they'll help you much with the glTexImage2D call...

DP Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #31 - Posted 2006-10-28 11: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

Yuri Vl. Gushchin
JProof Group
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #32 - Posted 2006-10-28 12:50:08 »

for video streaming, PBOs will help you, definetly.

That paper only shows how different texture formats affect sending data to the server and how readback can be affected. The only hint of using it to upload textures is this paragraph:

"To download data to the GPU, bind the buffer to the GL_PIXEL_UNPACK_BUFFER target using glBindBufferARB(). The glTexImage2D() command will then unpack (read) their data from the buffer object."

This unpacking, could mean a copy, you dont know...its up to the implementation. If you carefully look at the figures in the table, using BGRA instead of RGBA affects transfer "downloads" by 6.75% if you used BGRA. So the card will store BGRA in video memory, its just the transfer to memory. FPS will not be changed, but like you said, startup is changed.

In conclusion, PBOs are going to help the normal game citizen, they help readbacks. Using the optimal texture format will only help transfer rates initally, FPS during gameplay remains unchanged.

All figures are quoted from the 7800GT

DP Smiley

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #33 - Posted 2006-10-28 13: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

Yuri Vl. Gushchin
JProof Group
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #34 - Posted 2006-10-28 13:35:51 »

Ooops, i was reading the wrong section; so BGRA8 is infact a heck of alot faster than RGBA8....im not familiar with texture formats, but I heard that TGA is practically raw with a header, if it is raw, your going to have to do the swizzling in CPU (since the data is RGBA packed) and that might offset the speed of transfer....

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...

At the end of the day, unless your doing alot of readbacks, texture compression is going to be better...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #35 - Posted 2006-10-28 13: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

Yuri Vl. Gushchin
JProof Group
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #36 - Posted 2006-10-28 13:51:07 »

A 512x512 DXT1A DDS texture takes 171KB with all mipmaps (so that includes 256x256, 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2 and 1x1). If you zip it (with winRAR), it becomes 125Kb...

try doing that with JPEG and having the same quality as DXT1A. Also, the texture that I have has an alpha channel, JPEG dont have alpha channels, so its not a real 1-1 comparison, but close enough Smiley

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.

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #37 - Posted 2006-10-28 14: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

Yuri Vl. Gushchin
JProof Group
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #38 - Posted 2006-10-28 14: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

Yuri Vl. Gushchin
JProof Group
Offline Marvin Fröhlich

Senior Devvie




May the 4th, be with you...


« Reply #39 - Posted 2006-10-28 14:11:42 »

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.

The GIMP says, that JPEGs don't support them. But you could of course use a specific color like BLACK, to indicate some kind of user-defined-transparency.

As I mentioned in another thread, Java-ImangeIO reading is not sayd to be the fastest way to load textures. Maybe we should consider porting some open sourced image loading code instead of using ImageIO.

Marvin
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #40 - Posted 2006-10-28 14: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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #41 - Posted 2006-10-30 08:47:37 »

I agree with Yuri.

Also, if I remember well, bottleneck about texture loading is not actually JPEG/PNG/TGA/whatever *decoding* but 3-4 times copy.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #42 - Posted 2006-10-30 10:04:51 »

Now faster texture loading included, check it out !

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #43 - Posted 2006-10-30 14:50:29 »

I personally only use DDS or TGA; DDS is a horrible file format, but its easy to parse and there are alot of exporters for it (photoshop plugin and theres a beta gimp plugin too), there is also alot of toolsets from nvidia and ATI that help with DDS stuff....

With the custom file loader for DDS, i only oncurr 1 copy, and thats the glCompressedTexImage2D copy, a bare minimum. Maybe you should write your own file loaders and have a more specific approach to texture loaders. JPEG, GIF, BMP et al really weren't made for games...

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #44 - Posted 2006-10-30 19:14:14 »

DP : thanks for the tip but, texture loader does already load DDS compressed textures. (Thanks mattiasman, if I remember correctly).

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: 1 [2]
  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.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (50 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (57 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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!