Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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  
  Slick Textures awefully slow  (Read 7262 times)
0 Members and 1 Guest are viewing this topic.
Offline skappler

Senior Newbie





« Reply #30 - Posted 2012-11-27 19:24:34 »

Oh thank you. I didn't know this is still required Tongue
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.
Online theagentd
« Reply #31 - Posted 2012-11-27 19:41:14 »

Bind the correct texture? =S

Myomyomyo.
Offline skappler

Senior Newbie





« Reply #32 - Posted 2012-11-27 19:52:00 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline matheus23

JGO Kernel


Medals: 98
Projects: 3


You think about my Avatar right now!


« Reply #33 - Posted 2012-11-27 19:53:26 »

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.

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline RobinB

JGO Knight


Medals: 37
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #34 - Posted 2012-11-27 19:55:28 »

i think you also added the new texture coords?
I guess % does not do what you expect it to do?
Online Riven
« League of Dukes »

JGO Overlord


Medals: 606
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #35 - Posted 2012-11-27 19:55:35 »

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 Smiley

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)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline skappler

Senior Newbie





« Reply #36 - Posted 2012-11-27 19:59:33 »

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 Smiley

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 Tongue
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 Cheesy

@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 Wink
Offline matheus23

JGO Kernel


Medals: 98
Projects: 3


You think about my Avatar right now!


« Reply #37 - Posted 2012-11-27 20:13:19 »

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 Cheesy

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

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Online Riven
« League of Dukes »

JGO Overlord


Medals: 606
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #38 - Posted 2012-11-27 20:27:37 »

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline skappler

Senior Newbie





« Reply #39 - Posted 2012-11-27 20:32:14 »

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 Cheesy

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!
Legends of Yore - The Casual Retro Roguelike
Online Riven
« League of Dukes »

JGO Overlord


Medals: 606
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #40 - Posted 2012-11-27 20:34:26 »

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

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline skappler

Senior Newbie





« Reply #41 - Posted 2012-11-27 20:46:28 »

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

JGO Knight


Medals: 37
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #42 - Posted 2012-11-27 20:52:49 »

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 Sad
Online Riven
« League of Dukes »

JGO Overlord


Medals: 606
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #43 - Posted 2012-11-27 20:56:51 »

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' persecutioncomplex Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline skappler

Senior Newbie





« Reply #44 - Posted 2012-11-27 21:12:39 »

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

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

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

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

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

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

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

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

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

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

CJLetsGame (216 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

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