{"author_link":"\/users\/ronin748","author_name":"ronin748","author_uid":"ronin748","comments":[],"epoch":1556755780,"event":"LD44","format":"md","ldjam_node_id":155845,"likes":4,"metadata":{"p_key":"131890","p_author":"ronin748","p_authorkey":"1006193","p_urlkey":"348084","p_title":"Doing Ludum Dare with Vulkan","p_cat":"LDJam ","p_event":"LD44","p_time":"1556755780","p_likes":"4","p_comments":"0","p_status":"WAYBACK","us_key":"1006193","us_name":"ronin748","us_username":"ronin748","event_start":"1556236800","event_key":"75","event_name":"LD 44"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD44","removed_author":false},"_superparent":139254,"_trust":2,"author":6193,"body":"As usual, I decided to learn something new for Ludum Dare. Last time I learned Go, really liked it and wanted to use it a second time. Learning Vulkan had been on my bucket list for a while, so this was the perfect opportunity to do it. Why use Go + Vulkan? Go is garbage collected after all. Well, what could go wrong?\n\n![Screenshot from 2019-04-19 11-43-22.png](\/\/\/raw\/138\/1\/z\/2442e.png)\n\nSome weeks before LD44 I started writing a Vulkan renderer in Go (vulkan-go). I knew I would have to get this done beforehand as Vulkan is very verbose. You essentially start by selecting your physical GPU and then specify everything you want to do explicitly. There are swap chains, render passes, graphics pipelines and lots of different buffers. You have to allocate memory for your buffers and copy the data onto your GPU. All of your draw commands have to be recorded to a buffer beforehand. Doing all of this is both liberating and restricting. I actually settled on using the same command buffer for the entire game, with a separate draw buffer so that I wouldn\u2019t have to re-record anything of the fly. By Friday I had the core renderer done that could render colored triangles in only 1600 lines of code. I decided to use my LD40 WebGL engine as a base for this one.\n\n![20190427064610.gif](\/\/\/raw\/138\/1\/z\/24434.gif)\n\nAfter the theme was announced, I got to work on depth buffers, texture loading and obj parsing. Now I could finally render textured triangle meshes! The rest of the engine was much easier to do as I could essentially copy stuff over from my previous engine. I ended up adjusting a lot of the physics code as physics simulation is something I\u2019ve always struggled with. I definitely wouldn\u2019t recommend doing your own 3D physics as this is generally a difficult problem to solve. I use convex hull intersection for collision detection. You can calculate convex hull intersection simply by taking a dot product of all the faces and figuring out whether a vertex is inside or outside. This can be used for concave stuff as well if we assume that all geometry is convex locally. Only do intersection on the closest triangles and you should be good. The physics simulation itself just calculates the velocities directly, does a position correction and adds some damping. I wouldn\u2019t get involved with iterative methods or LCP. You just hope everything doesn\u2019t explode.\n\n![Screenshot from 2019-05-01 00-20-07.png](\/\/\/raw\/138\/1\/z\/2442f.png)\n![Screenshot from 2019-04-28 12-53-07.png](\/\/\/raw\/138\/1\/z\/24430.png)\n\nI settled on a game idea fairly quickly as I thought this would inform my technical decisions. The game would be about a grim reaper\u2019s job collecting souls and trying to make ends meet financially. I didn\u2019t want to make levels manually so I had the crazy idea of generating the levels procedurally. First I started by generating random 16x16 triangular meshes, but pure randomness just doesn\u2019t look very nice. So I created an implementation of the venerable diamond-square algorithm. Chunks of size 16x16 would be generated and then stitched together at the sides to make a continous level. Continous generation of chunks would make for an infinite world. I struggled with this a lot and you can still clearly see the edges of the chunks. I had never created infinite 3D terrain, so I\u2019m still pretty happy with it.\n\nThe actual gameplay was very rushed as I had little time left. Balancing was a guessing game and I ended up leaving lots of bugs behind. I had no working Windows machine, so cross-compiling took a bit to figure out. In the end it all worked out and I\u2019m pretty happy I did it. The Ludum Dares that leave me learning something are the best.\n\nhttps:\/\/ldjam.com\/events\/ludum-dare\/44\/worked-to-death","comments":0,"created":"2019-05-02T00:02:33Z","files":[],"files-timestamp":0,"id":155845,"love":4,"love-timestamp":"2019-05-02T01:54:36Z","meta":[],"modified":"2019-05-02T03:34:50Z","name":"Doing Ludum Dare with Vulkan","node-timestamp":"2019-05-02T03:34:50Z","parent":154176,"parents":[1,5,9,139254,154176],"path":"\/events\/ludum-dare\/44\/worked-to-death\/doing-ludum-dare-with-vulkan","published":"2019-05-02T00:09:40Z","scope":"public","slug":"doing-ludum-dare-with-vulkan","subsubtype":"","subtype":"","type":"post","version":468795},"node_metadata":{"n_key":"155845","n_urlkey":"348084","n_parent":"154176","n_path":"\/events\/ludum-dare\/44\/worked-to-death\/doing-ludum-dare-with-vulkan","n_slug":"doing-ludum-dare-with-vulkan","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"6193","n_created":"1556755353","n_modified":"1556768090","n_version":"468795","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/44\/worked-to-death\/doing-ludum-dare-with-vulkan","text":"As usual, I decided to learn something new for Ludum Dare. Last time I learned Go, really liked it and wanted to use it a second time. Learning Vulkan had been on my bucket list for a while, so this was the perfect opportunity to do it. Why use Go + Vulkan? Go is garbage collected after all. Well, what could go wrong?\n\n![Screenshot from 2019-04-19 11-43-22.png](\/\/\/raw\/138\/1\/z\/2442e.png)\n\nSome weeks before LD44 I started writing a Vulkan renderer in Go (vulkan-go). I knew I would have to get this done beforehand as Vulkan is very verbose. You essentially start by selecting your physical GPU and then specify everything you want to do explicitly. There are swap chains, render passes, graphics pipelines and lots of different buffers. You have to allocate memory for your buffers and copy the data onto your GPU. All of your draw commands have to be recorded to a buffer beforehand. Doing all of this is both liberating and restricting. I actually settled on using the same command buffer for the entire game, with a separate draw buffer so that I wouldn\u2019t have to re-record anything of the fly. By Friday I had the core renderer done that could render colored triangles in only 1600 lines of code. I decided to use my LD40 WebGL engine as a base for this one.\n\n![20190427064610.gif](\/\/\/raw\/138\/1\/z\/24434.gif)\n\nAfter the theme was announced, I got to work on depth buffers, texture loading and obj parsing. Now I could finally render textured triangle meshes! The rest of the engine was much easier to do as I could essentially copy stuff over from my previous engine. I ended up adjusting a lot of the physics code as physics simulation is something I\u2019ve always struggled with. I definitely wouldn\u2019t recommend doing your own 3D physics as this is generally a difficult problem to solve. I use convex hull intersection for collision detection. You can calculate convex hull intersection simply by taking a dot product of all the faces and figuring out whether a vertex is inside or outside. This can be used for concave stuff as well if we assume that all geometry is convex locally. Only do intersection on the closest triangles and you should be good. The physics simulation itself just calculates the velocities directly, does a position correction and adds some damping. I wouldn\u2019t get involved with iterative methods or LCP. You just hope everything doesn\u2019t explode.\n\n![Screenshot from 2019-05-01 00-20-07.png](\/\/\/raw\/138\/1\/z\/2442f.png)\n![Screenshot from 2019-04-28 12-53-07.png](\/\/\/raw\/138\/1\/z\/24430.png)\n\nI settled on a game idea fairly quickly as I thought this would inform my technical decisions. The game would be about a grim reaper\u2019s job collecting souls and trying to make ends meet financially. I didn\u2019t want to make levels manually so I had the crazy idea of generating the levels procedurally. First I started by generating random 16x16 triangular meshes, but pure randomness just doesn\u2019t look very nice. So I created an implementation of the venerable diamond-square algorithm. Chunks of size 16x16 would be generated and then stitched together at the sides to make a continous level. Continous generation of chunks would make for an infinite world. I struggled with this a lot and you can still clearly see the edges of the chunks. I had never created infinite 3D terrain, so I\u2019m still pretty happy with it.\n\nThe actual gameplay was very rushed as I had little time left. Balancing was a guessing game and I ended up leaving lots of bugs behind. I had no working Windows machine, so cross-compiling took a bit to figure out. In the end it all worked out and I\u2019m pretty happy I did it. The Ludum Dares that leave me learning something are the best.\n\nhttps:\/\/ldjam.com\/events\/ludum-dare\/44\/worked-to-death","title":"Doing Ludum Dare with Vulkan","wayback_source":[]}