Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (702)
Games in Android Showcase (203)
games submitted by our members
Games in WIP (774)
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  
  GLSL doesn't compile for some reason..  (Read 1317 times)
0 Members and 1 Guest are viewing this topic.
Offline trollwarrior1
« Posted 2014-01-04 08:32:45 »

So don't ask me for entire code, there is no need. The problem is here.

If I type this code into GLSL, it works. Doesn't give me non-compiled shader error.
   int index = int(gl_Normal.x);
   float r = radians(rotations[1000].z);

If I type this code however, shader doesn't compile. What is wrong?
   int index = int(gl_Normal.x);
   float r = radians(rotations[index].z);

This won't compile also.

   int index = int(0);
   float r = radians(rotations[index].z);
Offline Danny02
« Reply #1 - Posted 2014-01-04 08:51:22 »

It all depends on which OpenGL and GLSL version you are using. In older versions you are only allowed to use constant array indices. Sometimes is it also allowed to use dynamic loop indices("for") and to lookup uniform arrays in the vertex shader.
Offline trollwarrior1
« Reply #2 - Posted 2014-01-04 09:00:44 »

That is just stupid.. I don't know which version I'm using. It is probably the worst one, since I haven't declared any. How would I go about using GLSL V4.0? Do I need to change something in my code? Is it compatible with all machines?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Danny02
« Reply #3 - Posted 2014-01-04 09:13:28 »

I'm not sure if there aren't any restrictions with higher versions and also could not find any rules regarding array indexing in the newest spec. So it might be possible that you have to come up with some other solution for your problem.

If you describe to us what you try to do maybe we can help.

ps: you change the GLSL version with the following line at the very top of your shader code
#version 440

2.1   #version 120
3.0   #version 130
3.1   #version 140
3.2   #version 150
3.3   #version 330
4.4   #version 440
Offline trollwarrior1
« Reply #4 - Posted 2014-01-04 09:27:00 »

Ok I will try to describe what I'm trying to do.

*Render 2d sprites using immediate mode.
*Render each game loop, send data every loop.
*Make an array of class Asset, which has basic rendering variables. x,y,width,height,pivotx,pivoty,rotation,sprite,color.
*When you call a render method, add new asset with specified variables into my array. I also have an array or vec3 to store my rotation data(pivotx, pivoty, rotation). If rotation that I passed to my Asset class is not 0, I will add a new vec3 to me rotation array and take a stamp of where I put it in an array. If rot was 0, just make that stamp point to location 0 at my rotations array. That place always contains vec3(0, 0, 0), basically no rotation.
*After I'm done rendering my game, make a FloatBuffer out of my rotations array. All the elements that are not null are put into my FloatBuffer. It is then sent as a uniform vec3 to my vertex shader.
*After sending my rotations data, go through my asset arrray. Now render stuff using the information from Asset class. I pass glNormal3f(asset.rotationHandle, 0, 0); for my vertices to assign their pointer to my rotations array.
*In my vertex shader, gl_Normal.x is a pointer to my rotations array. That array has information of where is the pivot to rotate the vertex around, and by how much.

The problem is that I cannot access that array with my int index = int(gl_Normal.x) . I did some testing and I found out that you cannot access UNIFORM arrays with such an index. If I create an array inside my void main() I can access it however I want.

Is there anyway to copy all the data from uniform array to local(right?) array? This would really give a huge performance boost when rotating stuff. I really hope there is a way to access my uniform array.
Offline Danny02
« Reply #5 - Posted 2014-01-04 10:26:00 »

ok, stop!

you over complicating things way more than they need to.

First of all get rid of your "optimisation" of rotation data array. Just delete it.
As a second thing, do the rotation on the client side(CPU). Calculate the new positions of the vertices after the rotation in your draw method and be finished.

Btw, there are ways to do things like what you tried in GLSL, but I think I shouldn't tell you, because you will find them yourself when you are ready.
As a final thought don't over think stuff and don't try to do crazy optimisations("safe" some bytes through look-up tables) just do it in the most simplistic way possible, which is btw in most cases also faster than other crazy ideas.
Offline Dxu1994
« Reply #6 - Posted 2014-01-04 10:52:05 »

What are you doing that requires a 1000 indicies array anyway?

If you're doing 2d skinning, it's probably better to do that on the CPU.

In general you can transform a vertex on the CPU with a few instructions like so:

vx = x1 * tf.m00 + y1 * tf.m01 + tf.tx;
vy = x1 * tf.m10 + y1 * tf.m11 + tf.ty;

If youre just trying to rotate stuff, sticking it into a shader may actually hinder performance as you need to move all that data to the shader each frame!

Offline trollwarrior1
« Reply #7 - Posted 2014-01-04 11:00:12 »

I found the solution!

I needed to specify some kind of array size when creating uniform array. I made 1024 and it works perfectly. Almost.

I have another question. Does number 247 say anything to you about shaders? That is the amount of blocks that are actually rotated on the screen. Or 248 if you count the player sprite. Is there a limit to how much data I can send to shaders?

This is not crazy. This is just moving rotation calculation from CPU to GPU. You don't like it? I saved myself 600fps. You?
I'm trying to make something like sprite batch. Since you might want to render up to 1000 sprites I made the array size of 2048. There is 0 performance hit. Array are fast. I tried using Lists before, took another huge performance hit, so had to go with arrays.

What other way do you know of rotating over 300 squares around their own coordinates without losing any performance? (Almost, 50 fps at most.) I would be willing to learn the way you rotate that many squares.

Why would you NOT use your GPU? As far as I know, shaders are the only way to work with GPU. Did you try to make lighting on CPU? Without using shaders? I did. It was like SUPER slow. Each added light took like 300fps. And it was PER VERTEX. If it was per fragment, it wouldn't probably make even 10 fps or something.. But when you transfer your lighting code to GPU, it magically WORKS without taking almost any performance hit compared to CPU! Again.. WHY WOULD YOU LIMIT YOUR SELF TO CPU WHEN YOU HAVE A GPU SITTING THERE, WHICH IS DOING ALMOST NOTHING?
Offline StumpyStrust
« Reply #8 - Posted 2014-01-04 11:37:44 »

render up to 1000....dude java2D can do 10k with rotation.

Measuring fps is not a good way to benchmark/optimize. Use some sort of timing or a profiler.

I made a sprite batcher that can push out several hundred thousand sprites with rotation on the CPU. The limit I hit was fillrate/draw calls.

Also, lighting can be done without shaders. As a matter of fact I have done it without shaders and could have several hundred lights while maintaining smooth gameplay. Key is using FBO. I used glReadpixels and the stencil buffer. 

Shaders do not magically make things fast. You need to properly use them in order to get any boost and many things really should be left to the CPU.

PS: Please do not create 2 duplicate topics on the same thing in two different boards. Only one in opengl debugging was enough. People were and are sleeping so there is not need to get impatient. Your tone is very condescending and it makes it very hard for anyone on here (at least me) to take you seriously. Please try and be more respectful. Sorry I am sounding kinda cranky but Danny and Dxu were very respectful in there responses. Glad you "solved" your problem.  Smiley

Offline trollwarrior1
« Reply #9 - Posted 2014-01-04 11:45:48 »

After posting in OpenGL I realized this belonged in debugging. Sadly, I cannot delete my own topics, so ..

I didn't quite catch your thought on "several hundred thousand". Does that mean per second? Or each frame at 60 frames per second?

I didn't try to implement lighting with FBOs yet, can't tell.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline tom_mai78101
« Reply #10 - Posted 2014-01-04 12:03:08 »

After posting in OpenGL I realized this belonged in debugging. Sadly, I cannot delete my own topics, so ..

Try PMing the Java overlords, and maybe they can help.
Offline Danny02
« Reply #11 - Posted 2014-01-04 12:16:04 »

The thing is that especially as a beginner(as you are, no shame there of course) one should listen to the more experienced, because they went through the same stage as you and know best practises you have still to learn.

As Stumpy pointed out, don't use FPS as a unit to measure performance. It is totally unreliable, because you can not compare it. Always use frame-time, like:
"Hey I saved 1.5ms per frame with this ├╝ber-cool optimisation"

Coming back to you initial question and why it is bad to do what you do in your shader.
Using an array in a shader like you do is very bad, because it creates unpredictable memory access pattern. A GPU would always like to have a straightforward path of calculations. Which is similar to why it is not wise to use diverging if/else.

So in your case, when you already "using" the vertex normal, why don't you store the rotation data directly in the normal. This will not only be faster, but does also scale(no limit to sprite count) in comparison to your latest iteration.

In the end I would still recommend to do the rotation on the CPU, because it makes stuff simpler. Either way, the computation you are doing is so simple, that in the end it doesn't even matter if you calculate the rotation on the GPU or CPU, because there will be other factors like the fill-rate which will limit you first.
Offline trollwarrior1
« Reply #12 - Posted 2014-01-05 08:09:53 »

For now I'm just storing rotation data into the normal (+100fps faster, less stuff to write). But I will be back! Cheesy
Offline StumpyStrust
« Reply #13 - Posted 2014-01-05 13:29:24 »

+100fps? What is your current average? If you are at 1000+, then fps is literally meaningless. Like someone else here said. Use frame time.

Frame time. Time to render a frame.
Update time. Time to update game logic.
Physics time. Time to take a step in the physics simulation.
Specific Rendering time: Time to render terrain or all sprites or some other specific set of rendering routines.
AI Time: Time to update AI.

Point is to look at the different areas on a slightly larger scale so you can track down REAL bottle necks. FPS is really meaningless. If you can get a solid 60 on most systems, you are fine. Most people cannot tell the difference from 30-60 let alone above. And all of that is meaningless if you are not interpolating your updates/renders with some delta timing scheme. 

Offline trollwarrior1
« Reply #14 - Posted 2014-01-05 13:39:24 »

My game is running busy loop. It renders as much frames as it can. It takes count of it. Every second it displays how many frames it did. How is this bad? You calculate how many frames your game does each second. If you want your time, you can do 1 / FPS and you get the average time it took to render each frame. There is 0 difference.
Offline Danny02
« Reply #15 - Posted 2014-01-05 16:04:30 »

OK let me write it down for you.
The problem is when you say that some optimisation got your game 100 FPS faster, than this has no value in a conversation, because it tells nothing about the speedup.

Look, if your game is running at 50 FPS it means each frame takes 20ms to render. If you now have a speedup of 10FPS, so 50 -> 60 FPS(16,66 ms), you made your rendering 3,33ms faster per frame.

If you do the same, but start with 100FPS(10ms). So 100 -> 110FPS(9,1ms), you only realized a speedup of 0.9ms.

So telling us you got a speedup of 10FPS is utterly meaningless, because we don't know anything of the magnitude of the speedup (compare 0.9ms to 3.3ms).
Using FPS for an absolute value("my game runs at 60FPS") is fine, but using it as a relative value("runs 100FPS faster") is wrong.
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Lunch (43 views)
2016-12-06 16:01:40

ral0r2 (270 views)
2016-11-23 16:08:26

ClaasJG (403 views)
2016-11-10 17:36:32

CoffeeChemist (499 views)
2016-11-05 00:46:53

jay4842 (545 views)
2016-11-01 19:04:52

theagentd (570 views)
2016-10-24 17:51:53

theagentd (552 views)
2016-10-24 17:50:08

theagentd (503 views)
2016-10-24 17:43:15

CommanderKeith (498 views)
2016-10-22 15:22:05

Roquen (460 views)
2016-10-22 01:57:43
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
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!