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 (536)
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  
  Binding textures  (Read 2019 times)
0 Members and 1 Guest are viewing this topic.
Offline DavidYazel

Junior Member




Java games rock!


« Posted 2003-07-14 16:02:45 »

I have a question.  If I create N texture objects and I run out of texture memory, what happens?  Does the texImage2 fail?  I am confused because my docs say that opengl will automatically delete older textures and there is even an API to set that delete priority.

So if it does delete an older texture object how does my app know it has to reload it?  Will the subsequent bind fail?



David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Offline elias

Senior Member





« Reply #1 - Posted 2003-07-14 19:22:48 »

OpenGL will never delete your textures without you doing it explicitly. That said, your docs probably meant resident textures, and the functions to prioritize and query for residency. When a texture is readily available to the renderer, it is considered resident. If it isn't, it will have to be copied, and other resident textures might have to be kicked out.

Practically, residency means textures currently in video memory (usually 32, 64 MB on the common cards), and nonresidency means system memory. When binding a nonresident texture, the OpenGL driver will have to upload it to resident memory.

That also means that you can always create new textures, to the system memory limit, but performance will suffer if textures are swapped in and out of resident memory all the time.

- elias

Offline elias

Senior Member





« Reply #2 - Posted 2003-07-14 19:24:48 »

And that's also the reason texture binding are considering expensive - there's a risk that a texture will have to be uploaded at each bind.

- elias

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

Junior Member




Java games rock!


« Reply #3 - Posted 2003-07-14 20:48:07 »

I am still confused.  If you use glGenTexture to get a texture object name, then use glBindTexture, should you not call glTextImage if it is already bound?  or does opengl just ignore the following glTexImage call if it already has a copy?

And is it safe to change the texture between draws?  Do you have to delete the texture to repplace it with a new one?

If you delete a texture is it's name still valid?

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
Archimedes
Guest
« Reply #4 - Posted 2003-07-15 09:36:54 »

If I get the OpenGL manual chapter 9 correct, it's legal do it the following way. In the OpenGL init() method you generate all your Texture objects by doing something like:
1  
2  
3  
4  
5  
int[] tmpids = new int[1];
gl.glGenTextures(1, tmpids);
int id = tmpids[0]; // and store this id
gl.glBindTexture(o.GL_TEXTURE_2D, id);
gl.glTexImage2D(o.GL_TEXTURE_2D, ...);


Later on in the display() method you then activate the wanted texture object before drawing a polygon
---
1  
2  
3  
gl.glEnable(o.GL_TEXTURE_2D);
gl.glBindTexture(o.GL_TEXTURE_2D, id);
// draw the polygon


When the wanted texture object is already in the graphic card's V-RAM (resident), it's used, otherwhise its loaded from slow system RAM. For the latter to happen some other resident textures are being kicked (not deleted from the logical part, so their object id keeps intact). The manual mentioned that for this process typical implementations of OpenGL apply a least recently used (LRU) strategy to decide which texture objects to move out of the working set.

If the V-RAM is too small to hold all your textures residently, the game will go slow. You can't do anything expect to decrease the texture sizes (a typical option in game menues).

Of course, I could have mis-understood all what the manual said. :-)
Offline DavidYazel

Junior Member




Java games rock!


« Reply #5 - Posted 2003-07-15 14:24:07 »

Excellent!

So it would be my assumption that for scenes that have more textures than texture memory, but where the textures needed in any one frame are less than texture memory it would be most efficient to delete the texture objects explictly and manage a texture cache within your own code?

In other words are there advantages to doing texture caching management explicitely, or should we just rely on OpenGL to manage that?

Also, if you make a change to the texture, can we re-issue the gl.glTexImage2D(o.GL_TEXTURE_2D, ...) command to have the texture update on the card?  Is this the method used for "video textures" where the texture is changing every frame, or is there a better way to do it?

David Yazel
Xith3D Project Founder
http://xith3d.dev.java.net

It may look complicated, but in the end it is just a bunch of triangles
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.

CogWheelz (15 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

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

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

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

Riven (31 views)
2014-07-23 20:56:16
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!