Cryengine 5.3 får stöd för Vulkan i november

Detta är riktigt lovande nyheter!! Ska köpa alla deras Vulkantitlar bara för att stöda den goda kampen!

Vad jag har läst är att tanken med Metal kontra vulkan för apple är att den är enklare att programmerat till då den tar hand om vissa svårare saker och gör det bekvämare som för bl.a. minneshanteringen. Sen har inte apple några starka gpu:er antar jag som skulle ta nytta av vulkan och samtidigt konkurrera med pc.
Nu vet jag inte exakt hur moltenvk som wrapper fungerar eller presterar, men min fråga är kan det komma eller kommer det att komma någon form av cross platform wrapper, framework, "högre-nivå" språk eller liknande som kan ligga över Vulkan med syfte att kunna programmerar i olika nivåer? Att välja vilka delar man vill optimera närmare hårdvaran och vissa icke prestandakritiska delar att bara låta den "övre bekväma api:n" sköta det.

Jag följer Kingdom Come: Deliverance vilka också kör CryEngine samt har diverse samarbeten med utvecklarna bakom Star Citizen. Hoppas verkligen på bra Vulkanstöd i bägge spelen

CryEngine 5.4 i februari 2017 med stöd för fler grafikkort... AMD Vega bekräftat?

Cloud Imperium Games har moddat CryEngine så mycket att de slutade patcha upp motorn 2015 (har jag för mig). Sen dess har de tittat på ny kod från Crytek och sen gjort egna implementeringar i sin StarEngine. Med tanke på allt galet de gör med den motorn är nog inte Vulkan högst upp på prioritetslistan, men har Crytek gjort det så kan säkert CIG också göra det De har ju en massa ex-Crytekfolk i Tyskland som jobbar på StarEngine så de har kompetensen iaf.

Dom jobbar väl till och med ihop med Crytek?

Mer sådant här och det börjar lukta furyX köp mer och mer!

Jag tror inte att Metal var avsett för MacOS i första hand. Det kom till iOS först. Jag tror att anledningen att det kom till MacOS överhuvudtaget var för att det skulle underlätta för utvecklarna av iOS-spel.

Ja, Apple pajjar verkligen för hela gänget här!

Vad är detta för bakåtsträvande? Nu kan man göra det bättre, om man själv är bättre. Om man är sämre, så kan man göra det sämre.

Innan så har alla kunnat göra det lika kasst. Man kan fortfarande sitta kvar i DX11 eller OpenGL om man inte vill lära sig något nytt och utvecklas. Det är inget som hindrar en!

Vad är det för attityd att klaga på något som möjliggör bättre optimering för de som är grymma på att programmera? Det finns många som vill ha det.

Veckans jeopardy:
A: "För 1000kr väljer jag teknik"
B: "Nu blir det jobbigt för de som inte så duktiga som alla andra. Nu har de som är duktiga möjlighet att göra bättre saker."
A: "Vad är utveckling"
B: "Rätt!"

Hade själv sett att Apple haft officiellt stöd för Vulkan.

Vill man försvara Apple i detta fall kan man notera att Apple faktiskt lanserade Metal först, ungefär ett år innan DX12.

Har inte haft speciellt mycket tid till att själv skriva lite saker mot de olika APIerna, men vad jag läst så känns faktiskt Metal som det API som träffat mest rätt så här långt.

Många är förvånande över hur extremt litet Metal APIet är och hur lätt det är att förstå. Ur ett effektivitetsperspektiv verkar alla tre ligga relativt nära varandra, men ändå ligger Metal på många sätt betydligt närmare DX11 än DX12/Vulkan i hur det hanterar resurser och hur mycket staket det innehåller som hindrar utvecklare att skjuta sig i fötterna.

Däremot är Metal, precis som DX12 och Vulkan, en långt bättre abstraktion av en modern GPU jämfört med DX11 och OpenGL.

D.v.s. Metal verkar redan vara det allt fler verkar säga att DX12/Vulkan måste gå mot då det verkar vara väl komplicerat för de flesta att jobba med DX12/Vulkan (något som i flera fall manifesterar sig i lägre prestanda än med DX11).

Det är bra och uppskattas av dem som behöver det. Dem som behövde det körde också XNA, vilket var ett "lager" ovanpå DX. En förenkling av det API:et (som du säkerligen vet). Och det är sådant som kan finnas för de som inte vill grotta ner sig så mycket.

Jag tycker dock inte man skall tvinga alla att köra med stödhjul på sin cykel, bara för att vissa måste ha det.