Jump to content
  • Advertisement

_the_phantom_

Member
  • Content count

    13023
  • Joined

  • Last visited

Community Reputation

11256 Excellent

About _the_phantom_

  • Rank
    Legend

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. _the_phantom_

    Writing portable Vulkan

    *lumbers in to life for the first time in a while* On memory; while it is a bit of a pain it also has some advantages in that you can do something you previously couldn't do - alias memory. Granted, this needs a frame graph to sort out memory life times but it does mean that you can control the memory footprint a bit better (EA's frame graph presentation from GDC '17, iirc, has some good numbers). If you can't be bothered to deal with memory pain up front then AMD's memory allocation library is a good place to start ( https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator ) - the main thing you have to remember is that actual allocations are limited, I've not seen support for more than 4096 in the wild, so you'll be block allocating and then sub-allocating from that block. The main wrinkle I know about in this area is that NV seem to prefer that their render targets are allocated separately (see 'VK_KHR_dedicated_allocation', which might have been rolled in to the 1.1 spec; AMD lib above will use it afaik) and they have a fair few rules on alignments of types for buffers and images. AMD on the other hand seem not to care, often reporting very low alignment requirements so be careful with that when trying to sub-allocate/work out block sizes (someone I was helping out was basing block sizes for buffers on alignment information, his NV card gave him a large-ish number so things work, where as AMD reported back '1' which caused him to allocate a new block per allocation). It might be worth looking up the various numbers on https://vulkan.gpuinfo.org/ as a reference. The other advice I would give is - test on AMD as this is the only way to be sure you've not screwed up barriers/transitions. Put simply AMD require you to get this right; get it wrong and you'll luck out with it working at worst, corrupt or crash at best. NV, on the other hand, ignore all barrier function calls. Totally. They have their own low level state tracking which they apply so your barrier calls can be doing all manner of crazy incorrect things and it'll just work on their hardware/drivers (driver bugs not withstanding which is just a massive 🤦‍♂️ given the whole point of the new APIs... ). Basically NV is not a good test platform for correctness.
  2. _the_phantom_

    Unity dropping Monodevelop a let down for small indie?

    Yes, because nothing says "use our product" like shipping a built in installer for a product that no longer works... If they had done that then you'd have started a thread shouting about how Unity shouldn't be shipping an installer for a broken tool with their product and that Unreal is clearly better because they don't...
  3. _the_phantom_

    Unity dropping Monodevelop a let down for small indie?

    Because 2018.x marks the start of the big push to upgrade the .Net/Mono implementation used by the engine all the way up to the most recent standards for C# and .Net Standard - maintaining the Monodevelop plugin going forward was considered not to be worth the outlay when existing tools already have you covered for the new stuff. As for a couple of other comments; Unity hasn't been a 'small' engine for some time and as for a lack of power; the C# job system and ECS say "hi..." and then proceed to run rings around pretty much everything else in terms of performance.
  4. _the_phantom_

    I have been centrist/centre-left, Now I am going Right Wing

    Citation fucking needed. Certain areas have armed patrols (mostly airports, places like the House of Commons and occasionally you'll see a couple of armed officers at a train station), but the idea that there are response teams patrolling day and night is, frankly, bullshit. And for that reason the fact they got from their base of operations, into central London and ended the situation 8 minutes after it was reported is fucking amazing. You apparently know shit about my country, so how about you keep bitching about your own and STFU? Edit: And frankly, reading this thread (which I regret) makes me glad I have very little to do with this site now... the atmosphere is frankly sickening to behold and is just another group of people whos 'solutions' are going to make the problem worse...
  5. _the_phantom_

    Unreal Engine vs Unity Engine

    I'd have to double check the code (although I was looking at it just the other day so I'm 99% sure the following is correct), but that isn't quite how things are done; while it's true created game objects all have a 'transform' that is in fact a component which is added to the gameobject at construction time.
  6. _the_phantom_

    What happened to Longs Peak?

    I can tell you for a fact the CAD companies didn't kill it - I was having a conversation with someone on the ARB at the time who confirmed that. My working theory is that it was Apple and possibly Blizzard who did for it - AMD and NV were very much on board so I doubt they killed it... Intel is a maybe but feels unlikely.
  7. _the_phantom_

    Unreal Engine vs Unity Engine

    Ugh... I wish that lie would just die... Epic have done no such thing. Segments of the code base have been updated, and continue to be updated as time goes on, but there is plenty of code which goes back to the start of the engine kicking about - certainly UE4 wasn't a "complete rewrite" as I see so often claimed. Both engine developers work in roughly the same way; you take what you've got and you add to it. Sometimes a subsystem will get rewritten or ripped out and replace, but the majority of the time its just updates on top of updates. Epic and Unity are no different in that regard. (And getting permission from management to rip out and replace a system isn't easy; a place I worked previously allowed us to gut our renderer and start again but only after weeks of convincing people that what we had wasn't going to work going forward.)
  8. _the_phantom_

    Unreal Engine vs Unity Engine

    I'm intrigued by what you mean by the first one of these? The second... well, if you are talking C# scripts, then you can debug stuff from Visual Studio (with the Unity Tools plugin) or one of the OSX Mono environments easy enough.. in fact, using the Unity Tools plugin I think you can debug C# code with VSCode..?
  9. _the_phantom_

    Unreal Engine vs Unity Engine

    Plenty of large studios use Unity however you probably don't realise it it - the problem stems from the licensing terms; if you use a free version you have to throw up a splash screen, if you pay you don't. So, Joe Hobby who produces the poor/basic looking game has Unity splashed all over it. Meanwhile AAA Developer who has shelled out money doesn't mention it. Net result; people only see the bad looking games and think that is all Unity can do. I'd say at this point both UE and Unity could produce the same output, gfx quality wise, the difference is that out-of-the-box UE's post system makes it easier to produce basic shiny; however with an artist onboard both are just as capable.
  10. _the_phantom_

    Space Colonization and the Future

    Resources, or lack thereof, is one reason. As the human race consumes more and grows we'll run out of resources and the planet will find it harder and harder to support us. Physical space is another problem; you want more population? You are going to need more land. The big one, however, is summed up in a cartoon I read once; "Asteroids are natures' way asking how's that space program coming along?" We are basically one big rock away from humans no longer being a thing in the universe; if you want the species to carry on then we need to stop clinging to this rock and hoping another rock doesn't smash in to us. Even if we continue to avoid rocks then the big one is the sun expanding and consuming the inner planets; that alone limits human life span to less than 5 billion years. (Of course, thanks to entropy all human actions are ultimately pointless, the question is just at what point to do, or our descendent species, stop being A Thing.)
  11. _the_phantom_

    Starfield shader pipeline

    Honestly, splitting things in to a couple of draw calls using the CPU is probably the best way to go about this; you pretty much need two types of drawing (points vs quads/triangles) and trying to make the choice on the GPU might not be optimal. About the only other way to do it would be to run a compute shader over the 'star data' and have that build up point and triangle buffers and then use an indirect draw call to consume that buffer to render. You'd still end up issuing at least 3 dispatch/draw calls (1 for compute, 2 for draw) but you wouldn't have to sort any data as they would be issued back to back.
  12. _the_phantom_

    Starfield shader pipeline

    And then promptly forget that as the geometry shader stage is terrible and should basically never be used.
  13. The problem with comparing to 'the rest of the web' is that... well.. this site isn't "the rest of the web" and even if it was the rest of the web is a clusterfuck of piss poor narrow designs because apparently that's the latest circle jerk going on. On a forum, where people post code, it is just dumb, as you get beyond a few characters and then you have to start scrolling right to look at what people have written. And by taking out some of the top and bottom whitespace in order to solve the 'too long' factor posts are now starting to feel cramped and bunched up. The 'posted' date runs in to the main text and the end of a post crashes in to the footer. Also, the user avatar to the left of the 'reply to' box is just dumb. I know who I am, I don't need a picture to remind me (not that I have one either...). The main forum listing is also a disaster; no per-line delimiters meaning content just runs together like a de-saturated mess. Oh, and on Edge the layout feels slightly broken and, for Reasons, you are missing a dot to click when going to the most recent posts (the link is still there, just no graphic). (and if I could point these things out to other websites who fixate on 'fixed width' BS and other things then I'd be shouting at them too because it's insane; the web is not fscking print - stop trying to treat it as such ffs...) Edit: OK, site layout has changed since I wrote the above... some layout issues persist but in general the sizing is sane now, thanks.
  14. So, if GD.Net was a game I would be hitting the 'refund' button right about now. I run a 34" ultrawide monitor - my Edge window doesn't take up the whole screen and is sized to be comfortable when viewing websites. Most websites flows to a decent size, ones with forums pretty much without fail take up the majority of the window space... GD.Net... well... 50% of the window space is content, of that 1/4 is 'ads and other shite' on the right leaving 3/4 for content (some of which is lost with gutters and other terrible stuff). To recap; Monitor - 3400*1440 Edge - 2345*1262 GD.Net 'content' - 1169*1182 GD.Net sans right bar - 827*1182 GD.Net post content - 730*1182 730 pixels of 2345 is 'useful'. That is 31% of my (non-full screen) browser window. Or 21% of my whole monitor's horizontal resolution. Information is now cramp and compacted in the centre of the screen rendering it annoying to read and parse. If a game pulled this kind of 'lulz fuck your screen res' bullshit it would be refunded instantly (Fallout 4 and No Man's Sky suffered that fate within 3 minutes) so at this point I can only conclude that you no longer want people to be able to use the site using anything bigger than a 1024*768 monitor from the early-2000s....
  15. _the_phantom_

    DX12 to Vulkan

    Having read up on both in the form of a couple of books I personally feel, from an API point of view, it's pretty much a toss up as to which one you want to go for. I wouldn't worry about Win7/Win8 support of Vulkan personally; it's unlikely to be a deciding factor by the time someone starting now has something out. Linux might be a consideration but most people who have a Linux version of their game report sales numbers of about "fuck all" which largely seems to match the market as reported by Steam. Apple won't be touching Vulkan, they are knee deep in Metal (which, by what people have said, is a sane API on it's own - somewhere between D3D11 and D3D12 in terms of 'level'). Once you factor that out it comes down to what you want to support and what features you like/need - both are broadly speaking the same with a few differences. For example I like that Vulkan lets you enumerate all the queues on a device (so for my 290X it reports 1 gfx, 5 compute and 2 DMA) where as D3D12 virtualises it all. However when it comes to D3D12 I do like the indirect draw call type where you can also change buffers/constants along with the draw counts which means you could keep more things on the GPU for self-feeding. NV has a more comprehensive version as an extension but Vulkan lacks that by default. Vulkan seems a bit more verbose than D3D12, but eh, minor point imo once you get beyond anything simple. So, I'd pick one and run with it - both teach you to deal with the GPU in largely the same manner so you won't be missing out.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!