Rx – Extensible pixel editor implemented in Rust, inspired by Vi
cloudhead.io
cloudhead.io
Other than that, great project, spot on license choice, and best of all, Rust!
I've been looking for distrbution mechanisms for a while now, and static binaries are not easy for applications with a GUI.
As for Metal, it just works better currently with the underlying libraries I'm using (GLFW + gfx-rs), than MoltenVK.
It's (Azure DevOps) not always the easiest/best, but it's pretty good... my preference when including the project mgt tools.
Let me ask it the other way: is there a reason to use MoltenVK if we have a Metal backend?
gfx-rs (which wgpu-rs is based on) is the closest thing one can get to a low overhead portable GPU API.
This doesn’t apply to commercial software. Even if MoltenVK works flawlessly (I don't have experience with the technology), the only GPU API which does on Windows is Direct3D. For cross-platform stuff you want to support multiple GPU APIs, or you’ll have to spend a lot of money supporting users with broken/missing/nonexistent GL/VK drivers.
Likely the default of the underlying drawing library for Rust.
In addition, you have to install MoltenVK (a non-trivial task) if you want Vulkan on OS X.
With a static site generator, the GH readme file can be the website.
Agreed.
Vi-style editing of pixel art is a new concept that needs to be demonstrated first and foremost to drive this project.
Kakoune is another software for which the uncommon editing paradigm is one of the main features, and it is presented rather well on their main page [0]. A set of animated demonstrations of the editing paradigm comes before a display of the general appearance of the software in realistic contexts.
[0]: https://kakoune.org/
And perhaps for this overlap a tutorial is not needed, but it would be interesting to me to see it in action.
Says you. There is reason vim is not "dead" and it's not just cause "old people" still use it. Also, there are plenty of IDEs besides VS.
Finally, "vast majority" doesn't matter for shit with open source. One developer with an itch is enough. If there's a handful of others with same, all the better.
Developing videogames is not one of these reasons.
> there are plenty of IDEs besides VS.
How many of these IDEs are supported by mainstream 3D engines, or current-gen console SDKs?
Similarly, IdeaVim is shown as option in first run dialog of IntelliJ-based editors.
Similarly with Emacs key map in most older IDEs.
On a more related note, I find it interesting that the GUI doesn’t appear to be a toolkit like QT, but lower level, like a GUI designed for in-game use.
I can't speak for this project, but what you're describing is an Immediate Mode GUI [1]. imgui is one that comes up a lot.
This is the not-uncommon case where the irregular form is slowly losing ground to the regular form. It's possible that in a century, 'extensible' will be considered archaic.
[0] https://books.google.com/ngrams/graph?content=extendable%2C+...
I am considering using something like stretch[0] to handle layout concerns eventually.
Error of failed request: BadDrawable (invalid Pixmap or Window parameter)
The software you ran on a 25MHz machine was in all likelihood written in assembly, directly interfacing with the hardware of your machine, without even touching your windowing system (if you even had one, maybe you were running DOS). Modern operating systems frown on that sort of thing with extreme prejudice.
How is Vulkan more portable than a software renderer? And if you need hardware acceleration, OpenGL is more portable than Vulkan.
I would have thought SDL is probably a better target for this type of application. However, I'm happy to see developers use what they like and push the envelope how they like.
Just upgraded to Linux kernel 5.3 and beta mesa & vulkan so I can drop in my rx5700xt, which I still need to do.
The advantage that opengl has is a number of software implementations that can be used as a last ditch on unsupported systems. Efforts for software vulkan implementations are taking a long time to appear.
Wasn't SDL supposed to be that? What happened to that?
Vulkan is just an API for talking to graphics hardware. There are a wide variety of applications which can benefit from using it.
As someone who does graphics programming, I would not choose OpenGL for new projects. For one thing it's the future: while I only expect Vulkan to become more well supported as time goes on, the opposite is happening with OpenGL (see the state of support on Apple platforms). Also the Vulkan API itself actually makes it easier to target more platforms. Because the OpenGL api takes on more responsibility over how the graphics pipeline is executed, there is actually a lot more variation in behavior across driver implementations than you have with Vulkan. This was one of the biggest headaches of OpenGL development which Vulkan has largely solved.
So if I had to choose between losing some users who are using old hardware verses the headaches of supporting an OpenGL application across platforms, along with the fact that OpenGL is actually getting less support over time, the choice would be easy for me.
It's a moot point anyway since the developer here is already using a high-level compatibility library.
In about 2005-2007, count of pixels in displays started to grow much faster than CPU power. FullHD monitors entered mainstream market. CPUs stagnated because laptops stopped being expensive toys and started to become desktop replacement.
Nowadays, with 4k or higher rez monitors even in some laptops, pretty much all software actually needs what Vulkan (or D3D, or GL) offers, just to update screen at 60 Hz.
OpenGL is not portable.
Technically it works on Windows, but that’s only true if you’re happy with 11 years old version of the standard, OpenGL 3.0: https://github.com/Const-me/GL3Windows#building-and-running GPUs have changed dramatically over these 11 years, i.e. that version is way too old.
Technically, OpenGL doesn’t work on majority of ARM devices. They use OpenGL ES, not quite the same thing.
Vulkan works on most of these, with the only exception of Windows devices who have Intel GPUs older than Skylake, i.e. older than 2015.
wgpu-rs has backends for Vulkan, Metal, DX12, DX11, and GL (partial). The primary backends are the lower-level graphics APIs that are in active development: Vulkan, Metal, and DX12.
In any case the point stands. A OpenGL wrapper on top of Metal is also possible, no real reason to actually depend on Vulkan for Apple platforms.
"Partially" is misleading, MoltenVK almost completely supports Vulkan.
At this point the only features not supported are quite minor things, like lack of custom allocator support, and not being able to query pipeline statistics. Geometry shaders are also excluded because they're not implemented in Metal, but they are considered optional in the Vulkan spec.
https://github.com/KhronosGroup/MoltenVK/blob/master/Docs/Mo...
As a professor of mine used to say, 99% there is still not done.
It might also be interesting to mention that wgpu is implemented with gfx-hal, which provides a common abstraction for native graphics APIs. But besides wgpu, gfx-hal is used in the implementation of gfx-portability [1], which is a MoltenVK alternative that runs on Metal, DX12, and DX11.
Speaking of Rust and UI, has the story moved beyond "DIY GL / Qt bindings / website backend" or are those still pretty much the options?
For me it was as simple as installing mesa-vulkan-drivers and re-launching rx. It is a very nice and minimal editor - well done
I think it's just Nvidia and GPUs for ARM SOCs. You need GPU drivers to use desktop anyway.
This is based on the cargo manifest: https://github.com/cloudhead/rx/blob/master/Cargo.toml
If you're interested in this space, there's also a lot of effort going into druid: https://github.com/xi-editor/druid
Edit: actually just see this sibling comment: https://news.ycombinator.com/item?id=21115680
Paradigm: http://reactivex.io/ Implementations: http://reactivex.io/languages.html
That being said the editor looks very cool! Congrats on shipping!
who cares? we all know how to use Google by now to narrow results by adding qualifying keywords to the query; it's not like I'm just going to search "rx" or even "rx rust" when I'm looking for this project (probably "rx rust pixel"). it's a complete non-issue.
Plus first result for "rx rust" lead me to https://github.com/ReactiveX/RxRust
Namespace collision is gonna be a pain for end users and newcomers, possibly depressing discovery, which is our point.
At some point we will have to generate random strings for the name of our projects because all the "good" (or even "bad") ones are taken. :P
Highlights for a "poop+scoop" related startup include: Flingo, Trash.ly, Fastpoop, Stinkere, Guunk, and Spoop
Your software has not more inherent value just because it is written in Rust.
If a tool solves my problem I just use it.
Free software lives as long as people keep committing to it. If people want to learn rust they will maybe do so through contributions to free software. You see where this argument us going, language matters.
Such comment would have made sense if this software was promoted in a more general board/website, but HN audience is mostly compound by developers, so technical aspects matter. On top of that, it also gives an idea about the popularity of a programming language.
Why is it featured so heavily, instead of just in the build instructions? I don't know. Marketing? It appears to be by developer(s), for developers, and in the dev space Rust is very vogue right now.
Why do you assume bragging rights are not relevant enough?
Languages get mindshare because people see others using them to make stuff. Bragging is essential for growing languages.
People interested in rust but not particularly pixel editors, like several in this thread more interested in the graphics stack/current state of rust gui/graphics than pixel editor itself.