Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: 1 ... 33 34 [35] 36
1021  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-14 21:14:36

Thanks for the link to this great tool! Will be valuable for AMD people.
Looks like for Nvidia folks there is also hope Smiley
http://www.nvidia.com/object/nvshaderperf_home.html
1022  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-14 19:42:47
Wow, if register allocation is not completely wrongly and suboptimally implemented, then I would say no, as that register is likely to be reused by code later (or earlier) if the same register was also allocated for other variables.
But this is an assumption that I make about the LLVM register allocator!
So, unless you only have a single value in your code, which is your condition, that needs a register, then yes.
But then your simple shader will also not be a performance issue. Smiley
1023  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-13 23:04:32
Quote
After some research, we can have more than one shaders of the same type but only one "main" method ? is it right ?
Yes. That is correct.

But let me explain a little bit further. There are three things that you need to separate when talking about shaders.

First: The shader stages.

Currently, there are these stage:
- Vertex
- Tessellation Control
- Tessellation Evaluation
- Geometry
- Fragment
- Compute

These are like the "types" or "kinds" of shaders you can have and each has a different domain (i.e. "things on which they work").
Shaders in the "vertex" stage work on vertices, as you know, and shaders in the "fragment" stage work on fragments.
So, the stages are the kinds of shaders you can have.

Second: Shader objects.

These are comparable to object files in native programming languages, like C, C++ or Objective-C.
They are compiled from GLSL code and contain the compiled binary code as well as the description of the interface of this particular shader object, which consist of the "symbols" defined, declared and referenced by that object (i.e. declared uniforms, input/output variables, functions).
In GLSL a single shader object can only belong to a single shader stage.
There can, however, be arbitrarily many shader objects for the same shader stage.

Third: Shader programs.

Shader programs are created by linking multiple shader objects together.
This is also comparable to the linking process of native languages. The linking process takes all shader objects, identifies the declared and referenced functions and variables in them and links them together. That means, things of equal name within two different shader objects get identified to be the same.

Here, you could have a shader object A of stage "vertex" declaring and defining a function 'f' but not using it. Then you can have another shader object B, also of stage "vertex", which declares the existence (i.e. "prototype") of that 'f' and calls it.
During linking, the linker detects that the 'f' in the first shader object A is actually the same as the 'f' within the second object B and links declarations and references to the single definition.

Multiple shader objects of the same shader stage make quite some sense as you can modularize and factor out common functions you need in many of your shaders.

Can you have more than one main()?

Regarding functions and other symbols, you can only have a single function with the same name throughout all shader objects of the same stage. Therefore, you can also only have a single "main()" function.

Cheers,
Kai
1024  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-13 10:23:25
Thanks, basil, for your insights!
Goes along the same lines that I observed.

Divergent branching on uniforms is so heavily slow, but if they converge then it's like a no-op...
Hm..., actually the stroke-through above line from me is complete nonsense Smiley, as "uniform" means "uniformity" and therefore "equal for all threads." Smiley
I actually meant branching in general without uniforms.
Now I am curious as to why branching over uniforms actually is slower than subroutines...

But anyhow, regarding this, there is also one interesting extension:
ARB_shader_group_vote,
that can be used to avoid branch divergence by computing whether all threads of a warp will take either the one or the other path and then decide which path all of them should take.
1025  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-13 08:55:08
Also no one is actually using subroutines either for performance reasons.

Hi pitbuller,

it's good to hear of someone else also having used shader subroutines and can say something about their usefulness, since I have very few experience with them.
Could you provide empirical data as to whether, when and how much it actually made a performance difference for you using them?

My finding is that it is never an issue, because the shaders I saw were mostly bandwidth-limited, as they fetched a lot of data through buffers and textures/images for things such as deferred shading.

The next thing that made a huge difference in performance was diverging if/then/else branches for a given thread-warp.
It can be - though I am not a hardware engineer or drivers developer, so I cannot state it for sure - that shader subroutines are less of an issue because of coherence in the path chosen by a thread-warp (i.e. they all take the same path = the same subroutine).

On the other hand shader subroutines should then also be as performant as an if/then/else on a uniform.
But I will be most happy to hear about your or everyone else's findings.

Anyway, as a conclusion: Everyone should try it for themselves, as only that will give them reliable, empirical confirmation. Smiley

Thank you!
Cheers,
Kai
1026  Java Game APIs & Engines / OpenGL Development / Re: OpenGL multiple shaders nonsense! on: 2015-01-12 23:02:57
This is actually a very good question to ask!
And it kept the OpenGL community busy for quite some long time.

Concatenating multiple vertex shaders is sadly not possible.
But there are solutions:

The first and worst possibility for modularity is probably through transform-feedback, where you let one shader transform your vertices and write those out into a buffer object.
Then take another shader that sources the already-transformed data from that buffer.

The next best approach is ARB_separate_shader_objects.
It allows to mix-and-match multiple shader objects of different stages and programs through "pipelines."
You can therefore have two vertex shaders each compiled to a separate program and one fragment shader also compiled and linked to a single program.
Then whenever you need the first vertex shader, you would "bind" that shader to the vertex shader stage in a particular pipeline object together with your fragment shader.
The advantage of that is that you do not have to have a big "uber" shader that contains everything and you also do not have to build a shader program for each combination of shader objects and stages you have.

The next best thing is ARB_shader_subroutine.
It is however only available on GL4 capable cards.
That allows to have a limited support for "function pointers" in GLSL, like you know them from C/C++.
There you can define GLSL functions to be "subroutines" for a given subroutine type name.
As you wanted, you can then use uniform variables to "activate/select" a specific function of a given subroutine type during runtime without the need to rebuild your program or rebind your program pipelines.

Hope that helped!
Cheers,
Kai
1027  Games Center / WIP games, tools & toy projects / Re: Cross on: 2015-01-12 18:40:28
Just as an advice: For starters simply use the jar (i.e. "zip") file format.
That fits perfectly with Java as it can be read and written using the Java API and even the ClassLoader, if in the class path.
I am also thinking about module systems such as OSGi, where it can be a dynamically loaded "bundle/plugin", and what not.
And above all: It has excellent accessibility and support for reading/inspecting/writing from other tools/file manager (because being zip).
If compression factor is your main concern, than all that is of course only if you won't come up with a better compression agorithm than deflate.
1028  Java Game APIs & Engines / OpenGL Development / Re: modern OpenGL discussion on: 2015-01-11 13:38:48
I used IntBuffer for indices (since it's more simple than ByteBuffer) for glDrawElements but LWJGL don't have method facilities for use an IntBuffer and providing the number of vertices to fetch except by consumming all datas from the buffer.

You know you can still use a ByteBuffer, but to make it more convenient for you to fill it, you can create an IntBuffer view on that ByteBuffer with ByteBuffer.asIntBuffer().
Using this way you can also not forget about flipping or rewinding your buffer before handing it off to LWJGL.
1029  Game Development / Game Play & Game Design / Re: Video: "The Great Glitch Crisis of 2014" on: 2015-01-11 11:23:16
It's almost as if no-one reading or writing this stuff has ever had an actual job making software for a living....

Although I don't know about the professions of the people here, that's with everything in life, I would say.
The more people can only place their opinions instead of their experience on something, the more they talk about it.
But I think the posts serve as an incentive for people like you, who know their business, to share your experience with them. Smiley

By the way: In case I offended a respectable software-engineer by the above, I apologize! Wink
1030  Game Development / Newbie & Debugging Questions / Re: Painting algorithm Tilemap issue on: 2015-01-10 20:18:31
Informing yourself about the principles of Computer Graphics I would generally consider a good thing to do.
But I doubt you would find anything particularly worldshaking about that simple "Painter's Algorithm." Smiley

I mean, just be clear on that: Naturally, you need to draw things in the background first (your floor) and then afterwards on top of that your units.
The reason for that being that your renderer (one without "Z-buffer") paints the things as you command it to.
If you paint B after A ("after" as in program execution order "after") then clearly B will overwrite A's image.
1031  Game Development / Newbie & Debugging Questions / Re: Painting algorithm Tilemap issue on: 2015-01-10 19:57:50
Well, there are so many ways to do things, that I don't want to impose one on you.
The only thing I'm saying is that you would want to draw the things that should be on top of other things last.
If you do not use a Z-buffer algorithm (like when using OpenGL/Direct3D), then the Painter's Algorithm is your best choice.
1032  Game Development / Newbie & Debugging Questions / Re: Painting algorithm Tilemap issue on: 2015-01-10 19:45:27
Very wisely chosen title for your post, as the "Painter's Algorithm" is actually the solution to your problem. Smiley

That being: First paint the things that should be in the background. Then paint the things in the foreground on top of that.

Apart from that, It seems not obvious why some tile can render two things in the wrong order, as it seems it can only contain one single type of something. I guess you have then something else rendered apart from your tile map?
1033  Java Game APIs & Engines / OpenGL Development / Re: Cube-Map Shadow Mapping on: 2015-01-10 01:53:25
Quote
There's another method but I don;t remember what it's called
You likely mean Dual Paraboloid Mapping and it being applied to shadow mapping?
1034  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-09 22:04:09
Yeah, thanks for your link, too.

They seem to be saying just the same as the US document, and I think every other document would.
That being always in regards to the "interoperability with independently created software."

And of course under IV. (second 3°) it also says that you may not reverse-engineer if you intend to use that "for the development, production or marketing of software substantially similar in its expression, or for any other act which infringes copyright."

But that is of course obvious and of course no one would do that. Smiley
1035  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-09 21:41:00
Yeah, I too think it's mainly for learning something from it and of course not sharing or marketing it, only by which he would violate that "circumventing copyright protection" thingy. Grin
1036  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-01-09 21:34:03
Quote
Still reverse engineering the Battlefield 4 engine.
You do what?

Even though given that you might be able to do that, which is quite remarkable, you do know that you are very likely legally forbidden to do that by US law?

See section (f) Reverse Engineering.—

Also the European Computer Programs Directive has something to say about decompilation, which may or may not refer to what you are doing exactly, and whether Battlefield 4 is actually protected by US law instead of European law (which I guess it is):

See Article 6 - Decompilation

Sorry, I didn't want to be a grinch here, just wanted to let you know, before you decide to spread the news more. Wink
1037  Game Development / Newbie & Debugging Questions / Re: LWJGL - Update Mat4 Array Uniform on: 2015-01-07 15:49:26
Yes, glUniformMatrix4f.
1038  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 09:57:26
Quote
Stable enough...

Everyone is encouraged to use LWJGL 3. Being a community project, which not many developers currently rely/build on, it is vital for the project to be used more widespread. LWJGL 3 does not mature/get stable on its on.
It relies on the community to use it and (honestly) find, report (and possibly fix) bugs.

The current stability only results from early developers already using it and parts of it (namely GLFW) and detecting bugs in them.

For me, one of the very great things about the LWJGL's authors is that they are really eager to take care of any issues found within it.
They simply do not have the time to thoroughy test LWJGL, so they are more than happy to hear about any issues you report and are very eager to fix them!

Regards,
Kai
1039  Game Development / Articles & tutorials / Re: GLSL basics on: 2015-01-05 21:20:37
Good start, lcass, keep at it!
Could you please elaborate more on the various shader stages?
In your article they seem to be popping up too quickly with little "transitioning" between them and further introduction.

Also try to elaborate more on the interface between the host program and the shader.

All in all it's a good tutorial.

Just as a side note, for you and anyone else writing tutorials or articles, I also highly recommend reading the excellent book On Writing Well.
Even if English is not your native language, I found it applies to all other languages as well and greatly helps in improving writing style.
1040  Java Game APIs & Engines / OpenGL Development / Re: glVertex3f doesn't care about z axis??? on: 2015-01-05 14:52:39
Quote
... so make a call to either glFrustum or gluPerspective ...
Hey SHC,
sorry, but just to prevent some misunderstanding: There is no gluPerspective or GLU or GLUT in general in LWJGL 3 anymore.
That's why for perspective projection the OP needs to build the matrix on his/her own.
1041  Java Game APIs & Engines / OpenGL Development / Re: glVertex3f doesn't care about z axis??? on: 2015-01-05 00:22:32
Okay, so you need a perspective projection then.
Have a look at http://forum.lwjgl.org/index.php?topic=5586.0, which is a post on the LWJGL forum targeting LWJGL 3 with exactly that problem and a possible solution to it.
Normally I don't like referencing my own posts but it fits perfectly to your problem.
1042  Java Game APIs & Engines / OpenGL Development / Re: glVertex3f doesn't care about z axis??? on: 2015-01-05 00:01:08
Sri Harsha Chilakapati (known by his initials SHC here and on the LWJGL forum) is taking on the journey of writing a tutorial series on LWJGL 3.

I highly recommend having a visit to his site http://goharsha.com/lwjgl-tutorial-series/.

Regards,
Kai
1043  Discussions / Miscellaneous Topics / Re: OpenGL or DirectX on: 2015-01-04 12:01:15
Okay, my final advice to you would be, don't let you get insecure here, really.

From the point of where you stand currently, it makes no difference whichever you learn first.
And it's not like it's a decision for life, that, once you start with Direct3D you're bound to it forever.

Of course, it will take some good amount of time to understand and get comfortable with the API, but it is really not so much about the API as also stated by others here.
Instead it is about the principles of computer graphics.

But any arguing about it here is really going ahead of your time.
You will make no mistake by just delving into Direct3D.

And please do not get carried away by any prejudices that may or may not be attached to the company Microsoft or Direct3D. Any prejudices will just be in your way of learning things.
My opinion.
Be open to everything.

Regards,
Kai
1044  Discussions / Miscellaneous Topics / Re: OpenGL or DirectX on: 2015-01-02 15:32:54
Quote
So learn how to use the API to do things, as opposed to learn how the API actually does them?

Yeah, in a way like so, that is, to know what those *things* really are, like "synthesizing real-world light phenomena".
You see, OpenGL and Direct3D provide you with a very specific approach to rendering which is called rasterization to do rendering in real-time.
But there are other approaches to do rendering, such as ray tracing.

Once you grasp how rasterization works, you will begin to see beyond OpenGL and Direct3D and it won't matter anymore which API you use. Because all of them feature basics things such as textures, shaders and data/vertex buffers.

And then comes the time when you learn about all those nifty little tricks (so to call) that people invented over time in order to render real-world phenomena in real-time with rasterization, such as shadows with shadow mapping. Just have a look at the fantastic GPU Gems (http://http.developer.nvidia.com/GPUGems/gpugems_part01.html) series, which is a compilation of some of the best SIGGRAPH and Eurographics papers.

While looking at those things, you then realize that you need some grasp on mathematics (really easy maths, though), such as linear algebra with vectors and matrices.

And that's basically it. Anything further beyond that concerns itself with the mentioned nifty little tricks to quinch the last frames per second out of rasterization.

Hope that helped! Wink
1045  Discussions / Miscellaneous Topics / Re: OpenGL or DirectX on: 2015-01-02 14:54:58
Hi,

if you are going to go to college, which I assume is an university? in your country, I reckon you have some higher standards to approaching rendering than *just* learning to use some graphics API, such as OpenGL or Direct3D.

So, I guess the focus will be more towards the principles and fundamentals than to the mechanics of an API as in "do I use immediate mode, VBO or whatnot to throw my triangles onto the screen".
At least it was for me in my university years.

If the course applies DirectX, then do go with DirectX.
Starting with modern OpenGL 4, OpenGL and DirectX now have very little differences to them, as both now try to approach the least possible driver overhead, which eventually will result in both APIs reflecting the graphics devices as close as possible and converge each other.

But like said before, do not concern yourself too much with the mechanics of some particular graphics API. If you are new to both of them, there is no particular reason for one over the other anymore (disregarding cross-platform concerns or programming languages and other not so important factors when learning about computer graphics).

So, enjoy learning either of them! Learning Direct3D is hell of a lot of fun, just like OpenGL!  Wink

Regards,
Kai
1046  Game Development / Newbie & Debugging Questions / Re: Compute + Geometry Shaders on: 2014-12-29 23:29:23
To be honest, the focus of that tutorial series is not meant to be much about OpenGL Compute Shaders as it is about the physics and mathematics of light, which is eventually being applied to ray tracing and happens to use OpenGL Compute Shaders as one possible means for hardware-accelerated computing.
It just explains enough about OpenGL Compute Shaders in order to get something running and to understand the accompanying source code.

Anyway, I am certain that there are far better tutorials explaining the mechanics of OpenGL Compute Shaders and the underlying compute model, known from CUDA and OpenCL.
And if not, maybe someone wants to contribute one to the growing LWJGL Wiki? :-)

Still thanks to kappa and Catharsis for mentioning it! Wink

btw. Catharsis, the link to the Wiki article has changed, as it has been moved to a new Github repository, LWJGL/lwjgl3-wiki.
1047  Discussions / Miscellaneous Topics / Re: What I did today on: 2014-12-19 20:36:15
Quote
Started a LWJGL3 Tutorial

Nice, SilverTiger. That is really great!
LWJGL 3 needs more such tutorials, so that people can get started and to spread the news about what cool thing LWJGL is!

I think, you could also ask spasi to put it on the LWJGL github Wiki.
1048  Discussions / Miscellaneous Topics / Re: Change My JGO Name on: 2014-12-19 12:25:58
Hey, just one thing that right came to my mind as I read this post:

I've been on this forum for about a week or so, to see what's going on here and what nice people tell about their stories about what they do, how they came to learn things and where their hearts with their projects lie. Not, what their names are. ;-)

The famous German poet Geothe once said:
  "Namen sind nur Schall und Rauch", which roughly translates to:
  "Names are nothing but acoustic noise and smoke."

So, as kpars said, really, no one cares about one's name.

I know, it's tempting at times to have some auxiliary property or asset to you that might supposedly be fancy, but all that cares is who you are, not what you own or what your name is.

That may sound schoolmarmish, but I learnt this as a lesson for life actually. hahaha! ;-)
1049  Game Development / Newbie & Debugging Questions / Re: LWJGL - 3D Mouse picking on: 2014-12-18 20:07:30
For your concrete problem, you do not have to read it all, though.
Especially the first 2/3 of the article can be a bit long-winded, if you are not so much into ray tracing, history and problems of rendering in general... :-)

You can jump right into the section saying "Setting up the camera".
Or better, have a look at the source code whose references are found in hyperlinks beginning with "accompanying ...".
1050  Game Development / Newbie & Debugging Questions / Re: LWJGL - 3D Mouse picking on: 2014-12-18 19:47:47
Hi,

what you need to do is apply the inverse of the world-to-NDC transformation to your normalized-device-coordinates (NDC) space.
You therefore have to have the projection and view matrices of your scene, which OpenGL uses to transform a vertex from world-to-NDC space.
Once you have these, you need to invert the combined view-projection matrix to obtain the reverse transformation.
After that, you apply that transformation to the corner coordinates of your NDC space, which are -1 and +1 in both X and Y. Z can be 0.0 and W must be 1.

You might also have a look at the ray tracing tutorial in LWJGL: http://blog.lwjgl.org/ray-tracing-with-opengl-compute-shaders-part-i/

This tutorial uses modern OpenGL (OpenGL 4.3 Compute Shaders actually, also with a backport to OpenGL 3.0 GPGPU with fragment shaders) and uses NDC-to-world transformations to generate the rays for each framebuffer pixel, based on a pinhole camera model.

Cheers,
Kai
Pages: 1 ... 33 34 [35] 36
 
mercenarius (7 views)
2020-06-04 19:26:01

mercenarius (11 views)
2020-06-04 19:13:43

Riven (851 views)
2019-09-04 15:33:17

hadezbladez (5838 views)
2018-11-16 13:46:03

hadezbladez (2637 views)
2018-11-16 13:41:33

hadezbladez (6255 views)
2018-11-16 13:35:35

hadezbladez (1505 views)
2018-11-16 13:32:03

EgonOlsen (4741 views)
2018-06-10 19:43:48

EgonOlsen (5800 views)
2018-06-10 19:43:44

EgonOlsen (3283 views)
2018-06-10 19:43:20
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
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!