Hacker Newsnew | past | comments | ask | show | jobs | submit | foodmart's commentslogin

Looks fine to me on a Macbook.

That foreground colours for the main text is not even that light. Only lighter text is used for the lesser important sponsors sections.

Maybe you need to get your vision checked.


A rust installation is needed due to you having to compile it from source manually.

If binaries were to be distributed, a rust installation would not be needed.


Yes, I haven't provided the pre-built binaries yet. Maybe I should..


Check out snapcraft, it can build rust binaries!


With great power, comes great responsibility. For those who don't prefer this level of abstraction, just use a higher level zero cost abstraction.


The higher level abstractions aren't zero-cost.


No reason they can't be.


This might be a completely ignorant question;

How can there not be an drawing app built on top of this so that you can just model/draw and have it translate??


There will be.

The point of Vulkan wasn't to change the OpenGL API to something else. It was to expose more of what the inner workings of a modern graphics card is, and to remove ambiguity introduced by higher level abstractions used by OpenGL. It is more of a direct translation of what can be done with a graphics driver.

This means that developers (engine writers) who want to can now get a lower level access to what the graphics card can do, and do so in a more deterministic fashion.

Everyone else will be able to use higher-level abstractions that will undoubtedly appear, and those probably be easier to use than OpenGL itself. Best of all, they'll be open source so anyone can dig in and tweak (or understand) something rather than forever depend on some obscure OpenGL behavior no one really understands.

There will be growing pains. The existing engine codebases are heavily based on OpenGL, as are helper libraries. That will need to change. Things won't just be faster overnight. But judging by what I read, in the long run it will be better for everyone involved.


There will be. That's open source's job.

Vulkan isn't a complete replacement for OpenGL; it's a GPU API aimed to be built upon.


The goal is to have a cross-platform low level API that can be easily tested for compliance/conformance, right?


Also one that exposes graphics card mechanics so that higher-level tools can use them more intelligently for optimization purposes.

A good analogy is the RISC transition - implementations were made easier and faster, but as a tradeoff assembly was made much more difficult to program in. The idea being that only a small group of tool-makers with specialized knowledge of the underlying mechanics (in that case compiler developers, in this case engine developers) would ever have to deal with them.


I don't know, I feel like D3 solidly demonstrated that you can have absolute configurability without sacrificing any conciseness.


D3 is not remotely an abstraction API for a hardware compute engine. Vulkan isn't about "configurability", it's about cleanly expressing the specific operations that the hardware can perform, and the specific requirements for talking to it. Those are complicated, inherently. Data graphing, fundamentally, is "simple" in comparison (and to be fair, D3 exploits that beautifully).


D3 is not concise compared with most simple js graphing libs -- e.g. highcharts.


I agree, but it is not fair to compare D3 and highcharts because they are not in the same league.

There are many higher level libraries leveraging on D3 that could be compared to highcharts. There are also many lower level libraries that have the same scope as D3, and compared to most of them D3 is pretty concise - the parent comment has a point.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: