[HN Gopher] Veloren is a multiplayer voxel RPG written in Rust
___________________________________________________________________
Veloren is a multiplayer voxel RPG written in Rust
Author : albertzeyer
Score : 752 points
Date : 2022-03-13 23:57 UTC (23 hours ago)
(HTM) web link (www.veloren.net)
(TXT) w3m dump (www.veloren.net)
| kretaceous wrote:
| This looks awesome and I installed it via Flatpak in my Linux
| Mint 20.3 to try it out. But the launcher keeps crashing without
| showing errors. All I see is a window frame with no content
| inside (it's transparent) and then it crashes.
|
| Any help? I really want to play it!
| TobTobXX wrote:
| (1) Run it from the terminal (flatpak run <appid>) to get debug
| output.
|
| (2) Try installing the Veloren Flatpak direclty, not the
| Airshipper launcher one. Maybe it helps...
| zesterer wrote:
| You can run Airshipper without the GUI from the console with
| `airshipper run`.
| gspr wrote:
| Impressive work!
|
| PS: It would be great with a repository link on the downloads
| page. I missed the sentence about the license on the front page,
| and incorrectly assumed the game to be closed-source when the
| download page only showed binaries.
| pca006132 wrote:
| Interestingly their launcher GitHub readme provides installation
| instruction for NixOS users but their website does not mention
| it.
|
| Launcher GitHub page: https://github.com/veloren/Airshipper
| [deleted]
| yhoneycomb wrote:
| daguava wrote:
| Hacker news is a wonderful place where we can share many
| different projects and a love for tech and software
| development. Shallow, subjective, emotional comments don't lend
| themselves towards driving discussion and growth in any form,
| please consider expanding more fully on how this is
| "amateurish" and how that detracts from the artform.
| yardshop wrote:
| This is beautiful!!
|
| I got myself up into the Giant Tree and spent three nights. The
| colors and effects are wonderful. I could zoom way out to the
| neighboring mountains and pan around to see the whole landscape,
| then back in to see the crazy creatures on top of the tree.
|
| I put on my glider and jumped out of the tree and realized I
| didn't know how to fly yet and splat!!
|
| Even though it's multiplayer and has quests and lots of
| activities, I had a great time just exploring around by myself.
| Thanks for a fun game!
| fire wrote:
| Oh this looks cool! I wish I could have registered my username,
| but it's already taken; ah well, wasn't fast enough
| teekert wrote:
| Look very nice! Somehow I thought since it is Rust and not Java,
| it should be more fps than Minecraft (many other things seemingly
| comparable), but it's not, probably wrong assumptions on my end.
| zesterer wrote:
| The bottleneck for a game like this is the GPU and not the CPU
| (usually). Additionally, Veloren has a tonne of things that
| Minecraft doesn't:
|
| - A much larger world (compare the number of blocks in
| Veloren's trees against those of Minecraft, or the fact that
| mountains in Veloren are regularly many thousands of blocks
| tall, compared to Minecraft's 256 block height limit)
|
| - PBR rendering
|
| - Shadow-mapping
|
| - Bloom
|
| - A level of detail system, along with horizon maps for dynamic
| terrain-scale shadows
|
| - More advanced voxel lighting that respects normals
|
| - Fully volumetric cloud, aurora, and atmospheric rendering
| with raycasting
|
| - More detailed character models and animations
|
| - A more detailed particle system
|
| - Dynamic point lights and related effects (point light
| diffusion, for example)
|
| - High-detail terrain objects like grass, corn, etc.
|
| As another poster said, there's not really much point in
| comparing the performance of the game to that of Minecraft.
| They have virtually nothing in common from a rendering
| perspective other than the fact that their polygon normals are
| mostly oriented toward the cardinal axes.
| adtac wrote:
| JITs can sometimes be faster than compiled binaries because
| they have runtime information, but realistically it's probably
| because Mojang has had years and years to optimise.
| kaba0 wrote:
| Also, they are two completely different games, there is
| absolutely no point in comparing them. A single game feature
| difference can render the comparison meaningless.
| AlanSE wrote:
| I played a bit into this game (maybe about 20 hours), and it's
| good. The size of the map dominates the game-play as you aim to
| explore all the types of destinations. It's a procedurally
| generated world, and some hilly towns will get a little weird.
| The glider is really a killer features, because the mountains are
| really really steep, you climb up to the top and the glide to
| cover a fairly large distance on the map.
|
| It was still hard to get into the social element of the game,
| because of so few players and such a large map. I think other
| players tended to be concentrated at the main spawn point, so a
| lot of the rest of the world was a backwater essentially.
|
| They also have a giant tree. It will cost you some hours, but
| it's quite different than anything else you'll find.
| NikolaNovak wrote:
| Gliding - like tribes?
|
| I miss that mechanic so much I'll try any game to get my kick
| thegeekpirate wrote:
| No, that's skiing ;)
|
| https://tribes.fandom.com/wiki/Skiing
| rco8786 wrote:
| Guessing more like Breath of the Wild. Jump off something
| really tall and open something akin to a canopy that lets you
| fly unpowered over long distances.
| kibwen wrote:
| Veloren's is much more physics-based than BotW, you can
| tilt and steer the glider to control your flight. Here's a
| good video that also shows off the extreme elevation of the
| world's mountains: https://youtu.be/w-kYWjrU6IE
| remram wrote:
| That looks fun! What happens afterwards? Do you have to
| spend many hours climbing back to the top of the
| mountain, or is there some sort of fast travel?
| Ntrails wrote:
| My disappointment upon turning sound on and not hearing
| "Sail" was palpable! Looks cool, although very much like
| the Minecraft gliding from memory
| NikolaNovak wrote:
| Ahhhh... I enjoy that too but many places to get that
| particular kick :)
| ceroxylon wrote:
| Have you tried Population One? It is surprisingly fun, the
| only downside is the hardware you need to play it comes from
| Zucky.
| keyle wrote:
| Shazbot!
| cevn wrote:
| I am the greatest!
| thoughtpalette wrote:
| Man I miss that game/community.
|
| edit: I was Vag/Dis, played PB Mod from 00-04' if anyone's
| still around. |!i!PbP|
| opan wrote:
| I would kill for a libre FPS-Z game.
| NikolaNovak wrote:
| Midair tried it but I don't think it was libre
| superkuh wrote:
| Correct. They never even allowed private servers or mods.
| This is also what killed Tribes: Ascend. The modern
| microtransactions model has made games like Starsiege:
| Tribes impossible to make by profit seeking corps.
| TulliusCicero wrote:
| > It was still hard to get into the social element of the game,
| because of so few players and such a large map. I think other
| players tended to be concentrated at the main spawn point, so a
| lot of the rest of the world was a backwater essentially.
|
| Ah, so it's an MMO then?
| maeln wrote:
| Yes and no. You have the choice, the game offer an offline
| mode, where you are alone with npc in your own little world,
| or a online mode where you can connect to any server of your
| choice. The server is open-source too, so you can run your
| own little Veloren world for you and your friend.
|
| Though, fair warning, the game, at least last time I played
| it, 2-3 months ago, was still very much balanced toward
| teaming up with at least one other person to beat most
| dungeons. You can beat them alone, at least the low level
| ones, but it becomes tedious since you respawn at the
| entrance of the dungeon, and they can be quite deep.
| chaostheory wrote:
| I played an older version. You can host your own games like
| Minecraft. Also runs on ancient, underpowered hardware
| relatively well
| nyanpasu64 wrote:
| I also played an older version on an underpowered GPU
| (either 2016 Intel laptop integrated graphics or GT 730). I
| had to reduce the window resolution considerably, and the
| frame rate was still poor. I might try again on a faster
| GPU.
| chaostheory wrote:
| Yeah, it probably won't work well on an old laptop with
| integrated graphics. I'm using using an ancient AMD
| Phenom 8 core with a Radeon 6900. I think both are close
| to a decade old now.
| Wowfunhappy wrote:
| How does it compare to Cube World Alpha?
| [deleted]
| moxvallix wrote:
| This game is quite a fun time, even if it is only a short time. I
| got a bunch of my mates together, and the four of us worked
| through the main progression. There was a great loop of venturing
| out to a dungeon or cave, taking on challenges greater than we
| could handle, managing to scrounge some expensive loot or rare
| gear, before returning to a village to trade with NPCs. At the
| time there was also a bug where a very common flower would sell
| for very high prices, allowing us to get a lot of gold. We could
| trade this for valuable health potions that help greatly in
| difficult dungeons.
|
| We got a couple of nights together out of the game. However,
| unfortunately the game is rather short, and after we had
| conquered a level 6 dungeon, and obtained the best gear, there
| was little left to do. Development is still ongoing, and it is
| exciting to read the devlogs every now and then to check on the
| progress however. And maybe once there is enough extra content
| we'll jump back in for another session.
|
| The world generation in the game is absolutely breathtaking.
| Might even go as far as saying it rivals that of the new
| Minecraft 1.18 World generation update, at least with the
| mountains. And I really love the music in the game, it fits
| really well with the whimsical aesthetic of the game, and I get
| it stuck in my head every now and again, even though I haven't
| heard it in months.
|
| The game had its fair share of jank as well, as is to be expected
| with a (pre-alpha?) early version of the game. The movement took
| a while to get used to, and it felt a bit floaty at times, and
| didn't always feel like I was fully in control. As well the
| camera was really close to the ground, which was a lot to get
| used to, as I am used to the taller perspective of Minecraft.
| However, the game does a great job of allowing the player to
| switch between first and third person, merely by scrolling the
| mouse wheel. (You can take the camera really far out too to get
| great cinematic screenshots, of which I have a collection)
|
| The combat felt a bit off at times as well, as the cooldown
| between attacks, and the speed of the attackers often matching
| that of the player felt like you couldn't escape once an enemy
| locked on. Luckily the middle button roll could usually get you
| out of attack range, but it felt like this could be improved (and
| I think it may have been improved since).
|
| At the time I was playing, the trading system was also really
| confusing, but I believe it has been changed since.
|
| All in all, it is well worth checking out the game. Make sure you
| play the nightly. Best enjoyed with a group of mates, but it is
| also fun just exploring by yourself. I can't wait to see what
| cool stuff is still to come with this game.
|
| Edit: added section about janky combat.
| CursedUrn wrote:
| I would expect the game to be short if you abuse a bug to get
| massive amounts of gold and skip through the progression way
| faster than you're meant to.
| [deleted]
| miggelindo wrote:
| That's pretty cool.
| Shared404 wrote:
| This is one of those projects I don't actively use, but keep an
| eye on and love to see progress in.
|
| Last time I played, it wasn't really there as a game yet, but I
| think it's about time to try again!
| zozbot234 wrote:
| AngelOnFira wrote:
| I definitely see where you're coming form, but we're quite
| confident that we couldn't have made this game without Rust!
|
| There are lots of benefits we get, but here are some of the
| quick highlights:
|
| 1. "Code that compiles probably works" means that we can work
| quite quickly as a diverse team from all around the world, and
| not spend so much time worrying if our code will break that of
| others.
|
| 2. Our goal is to eventually be able to get 1000 players on the
| same world, on the same server. So far, the max we've reached
| is 195 players at our last release party. Our multiplayer
| server doesn't just send the location of players, but actually
| runs a ton of realtime simulations of the world, including
| economy, trade between towns, physics, NPCs, all with more
| coming in the future. All this to say with all the work that
| has to be done, we get massive benefits from how easy it is to
| do multithreading/ECS paradigm work with Rust
|
| But either way, we always like to shill whatever we like best.
| Still very happy to be a flagship project to show off how cool
| Rust is!
| super_flanker wrote:
| What's wrong with it? Rust in one of the things I'm interested
| in, so it really helps when title contains "Rust". If you don't
| like it ignore it, nobody is forcing you to go through it.
| opan wrote:
| 3D free software game developed in modern times and not a fork
| of Quake 1 or 3 is what makes this a big deal to me. Rust is a
| neutral point to me, but it does probably make it harder to run
| on other architectures.
|
| The biggest negative to me about this project has always been
| the way they push Discord on you. I'll likely never be a part
| of the community even if I do play it because of that.
| toastal wrote:
| They mention GitLab, Discord, Matrix, Reddit, and their Wiki
| on their "join us". Seeing Matrix should be a good sign.
| tormeh wrote:
| There's a bridge to Matrix, so you don't need to use Discord.
| Although personally I regard Discord as a nicer experience.
| brink wrote:
| Have you tried Rust? It really is something special.
| zozbot234 wrote:
| Yes, but is it so special that us HNers need to be reminded
| about it every time someone rewrites some random software
| thingy in Rust? It gets so boring after a while.
| tormeh wrote:
| It's the reason I chose to contribute to the project, so
| yes.
| Quikinterp wrote:
| There's also people like myself who have a general interest
| in voxel related software. I've always been fond of the
| aesthetic but also all of the optimizations people use for
| voxel games and renderers
| zozbot234 wrote:
| Of course every project has its own genuine points of
| interest, I'm not denying that! But the commonality is
| clear enough.
| amelius wrote:
| It's almost like:
|
| Sent from my iPhone
|
| Except now it is:
|
| Written in Rust
| libraryatnight wrote:
| I've never felt like anyone was reminding me about
| anything, HN is a site frequented by programmers, it's
| useful to programmers to see what other programmers are
| building and with what tools. Rust is popular so we see it
| a lot but we also see X written in Go, or Y written in
| Python, and so on.
| skohan wrote:
| I don't think that's completely correct - I think
| "written in rust" being bandied about as a feature is a
| somewhat unique feature of the Rust community
| detaro wrote:
| Not really. It especially happens with currently
| "interesting" languages more than with others, but it's
| fairly standard to mention it in places like here. E.g. a
| few years ago you saw it most with Go or NodeJS, because
| at that time those were the "interesting" languages.
| npigrounet wrote:
| Rust guarantees insane performance and no bugs.
| Rendello wrote:
| If the Rust game dev aspect interests you, check out the Rust
| Game Dev podcast too. One of the co-hosts works on Veloren:
|
| https://rustgamedev.com/
| AngelOnFira wrote:
| I do! We actually have an episode coming out tomorrow! (today?
| edit: it's already out!)
|
| I'm really happy that I could get more integrated with the Rust
| Gamedev "Working Group", since I've been able to chat with so
| many cool people through the podcast, and host a monthly meetup
| to see what people have been working on. It's a great
| community!
|
| Another great Rust gamedev link if you want to see how the
| ecosystem is doing: https://arewegameyet.com
| orangetuba wrote:
| Holy cow, why hadn't I heard about this? Thank you!
| okasaki wrote:
| This looks really cool. Curious though that they picked GPL3, but
| not AGPL, given the product type.
| zesterer wrote:
| We're considering moving to AGPL.
| rklaehn wrote:
| This is great. My kids are very much into minecraft. I am very
| much into rust.
|
| I would love to help them make the step from playing games to
| hacking on games. This was very simple back when I was a kid, but
| is quite hard now. The games you can make are so much less
| impressive than the games they are used to.
| nirui wrote:
| See? This is why today's kids making me jealous. Back when I
| was just a ~10 years old, I couldn't even found a game that
| worth playing (through I'm picky) and also supports modding,
| let alone a full open-sourced game written in a programming
| language that I'm interested in.
|
| Imagine I started learning Rust at 10 years old...
| dncornholio wrote:
| A lot of young developers get into coding because of Minecraft
| and Java..
| skerit wrote:
| I was also very attracted to this game, but then I found out
| it's really an RPG and there is no (real) building of any kind.
| I don't really know anyone who wants to play a procedural
| generated blocky-RPG they can't modify the environment of :/
| DrSiemer wrote:
| That's why I thought, until I played Cube World.
|
| The procedural generation somehow instantly provides a sense
| of mystery, that makes you want to discover what this "fresh"
| world has to offer. Like Minecraft, the unexplored feeling
| adds a sense of adventure, that is hard to mimic in a
| handcrafted map.
|
| When you climb over a hill and are greeted with an amazing
| view, you feel like you are experiencing something unique,
| instead of the exact same curated sensation all the other
| players of the game will be having.
|
| The fact that you cannot destroy every block in it does make
| the game feel more solid. The freedom you have in a game like
| Minecraft also limits certain gameplay aspects: you can
| always dig a hole and hide.
|
| Personally I don't mind the lack of building options at all.
| It's fun, but it can get a bit grindy when you are trying to
| create something big in survival mode.
|
| It was such a shame Cube World never got anywhere, I'm glad
| this is here to pick up where that left off!
| geek_at wrote:
| I had the same thought. I thought the main point of a voxel
| engine is to be able to modify the terrain. If not then it's
| just a fixed scenery
| gefhfffh wrote:
| It's not completely fixed, e.g. you can dismantle trees
| with fireballs, dig for minerals in caves or work on rocks
| aasasd wrote:
| Real shame that the 'voxel' word got hijacked for cubes, which
| are obviously polygonal.
|
| In 'Vangers', the map is made and rendered with real voxels. Now
| that's some shit: https://www.youtube.com/watch?v=P9R7QJ5Sh1o
|
| Simply having blocky cubes as units is just not the same, at all.
| Quikinterp wrote:
| It didn't get hijacked. Cubic voxels are still voxels. There
| are lots of non cubic voxels games that come out still.
| remram wrote:
| Here's from Vangers' website https://web.archive.org/web/201001
| 14235648/http://www.kdlab....:
|
| > All the worlds in Vangers were created with Surmap A.R.T.,
| K-D Lab's proprietary terrain editor, and the accompanying
| _voxel-polygonal technology_.
|
| How do you figure you can render a voxel without any sort of
| polygon?
| zesterer wrote:
| If you take 'voxel' to mean '3D pixel', then how does Veloren
| not fall into that category? What does "real voxels" mean? If
| you're talking about rendering things as point-clouds or using
| raycasting, then you're not describing voxels. You're just
| describing one of many possible techniques for rendering
| voxels. Isosurface extraction into a polygon mesh is also in
| that set and is no less valid than the definition you're going
| for.
| bodge5000 wrote:
| From what I understand, theres 2 different definitions of what
| a voxel is.
|
| The first, as is the case with this, is moreso on the data
| structure side of things, in which a voxel is like a point in a
| point cloud, but the point cloud is fixed to a 3d grid. The
| meshes can be anything, but cubes are the most common, and they
| are almost always polygonal.
|
| The second is, as you describe, a fundamentally different
| rendering method using "3d pixels" instead of polygons. These
| kinds of voxels almost always use the same data structure above
| as well, but as you say they aren't polygons.
|
| Strange we ended up with the same word for both, unless I'm
| mistaken
| aasasd wrote:
| Voxels as in '3d pixels' have been around since the 90s at
| the least, as evidenced by Vangers. Later, some people took
| the word and used it to describe Minecraft, in the meaning
| 'big blobs that aren't even the smallest atomic unit, as
| there are clearly items that are made with smaller shapes'.
| orangetuba wrote:
| How do you build a game engine from scratch these days? I mean,
| what is the underlying somewhat low-level graphics library? Is it
| wgpu or OpenGL?
| skohan wrote:
| There's a whole community of people doing game engines from
| scratch. My guess is they're using Vulkan or OpenGL.
| Jweb_Guru wrote:
| The project is using wgpu-rs (and has actually contributed
| quite a bit to it). Can highly recommend it for other projects,
| it really is the way to go if you want to be portable but don't
| want to sacrifice a ton of performance (as using OpenGL does
| nowadays). Using wgpu generally means you're getting a fast
| subset of most of the modern APIs, at the cost of some control
| and performance in certain cases (though not too much
| performance--we'd like to shrink that even further), so for us
| it's the way to go.
|
| The other two choices people usually bring up are OpenGL and
| Vulkan. The project was originally using OpenGL and was quite
| limited as a result; theoretically, you can do better by
| abandoning portable versions of OpenGL, but many modern OpenGL
| drivers are incredibly poor (particularly on Windows), and a
| lot of machines support, e.g., DirectX 11 or Metal but not a
| version of OpenGL with the same feature set. Going with
| straight Vulkan means you're either going through a (slow)
| translation layer on many older machines (and Macs), or giving
| up on them entirely. Vulkan is also _incredibly_ hard to use
| correctly if you 're using it directly and want to be portable
| across GPUs; the spec has a lot of edge cases that are quite
| unclear even to experts, and often requires consulting with
| driver developers to figure out exactly how they were
| interpreted (to be fair, this has become less of a problem over
| time, but it's still an issue for corner cases in the spec).
| Narishma wrote:
| > Using wgpu generally means you're getting a fast subset of
| most of the modern APIs, at the cost of some control and
| performance in certain cases (though not too much performance
| --we'd like to shrink that even further), so for us it's the
| way to go.
|
| Another cost is that you lose support for older GPUs.
| Jweb_Guru wrote:
| This is an overstated problem, in our experience. Most
| older GPUs that don't support Vulkan, DirectX 12, or Metal,
| but would be capable of running the game in the first
| place, support DirectX 11, which is one of the wgpu
| backends already. An OpenGL fallback on Linux is coming and
| will help address the remaining cases, but it won't perform
| well at all (and we're okay with that, since the percentage
| of our users who actually need it is quite small; Vulkan
| support on Linux has gotten really good, probably thanks to
| Valve's efforts).
| pyrrhotech wrote:
| How do you implement all the things the game engine gives you
| for free? Physics, camera, scene management, lighting,
| colliders, shaders, navmesh, etc. It seems like an impossible
| feat to implement all this yourself PLUS build a game on top.
| Wouldn't just building the game itself be a 2000-20,000 hour
| project? And I imagine building the game engine would be an
| order of magnitude more complex, if not more time
| Jweb_Guru wrote:
| It's a lot of work, but there are a lot of tutorials and
| readymade libraries out there to get you started (which you
| may end up ripping out if the project grows sufficiently
| that it's worth doing custom stuff, but most projects never
| get to that point). It's definitely nowhere near as
| difficult as it seems like it would be to get a basic game
| up and running (though it's still very hard)--you're not
| going to come close to competing with something like UE5,
| but if you're doing a game from scratch that probably isn't
| your goal in the first place.
|
| For FOSS in particular, it helps that people are willing to
| devote _massive_ amounts of free time to programming when
| the outcome is a video game--it 's why a lot of people got
| into computer science in the first place, after all.
| hnlmorg wrote:
| Cube world was released?!? How did I miss that. Anyone played it?
| Is it any good?
| DrSiemer wrote:
| > Anyone played it? Is it any good?
|
| Yes and nope. Some fun and promising features were removed and
| whenever you switched zones all your levels would reset, except
| for some minor stats, breaking any sense of progress and
| nerfing the need to explore.
| Duralias wrote:
| Depends on who you ask, but it is kinda worse than the alpha,
| far lesser scope.
|
| Gameplay loop is defined though and it is definitely more
| finished than the alpha, but there are some very annoying game
| design choices and it is very repetitive, but people are trying
| to fix those things with mods, not sure how well since I
| haven't touched it since launch.
| thih9 wrote:
| For others missing context:
|
| > An alpha version of [Cube World] was released in July 2013,
| but saw sparse updates and communication from von Funck, with
| many considering the game to be vaporware until he officially
| released it on September 30, 2019.
|
| source: https://en.m.wikipedia.org/wiki/Cube_World
| elcritch wrote:
| Can this run in VR? It'd be fun to have a truly open VR sandbox
| world. I don't see anything at first glance though.
| chimprich wrote:
| This would be very interesting. There doesn't seem to be a lot
| of GPL'd VR stuff out there, and I would think this would work
| very well in VR.
| Yaina wrote:
| I'm still traumatized from Cube World..
|
| (But it looks cool, definitely gonna browse through the source
| code a little)
| Tepix wrote:
| Looks like CubeWorld. Has anyone tried to compile it into WASM
| and run it in a browser?
| daguava wrote:
| I feel like some of the "inspired by cubeworld" stuff is a little
| too heavily inspired, but I really enjoyed taking a quick look at
| the source and logging in to check things out.
|
| Things seemed pretty clean, and because everything has source
| posted I was able to mess around with the apis, and try a few
| things against your services :) (hope I didn't set off any alarms
| lol). That said, what I'm assuming is Sha256 could always be a
| bit tighter, consider a strength upgrade on those credentials.
|
| There's a bit of snobbery going on here for go / voxel hate, but
| I really enjoyed digging into a completely open source setup for
| something that is already a nice intro of game, services, and
| execution, well done :)
| Jweb_Guru wrote:
| Credentials use argon2.
| daguava wrote:
| Thanks for the info, I saw the length matched the usual
| sha256 so assumed it ended there.
|
| I'm from a bcrypt crowd which is why I offered the suggestion
| but as long as you're taking things seriously I'm all for it
| :)
| AngelOnFira wrote:
| Let us know if you find any holes!
|
| We currently have an MR where we're overhauling some of the
| auth, and I know in the future we do want to explore what else
| we could add/improve for our backends :)
| daguava wrote:
| The only hole I found was if you bypass UI hashing you can
| create an account that can never be logged in to, but...
| that's the most secure account I can think of.
| Shadonototra wrote:
| This game is the worst to compile, makes me glad i haven't picked
| that language
|
| I can't imagine myself being stuck for 10 minutes to see a change
| happen on screen
|
| Just take a look at a Veloren dev changing a line, then compiling
| it: https://www.youtube.com/watch?v=nR2WDBMjkh8&t=976s
|
| Rust is not made for game dev, this project is the proof, your
| progress will stall at some point because you won't be able to
| iterate on your game anymore!
|
| That's the curse of Rust
|
| Where are the gamedev that announced using Rust from now on 5
| years ago? they still stuck compiling their projects!
|
| What a disaster:
| https://github.com/veloren/veloren/blob/master/Cargo.lock
|
| 7.5k LOC just for dependencies..
| p0nce wrote:
| Isn't Rust supposed to have incremental compilation?
| coryrc wrote:
| I think you have some good content in this post, but I find the
| attitude unnecessarily hostile.
| zesterer wrote:
| (there is no good content in this post, they just want to
| arbitrarily hate. They make extremely basic errors throughout
| and clear haven't ever used Rust, at least for anything non-
| trivial)
| coryrc wrote:
| It inspired a wonderful rebuttal from the dev, which I
| learned more about tradeoffs of speed versus complexity.
| zesterer wrote:
| There are several of us. I'm also one of the devs.
| Jweb_Guru wrote:
| Veloren's compile time _is_ bad, but this is hyperbolic
| nonsense. To address your points in order:
|
| * Compilation is a ton faster on an M1 and with a non-default
| linker. Compilation from scratch (including all dependencies)
| took around 10 minutes for me last time I tried; compilation of
| the main game is much faster (I think in the ~ 1 minute range,
| which is more than acceptable if you're not doing something
| sensitive like animation work.). Obviously, not everyone has an
| M1, but it's hardly a dealbreaker if you've got a machine
| designed for development.
|
| * The developer in your video is changing a line in veloren-
| common, a "root" crate that leads to a bunch of other stuff
| recompiling. The vast majority of changes are in leaf crates,
| which compile much faster. For animations, in particular (which
| require quick feedback) we have a separate compilation unit
| that compiles on the order of seconds and can be configured to
| be dynamically linked to the main game, so they can get pretty
| much instant feedback. For as many kinds of assets and data as
| possible, we also push it out to configuration files with hot
| reloading, so most people working on models, item and color
| tweaks, etc. don't have to wait for compilation at all and can
| just save their files.
|
| * Many games written in C++ also take ages to compile. Rust
| isn't unique in that regard. Clearly, it hasn't stopped
| Veloren's development (I can't think of anyone who quit
| development because of the compile times, though there's a lot
| of grumbling). In fact, I'd venture to say that Veloren has had
| some of the most developers and fastest development of any 3D
| open source game I'm aware of, regardless of language.
|
| * No major developer I'm aware of announced using Rust for
| games 5 years ago. What are you talking about? If you mean the
| Chucklefish title, that had nothing to do with compile times.
| As far as I know, the game companies using Rust right now are
| mostly using it for tooling.
|
| * The file you linked is the equivalent of yarn.lock,
| Cargo.toml is the actual dependency file. Dependencies do not
| need to be recompiled each time you compile Veloren, only the
| first time. Additionally, most dependencies compile pretty
| quickly and parallelize well. There are a handful of
| dependencies (the procedural macro ones in particular) that
| take a huge percentage of the overall compile time and/or act
| as bottlenecks, which is tolerated because they are extremely
| useful.
|
| Veloren could optimize more aggressively for compile time, if
| the project was so inclined. A lot of that compile time is
| spent on generated code from macros like serde. Veloren also
| deliberately tends to use very large crates rather than trying
| to split everything into very small compilation units (some of
| them have been split up to improve compile times, but not too
| much). The project's perspective is that benefits of using
| those libraries (which _greatly_ simplify development) and
| having fewer crates (which makes it much easier to avoid
| exposing internal APIs to get anything done) far outweigh the
| compile time costs, but not every project takes that approach
| and there are a lot of games that compile much faster than
| Veloren. It 's really not a fundamental limitation of the
| language.
| fredoliveira wrote:
| > Veloren's compile time is bad, but this is hyperbolic
| nonsense.
|
| Eh, I just tried it because I was curious about M1-ready
| builds, and: Finished dev [optimized]
| target(s) in 5m 08s veloren on master via
| v1.59.0-nightly took 5m18s
|
| 5 minutes doesn't sound bad to me. Mostly because I remember
| how long it took me to compile Gnome back in the day :')
| zesterer wrote:
| Also try recompiling it after a trivial change. You'll find
| that it'll take less than a minute, perhaps even seconds.
| Jweb_Guru wrote:
| Like I said, it's not bad at all on an M1 (or other
| machines aimed at professional developers). A lot of the
| project's contributors are hobbyists or using less
| overpowered hardware, though, which is why the project has
| taken steps to try to make it better for the common cases
| (CI machines can also be an issue). But there's a huge
| difference between acknowledging it's a problem, and trying
| to somehow claim that it rules out Rust for game
| development (Veloren is an existence proof that this is not
| the case!).
| pjmlp wrote:
| > Many games written in C++ also take ages to compile.
|
| Only if they didn't took the effort to use binary libraries
| for third party dependencies, or using hot code reloading
| tools like Live++ or Visual Studio's hot reload for native
| code.
|
| Granted, nothing prevents Rust to have similar options, but
| they don't seem to be a high priority currently.
| Jweb_Guru wrote:
| I mean... if you change the size of a type used by value in
| a bunch of other places downstream (the equivalent of the
| change in the video), none of what you're describing is
| going to help much with compile time, since it's not ABI
| compatible. For less invasive changes rustc already does a
| decent (not amazing) job of avoiding recompiling unchanged
| dependents. As far as initial compile time goes,
| precompiled binaries would definitely help (on non-
| overpowered hardware particularly), but initial compile
| time is not really a development bottleneck since people do
| not recompile from scratch all that often. I do think
| people dramatically underestimate how long they would spend
| waiting for the equivalent C++ libraries to compile when
| comparing from-scratch compilation times to Rust projects,
| though, but that's neither here nor there.
| pjmlp wrote:
| Mostly because compiling from scratch in C++ is seldom a
| thing outside FOSS environments, all frameworks in
| gamedev SDKs are binaries already.
|
| By the way, Rust incremental compilation is broken again,
| yes I know of the workarounds.
| Jweb_Guru wrote:
| Regardless of what gamedev SDKs with billions of dollars
| behind them do or do not do, initial compile time is
| simply not a major bottleneck for developer productivity
| for Veloren. What _is_ a bottleneck is how long it takes
| from making a change to seeing it in-game _after_ the
| initial compile. On that front, C++ and Rust are on
| pretty similar footing (at least when incremental
| compilation is working :P) and it mostly comes down to
| how much the project is prioritizing compile times.
| pjmlp wrote:
| No they are not, given that Visual Studio and Unreal both
| have C++ hot reload since ages, and there are other third
| party solutions like Live++.
| Jweb_Guru wrote:
| C++ hot reload does not improve compile times beyond what
| you can do yourself via dynamic linking (and can't help
| at all within compilation units, or avoid recompiling
| dependencies when ABI-level stuff breaks--choosing to
| have relatively small and large numbers of compilation
| units, or discourage ABI-breaking changes, is absolutely
| a project-level choice). For stuff that's time sensitive
| to compile, Veloren already uses dynamic linking with
| automatic hot reloading with the correct configuration
| options. I agree it's not as convenient as having tooling
| to do it for you, but, again, there is a lot more money
| in that stuff than there is in Rust game development
| right now.
| zesterer wrote:
| When you say 'broken', what you mean is '1 out of every
| 50 compiles will need a clean of the incremental compiler
| artifacts, which adds maybe 30 seconds to the subsequent
| compile but doesn't mean recompiling dependencies'. To
| call it 'broken' is quite misleading, it's just a minor
| annoyance that will be gone in the next release cycle.
| pjmlp wrote:
| > This mitigates the effects of a known bug, #94124,
| which can cause deserialization errors (and panics)
| during compilation with incremental compilation turned
| on.
|
| It looks broken to me.
| xialvjun wrote:
| Does it have a VR mode? It will definitely be awesome.
| eternityforest wrote:
| Looks like the graphics are a bit nicer than Minecraft/test
| TeeWEE wrote:
| Cool! Tip: The airshipper macos file is not executable, i had to
| chmod it to make it run.
| noisy_boy wrote:
| The airshipper file dumped core on Pop!_OS 21.10
| TeeWEE wrote:
| Tip: The loading screen for singleplayer was not very clear, i
| thought the game was hanging.
| brunt wrote:
| A previous HN post with some comments from core developers:
| https://news.ycombinator.com/item?id=26037461
| noja wrote:
| The "Tutorial" button is not working for me.
| deutschew wrote:
| getting fatigued by minecraft look & feel, what is the next
| evolution to block vixels?
| skocznymroczny wrote:
| voxels processed through marching cubes algorithm -
| https://developer.nvidia.com/gpugems/gpugems3/part-i-geometr...
| GartzenDeHaes wrote:
| Dual Contouring? https://www.boristhebrave.com/2018/04/15/dual-
| contouring-tut...
| vgb2k18 wrote:
| Destructible environments. Ala, Teardown.
| https://forum.unity.com/threads/want-to-recreate-teardown-de...
| The discrete voxels can be smaller than in Minecraft, and
| behave like physical box shaped objects when dislodged.
| engineer_22 wrote:
| Is this game kid friendly?
| qchris wrote:
| I'm a little curious, is there a technical reason why voxel games
| are easier to build than non-voxel ones? The docs mention that
| all of the assets are community-contributed. Does making them
| voxel-based just drastically lower the skill theshold to make a
| contribution, vs. smoother ones in something like Blender? I
| guess I'm a little curious about the relative amounts of effort
| that would have been required to make this kind of game
| (procedurally-generated open world, I believe) using non-voxel
| assets and mechanics, since the existing set seems to be pretty
| fully-featured.
| ramses0 wrote:
| There's a benefit to direct manipulation of pixels/voxels
| within the game.
|
| Imagine, if you would: build a 64x64 "flat" foundation of
| stone. Clicky-clicky-pokey-pokey to place/remove colored
| blocks. Post something somewhere to someone: "Hey, I have some
| fresh voxels for someone to do something with!" => scrape-
| world.php => asset.vxl => etc...
|
| Basically, games with a built-in level-editor tend to be easier
| to contribute to. Minimally: the potential "editors" are
| already familiar with 90% of controls, viewpoints, and can see
| the asset "in-game" already (and they're probably already "in
| the game / editor" already, no context-switching to blender or
| autocad or something).
|
| I'm 1000% sure that if minecraft added some sort of symmetry +
| polygon + joint/bone/connection-point tooling, you'd see an
| explosion of polygon assets available within the community.
|
| The technical reason that voxel games are "easier to build" is
| that you can easily make a 1000x1000x1000 array of
| integers/chars, and get a 50-"voxel" radius from somewhere and
| start rendering it with raycasting. Can you render a square?
| Can you render 100 squares? Boom => voxel engine. Can you
| get/set a 3d-pixel (voxel)? Can you click "destroy/create" on a
| raycast target? Boom => voxel editor.
| aufhebung wrote:
| If I put a 5 year old in front of a polygon based 3D modelling
| program they will have no idea what to do, and even if I teach
| them the tools they will have trouble. If I put a 5 year old in
| front of Minecraft they will eventually figure out how to build
| stuff. I hope this answers your question.
| Computeiful wrote:
| I've always imagined that voxels are the pixel art of the 3D
| world. Much easier to create from both an aesthetic and
| development point of view. Hard discrete edges that fall along
| the XYZ planes are much easier to program for (think collision
| detection etc).
| aliswe wrote:
| Note that its generally much more difficult to develop a voxel
| based game than a polygon one.
| jayd16 wrote:
| Its easier to generate destructible worlds using voxels than
| chunking meshes in some other way. It brings on some other
| challenges and benefits as well.
| colordrops wrote:
| Guessing here, but perhaps the computational complexity for
| rendering voxel assets is much more bounded, e.g. you can't
| make something with a super dense vertex count and complex
| shaders and other transforms and bog the game engine down.
| zesterer wrote:
| Actually, completely the opposite is true. There's a reason
| that voxel games appeared _after_ games with more traditional
| meshes.
|
| The fundamental complexity of voxel data structures is
| higher: O(n^3) for iteration, and the density of polygons
| required after meshing is generally much higher. The only
| real benefit from a complexity standpoint is that storage and
| access of specific voxels is much faster, but this often
| doesn't represent a payoff.
|
| Voxels are great for a lot of things, but making a game like
| Veloren run quickly is much harder than you might initially
| realise. There's a reason that we're told at least every 3
| years that a new company has come up with the 'engine of the
| future' using voxel tech only to have it vanish into
| obscurity as they try to turn it into something that's not a
| tech demo.
|
| For Veloren, there is a big benefit: we get to create
| enormous procedural worlds. But actually controlling the
| complexity of that data and efficiently storing/accessing it
| is a non-trivial change as you'll see from the project's dev
| blog.
| jayd16 wrote:
| >and the density of polygons required after meshing is
| generally much higher.
|
| That seems a bit misleading. With uniform voxels the
| occlusion culling becomes much easier and you only render
| surface polygons.
|
| On the other side you don't get hand made imposters so
| rendering far away mountains and such becomes a challenge.
| You dont want to render every voxel of a distant object if
| a voxel is smaller than a pixel.
| wmil wrote:
| It's easier to be consistent when everyone is on voxels. If you
| give all of the artists full freedom then it's a lot of work to
| make things match in one game.
|
| On a non-voxel game it'd be very obvious that there were a
| bunch of different artists involved who were working somewhat
| independently.
| BatFastard wrote:
| As someone who has lead polygon games and voxel games, let me
| say if you are looking for community contributions, voxels are
| way to go. Decent looking poly assets need professionals, and
| professionals are expensive.
| whatshisface wrote:
| Roblox, a non-voxel sandbox game, was written before Minecraft,
| so one answer would be that it's easier to use meshes.
| AngelOnFira wrote:
| Great question! Core developer here, and I haven't thought
| about this too much.
|
| I think one benefit this gives us is on the artist contribution
| side. Being an art contributor on the project has a lot less
| overhead of being a formal "artist", since you can quite easily
| make fauna or creatures or just concept art. We've seen lots of
| this in our blog posts!
|
| But also, in terms of terrain itself, I think it allows us to
| really crank up how wild and wacky our procedural generation
| is, and still have a great looking world (unlike something
| higher-fidelity like No Man's Sky). We do a lot of cool things
| under the hood; we have a full erosion system that creates the
| mountains out of the sea, a site system that places villages in
| places that make sense, and the ability to mash together shapes
| that then get "rasterized" into voxel houses. I don't know how
| much of this would be possible and still look alright if we
| weren't taking a voxel approach.
| abledon wrote:
| bringing the idea further... is it possible to move the game
| towards something like "noita" where each pixel in noita can
| interact in a ton of ways etc... except here it would be a
| voxel?
| iamwil wrote:
| I think you're looking for a game like Teardown. Check it
| out: https://store.steampowered.com/app/1167630/Teardown/
| AngelOnFira wrote:
| I don't think so with the current engine, however, we do
| have a pretty solid particle system that does allow for
| some cool visuals similar to Notia. But that said, I'm not
| sure what "Notia inspired" physics would look like in a 3d
| game... I guess a lot of blocks melting? Could be cool to
| experiment with :) I know there are voxel engines that are
| far more geared towareds this than we are, we try to store
| information about each voxel as compactly as possible for
| efficiency, and we use LoD at the macro level (mountains
| off in the distance) rather than the micro level (zoom in
| really close on a single vosel, more geometry becomes
| visible).
| aweinstock wrote:
| I do think adding a Noita-style cellular automaton would
| be fairly straightforward.
|
| Currently Veloren has water and lava, but neither will
| flow (e.g. if water blocks are manually placed on top of
| a hill, they won't flow downhill, fortunately this is
| rare due to worldgen). A simple way to fix this would be
| to have an ECS system that uses CA-style rules (e.g. a
| water block with an adjacent-and-below air block swaps
| places with that air block), though naively doing this
| would be expensive (iterating over all loaded terrain
| chunks every tick). A possible optimization would be to
| detect such blocks, remove them from the main terrain
| grid, put them in a separate entity-with-terrain-collider
| (the same kind we use for airships), and only iterate the
| (sparsely populated) AABB of fluids-that-have-recently-
| moved. This is similar to what Noita does with keeping
| track of recently-updated terrain rectangles. Once this
| is in place, it can be straightforwardly extended with
| more fluid interactions (e.g. Minecraft-style water +
| lava = obsidian, more Noita-inspired gases rising).
| qchris wrote:
| This is really interesting, thanks so much for the reply!
| It's awesome to get a little bit more insight into projects
| like this, especially because I've got a limited (but
| growing) insight into both playing games and building
| projects with game engines.
|
| Just to parrot back what (it sounds like) you're saying:
| using voxel-based assets in a game with community-contributed
| assets that extends itself using procedural generation is
| that the difficult of integration tends to be lower. This is
| because voxel shapes allow "artists" (which don't necessarily
| have to be highly-skilled) to build game-appropriate assets
| fairly easily, and for the generative process to more easily
| combine those elements into a cohesive world model than might
| be possible with polygon-based assets. Does that sound about
| right?
| AngelOnFira wrote:
| Ya, it's certainly a art style that gets complimented by
| both the artists, and the developers that work on worldgen.
| There's a lot of grey edges as well; at our last release
| party we had an artist create an entire pre-made city, and
| load that in for players to explore at our release party.
| None of the city was proc-gen, but it was really great to
| see how the architecture was put together when it was
| crafted by a human, compared to how our different proc-gen
| cities/forts/encampments look a lot more like they're part
| of the landscape.
|
| So basically + Cohesive world + Ease for artists + Doesn't
| need to look so real
| sjmm1989 wrote:
| > So basically + Cohesive world + Ease for artists +
| Doesn't need to look so real
|
| I think this is the basic principle as to why Nintendo
| was able to get away with underpowered consoles for as
| long as they did. At least in comparison against other
| beefier consoles out during each releases duration.
|
| So long as the aesthetics and quality are consistent,
| people are willing to accept a lot.
| happimess wrote:
| See also The Witness, which is gorgeous and probably
| could have run on a dreamcast.
| jackling wrote:
| Great game! Is there any resources where someone can learn
| more about procedural generation? Curious to know what places
| one can learn about "full erosion systems".
| AngelOnFira wrote:
| We don't have a great way to find the blog posts that do
| talk about these topics outside of searching, but here are
| some references:
|
| Erosion - https://veloren.net/devblog-43/ Erosion + rivers
| - https://veloren.net/devblog-36/ Towns -
| https://veloren.net/devblog-31/
|
| There are lots of other blog posts that discuss these
| topics, I should really aggregate some of these sections in
| the future. Those links go into the most detail I think,
| future stuff is more about tweaks than the core systems
| (we've been putting out a blog post each week for 160+
| weeks now!)
| UltraViolence wrote:
| I downloaded this game to see how well a game written in Rust
| performs.
|
| I very much appreciate the stability and performance Rust brings.
| I believe software written in Rust is much more long-lived that
| similar C/C++ software since memory issues are almost certain to
| occur with the latter.
|
| Not to mention the security benefits Rust brings to the table.
|
| I don't really care for the game itself. I'm much more a BZFlag
| player anyway.
| fbrchps wrote:
| > inspired by games such as Cube World
|
| Well I'm glad to see this so early on, considering it looks like
| a Cube World knock off.
|
| Although to be fair, I would imagine this game was first thought
| of as people's expectations for CW fell flat upon the initial
| (and only?) release
| chinchilla2020 wrote:
| Inspired by Cube World?
|
| Are we not going to mention the 900lb gorilla, Minecraft?
| ehsankia wrote:
| Other than the Voxel graphics, games like Cubeword and this
| have little in common with Minecraft. Minecraft from the
| start focused more on mining and building than movement and
| combat. Of course there's mod, and they later added
| enchantments, but Cube World focused a lot more on the RPG
| aspect, with classes, fluid movement, magic and extensive
| weaponry, etc. It's very different from the 1 block jump
| distance and sword+arrow of minecraft. The game play is also
| a lot more focused on dungeons, bosses etc. Minecraft
| shoehorned a dragon battle and "ending", but it's far from
| being a combat focused rpg.
| Macha wrote:
| Its literally three words after the excerpted section, but I
| agree that Cube World is a more direct inspiration. Certainly
| Minecraft popularised combining voxel games with open worlds,
| but I think gameplay wise Cube World definitely belongs first
| on the list. After all, Minecraft didn't introduce the
| concept of voxel terrain though, infiniminer and worms 3d
| being earlier examples of games using it
| nonbirithm wrote:
| Having been a part of that era, I can attest that to a
| certain tribe of young and aspiring programmers, attempting
| to implement clones of Minecraft and talking endlessly
| about "procedural generation" and "voxels" and "chunks" was
| all the rage back in 2012.
| zesterer wrote:
| I was one of them, as my YouTube channel can attest. The
| desire to create procedural worlds never left though.
| libraryatnight wrote:
| https://cubeworld.com/
|
| That's Cube World. This game looks a lot like Cube World. And
| not just in the way that Cube World looked like Minecraft in
| that it was blocks and procedural (which is mostly where Cube
| World and Minecraft intersected, cw has no block building in
| the game).
|
| Looking at this game and knowing a little of the saga of Cube
| World I'd bet Veloren is an Open Source response to Cube
| World making an appearance, exciting a lot of people with
| potential, going silent for years, then eventually releasing
| something less fun than the initial preview and dropping into
| obscurity. It looks at a glance like this began development
| during the aforementioned silent period.
| daguava wrote:
| You're looking at the wrong monke.
| AngelOnFira wrote:
| Of all of our inspirations, Cube World is certainly what
| brought us together to start the project. We originated from a
| Reddit post on the Cube World subreddit that asked "why not
| just make an open source game out of what we liked?"
|
| Of course, since that was in mid 2018, many of the devs that
| have joined the project haven't played Cube World, and are
| inspired by other games or mechanics they enjoy. We list our
| inspirations as Cube World, BotW, and Dwarf Fortress as our
| primary ones. As is mentioned in other comments here, Minecraft
| is also part of this lineage, however, we aren't going down the
| path of buildable blocks very much.
|
| Since the early days of Veloren, we've defintely worked to
| break away from "just a clone", into gameplay that is more
| derivative of what we can achive with our engine, but there is
| still a lot of work to go before we consider it "released" :)
| andyfleming wrote:
| Source is here if anyone is curious:
| https://github.com/veloren/veloren
| AngelOnFira wrote:
| That's actually a mirror, our main repo is on Gitlab :)
| https://gitlab.com/veloren/veloren/
| TheKnack wrote:
| Is the user supposed to have to use chmod to make the
| launcher executable on Mac? The docs don't mention anything
| about it so I'm not sure how non-devs will figure out how to
| run it.
|
| Are there plans for an M1 version? I checked Gitlab issues
| and didn't see anything.
| fredoliveira wrote:
| I was curious too, so I decided to build it. The build
| process took exactly 5min8sec on a M1 Pro, and was pretty
| flawless. Only gotcha was that I had to install rust
| v1.59.0-nightly using rustup because of one of the
| dependencies.
|
| If you want to do the same: brew install
| cmake git-lfs git lfs install git clone
| https://gitlab.com/veloren/veloren.git cd veloren
| cargo run
|
| Based on this, I see no reason for a downloadable M1-ready
| version of Veloren to be made available. Compilation is
| trivial and fast, so might as well.
| Jweb_Guru wrote:
| It already runs on M1. The chmod thing is an issue with the
| CI that should get fixed soon, hopefully.
| TheKnack wrote:
| It runs on M1 under Rosetta emulation. Performance and
| stability would be better with an M1 native version.
|
| It looks like the chmod issue has been around a long
| time. I found Reddit posts going back a year or two. If
| it's not going to be fixed, why not put a note on the
| downloads page so people can actually run the game?
| Jweb_Guru wrote:
| Veloren uses some native libraries, so IIRC getting it to
| work under Rosetta was not completely painless either.
| That said, the reason native M1 builds aren't currently
| offered is that Apple makes it a pain to compile from
| other architectures, not that Veloren doesn't compile for
| M1 (it does). I believe native M1 builds are actually in
| progress right now. So is the chmod issue, which AFAIK we
| only figured out the root cause of relatively recently
| (September?).
| DeathArrow wrote:
| I wonder what graphical libraries are they using. DirectX,
| Vulkan, OpenGL, Metal? A wrapper over some of these?
| Galanwe wrote:
| From their github/cargo.toml it seems to be using "wgpu"
| (https://sotrh.github.io/learn-wgpu/#what-is-wgpu) which at
| first glance seems to be an abstraction layer that can fallback
| to OpenGL/DirectX/etc depend on ng on the platform.
| skocznymroczny wrote:
| wgpu is based around the WebGPU standard, which is expected
| to replace WebGL in web browsers for 3D graphics. wgpu (and
| WebGPU) is closer to DX12/Vulkan/Metal than OpenGL/DX11.
| Although it's much easier to use than Vulkan/DX12,
| abstracting away things like synchronization, memory
| management. I use wgpu in my D application through wgpu-
| native (offers a C header to interface with languages other
| than Rust) and it's been a great experience overall.
| guest1239571 wrote:
___________________________________________________________________
(page generated 2022-03-14 23:02 UTC)