Slick Textures awefully slow

[skappler]

Oh thank you. I didn't know this is still required
It works but the textures are weird



It should be a brown block of dirt with some grass on the top. It worked in before.

[theagentd]

Bind the correct texture? =S

[skappler]

I did so. Before I changed the code it worked perfectly. I didn't change anything. The texture is bound only once in the beginning.

Games published by our own members! Check 'em out!

[matheus23]

Bind the correct texture? =S

Probably a good question: (I haven't worked much with DisplayLists yet...)
Bind before calling glCallList(); or while compiling the DisplayList?

My guess: while compiling.

[RobinB]

i think you also added the new texture coords?
I guess % does not do what you expect it to do?

[Riven]

I did so. Before I changed the code it worked perfectly. I didn't change anything.

You've got to change your mentality a bit

Assuming the code is broken because you screwed up is usually correct and will help you finding the solution faster. Throwing your hands up in the air like 'it wasn't me' is understandable when you're new to all this, but eventually you'll see that your own code is at fault. (and if not, there is still nothing else to do than change your own code to work around some bug)

[skappler]

I did so. Before I changed the code it worked perfectly. I didn't change anything.

You've got to change your mentality a bit

Assuming the code is broken because you screwed up is usually correct and will help you finding the solution faster. Throwing your hands up in the air like 'it wasn't me' is understandable when you're new to all this, but eventually you'll see that your own code is at fault. (and if not, there is still nothing else to do than change your own code to work around some bug)

Yes I know I tend to do this
And matheus you were right, I had to bind the Texture while compiling. Can anyone explain why?
What's also weird is that I haven't any blue texture like the one that was bound

@RobinB The texture coordinates remain the same, because the spritesheet didn't change.
Also I study Computer Science so I think I know what % does

[matheus23]

And matheus you were right, I had to bind the Texture while compiling. Can anyone explain why?
What's also weird is that I haven't any blue texture like the one that was bound

Phew... I'll try... tho I don't know much about DisplayLists...

So... probably it's more about the concept:
A Display list is really just for reducing the ammount of calls to OpenGL and being able to really pre-compile them when you compile them, instead of everytime interpreting all the commads you give to opengl.
Compiling also gives the ability to optimize it.

So to be more precise: it's about state-compiling.
Changing the texture would change your state, which means things are not like they used to be when compiling. Having a texture pre-compiled inside the list allows some optimization, for example terminate all glBindTexture calls, which are binding the same texture. Usually opengl couldn't do this, because it does not know, if you bind the same textures every frame. With display lists this is not possible anymore, so opengl is able to terminate those calls.


I don't get why display lists got deprecated... One cool thing about them is for example that you are able to let a glCallList compile inside a display list, so your display list calls another display list.
Now imagine your whole game world is one single display list and once a part of your world changes, you simply only recompile the specific display list and everything works...

[Riven]

I don't get why display lists got deprecated... One cool thing about them is for example that you are able to let a glCallList compile inside a display list, so your display list calls another display list.
Now imagine your whole game world is one single display list and once a part of your world changes, you simply only recompile the specific display list and everything works...

One of the problems is that compiling display lists is really slow. So yes, in theory you could make a hierarchy of display lists, but the moment you have to update content that is a bit large (a few thousand vertices) you get a noticable hickup in your framerate.

The only modern benefit of display lists today is compiling a bunch of state changes, not feeding geometry. It can massively reduce the number of calls to the driver, and if you're in luck the driver just passes the handle to the GPU which will apply all state changes.

Streaming & storing geometry is so fast these days, using VBOs and mapped buffers, that there is no reason to use displaylists for them.

[skappler]

And matheus you were right, I had to bind the Texture while compiling. Can anyone explain why?
What's also weird is that I haven't any blue texture like the one that was bound

Phew... I'll try... tho I don't know much about DisplayLists...

So... probably it's more about the concept:
A Display list is really just for reducing the ammount of calls to OpenGL and being able to really pre-compile them when you compile them, instead of everytime interpreting all the commads you give to opengl.
Compiling also gives the ability to optimize it.

So to be more precise: it's about state-compiling.
Changing the texture would change your state, which means things are not like they used to be when compiling. Having a texture pre-compiled inside the list allows some optimization, for example terminate all glBindTexture calls, which are binding the same texture. Usually opengl couldn't do this, because it does not know, if you bind the same textures every frame. With display lists this is not possible anymore, so opengl is able to terminate those calls.


I don't get why display lists got deprecated... One cool thing about them is for example that you are able to let a glCallList compile inside a display list, so your display list calls another display list.
Now imagine your whole game world is one single display list and once a part of your world changes, you simply only recompile the specific display list and everything works...

Ok that makes sense. Thank you very much =)

I don't get why display lists got deprecated... One cool thing about them is for example that you are able to let a glCallList compile inside a display list, so your display list calls another display list.
Now imagine your whole game world is one single display list and once a part of your world changes, you simply only recompile the specific display list and everything works...

One of the problems is that compiling display lists is really slow. So yes, in theory you could make a hierarchy of display lists, but the moment you have to update content that is a bit large (a few thousand vertices) you get a noticable hickup in your framerate.

The only modern benefit of display lists today is compiling a bunch of state changes, not feeding geometry. It can massively reduce the number of calls to the driver, and if you're in luck the driver just passes the handle to the GPU which will apply all state changes.

Streaming geometry is so fast these days, using VBOs and mapped buffers, that there is no reason to use displaylists for them.

So the way I do it will give me laggs when I rebuild a display list? I wanted to have one List per chunk and update them when a block within a chunk changes. Is this inefficient? And would VBOs be a huge improvement?

Games published by our own members! Check 'em out!

[Riven]

To be a bit blunt: display lists are deprecated for a reason. If you're new to OpenGL and have yet to write all the code that will make OpenGL calls, it's best to avoid anything that is deprecated...

To learn about how to use vertex arrays, vertex buffer objects, look here:
http://www.java-gaming.org/topics/introduction-to-vertex-arrays-and-vertex-buffer-objects-opengl/24272/view.html

[skappler]

I think my fault was to learn OpenGL with the redbook. The version I read was last reviewed in 2002
Thank you for the tip, I will check it out as soon as I have the time for it!

[RobinB]

To be a bit blunt: display lists are deprecated for a reason. If you're new to OpenGL and have yet to write all the code that will make OpenGL calls, it's best to avoid anything that is deprecated...

To learn about how to use vertex arrays, vertex buffer objects, look here:
http://www.java-gaming.org/topics/introduction-to-vertex-arrays-and-vertex-buffer-objects-opengl/24272/view.html

Even that stuff is mostly deprecated sadly enough.

Deprecated:

1   2   3   4

glColorPointer(...       glVertexPointer(..       glNormalPointer(...       glTextPointer(...

Your supposed to do evrything with shaders now

[Riven]

The choice of using immediate-mode/VAs/VBOs is fully independent of your choice of using fixed-pipeline/shaders. You can mix and match.

You are however correct that gl*Pointer is replaced by glVertexAttribPointer. I will update the tutorial 'soon'

[skappler]

Are there any other tutorials or resources about all this VBA and VBO stuff? I liked the way the redbook was written.
Also: I just started learning shaders, so would it be better to finish the shader stuff and stick with immediate mode / display lists till then, or first learn the "modern" OpenGL stuff?