next »

[Boreal]

glVertexAttribPointer() has been replaced with a better API

Which one? Cannot find anything related to this.

I wrote an answer on GDSE that might help:
http://gamedev.stackexchange.com/questions/92832/in-opengl-whats-quicker-lots-of-smaller-vaos-or-one-large-one-updated-each-fr/95616#95616

[powly]

Ah, thanks! I'm maybe not as excited about this but will definitely start using it -- less binds is less binds and it looks somewhat better. Along with the direct state access in 4.5 you don't have to bind an attribute array buffer ever, I guess. In your example there, should the second

Code:

glVertexAttribFormat(0, 3, GL_FLOAT, false, 0);

have 2 as the first parameter since it's the location? I'm trying to get away from manually handling locations and querying what GL decided to use instead.

[Boreal]

Yes, it should be.  Nice catch, I fixed my answer.

[Sik]

This, pretty much.

[Boreal]

I just had an epiphany about how I am going to design my scripting engine.

For a while now I've been struggling to come up with a solution to the goal using a common language to write CPU kernels, GPU shaders, entity data, AI behaviours, and so on.  I tried writing my own interpreters/compilers for existing languages and even a custom language.

Yesterday I discovered the concept of an embedded domain-specific language (EDSL).  This got me thinking, and I asked myself this: what if I used an existing scripting language as a host for an EDSL?

I'm gonna go ahead and use Lua as the reference implementation, since it has such a great API.  This is an example of a simple kernel that adds 1 to its input.  You would use this specific dialect of the EDSL to write shaders.

Code:

x = Input(0, Integer)

y = x + Integer(1)

Output(0, y)

Using operator overloading and type constructors, I can encode what appear to be imperative instructions as nodes of an abstract syntax tree (AST).  The AST can then be interpreted, compiled to GLSL or SPIR-V, etc.  This paves the way for opaque usage of asynchronous or lazy procedures.  On top of this, the host language now becomes an extremely powerful preprocessor.

The beauty of this is that I could potentially support other scripting languages as hosts.  This is the Scheme equivalent of the example kernel:

Code:

(define x
    (make-input 0 make-integer))

(define y
    (+ x (make-integer 1)))

(make-output 0 y)

I could even write a system to build up an AST in-place using C++ as my host!

[BorisTheBrave]

Boreal, what you are describing is called "abstract interpretation". It's quite a useful technique. But you've yet not hit upone one of it's major difficulties. How are you going to handle control flow? Hopefully, you don't need it, as nearly all languages don't give you sufficient hooks to do it abstractly. Getting variables to work as expected is also hard.

It's possible to get it going, but most people prefer just to write a simple language parser instead, which also gives you an AST.

[powly]

Sounds cool, handling that kind of off-loading automatically would be awesome.

I got this simple method for video capturing up and running -- it's great to not have to open up some other software and then convert before uploading. I switched from the suggested direct readpixels to a pixel pack buffer to reduce lag when the program is not bandwidth bound. I also tried to output directly to webm, but the compression is very slow so it might be a better idea to keep using mp4 or convert offline. Or something else maybe? I know next to nothing about video formats.

[Boreal]

Boreal, what you are describing is called "abstract interpretation". It's quite a useful technique. But you've yet not hit upone one of it's major difficulties. How are you going to handle control flow? Hopefully, you don't need it, as nearly all languages don't give you sufficient hooks to do it abstractly. Getting variables to work as expected is also hard.

It's possible to get it going, but most people prefer just to write a simple language parser instead, which also gives you an AST.

The EDSL is pure, so control flow only exists in the form of condition statements (if-then-else).  My first thoughts were just to use another type constructor, a la

Code:

x = Input(0, Boolean)
y = Cond(x, Integer(100), Integer(0))

But you're right, that may end up being a big oversight on my part.

[oahda]

I tried to read up on this EDSL thing and I tried to parse your post again, but I still don't really get exactly what it is or what the point of it is. Not to have to write both C++ and GLSL but write both program and shader in Lua? Why? What am I not understanding?

[Boreal]

I tried to read up on this EDSL thing and I tried to parse your post again, but I still don't really get exactly what it is or what the point of it is. Not to have to write both C++ and GLSL but write both program and shader in Lua? Why? What am I not understanding?

The idea stemmed from using compute shaders, and potentially having to support a CPU fallback if the user's GPU did not support OpenGL 4.3.  I figured if I had a DSL, I could write it once and compile it both to GLSL and to some function to be run on the CPU in parallel, and I wouldn't have to maintain multiple copies of the same program in different languages.  Then I got thinking about the other possibilities, like being able to script AI or networking while both abstracting away finicky implementation details and allowing mass parallelization.  As well, I can use the host language as a super powerful implementation-agnostic preprocessor and macro system.

I've always just been the kind of programmer to prefer doing more work up front if it means simplifying and streamlining things later.  As well, I am dedicated to making my game mod-friendly.  While there's a lot to be said for supporting many DSLs individually, I would rather only have to deal with minimally one FFI since it's a huge pain, even with Lua, and put the burden of interfacing with my EDSL on the host language.

[BorisTheBrave]

The idea stemmed from using compute shaders, and potentially having to support a CPU fallback if the user's GPU did not support OpenGL 4.3.  

Of course, Mesa has already done this for you, in the context of OpenGl at least.

[Boreal]

It just werks.  It's incredibly naive and there's no types other than an integer yet, but still.



Updated to reflect adding a pseudo-generic type system.

[Layl]

I'm looking at doing something similar for my shader code, basically a system that translates .NET IL into GLSL, allowing you to write your shaders in C#. Since there's already an existing project that does this, I can either just add that in as a dependency, or write my own implementation based on it.

[Boreal]

I can somewhat see turning CIL into SPIR-V, but to GLSL?  That's a bit crazy.

[ProgramGamer]

I got accepted into a university and am starting a four year long coop software engineering program in September! :D

[oahda]

UTF16 text rendering working in like an hour with custom OpenGL using SDL_ttf for SDL2!

[gimymblert]

but does it handle emoji
/sad joke, kill me

[Photon]

I got accepted into a university and am starting a four year long coop software engineering program in September! :D

Congratulations! 

[Exudes]

I almost feel like I should name them.

[Boreal]

Today I discovered the -jN flag for Make, which enables a multi-core build (set N to the number of cores + 1).

Since I have an 8-core (FX-8320) my build is lightning fast now