How good is vulkan conformance? Just ran into an opengl bug on amd and that was from DSA.
Automerge is there but it only works up to an hour after the original post now, if I recall correctly.
It's getting harder and harder to lie to my boss about my future at this company. My coworkers asked me what I'm gonna use my vacation days on today and I froze
When are you moving to your new company?
I'm not sure if there's any folks from the Ottawa, Ontario area, but this event is happening tomorrow (registration required): Discover Technata | Career Fair | Kanata |
OpenGL sometimes necessitates an ugly mess - lots of devs agree that while Vulkan requires more code up-front, it becomes less complex and more understandable code later. Discarding state is also just WONDERFUL.
In regards to a million year project, that was VulpesRender. It started not so great, and I'm constantly tuning it and polishing it based on the needs of applications that use it. Learning Vulkan works best like so, imo: (these are just thoughts, feel free to do your own thing)
Start with the vulkan-tutorial examples and walk through those. You'll get a monolithic source code file, but it starts getting you to understand how the parts of the API interact
After that, break down the Vulkan tutorial bits into classes: this is how I started, and it works well since you can see how things relate fairly easily
Expand upon the base Vulkan tutorial stuff by trying examples on Sascha Willem's Vulkan repo - its a good way to test out your new classes that wrap up Vulkan stuff
Read and explore lots of example code! There are more and more good Vulkan engines, blogs, and articles appearing. Feel free to DM me on discord for links
Side note: maybe don't use Vulkan-hpp. It's kinda gross in a few fundamental ways, uses lots of autogenerated code iirc, and doesn't really help that much if you're already working at that low of a level
As an example of a "million year project", take a look at VPR earlier in it's commit history, and compare it to where it's at now if you like. I've spent a lot of time (565 commits, my most yet!) learning to reduce the scope of that tbh, along with just general polishing and improvements based on reading I've done (both on graphics stuff, and from books like "Clean Code"). Vulkan is hard to learn for sure, but I honestly enjoy it a ton and can't express how much I dislike OpenGLs state stuff now haha. You've been practicing with DSA and understand many of the fundamentals required for Vulkan - I definitely think you're more than capable of tackling Vulkan. Using DSA was what I did right before I switched, and statefullness is part of why I switched too. That was probably about 10 months ago now, I think.
In regards to Vulkan compliance: pretty good, tbh. I've not required or had use for many extensions yet but there's this hardware database that documents what extensions and formats hardware supports: Vulkan Hardware Database
It also lets you see by percentage how much hardware supports a given format or extension, which is really useful for making design decisions like what kind of texture formats to use or what kind of extensions you should try to use by default (for me, I enabled dedicated allocations for my memory subsystem). There's also not a lot of split between versions of Vulkan yet, either.
Also, there's tons to enjoy about Vulkan imo:
Push constants are a beautiful beautiful thing for sorta literally pushing data like the MVP matrices to the GPU at runtime, without needing uniform buffers
Texture bindings actually suck less to handle: more upfront code again for sure, but once you get into more complex usages they really shine
Threading is easy to do - both for transferring resources to the GPU on a completely separate thread, and for recording commands. It's hilarious how easy it is compared to OpenGL. (e.g. this)
Speaking of recording commands - that's probably my favorite difference. It makes much more sense, lets you pre-record commands, and uses practically no state information
Also, renderpasses + subpasses: lets GPU optimize things like G-buffer stuff by using transient memory and lets you run subpasses potentially in parallel
End of May. Gonna give two weeks notice. Problem is I already accepted the job offer at this current company, but the new company offered me almost twice as much, and it's in an area that has more tech jobs.
How long have you been there? Just curious? It doesn't change anything, you're obviously making the right call.
A little over a year
Why not give them a months notice. They'd probably appreciate a little more heads up.
People look at you different when they know you're quitting, especially when you haven't been that long. 2 weeks is long enough, you put yourself at a disadvantage any other way. That being said I would have spilled the beans to any close co-workers a while ago.
Spent the first two days of my holiday writing an api for creating TXT records on a custom nameserver, for DNS-01 validation which Let's Encrypt wildcard certificates require.
The result is a very tiny web application written in Rust and hosted on https://dns-01.online
You basically create an account to get an API key, and then you can POST TXT records straight to my nameserver, and you'll be able to complete Let's Encrypt dns-01 challenges.
My mom told me that 2 weeks is 2 weeks more notice than my employer is required to give me
I told one coworkers, but nobody else
So I'm trying to basically make Bullet physics for roguelikes.
The ultimate motivation is to overhaul the vehicle physics in Cataclysm:DDA. It's an open-source roguelike with multi-tile vehicles. Rotation is handled interestingly. Basically things skew instead of rotating. This obviously has drawbacks, like zombies being able to attack you in your "sealed" car if you park diagonally. That's not a problem I plan on tackling. Currently Vehicle-Vehicle collisions are pretty much nonsense. There's no concept of angular momentum and collisions between vehicles and much smaller vehicles are just wrong. For example, a 70 ton tank will be stopped by a 2-door coupe if the tank isn't going over 50mph. Kind of silly.
https://files.facepunch.com/forum/upload/133270/3757ed83-97f0-49b6-8e53-21608bbdcb2c/image.png
https://files.facepunch.com/forum/upload/133270/9b74b175-f788-4523-9269-9c879c8137cb/image.png
https://files.facepunch.com/forum/upload/133270/8254b227-fdb2-4387-b954-c349110b6696/image.png
https://files.facepunch.com/forum/upload/133270/088657a6-b780-4c12-9ee0-bcd3cd548bfd/2018-03-28_15-44-38.mp4
https://files.facepunch.com/forum/upload/133270/46220f76-c7e3-49f3-b423-0d7e11f6e59e/image.png
Made the window bigger and now have "cars" so I'll be able to see if my rotations are all skewed up.
Honestly the cars in C:DDA are the wonkiest and also best part of the game. I never played it that much but the idea of a roving zombie killing shelter was always appealing. If only it wasn't so janky. In fact any more-than-one tile anything in roguelikes is super weird. In most roguelikes you can walk over teammate's tiles and even occupy the same ones as them. A fluffy bunny is equally as large as a behemoth or dragon.
In dwarf fortress the only multi tile entity apart from buildings (which are simple because they don't move) are wagons. Wagons are themselves black magic that interacts very oddly with the game. They are not objects, like a wheelbarrow or barrel, but in fact living breathing entities. When you scuttle a wagon it "dies" and leaves behind "wagon wood", much like disassembling a building. However, "wagon wood" is actually caused by the butchering of the wagon "animal" and is basically the wagon's guts and carcass. Sometimes bugs showed up where dwarfs got upset over the butchering of their favorite wagon friends. It's also impossible to create new wagons. Some people tried to necromance wagons back to life but it didn't work out.
My main point really is that multi tile entities in any roguelike or grid based game are super weird and often unintuitive. The way wagons traversed up and down terrain meant that a part of them existed on different Z levels which is just a nightmare. On top of that, even though a wagon was 3 tiles long it could exist on overlapping Z levels, as if it actually wrapped in on itself to surmount its obstacle.
SDL_sound in 2018, 10 years later
https://r4w9vg.dm.files.1drv.com/y4mZ2npX36lFHOVV3SNIocdTtGZ1RQhBOuodWxAHq4hPyk1EVfiK1Qvgkkw-SwiGkmcCjIJ66Xk2K_UKgqBvfe7OynfIt_3OBFxzLHQpN6Cxt0yTVNRsoQn4SYKrVCGLWyucUiZi-wh-dZuRAjCUX3OJnSvy5myVYm2yXfSWxJ9Pwu_ti9sp1k0Kt1DNAz7BxRUD0Mz8sCq_znA3Pkk5tDUZg?width=3000
https://sixevg.dm.files.1drv.com/y4mgfhbo7CSCWNly751ng6M-HrYrb4cf_hj5RaRCkATCJU83JL613eGFcU9o_V-yFA2-ZKAxQcLKPFwT_d3ZmQ-eTmBFzJ58393EbQJWN-qUC3VqPcooNmm5hEdJY569h5R0XOmaFKoquIw-xtd5zyB-GePPX0RyvrjmaA7cgtCXVubsaN3bmA5rMcUx3XWNpHVrSgpwXmhHDG2YlTffnPjiw?width=1125
😩
I just want to make a raycasting game about driving cars and running over nazis. I've got raycasted walls (not very efficiently) and floorcasting is proving a little difficult. My code is all over the place so maybe I should just start over. I have a name for my mythical land of nazi roadkill: Strudeldorf
Does your windscreen get coated in apple sauce the wilder it gets? Interesting opportunity for some cool refraction there
I currently have wallcasting and the physics for car driving, but that's it. There's no nazis or even collision detection. I'm writing a software renderer
It looks like lgf as a drop-in replacement for LÖVE is starting to work out. There's obviously not a lot supported compared to the full 0.10.2 API right now, but it boots.
https://i.imgur.com/TZlGG65.png
One of the weird things, though, is that creation of nested fullscreen canvases—still framebuffers in lgf—clears the screen. I'm wondering if it has to do with retention of binding framebuffers, retention of bound textures, or something of the sort. If I can figure that out, I'll have made another step forward. I also recompiled SDL_sound with static lib dependencies, so I could cut down on those .dlls from earlier to just one that needs to be accessed from the FFI.
Quit my old job today. That was fucking awkward. My boss's face was devastated, he didn't see it coming whatsoever I suppose.
Sometimes, when I waste an entire day trying to figure out why im getting hardfaults on a STM32F7 microcontroller I miss the rich experience Visual Studio and C# give me
You should look into getting yourself a bus pirate and debugging the microcontroller with dbg over jtag.
Vcpkg works great for VS but I cannot for the life of me get it to work with cmake
I actually gave up on it and used it only for libmodplug, because their binaries ended up different than compiling straight from releases they claim to use. I think they do a bunch of custom patches on top of all their packages.
https://i.imgur.com/hKxjy7T.png
hahahahahaha yes
to use, run `lgf .` instead of `love .`
I'm not a big fan of the bus pirate because of hardware (speed) limitations.
I use an ST-Link and a Saleae Logic Pro 8 with vscode and GDB+OpenOCD, but because of the nature of the bug having a debugger wasn't of much use in the end
I pity the fools who use an arduino and have to result to `Serial.print` instead of proper single step debuggers
I know it's pretty noobish, but this week I managed to implement "LeakingMaxHeap", basically it's MaxHeap with limited number of samples.
U put in floats, maximums float to the top (just as in any MaxHeap), then when it's full, maximums start to leak out, in the end only smallest numbers remain.
I will use it for k-nearest-neighbors querying, hope it makes sense.
Sorry, you need to Log In to post a reply to this thread.
What are you working on? v67 - March 2017
