• Competitor rules

    Please remember that any mention of competitors, hinting at competitors or offering to provide details of competitors will result in an account suspension. The full rules can be found under the 'Terms and Rules' link in the bottom right corner of your screen. Just don't mention competitors in any way, shape or form and you'll be OK.

Behind the scorching beauty of Oxide’s Ashes of the Singularity!

LtMatt

LtMatt

LtMatt

Caporegime
Joined
12 Jul 2007
Posts
42,370
Location
United Kingdom
Thanks to low level API's like Mantle, Directx 12 and Vulkan - We can do things that just weren't possible before. :)

The team at Oxide shows how their upcoming RTS uses AMD’s Mantle to create previously impossible numbers of onscreen effects, bringing an entire space war – not just a battle – to spectacular life.
Click to expand...


https://www.youtube.com/watch?v=t9UACXikdR0
 
Last edited:
Last edited:
I must admit that really does look good, an awful lot of units on the screen at once, with loads of missile trails, very impressive indeed.

One thing that I did notice, and that is not to take anything away from the demo of the tech at all which is very very good. nothing seems to die, I can only assume that is the way that particular demo was coded so that it could be left on a never ending loop. :)
 
Very nice, apart from at 1min 26secs where Richard Huddy says "no current graphics systems can handle more than 8 lights, can it?"

It sounds like he's trying to imply that Mantle is responsible for this, and more than 8 lights wouldn't be possible without it.

I know it's marketing talk, but AMD do themselves no favours with little snippets like this.

And in all fairness afterwards Brad Wardell then says that "as well you can do this on dx12 or on Vulkan", which sets the record straight.
 
All the lights make me want to play SoTS 2. Does look pretty, lets hope the gameplay is good too.

Matt do you know if they plan on doing anything with Trueaudio? Not that I have either Mantle or Trueaudio on my card, but it is something I've been interested in since AMD announced it.
 
humbug said:
Knocking on to 30,000 particles rendered at any given time is vast.... awesome stuff :)
Click to expand...

It does make me wonder how Sup Com did it back in the day I mean this looks great and will no doubt be very efficient compared but you could get similar numbers in a sup com game which came out in 2007. 8000 unit max wasnt it?
 
Nutella33 said:
It does make me wonder how Sup Com did it back in the day I mean this looks great and will no doubt be very efficient compared but you could get similar numbers in a sup com game which came out in 2007. 8000 unit max wasnt it?
Click to expand...

It was around 1000 per side after patches, knocked down from 2000 at launch.

so with 8 a side, it would have be 16000, but the game came to a crawl with only 2000 on a map, the buildings were also included in the unit count. If the fps did not plummet, then the game would go into "Time Dilation" and the entire simulation would slow.

It did not help when the AI would mess up badly.

Cant wait to play games using the new "Low abstraction" API's, would love to see vulkan hit it off, it will be a boost to not only gaming, but also to Industrial software. e.g The Autodesk product line.

I love how he says "This is only a small map" and yet there are 5000 units on it already, pushing who knows how many draw calls from particle effects, etc.
 
Nutella33 said:
It does make me wonder how Sup Com did it back in the day I mean this looks great and will no doubt be very efficient compared but you could get similar numbers in a sup com game which came out in 2007. 8000 unit max wasnt it?
Click to expand...

It was one of if not thie first game to detect Multi core CPU's and then allocate calculations to each core (upto 4)

I'm not entirely sure but i think they used their own higher level extraction layer to achieve that.

Whatever they did its not conventional and it was impressive for the time.

The problem today as it was then is the allocation threading in DX is pretty much fixed, you can allocate AI Calculations to thread 1 and various real time environment entities to thread 2 and 3 and 4 and 5....

If one of those threads starts to pass about 4,000 Draw Calls the hand shake between the CPU thread and GPU starts to get choked up, so it forms a que, which increases latency, if the latency increases then the GPU needs to wait on the CPU, if the GPU needs to wait on the CPU it will have to slow down to allow the CPU to catch up... the end result is your Frame Rates drop.

Threading isn't so much a problem as it is the fact that its fixed, if you have 6.000 Batches on one thread its slowing the system down, the system isn't intelligent enough to move some of those batches to a thread that is only loaded with 800 Batches.

Then there's the extraction layer, the system thats acting as the go between, that system by its self is a massive cause of slowdowns.
Idealy it should be removed entirely so the GPU communicates directly with the CPU "low level"
 
Last edited:
MoodyB said:
Very nice, apart from at 1min 26secs where Richard Huddy says "no current graphics systems can handle more than 8 lights, can it?"

It sounds like he's trying to imply that Mantle is responsible for this, and more than 8 lights wouldn't be possible without it.

I know it's marketing talk, but AMD do themselves no favours with little snippets like this.

And in all fairness afterwards Brad Wardell then says that "as well you can do this on dx12 or on Vulkan", which sets the record straight.
Click to expand...

Good post.
All graphics systems since the fixed function pipeline in ancient Directx/OpenGL hasn't been limited to 8 lights at the API level.

Since shaders came into being, the number of lights are only limited by time and memory constraints.

Different lighting types have different compute times:
Ambient light.
Directional lights.
Point lights.
Spot lights.
etc...

Then you have an objects "surface" or " "material properties" which the lights fall upon:
Diffuse reflection factor.
Specular reflection factors.
Lighting angle against the surface normal.
lots of others...

which will affect the lighting computation time.

TBH, it sounds like all marketing talk, with very little, if any, technical details.
 
Last edited:
You must log in or register to reply here.
Back
Top Bottom