next »

[oahda]

What about Vulkan? Has anybody tried it yet?

[Dacke]

I'm not at all knowledgeable on the topic. But my understanding is that Vulkan is even more geared towards people building big, efficient engines rather than individuals working directly with it. So my expectation is that we'll get libraries/middleware that act like Vulkan-backed "replacements" for working directly in OpenGL.

maybe? 

[Garthy]

Vulkan sounds very interesting technically. It does not look like it's particularly easy to use though. For example:

https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp

Over 1000 lines of code for what is essentially Hello World. Yikes!

NVIDIA's example:

https://github.com/NVIDIAGameWorks/GraphicsSamples/blob/master/samples/vk10-kepler/HelloVulkan/HelloVulkan.cpp

400 lines long, but external dependencies that'll pad it out a lot.

It looks to be very powerful but very hard to use. I wonder if the intended audience are library and engine developers.

However I am just speculating at this point. Someone who has spent some time with it could probably offer better insights.

[JWki]

I did spend some time with Vulkan.
It took me about 4 hours and about 1200 lines of self contained code to get Hello Triangle going. A lot of that code can be reused for a real application though because there's A LOT of one-time setup in Vulkan.
In general, the API is just really verbose, and resource binding is a bit more complex than in OpenGL, but it is not as difficult as it looks on first sight. Also, debugging is WAY better with the validation layers enabled.

I have to admit though I don't know if I will use Vulkan for hobby projects because I'm just so fluent in OpenGL. Even though going back to the crappy debug callback is a fucking pain.

On the topic of modern OpenGL vs the deprecated APIs, please never ever use those. I only feel more or less happy now with OpenGL 4.5, I can't even really stand having to use 3.x style for my thesis which uses WebGL. If you want to somehow be efficient with OpenGL, and you really want to be efficient, get used to the newer APIs, I promise they are really really easy to understand once you grasp the basics of computer graphics.

[InfiniteStateMachine]

Modern OpenGL is far, far harder to pick up than earlier iterations. The fixed-function pipeline was much easier to pick up than being forced to jump right into shaders from the start (as you are required to do with modern OpenGL).

The payoff is worth it though. As soon as you need to do something more than moderately complex, shaders are far, far easier to work with.

I'm glad the days of playing roulette with supported FFP functionality are past us, although I think the barrier to entry for modern GL is too high now.

OpenGL 1.0 I think might be one of the only times I ever saw a performance hit from function call overhead. Display lists solved that but wow, that was pretty crazy :D

[gimymblert]

Trying to program 2 pts circle intersection and finding tangent to point, but everything keep blowing up I don't know why
That was supposed to be the easy part ... why are the most unsuspecting trivial parts always failing me? Need to investigate where teh problem is

[Garthy]

Modern OpenGL is far, far harder to pick up than earlier iterations. The fixed-function pipeline was much easier to pick up than being forced to jump right into shaders from the start (as you are required to do with modern OpenGL).

The payoff is worth it though. As soon as you need to do something more than moderately complex, shaders are far, far easier to work with.

I'm glad the days of playing roulette with supported FFP functionality are past us, although I think the barrier to entry for modern GL is too high now.

OpenGL 1.0 I think might be one of the only times I ever saw a performance hit from function call overhead. Display lists solved that but wow, that was pretty crazy :D

I didn't get heavily into the performance side of things back then, but I'm not surprised to hear that function call overhead was an issue.

[Sik]

So my expectation is that we'll get libraries/middleware that act like Vulkan-backed "replacements" for working directly in OpenGL.

Yeah that's the idea. Especially in game development where we're moving away from making our own engines even for simple stuff, it seems the trend is to either make engines (middleware) or make games (on top of the middleware), never both. Specialization in a nutshell.

And the little I've seen from Vulkan made even the most complex OpenGL code look simple in comparison. Argh.

[JWki]

So my expectation is that we'll get libraries/middleware that act like Vulkan-backed "replacements" for working directly in OpenGL.

Yeah that's the idea. Especially in game development where we're moving away from making our own engines even for simple stuff, it seems the trend is to either make engines (middleware) or make games (on top of the middleware), never both. Specialization in a nutshell.

And the little I've seen from Vulkan made even the most complex OpenGL code look simple in comparison. Argh.

Gotta say I hate that trend. Really like the handmade dev movement gaining traction atm.
On Vulkan, it's just a different level of abstraction really, trying to help the driver as much as possible up front because the real pain with OpenGL is hitting slow paths in the driver because the API is not explicit enough to make sure you don't.

[powly]

To date there is no actual piece of software that has gotten a relevant benefit from being Vulkan/D3D12 -- the potential gains are never realized since these "new kind" of low-level APIs only minimize the CPU overhead which is normally not your bottleneck and, potentially more importantly, require you to do the optimizations that have always been the responsibility of driver developers who know the hardware inside and out. It might be worthwile if you have hundreds of engineers to throw at the problem but I'd stick to the good old ones (with proper support and mature toolchain/community). Unless you're using an engine; EPIC or Unity could have enough manpower to get the code specialized for enough platforms (though it still requires you to have quite specific computational tasks go see any kind of relevant improvement)

[MorleyDev]

If memory serves some people reported higher FPS with the new Doom game's Vulkan version? Or has that since been debunked? I've been mostly in enterprise space lately (Well, Angular 2 and WebAPI enterprise space), haven't been keeping track of the game dev world as much.

[GSGBen]

I found yesterday that one of Unreal Engine 4's round() functions doubles the value to sort out rounding of even .5 values.....limiting int32's to half their usable range. FFFFFFFFFFFF

[AaronB]

Took me a while to tweek this Nvidia vs ATI anomaly:

Code:

particles[p1].join_vector[link1] = join_vector;
particles[p2].join_vector[link2] = -join_vector;

Works like a charm on Nvidia - for ATI, nada, YOU GET THE SAME VECTOR FOR BOTH.

solution:

Code:

particles[p1].join_vector[link1] = join_vector;
particles[p2].join_vector[link2] = join_vector * -1;

go figure ?

[DrDog]

Code folding is real cool when it's a couple of 5-15 line well-named and well-documented methods.
Then suddenly you see

Code:

10void process(string type, int size, char[] buf){ 
150

[gimymblert]

To date there is no actual piece of software that has gotten a relevant benefit from being Vulkan/D3D12 -- the potential gains are never realized since these "new kind" of low-level APIs only minimize the CPU overhead which is normally not your bottleneck and, potentially more importantly, require you to do the optimizations that have always been the responsibility of driver developers who know the hardware inside and out. It might be worthwile if you have hundreds of engineers to throw at the problem but I'd stick to the good old ones (with proper support and mature toolchain/community). Unless you're using an engine; EPIC or Unity could have enough manpower to get the code specialized for enough platforms (though it still requires you to have quite specific computational tasks go see any kind of relevant improvement)

I'm late to that but god that is at least wrong for emulateur! Adding dx12 version to wii and wii U put them to a level where I have no more GPU hit because of them, I'm cpu bound or even hard drive bound for performance! I can even play wii game using 16x supersampling in full HD without a single performance hit, it's insane, the difference between after and before is night and days. Ps3 and x360 games became playable overnight from 3fps to 60!



Okay now a rant from another forum, because Im' grumpy

I tend to dislike visual scripting, but not for the same reason most people dislike them, they are just poorly design, and design with the wrong reason in mind.

[USER=187506]@neginfinity[/USER]

1. I have been coding for 10 years and I'm still slow and bad at it, and one main cause is mistyping leading to stupid syntax error ... which makes me and especially beginner lost a lof time. And the key thing with visual logic is that it remove syntax from the equation entirely leaving you dealing with the pure logic. Where were the hater when I slowed a production with a perfectly working code that had a bunch of missing ";" in the neverwinter scripting language (old bad memories of the beginning years :oops: ). Also renaming can be a nightmare with text interface, you have to get the options right to not have collateral damage to rename health to hp doesn't turn variable like healthiness to hpness and break the code entirely, and let's not talk about file dependency when renaming in one file don't necessarily propagate to all files, that makes a lot of difficult to track bugs, for stupid error.

2. Code is mostly about logic flow, logic flow is hard to see in "proper" code, you can have a variable declaration that only have an impact 1000 lignes below, and then maybe it goes through a series of function and to merge back with itself, tracking this is hard, especially if you are a beginner and added stuff as you go trying to get result. With visual node base script, you see the whole flow and can trace it intuitively, the logic error are more readable.

3. Text is sequential in nature, concurrency and dependency are hard to see, visual node base scripting make the nature of code apparent, it's a flow, it's also a graph, and you can use graph properties to make the logic clearer, like highlighting a particular trajectory through the code and highlighting the node along that path, so you can clearly see what affect what, even in spaghetti code ... but that's not a function you typically see in node system because people haven't thought about them much (though blue print seems to have a simple version of that features).

4. Also simply readability convention. We have stuff like Hungarian notation for typing, we have almost no equivalent in visual scripting because it's not taken as seriously, a lot of spaghetti is the equivalent of naming variable using only one non descriptive letter or insanely short abbreviation that became obscure once you are out of your coding flow and you forget why you name that way, you have comments to deal with this obscurity, you have coding style to help with the insanity of looking at code and you have IDE that keep track of stuff because text is bad for that, you have intellisense because typing is effectively slow and inefficient, it's actually a distinct skills from programming itself. The main problem of code, and I mean most system, is simply chunking data. It's related to above, it's simply that best practices and tools to deal with the atrocity of typing are older and more mature than visual coding, I remember when code bubble was hype in some coding circle because it allows to see two related code together side by side! what a revolutions!

5. And let's be honest, typing is just an input interface, a series of step to select a command or a parameters, it turns out that drag and dropping is exactly the same thing, a series of step to select a command or a parameters ... except like pointed earlier, it actually prevent syntax error and help seeing the logic faster. Anyone trained enough in visual coding can deal with spaghetti visual and also make pleasantly organize visual flow, just like people trained to typing can see the flow of code that would scare most beginner (and me, ugh those stupid "bracket" block and those ugly ";"), yet they will still cringe at spaghetti type full of typing quirks (start a fight among programmers about how to properly place a bracket, after the if and under it?) and bad naming convention. ANd to fully understand what's happening you still have to do a lot of unnecessary scrolling with both approach. :mad:

I'm a bad programmer, I'm slow, make constant stupid mistakes with syntax, I still prefer typing over visual coding but I tend to favor simple language with lots of magic function (blitz3D) to prototype because I don't like those stupid mistakes lock me out of my thinking process to solve something that have nothing to do with the task at end, and you know that programming require attention, any distraction is consuming and makes you inefficient, typing is inefficient, even more so for beginner that must constantly think about the text more than the logic. But let's be frank all interface to programming are kind of bad right now, I think we need a revolution and less baby ducking throwing tantrum people are trying to make more people efficient because it does not tickle your preferred way of doing. There is problem and we need to solve it, visual or not! Yes I'm mad at coding :mad:

[AaronB]

I tend to dislike visual scripting, but not for the same reason most people dislike them, they are just poorly design, and design with the wrong reason in mind.

The thing to bear in mind is with each level of abstraction you will introduce less flexibility and efficiency.  Assembler will always be faster/efficient than a higher level language and a text based language will always be faster/efficient than a visual approach.  At the end of the day you are just manipulating electrons through a bunch of switches.  Horses for courses. For an analogy - there is a lot of power in directly manipulating billions of cells with its gazillions of chemical reactions, you can bio-engineer the next human super race. Or you can just control the same system by unwrapping a cheeseburger - which won't quite give the same results.

[gimymblert]

I don't believe that's true, because you use the confusion between interface and abstraction, visual interface isn't about abstraction (ie high level command). I can perfectly do a visual interface for assembler that match 1:1 the text interface with no problem.

That's a misunderstanding that plague discussion about coding.

[qMopey]

Well when we say "visual scripting" there's often a lot of stigma about what that means. Usually it means something like UE Kismet with nodes and such. That implies a lot of abstraction.

[bateleur]

The thing to bear in mind is with each level of abstraction you will introduce less flexibility and efficiency.  Assembler will always be faster/efficient than a higher level language and a text based language will always be faster/efficient than a visual approach.

Two things about this: First, Assembler is only faster than a higher level language in the optimal case. In reality, modern compilers are so good that hand coded Assembler is almost never the best option even if you care only about performance. And in fact for all but the simplest tasks it quickly ceases to be obvious what the best language choice is. In particular, if you ever call libraries you didn't write yourself (which of course almost every program does) then the efficiency of the library implementations will often be the most important factor.

Second, as software becomes more complex we increasingly care a lot more about coding efficiency and a bit less about runtime performance. As such, any coding system which enables programmers to work more efficiently is worth considering. A modern high level language in the hands of a competent programmer can easily be (literally) ten times faster to develop than C for non-trivial tasks.

The real problem with visual coding over text is that it's so much less expressive. That's by no means an insurmountable problem, but a truly powerful visual coding language might conceivably end up no simpler to use than text. The appealing simplicity of (eg.) Scratch arises partly from the fact it's usually doing simple things.

[gimymblert]

The thing is what would be the paradigm of manipulation, My main issue with text is that it's open to syntax error and require many step (typing) to select one command. Visual scripting remove syntax error but have a slower procedure to select command (drag and drop), the question is how to improve the selection procedure to keep it fast yet precise?

My proposition would be to use tree interface where node are selected through keys in a hierarchical fashion. But I move the problem to setting up the tree. So instead of typing a function, you would type it's tree adress, then have an interface to input parameter one after another (with a backtrack, forward key to navigate among them).

We can also have best of all word, ie function get turn into token object you can drag, but can be type when edited, the drag and drop automatically create corresponding and edited text code, and we can navigate through them using tree selection.

Because ultimately, we can get code to a bunch of object, statements/expression (basically line), loop, variable, function, objects etc ... they are rigidly define don't necessarily have order dependency. For example what if function are basically floating windows you can minimize, so you explore what's in a function without scrolling or opening a file, by clicking it's identifier? or that you could see the code through their identifier or the attached plain text that describe them, using mad lib to embedded the parameters? I could click a new line to add it (or any keys like "enter" like currently) then either type the identifier, use the graph selection or go to the function automatic ibreary on the side of the IDE to drag and drop it into the line, which would open an automatic box to input parameters... things like that.