Devs should just not use GameWorks because it's extra work for nothing but spite in return. What's the point? It's not like they're charging more for more. I still don't see proof of GW performing significantly worse on AMD's hardware compared to on Nvidia's hardware, but instead it keeps on being perpetuated.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
NVIDIA makes source code for select GameWorks libraries available to developers via GitHub
- Thread starter Odellus
- Start date
Devs should just not use GameWorks because it's extra work for nothing but spite in return. What's the point? It's not like they're charging more for more. I still don't see proof of GW performing significantly worse on AMD's hardware compared to on Nvidia's hardware, but instead it keeps on being perpetuated.
Yeah thats normal practice with 3d party libraries, it helps the licensee to stay current with any changes that might be useful to them, I never liked it myself, but everyone does it. (the code that is changed in the libraries, all other code doesn't have to be shared)
When we licensed the Cry Engine, Crytek wanted us to give everything back, even our game code, network code etc. We were able to negotiate to leave out the game code, and any 3rd party network code that we would be using.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
Problem isn't completely about AMD performance vs Nvidia. You have to remember AMD fixes mist of these GW issues by limiting Tess from 64x to 16x/8x to bridge that performance gap. All in all the issue is attempting performance across both rather than allowing on vendors support that may or may not have performance issues.
OXIDE deserves great praise as they are actually working as I mentioned above to get performance from both without resorting to ones single tech to achieve certain effects/results. They alone have shown what to look forward to with dx12 to extensive accolades.
Cr4ckm0nk3y
Gawd
- Joined
- Jul 30, 2009
- Messages
- 847
Problem is other devs, unlike Oxide, want the middleware for whatever reason. Since NV was the only game in town for a long time they will of course be proprietary about it.
Users shouldn't be pissed at NV; they should be pissed at AMD and Richard Huddy for taking so long with GPUOpen.
No engine licensor have added any middleware that limits the ability of the licensee to utilize that said engine to the full extent. It would be stupid to do so and try to remain competitive in that market.
Epic doesn't do it, Crytek doesn't do it, Unity doesn't do it, Lumberyard doesn't do it, Stingray doesn't do it, Frostbyte doesn't do it, Snow drop doesn't do it, Id tech doesn't do it. The list goes on and on.
You take Oxide as the normal, it is the norm for all engine developers and licensors, its just smart business. What the dev does to their game afterwards is up to them. Oxide has been forth coming, I think not, it stinks the way they have stated that async didn't work on an IHV's hardware without even asking them first if it was an issue or not, than they back tracked. Now we can easily see after this years GDC it definitely wasn't the case.
Do remember an interview with Andersson and Sweeny (Carmak was there to), and Andersson stated pretty much the same thing about nV hardware vs. AMD hardware? Sweeny had a weird look on his face almost like what Andersson was saying was crazy, and then made a quibble about his statement and ended the discussion right there? Do you think after this years GDC meeting about async, that kinda goes to what Sweeny was getting at?
Even two or three weeks ago, AMD went on record with the redit open Q&A and stated the same thing. Do you see nV retaliating like AMD did when it was about Tessellation? Do you see nV whinning about Aync on AOTS, they stated one thing, it isn't representative of all DX12 games and that was it, they never had their marketing people doing interviews, live chats etc about how Async was screwed up on that specific game on their hardware. Because they took the road we need to fix this issue, put money where the money needs to be. Problem is AMD is spending $ on the wrong things or wrong things first, instead of improving their bottom line by improving tools and resources that would improve developer relationships and help developers lower their costs, AMD's first goal is to limit Gameworks and then do their OpenGPU initiative. By the time Open GPU really gets traction, nV will be making other Gameworks effects that OpenGPU won't have. When the competition has a leg up on you, you need to double or triple your efforts to catch up, you don't go at the same pace as before. Is it prudent to try to stop Gameworks infiltration, yes it is, but as a end user does it matter if we know about it, not really, since its up the Dev's that integrate it and let us deactivate them. They need to sway the Dev's to not use them, and trying to making end users to tell the dev's not to use them won't work too well. Only way is to have end users not buying certain games. That not only hurts the dev's but in a round about way hurts nV and AMD too, because it just hurts the pc game industry as a whole.
Engine Dev's don't use middleware or try to avoid using middleware as much as possible that require additional license fees or contracts, it makes it much easier to sell their engines, as listed above. Dev's do it because the end user doesn't matter to them if they have access to the code or not, and not like they will develop more on a game.
Last edited:
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
AMD was maybe little bit to busy with creating Mantle and see what that got us ..
They also don't have unlimited resources. There's a reason middleware exists.
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
WRONG WRONG WRONG. Look if you want us to take you seriously you need to get off that Nvidia high horse. Nvidia tried strong-arming Oxide but they didn't take it. Nvidia didn't admit to not having the ability to do HARDWARE async but rather wanted us to believe it was just a driver switch on issue. By now we all KNOW Nvidia does not have HARDWARE async capability, which was the whole argument all along. So no OXIDE hasn't had to backtrack. Hell Kollock on OCN has given large amount of details in the case of async and many other aspects of their (OXIDE) engine.
But to the point of Epic/Crytek... no crap, really? Of course they wont use middleware, they make Engines. But that proves my point about oxide and the point of avoiding vendor related middleware. These engine developers want to ensure they have the most efficient effect-full engine around to get Game devs to use their engine/make money. Gameworks doesn't do that for them. And at no point did I infer OXIDE was the norm, just they are doing it like it should be done.
WTF are you taking about, nV has the ability to hardware aysnc, what do you think GDC takes were all about? Did you see anywhere there that says they can't do async in hardware? You do realize that the ability to do async or multi engine is a REQUIREMENT OF DX12 specs? There would be no way of getting DX12 certification if they weren't capable of doing these in hardware. So don't talk about something that you don't know about, nor are willing to learn about, because your understanding of the situation is so limited. Did you miss the part right now they are getting a MAXIMUM of 10% increase due to Async shading. 10%, if you see more than that going from Dx11 to Dx12 or async on and off, there are other parts that are coming into play that is creating that increase.
And its not about the high road, they asked Oxide don't run their async path on their hardware at the time there were issues, and ever single patch since those issue reemerged but fixed through driver updates on nV's part. nV got to work on what they have to do its that simple. How long as UE4 been out, when did nV on their own accord make branches for Gameworks for UE4? Is AMD even bothered with doing Tress fx branches? Don't even need to talk about Open GPU branches that probably won't happen. Yeah nV did it on their own. They didn't have Epic do it for them. Why can't AMD do the same? Its been what 2 years now since gameworks libraries were integrated into UE4. Who is being aggressive and pushing their game effects libraries where it could be used by Indie developers with a simple compile of an engine, they don't' even need to worry about integration. AMD could do the same, I'm sure Epic would love them to do it, BECAUSE they don't need to spend resources on it, AMD does, and it helps get more users interested in their engine.
Oh god you think Oxide's engine is good? have you ever done any game development? Why do you think Unreal, Epic games had what over 300 games at a single time licensing their engines? You think game companies are so stupid that they were willing to pony up 1.35 million of an engine that Oxide wouldn't even get close to? Do you realize the resources to make a AAA game engine? Oxide is not capable of making that kind of engine. They made an engine that is good for what they need or type of game they are making,, but don't even try to compare Oxide's capabilities to the top engines on the market. That's like trying to compare Ogre engine to a crappy Torque engine. Why do you think Crytek an engine maker that has much more experience than Oxide's dev team unable to compete with Epic? Damn they can't even compete with Unity let along Epic. There are very strong reasons for this. If you bothered just trying to use the engines out there that are FREE to dl and test out, you would know why. Shit I think Lumbar yard is better then Cry Engine right now even though it has a few less graphical features, its got a damn nice networking system. Why do you think Id tech wasn't able to keep up with Epic? its all about the tools man, if you don't have them, you don't have a good game engine. I can pretty much say for certain that Oxide's engine is 5 or so years behind when you start looking at their tools. this was the problem with Cry Engine, tools are no where near as good as Unreal's, they have gotten a lot closer but it took them 3 generations of engines, a total of 10 years.
And its not about the high road, they asked Oxide don't run their async path on their hardware at the time there were issues, and ever single patch since those issue reemerged but fixed through driver updates on nV's part. nV got to work on what they have to do its that simple. How long as UE4 been out, when did nV on their own accord make branches for Gameworks for UE4? Is AMD even bothered with doing Tress fx branches? Don't even need to talk about Open GPU branches that probably won't happen. Yeah nV did it on their own. They didn't have Epic do it for them. Why can't AMD do the same? Its been what 2 years now since gameworks libraries were integrated into UE4. Who is being aggressive and pushing their game effects libraries where it could be used by Indie developers with a simple compile of an engine, they don't' even need to worry about integration. AMD could do the same, I'm sure Epic would love them to do it, BECAUSE they don't need to spend resources on it, AMD does, and it helps get more users interested in their engine.
Oh god you think Oxide's engine is good? have you ever done any game development? Why do you think Unreal, Epic games had what over 300 games at a single time licensing their engines? You think game companies are so stupid that they were willing to pony up 1.35 million of an engine that Oxide wouldn't even get close to? Do you realize the resources to make a AAA game engine? Oxide is not capable of making that kind of engine. They made an engine that is good for what they need or type of game they are making,, but don't even try to compare Oxide's capabilities to the top engines on the market. That's like trying to compare Ogre engine to a crappy Torque engine. Why do you think Crytek an engine maker that has much more experience than Oxide's dev team unable to compete with Epic? Damn they can't even compete with Unity let along Epic. There are very strong reasons for this. If you bothered just trying to use the engines out there that are FREE to dl and test out, you would know why. Shit I think Lumbar yard is better then Cry Engine right now even though it has a few less graphical features, its got a damn nice networking system. Why do you think Id tech wasn't able to keep up with Epic? its all about the tools man, if you don't have them, you don't have a good game engine. I can pretty much say for certain that Oxide's engine is 5 or so years behind when you start looking at their tools. this was the problem with Cry Engine, tools are no where near as good as Unreal's, they have gotten a lot closer but it took them 3 generations of engines, a total of 10 years.
Last edited:
Maybe that is what AMD should do - Make a game engine or work with a current game engine to not only have libraries but a complete example. I think you said it - tools that help get the job done with the raw material or programming that is top notch. AMD has some great positional sound capability (too bad it is not used much for the PC - more tools needed, game engine using it etc.). AMD work with Creative Assembly on Alien Isolation was some great work, highly efficient great looking engine (radiosity using direct compute, HDAO+, deferred renderer allowing thousands of dynamic lights using Cubemaps for dynamic elements such as characters and particles [each particle can add light to the scene], light from computer monitors added light to the scene. Probably the best lighted game I've seen yet, of course some issues with specular aliasing was evident. The game ran so good on hardware that HardOCP did not think it was worthy to use - maybe too efficient is not good 
. Has to be great in 4K and should run well.
. Has to be great in 4K and should run well.JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
You just keep right on trying to be the good little soldier here for Nvidia. They didn't just ASK OXIDE to turn off async, they tried to make it look like they had Hardware Async by making it look as though it was a simple switch in the driver. Keep in mind OXIDE cannot see the driver so knowing whether something is turned off or on is unknown to them. Nvidia came off as bullies, when OXIDE didn't back down Nvidia did. Simple as that.
As far as OXIDE being a great engine or top of the line, I never made that argument. I said they are doing it right. They are coding their effects, not using middle ware. They have shown us mixed GPU and its possibilities, no one else has. They are going that extra mile to code these things themselves, venture where none other have attempted yet, be self-reliant. If you read some of what Kollock states at OCN you get the feeling that they don't always know exactly why some of the things work they way they do outside of the code they control. They have no real explanation in regards to mixed GPU and why it does better than CF/SLI, just that it does. I am sure the other engines will too, in time, be self reliant and purveyors of progress. But the last year and a half of GW has shown why such black-box middleware is the bane of Gaming.
Oh Oxide knew what was going on, don't tell me they didn't. We figured it at B3D in two or three days Oxide was taking crap, with a small program, and you are telling me Oxide didn't know what was going on? Just because you couldn't read a graph doesn't mean others can't either.
You think Oxide's dev's are buffoons? Same freakin driver Oxide was using......
No you don't understand, they aren't doing their engine right. There is no such as as the correct way, there is a better way though. The top engines right now were all made for Dx11, and slowly they are being converted to Dx12, don't' worry you will see the difference, actually why don't you play around with Real AAA engine and make your comments about Oxide engine after that? What you too lazy test that. UE4 can do MGPU too what you didn't know that (an engine that has issues with SLI and Crossfire? Oh see I have an issue with when something just works and they don't know why... LOL, they wrote the code for it, they should know why. They should understand why because its really easy to see too if you open up a profiler.
Its because the GPU that is slower at certain things (also you have control over this explicitly, so don't tell me they don't know what is going on), only certain amount of work is being done on the slower GPU thats it doesn't matter how much work is there, its being split up so that there is no waiting on either GPU's. Also the memory pool is not cloned over the cards, and is shared, engines that need information from previous frames to compute lighting will work with MGPU unlike with SLi or Crossfire, there is no such things as these.
That was easy to see too! I can't believe Oxide could not see that.
You think Oxide's dev's are buffoons? Same freakin driver Oxide was using......
No you don't understand, they aren't doing their engine right. There is no such as as the correct way, there is a better way though. The top engines right now were all made for Dx11, and slowly they are being converted to Dx12, don't' worry you will see the difference, actually why don't you play around with Real AAA engine and make your comments about Oxide engine after that? What you too lazy test that. UE4 can do MGPU too what you didn't know that (an engine that has issues with SLI and Crossfire? Oh see I have an issue with when something just works and they don't know why... LOL, they wrote the code for it, they should know why. They should understand why because its really easy to see too if you open up a profiler.
Its because the GPU that is slower at certain things (also you have control over this explicitly, so don't tell me they don't know what is going on), only certain amount of work is being done on the slower GPU thats it doesn't matter how much work is there, its being split up so that there is no waiting on either GPU's. Also the memory pool is not cloned over the cards, and is shared, engines that need information from previous frames to compute lighting will work with MGPU unlike with SLi or Crossfire, there is no such things as these.
That was easy to see too! I can't believe Oxide could not see that.
Last edited:
Maybe that is what AMD should do - Make a game engine or work with a current game engine to not only have libraries but a complete example. I think you said it - tools that help get the job done with the raw material or programming that is top notch. AMD has some great positional sound capability (too bad it is not used much for the PC - more tools needed, game engine using it etc.). AMD work with Creative Assembly on Alien Isolation was some great work, highly efficient great looking engine (radiosity using direct compute, HDAO+, deferred renderer allowing thousands of dynamic lights using Cubemaps for dynamic elements such as characters and particles [each particle can add light to the scene], light from computer monitors added light to the scene. Probably the best lighted game I've seen yet, of course some issues with specular aliasing was evident. The game ran so good on hardware that HardOCP did not think it was worthy to use - maybe too efficient is not good
Yeah, well they dont' need to make a game engine, take one thats out there and help bring the what they need to fully show their cards off to the fullest extent, and engine that will be used by many lol, that is very important. I don't know if they will have the leverage to keep nV out of the mix, but its a good start. I think they did with the Frostbyte engine but since this is a in house engine only that one developer/ publisher will use it, and they don't always use it for every game they are making.
The easiest one right now would be Cry engine, Unreal, and Lumberyard. They just have to make their own branches, and post them on Git hub, the companies that originally made the engines will promote the paths and as users start using them, it will self promote. But this is a lot of work, as you will need to have a team of dev's solely working on the branches with each update things change so they have to be doing it full time.
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
They have Async more then likely but it takes them a long long time to write a driver for it .. check the date on the link.
Nvidia Actively Working To Implement DirectX 12 Async Compute With Oxide Games In Ashes Of The Singularity
Over 7 months ?
Btw you rant on about Oxide, I'll let you know when one of the other companies makes an engine that performs superior with RTS that does many many units ...
That other people using other engines does not make them better per definition .....
Well, Total War series have been around forever, and they're pretty famous for battles of massive scales.
This is a game released in 2009 on DirectX 9.
2004. DirectX 9.
What makes AotS so special again?
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
It can do it better and not suffer some of the well known problems with RTS and many many units. Without coming to a standstill when doing trivial things as zooming out.
Anarchist4000
[H]ard|Gawd
- Joined
- Jun 10, 2001
- Messages
- 1,659
Isn't that what the entire console market is?Maybe that is what AMD should do - Make a game engine or work with a current game engine to not only have libraries but a complete example. I think you said it - tools that help get the job done with the raw material or programming that is top notch. AMD has some great positional sound capability (too bad it is not used much for the PC - more tools needed, game engine using it etc.). AMD work with Creative Assembly on Alien Isolation was some great work, highly efficient great looking engine (radiosity using direct compute, HDAO+, deferred renderer allowing thousands of dynamic lights using Cubemaps for dynamic elements such as characters and particles [each particle can add light to the scene], light from computer monitors added light to the scene. Probably the best lighted game I've seen yet, of course some issues with specular aliasing was evident. The game ran so good on hardware that HardOCP did not think it was worthy to use - maybe too efficient is not good
AOTS has what's probably the only true DX12 engine available atm. Anyone saying otherwise is probably a Nvidia marketing guy.
Compute ONLY they should be able to do async with some added CPU overhead. You know how many instances of a compute shader will exist and you can divide them out ahead of time. This seems to track with the numbers we've seen so far. It only works in limited cases and lowers performance more than it improves it. Obviously Nvidia would say it's not properly enabled yet for marketing reasons. It will probably stay that way until Pascal or later can show positive gains in reasonable scenarios.
And there were articles and videos about all the tricks they had to do to make it more realistic. Because all the units ended up getting synced together to lower the number or draw calls. You would take a single unit type and they'd have x number of different poses each guy would be in. Even then the game managed low thousands of units at best.
Yakk
Supreme [H]ardness
- Joined
- Nov 5, 2010
- Messages
- 5,810
Reading this thread... Just... wow...
Even the devs at Creative Assembly are going DX12 (using multi-threading at the CPU level and Async at the GPU level of coarse) for their newest Total War: Warhammer (FINALLY!).
As was said above, having identical duplicates is a far cry from having thousands of individually moving units.
Even the devs at Creative Assembly are going DX12 (using multi-threading at the CPU level and Async at the GPU level of coarse) for their newest Total War: Warhammer (FINALLY!).
As was said above, having identical duplicates is a far cry from having thousands of individually moving units.
Cr4ckm0nk3y
Gawd
- Joined
- Jul 30, 2009
- Messages
- 847
Nitrous??? The engine was developed for DX11 and added DX12 support.
By your definition then UE4 and Cryengine 5 are also "true" DX12 engines.
Yakk
Supreme [H]ardness
- Joined
- Nov 5, 2010
- Messages
- 5,810
The Nitrous Engine was developed for Mantle/DX12/Vulkan. The Oxide devs have been around for quite a while... they already had DX11 code they just added to their new engine.
Cr4ckm0nk3y
Gawd
- Joined
- Jul 30, 2009
- Messages
- 847
You may want to check that again. They didn't "add" DX11 to Nitrous. It was built on DX11.
According to Oxide, Nitrous was announced on October 23, 2013 followed by Mantle support Nov 2013.
DX12 API was announced until GDC 2014. Dan Baker didn't even talk about Nitrous and DX12 until May 2014.
Dan Baker - May 2014 said:
The Nitrous engine existed before DX12, so to say "The Nitrous Engine was developed for Mantle/DX12/Vulkan" is not only wrong but silly.
Nitrious was initially designed to run DX11, then added Mantle support, and now DX12. It is evolving to incorporate new API's as all the other engines are.
So to say Nitrous is the first true DX12 engine and all others aren't is BS.
yeah and they have been working on it, and that is what I stated, they are working on it, and they seem to have to do it for every iteration of AOTS patches. Does that sound like the developer is making use of information they have from IHV, if the IHV has to the changes in drivers? Maybe there is a communication problem between the IHV and dev, I don't know, but I'm not going speculate on that, but one thing for certain nV is keeping up with the changes they have to do, all the while not saying anything towards why Oxide's patches seemingly breaks something that had been fixed in the past.
Now the second part of your statement, isn't that what I stated, its good for the type of game they are making, that doesn't make it a great engine comparied to others. Its nice that it has certain features, but can you see other companies using the nitrous engine right now? Do you think poeple can use it for a FPS or an RPG, or an MMO type games?
Oxide's engine is probably light in many areas where it can't be used in other games. Creating a general purpose engine is much harder to do than an engine that is specifically tailored to one game.
Again, DX12 or any low level API gives some advantages over other API's, but that doesn't exclude the amount of work it takes to create a AAA engine on different API, different constraints etc. Just because Oxide showed off their stuff first, and got great press from AMD doesn't give them anything over other developers that make much better and feature full engines. Would like to see CPU tests from UE4 and how it can handle more than what Oxide is doing? Just dl the Elemental tech demo and run it, in Dx12 it has over 3 times the performance on varying resolutions and this was on low end system an i5 that I was testing. The particles and mesh amounts were crazy in that demo, not to mention destructible environments.
As others have shown there were engines using massive amounts of characters, btw characters are much more CPU intensive and GPU intensive, than the ships that Oxide has, this is because triangles are animated, which lighting data has to be recalculated when this happens. Translation, Rotation, Scale of an entire object, the rendering pipeline doesn't need to recalculate all lighting data. And you post about this, each character has to be put into a separate draw call if the animations are not going in sequence, really no way around this, at least from what I have seen. Although I haven't played that game, from what I have seen in the past videos, it seemed that way so the "optimization" of what they did was to sync them seems probable.
Now even Oxide's engine optimizes batches for different hardware configurations. This was talked about with Oxide's dev's when they were on stage taking about Mantle. So again, its all about give and take. A system like this I would suspect has to be tailored to a game, but UE4 this type of system can be done and they are working on it (actually pretty much implemented), it was requested and added to their back long close to a year ago. I have no doubt they can do what Oxide's engine can do from the DX12 demos we have seen so far, the features are in there, just that no one is specially touting them, since there really is no reason to. Come on, Oxide wants to license their engine, their competition is Epic and Crytek, and the others I have mentioned, you think Those companies are afraid Oxide's engine is going to take over their marketshare?
Just a personal impression of AOTS from what I have played so far, I think its interface is clunky, a bit hard to understand in the beginning etc. But I don't know if this is an interface that was built into the engine or separate for the game. So ATM I think its poorly designed doesn't matter if its the game or engine, something should be changed *due to responsiveness of it*
Gamasutra - Press Releases - New 64-bit Cross Platform 3D Engine Announced by Newly Formed Oxide Games
this was the first announcement of the Nitros engine, low level API weren't even out yet for PC's at the time, so Nitros was DX11 and OGl at that time. lets put to bed that Nitros was built from ground up to be DX12. It was ported over well possible rewritten for DX12, just as Epic did for UE4 and Cry Engine 5 too. Just because the others didn't sit there and toot their horns as much as Oxide by showing off a game similar to what Oxide did doesn't mean those features aren't there, we have seen them in demos where they seem to have those same features in abundance.
Last edited:
They wanted to drop DX11 completely from their engine, it was a DX11 and Ogl engine first as it was made prior to any low level API was available for PC in 2013
To add more to what I have stated before, its not all about the API or draw call amounts per mesh either. If a mesh object even though its instanced will drop draw call amounts, if the texture + shader isn't instanced as well, draw calls will increase. Instancing objects, textures and shaders also will increase GPU times while dropping CPU times. AOTS doesn't need to worry about this, as their ships are static meshes and static textures. So there is much more involvement with other types of games and demos UE4 has shown off. The technology is in the engine, just because it doesn't show the exact same amount of objects doesn't mean its not there. Its a platitude expression when you start saying one engine is DX12 over another without looking at all the factors we have thus so far talked about in a contrite fashion.
Things like this is what you can do with DX12
ArtStation - CRYENGINE - Forest Lighting Study #1, Damian Stempniewski
and Cry Engine V and SVOTI, you want to talk about who is pushing DX12 tech to the limits, stuff like this is much more impressive. These were just older assets that come with the engine. Did you see Crytek do a huge press release and set up at a conference and talk about this? No but its in the engine. Just because they don't talk about all their features and what DX12 brings to them, doesn't mean they haven't or arn't thinking about pushing the boundaries of low level API's.
Things like this is what you can do with DX12
ArtStation - CRYENGINE - Forest Lighting Study #1, Damian Stempniewski
and Cry Engine V and SVOTI, you want to talk about who is pushing DX12 tech to the limits, stuff like this is much more impressive. These were just older assets that come with the engine. Did you see Crytek do a huge press release and set up at a conference and talk about this? No but its in the engine. Just because they don't talk about all their features and what DX12 brings to them, doesn't mean they haven't or arn't thinking about pushing the boundaries of low level API's.
Last edited:
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
Code:
https://youtu.be/eXCXJoRsgJc?t=165Oxide ported to Mantle then from Mantle to DX12.
You can choose which words you are using describing an engine which uses DX12 but how does that not have any implications on how well it uses DX12 versus what can already be done in DX11, for me the amount of cores used and the performance scaling well on 8 cores is pretty important that can not be done with DX11.
And I'm not expecting miracles it will take a good amount of time for developers to get there.
So AotS will boast thousands of individual units with individual graphics/textures/deformities/destruction? Because as far as I can see from the early videos and even the benchmark there's nothing that truly wows me. At best a couple hundred units of around 10-15 types. That's a far cry from thousands of individually moving units.
Do you have any videos that show such claims you're making?
Anarchist4000
[H]ard|Gawd
- Joined
- Jun 10, 2001
- Messages
- 1,659
Keep in mind Oxide was one of the companies pioneering development of Mantle. Effectively they would have been one of the first companies to ever see it, including the design phase. AMD Mantle Interview with Oxide Games' Dan Baker This is from Feb 2014 and they were already being crushed from API overhead with a working engine. That would seem to indicate they had an engine capable of pushing a lot of draw calls. It's more likely they started with DX11/OGL, ran into a wall, and literally developed an entirely new graphics API to fix the problem.
I should probably clarify myself. AOTS is the only GAME we've seen so far with a true DX12 engine. There are others in the work, but Hitman and the PC port of ROTTR don't seem to be designed around DX12. Civ:BE or Battlefield with Mantle I'd still consider halfway as the technology was still largely under development.
The big issue with TW was syncing all the animations. Unit sizes were typically <200 with 20 units per side. It could however be modded upwards, but I never tried it. They also used a ton of sprites/2D for most of the units. That's the LoD you see running halfway up the videos. You'll have most of the guys stabbing/slashing air and random guys on the other side following over. They did a good job trying to keep the appearance of randomness, but you would notice if you looked. A lot of the lighting and effects AOTS have aren't there either. Certainly not with the same degree of accuracy.
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
Google: Oxide Nitrous Mantle star swarm ...
In the AMD channel you have some serious footage of the engine in the early stages doing some amazing stuff ..
Why not just post links instead? Is it really that hard to do? If it's so obvious then showing links/videos should be easy, instead of telling me to do it myself, which I might end up finding wrong videos.
Last edited:
- Joined
- Apr 29, 2006
- Messages
- 2,339
First game with Hairworks: COD Ghosts released Nov 5 2013
First game with TressFX: Tomb Raider release Mar 5 2013
JustReason
razor1 is my Lover
- Joined
- Oct 31, 2015
- Messages
- 2,483
Now I am seeing that this Gameworks is the old version. The new version is just as closed as before. Well that seems to be the talk across town.
Pieter3dnow
Supreme [H]ardness
- Joined
- Jul 29, 2009
- Messages
- 6,784
Is it a trick then to get better code in their base and use it for their closed project ?
LOL you have no idea of a GNU/ general licenses works do you? That can't be done that way. And what would they need from outside help right now? Do you see any advantage they need, they seem to be doing fine without help.
Normal causation of older products to go open source when there are better/newer things coming up
Normal causation of older products to go open source when there are better/newer things coming up
Yep. And the bonus is someone smart might make good changes that they can then learn from and optimize in their newer codebase.
I'm not 100% sure how GNU works, but I don't think it covers algorithms, does it?
Sadly this is not true. Algorithms are quite patent-able. This is why most linux systems don't give you mp3 support out of the box.that is correct! Nothing ever covers algorithms
List of software patents - Wikipedia, the free encyclopedia
The GNU system (and free software in general) works by licensing their creations under free/copyleft licenses
Hmm not exactly, the algorithm themselves are not patent-able, and even older patents that did give algorithms patents, never were able to hold up in court. What is patent-able is lets say we take that algorithm and use it for a specific case that hasn't been used before, that can be because of that specific use. I was talking to an entertainment and software patent lawyer about 10 years ago, and this is why patents for software are almost exclusively done in a black box (only high level oversight is ever revealed).