Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Valve-Entwickler: OpenGL-Treiber…

Man muss noch freundlich zu den Treiberentwicklern sein

  1. Thema

Neues Thema Ansicht wechseln


  1. Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: Lord Gamma 13.05.14 - 15:37

    Wenn es genügend Software gibt, die auf OpenGL setzt, dann werden die Treiberentwickler auch gute OpenGL-Treiber entwickeln müssen, ohne dass man freundlich zu ihnen sein muss.
    Das ist ja bei Direct3D auch so, wo bei manchen Spielen gleich Beta-Treiber, Hotfix-Treiber usw. veröffentlicht werden. Und je nachdem, welcher Grafikkartenhersteller da bei der Spieleentwicklung "mithilft", muss der jeweils andere nachbessern. Früher hat meist Nvidia bei der Entwicklung "geholfen", jetzt ist es auch immer öfter AMD, die ihre "Hilfe" zur Verfügung stellen, so dass bei Tomb Raider bspw. Nvidia die Treiber verbessern musste.

  2. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: violator 13.05.14 - 15:41

    Lord Gamma schrieb:
    --------------------------------------------------------------------------------
    > Wenn es genügend Software gibt, die auf OpenGL setzt, dann werden die
    > Treiberentwickler auch gute OpenGL-Treiber entwickeln müssen, ohne dass man
    > freundlich zu ihnen sein muss.

    Und warum ist das nicht schon in den 90ern geschehen, als fast alle 3D-Spiele über OpenGL liefen und zu der Zeit auch besser waren als DX?

    Es gab schliesslich schon den "wenn es genügen Software gibt"-Zeitpunkt...

  3. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: Lord Gamma 13.05.14 - 15:50

    violator schrieb:
    --------------------------------------------------------------------------------
    > Lord Gamma schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wenn es genügend Software gibt, die auf OpenGL setzt, dann werden die
    > > Treiberentwickler auch gute OpenGL-Treiber entwickeln müssen, ohne dass
    > man
    > > freundlich zu ihnen sein muss.
    >
    > Und warum ist das nicht schon in den 90ern geschehen, als fast alle
    > 3D-Spiele über OpenGL liefen und zu der Zeit auch besser waren als DX?
    >
    > Es gab schliesslich schon den "wenn es genügen Software gibt"-Zeitpunkt...

    Es gab damals relativ gute OpenGL Treiber. Quake 3 lief bspw. überall, wo ich es gesehen hab, einwandfrei.

  4. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: xmaniac 13.05.14 - 15:50

    Ich sehe da auch eher eine umgekehrte Erwartungshaltung. Bei Direct3D Programmiert man nach API und wenn es irgendwo läuft müssen die Fehler wohl im Treiber liegen. Die OpenGL API ist eher ein Pralinenkästchen aus ARB und EXT Erweiterungen, ohne das man weiss was man vorfinden wird, und ob die Funktionen nur zur Verfügung stehen oder tatsächlich implementiert wurden. Es gibt kaum nützliche Standardsets auf die man sich verlassen kann, und wenn man sich etwas zusammenbastelt das wirklich überall läuft, kann man die Performance meist vergessen. Viele Dinge sind schon in der Spezifikation nicht genau definiert, wogegen Direct3D einen Referenzrenderer bietet und bis hin zum Subpixelsampling alles genau definiert hat. Aber wenn man das mal in Foren schreibt, kommen all die OpenSource-Fans ohne Ahnung aus Ihren Löchern und fahren einem ohne kompetent zu sein über den Mund. Und am Ende wundert man sich wieder wieso die Profis dann doch lieber Direct3D nutzen so sie können und schiebt es auf eine Monopolstellung von Microsoft... dabei haben die Redmonder wie bei so vielem einfach zuverlässige Softwarequalität - und damit meine ich zuverlässog hoch!



    1 mal bearbeitet, zuletzt am 13.05.14 15:53 durch xmaniac.

  5. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: Crass Spektakel 13.05.14 - 15:54

    violator schrieb:
    --------------------------------------------------------------------------------
    > Lord Gamma schrieb:
    > ---------------------------------------------------------------------------
    > Und warum ist das nicht schon in den 90ern geschehen, als fast alle
    > 3D-Spiele über OpenGL liefen und zu der Zeit auch besser waren als DX?

    Damals ist das so geschehen, denn das damalige OpenGL war relativ schlank und Extensions eher die Ausnahme und DirectX... naja, wie oft wurde DirectX in den 1990ern von Grund auf komplett neu überarbeitet und mit neuer API in den Ring geworfen? Sieben Mal?

    > Es gab schliesslich schon den "wenn es genügen Software gibt"-Zeitpunkt...

    Dem wiederspreche ich. Was ausser Quake 1 und Unreal Tournament gabs denn damals gross? In den 1990ern war die meiste Zeit nicht OpenGL sondern UNIVBE der Standard, wenn nicht gar "Hardwarebanging VGA". Kaum zu glauben, die ersten Windows-Spiele setzten auf GDI und nicht DirectX auf und das lief auch (Total Annihilation z.B.).

  6. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: QDOS 13.05.14 - 16:05

    Crass Spektakel schrieb:
    --------------------------------------------------------------------------------
    > naja, wie oft wurde DirectX in den 1990ern von Grund auf komplett neu überarbeitet und mit neuer API in den Ring geworfen? Sieben Mal?
    Kann hinkommen - in Hinblick auf die heutige OpenGL API war das offensichtlich nicht der schlechteste Ansatz…

  7. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: /mecki78 13.05.14 - 16:19

    xmaniac schrieb:
    --------------------------------------------------------------------------------
    > Bei Direct3D Programmiert man nach API

    Das macht man bei OpenGL auch.

    > Die OpenGL API ist eher ein Pralinenkästchen aus ARB und
    > EXT Erweiterungen,

    Nein, ist sie nicht. Es gibt eine genau definierte Core API und die ist überall gleich. Wenn du Funktionalität nutzt, die nicht Teil der Core API ist, dann ist das dein Problem und dann musst du auch damit leben, dass die nicht überall vorhanden ist oder überall gleich gut funktioniert.

    Der Unterschied ist nur, dass bei OpenGL die Core API eben viel kleiner ist und viel weniger Funktionen hat, eben weil man alles was nicht unbedingt nötig ist auch über optionale Erweiterungen abbilden kann. Da D3D keine solche Erweiterungen hat, muss man hier aber eben alles in die Core API aufnehmen und entsprechend groß ist die Core API.

    Die Folge ist, dass immer nur die neusten Grafikkarten die neuesten D3D Standards unterstützen können, weil die Anforderungen der Core API so hoch sind, dass schon 6 Monate alte Hardware die oft nicht mehr erfüllen kann, während eben bei OpenGL morgen eine neue Core API veröffentlicht wird und selbst 2 Jahre alte Hardware kann die noch erfüllen.

    Dein Problem und das Problem der meisten Spieleentwickler ist, dass die nur das neuste vom Neuen unterstütze wollen und davon ausgehen, dass Spieler sich doch sowieso alle 6 Monate eine neue Grafikkarte kaufen. Man könnte natürlich Spiele so entwickeln, dass sie neuste Hardware ausreizen und zeitgleich aber sich "soweit zurück fahren können", dass sie auch auf 3 Jahre alter Hardware noch recht gut laufen und dennoch nicht wie Dreck aussehen.

    Könnte man... aber das wäre ja Extraarbeit und man hat 2 Mio die man in sinnlose Features stecken kann, die 90% der Spieler nie zu Gesicht bekommen, aber 100'000 um das Spiel auf breite Hardware lauffähig zu machen an denen scheiterst es. Denn als Programmiere kann ich bestätigen: Firmen wollen nur noch Code der äußerlich HUIIII ist, egal wie stark er innerlich PFUIII ist: voller Bugs, voller häßlicher Hacks, zig Codeteile völlig ungetestet oder nur mal schnell angetestet, keine Code Reviews, Sicherheitschecks auch nicht, dann ist das Ding eben ein halber Trojaner, und von Lesbarkeit oder Wartbarkeit will keiner was hören. Hauptsache sieht am Bildschirm geil aus und crashed nicht gleich in der ersten 5 Minuten, dann hat es "Release Qualität".

    /Mecki

  8. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: violator 13.05.14 - 16:37

    Crass Spektakel schrieb:
    --------------------------------------------------------------------------------
    > Dem wiederspreche ich. Was ausser Quake 1 und Unreal Tournament gabs denn
    > damals gross?

    Also HL1 lief unter OGL auch wesentlich besser als DX. Und damit hätten wir schonmal die drei wichtigsten Egoshooter ihrer Zeit genannt.

  9. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: Seitan-Sushi-Fan 13.05.14 - 17:35

    violator schrieb:
    ----------------------------
    > Also HL1 lief unter OGL auch wesentlich besser als DX. Und damit hätten wir
    > schonmal die drei wichtigsten Egoshooter ihrer Zeit genannt.

    Naja, Half-Life nutzt eine modifizierte Quake1-Engine. OpenGL war da ja schon mit dabei. ;-) Den Direct3D-Port gab's doch damals nur, weil Valve noch enge Verbindungen zu Microsoft hatte (Gabe Newell und der andere Valve-Gründer sind ja ehemalige Microsofties).

  10. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: nille02 13.05.14 - 18:39

    Lord Gamma schrieb:
    --------------------------------------------------------------------------------
    > Es gab damals relativ gute OpenGL Treiber. Quake 3 lief bspw. überall, wo
    > ich es gesehen hab, einwandfrei.

    Oder man hat nur entsprechend viel Zeit in in den OpenGL Renderer gesteckt.

  11. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: xmaniac 14.05.14 - 03:03

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > xmaniac schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Bei Direct3D Programmiert man nach API
    >
    > Das macht man bei OpenGL auch.
    >
    > > Die OpenGL API ist eher ein Pralinenkästchen aus ARB und
    > > EXT Erweiterungen,
    >
    > Nein, ist sie nicht. Es gibt eine genau definierte Core API und die ist
    > überall gleich. Wenn du Funktionalität nutzt, die nicht Teil der Core API
    > ist, dann ist das dein Problem und dann musst du auch damit leben, dass die
    > nicht überall vorhanden ist oder überall gleich gut funktioniert.

    Ja, überall gleich Lahmarschig mit gleichwenig Funktionen. Na toll, das schrieb ich doch praktisch so.

    > Der Unterschied ist nur, dass bei OpenGL die Core API eben viel kleiner ist
    > und viel weniger Funktionen hat, eben weil man alles was nicht unbedingt
    > nötig ist auch über optionale Erweiterungen abbilden kann. Da D3D keine
    > solche Erweiterungen hat, muss man hier aber eben alles in die Core API
    > aufnehmen und entsprechend groß ist die Core API.

    Wenn es keine Core API gibt, ist es nur die entsprechende Direct3D API. Fällt dir was auf?

    > Die Folge ist, dass immer nur die neusten Grafikkarten die neuesten D3D
    > Standards unterstützen können, weil die Anforderungen der Core API so hoch
    > sind, dass schon 6 Monate alte Hardware die oft nicht mehr erfüllen kann,
    > während eben bei OpenGL morgen eine neue Core API veröffentlicht wird und
    > selbst 2 Jahre alte Hardware kann die noch erfüllen.

    Nö heißt es nicht. Du kennst dich nicht wirklich mir D3D aus, oder?

    > Dein Problem und das Problem der meisten Spieleentwickler ist, dass die nur
    > das neuste vom Neuen unterstütze wollen und davon ausgehen, dass Spieler
    > sich doch sowieso alle 6 Monate eine neue Grafikkarte kaufen.

    Ziemlicher Unsinn. Das Problem der Spieleentwickler ist das sie nicht ein schier Endloses Set an möglichen Funktionkombinationen unterstützen können. Wenn du nur 16 Funktionen bei OpenGL nimmst, die eventuell unterstützt sind macht das schon 2^16=65536 verschiene Kombinationen. Dagegen sind 10-20 stets aufeinaner aufbauende DX Versionen ein Witz. Und um ältere Grafikhardware noch zu unterstützen reicht ein D3D9 Renderer für praktisch alles. Das ist dann wenn du so willst entsrechend zur OpenGL Core API die Abwärtskompatibilität.

    > Man könnte
    > natürlich Spiele so entwickeln, dass sie neuste Hardware ausreizen und
    > zeitgleich aber sich "soweit zurück fahren können", dass sie auch auf 3
    > Jahre alter Hardware noch recht gut laufen und dennoch nicht wie Dreck
    > aussehen.

    Ja mir Direct3D ist das leicht möglich, einfach eine D3D9 Renderer hinzufügen und für die neuesten Features ein D3D11 Renderer. Mehr braucht man da praktisch nicht um praktisch alle halbwegs taugliche Hardware noch zu unterstützen, und ebenfalls neuere Grafikkarten gut auszureizen. Bei OpenGL kannst du die alten Krücken zwar mit der einer Core API unterstützen, neuere Karten auszureizen wird aber praktisch unmöglich.

    > Könnte man... aber das wäre ja Extraarbeit und man hat 2 Mio die man in
    > sinnlose Features stecken kann, die 90% der Spieler nie zu Gesicht
    > bekommen, aber 100'000 um das Spiel auf breite Hardware lauffähig zu machen
    > an denen scheiterst es.

    Unsin, kehre die Verhältnisse um, dann stimmts etwa von den Kosten. Und trotzdem laufen die Spiele doch auch meist noch auf älterer Hardware. Irgendwann wirds uninteressant - wer nie neue Grafikhardware kauft gibt auch kaum Geld für Spiele aus. Besonders nicht für Spiele die versuchen die alte Hardware noch halbwegs auszureizen.

    > Denn als Programmiere kann ich bestätigen: Firmen
    > wollen nur noch Code der äußerlich HUIIII ist, egal wie stark er innerlich
    > PFUIII ist: voller Bugs, voller häßlicher Hacks, zig Codeteile völlig
    > ungetestet oder nur mal schnell angetestet, keine Code Reviews,
    > Sicherheitschecks auch nicht, dann ist das Ding eben ein halber Trojaner,
    > und von Lesbarkeit oder Wartbarkeit will keiner was hören.

    Komische Bude bei der du da arbeitest. Das sieht bei anspruchsvollen Spieleschmieden sicherlich anders aus.

    > Hauptsache
    > sieht am Bildschirm geil aus und crashed nicht gleich in der ersten 5
    > Minuten, dann hat es "Release Qualität".

    Mach aus 5 Minuten 5 Stunden und füge keine Speicherleaks hinzu. Dann hat ein Spiel releasequalität. Wo ist das Problem? Schon mal engines wie die von UT angesehen? Die skalieren runter bis zu Handys, und unterstützen diverse Renderer. Glaubst du das bekommt man hin wenn der Code innen Pfuii ist? Und trotzdem werden die Jungs entsprechend über OpenGL fluchen, und Direct3D feiern...



    1 mal bearbeitet, zuletzt am 14.05.14 03:11 durch xmaniac.

  12. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: nille02 14.05.14 - 10:23

    Die Erweiterungen und Kombinationsmöglichkeiten sind nicht das eigentliche Probleme. Die Probleme liegt der unterschiedlichen Implementierung das diese oft furchtbar ist.

    Eine Referenzimplementierung und ein Offizielles Piglit mit mehr Tests würde OpenGL gut tun.

    Die Tests für die Hardware Firmen um ihre Implementierung zu überprüfen und die Referenzimplementierung für die Studios. Sollte mal etwas nicht Funktionieren, kann man das noch gegen den Softwarerenderer testen.

    Man könnte sie ja auch, ähnlich wie Mesa3D, auch nutzen um den Hardware Treiber zu nutzen.

  13. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: /mecki78 14.05.14 - 11:48

    xmaniac schrieb:
    --------------------------------------------------------------------------------
    > /mecki78 schrieb:
    > ---------------------------------------------------------------------------

    > Wenn es keine Core API gibt, ist es nur die entsprechende Direct3D API.

    Ich weiß zwar nicht warum du noch einmal zusammenfassen musst, was ich bereits geschrieben hatte, aber ja, bei D3D ist alles Core API, weil dort gibt es eben nur eine Core API.

    > Nö heißt es nicht.

    Doch, heißt es schon und den Beweis dafür lieferst du ja selber ein paar Zeile weiter unten (kommt gleich).

    > Du kennst dich nicht wirklich mir D3D aus, oder?

    Ich finde es immer lustig, dass Foren Poster, die keine Ahnung haben, mit wem sie gerade kommunizieren und die selber oft gar keine Erfahrung auf dem Fachgebiet haben, immer der Meinung sind, sie könnten ihrem Gegenüber erzählen, dass er keine Ahnung von der Materie hat. Typischer Fall von Dunning-Kruger-Effekt.

    > Das Problem der Spieleentwickler ist das sie nicht ein
    > schier Endloses Set an möglichen Funktionkombinationen unterstützen können.
    > Wenn du nur 16 Funktionen bei OpenGL nimmst, die eventuell unterstützt sind
    > macht das schon 2^16=65536 verschiene Kombinationen.

    Genau das ist Unfug und genau das zeigt, dass du von 3D Programmierung überhaupt keine Ahnung hast. Bei den Funktionen, die nicht Teil der Core API sind handelt es sich nicht um "kritische" Funktionen und daher muss du nicht alle Kombinationen aus allen Feature Sets unterstützen.

    Schau, von diesen 16 Funktionen sind z.B. 4 spezielle Arten der Texturfilterung, die die Qualität von verzerrten/gezoomten Texturen verbessern. Wenn ich also eine Textur lade, dann schalte ich alle 4 an, weil das die beste Qualität bringt. Wenn aber nur 3, 2 oder 1 diese Filter existiert, dann schalte ich halt nur die an und wenn keiner existiert, dann schalte ich eben keinen an. Laut deiner Betrachtung muss ich 2^4 = 16 Kombinationen Explizit unterstützen, faktisch hat aber meine Texturladefunktion einfach nur 4 dreizeilige IF Anweisungen.

    Auch ansonsten sind das meistens recht einfache binäre Entscheidungen. z.B. kann es mir eines bestimmte Erweiterung erlauben realistische Schatten zu zeichnen. Wenn die das ist, rufe ich eine Funktion aus, die dem Spieler einen realistischen Schatten gibt und wenn nicht, dann rufe ich eine auf, die einen einfachen "Fake Schatten" zeichnet. Alternativ kann ich auch gar keinen machen wenn die Funktion fehlt, immer nur einen Fake Schatten (stört die meisten Spieler nicht wirklich) oder aber einfach die Funktion voraussetzen, d.h. kann die Grafikkarten oder der Treiber das nicht, dann wird das System gar nicht erst unterstützt (so wie manche Spiele eine Grafikkarte mit X MB RAM voraussetzen, egal welche D3D Version die beherrscht). So hat das Blizzard bei Diablo 3 für Mac gemacht.

    > Ja mir Direct3D ist das leicht möglich, einfach eine D3D9 Renderer
    > hinzufügen und für die neuesten Features ein D3D11 Renderer.

    So, hier schreibst du genau das, was du oben noch verneint hattest. Ich sagte,

    Die Folge ist, dass immer nur die neusten Grafikkarten die neuesten D3D Standards unterstützen können, weil die Anforderungen der Core API so hoch sind, dass schon 6 Monate alte Hardware die oft nicht mehr erfüllen kann

    Wenn ich auf einen alten Rederer Wechseln muss, damit die Karte funktioniert, dann kann sie eben nicht den neusten Standard unterstützen. Genaus das hatte ich doch geschrieben und genau das hattest du weiter oben aber verneint.

    Ich kann auch bei OpenGL auf einen alten Renderer wechseln, gemeint ist hier die Core API, nur zum einen muss man das bei OpenGL seltener, weil eben viel mehr, auch ältere Karten problemlos die neueren Core APIs unterstützen, zum anderen bleiben auch bei einem Core API Wechsel die Extensions erhalten. Statt also ein Spiel zu schreiben, dass OpenGL 4 voraussetzt und dann extra für OpenGL 3.3 Karen einen extra Codepfad zu haben wo auch immer sich die Standards unterscheiden, kann ich mein Spiel gleich nur auf OpenGL 3.3 Basis schreiben, wenn ich auf keine 4er Funktion dringend angewiesen bin und dann aber 4er Funktionen über Extension nutzen, wo sinnvoll und wenn vorhanden, da viele OpenGL 3.3 Karten auch einiges an OpenGL 4 Funktionen über Extension bieten, nur eben nicht alles und daher nicht OpenGL 4 voll unterstützen (was am Treiber aber auch an der Hardware selber liegen kann).

    > Irgendwann wirds uninteressant - wer nie neue Grafikhardware kauft gibt
    > auch kaum Geld für Spiele aus.

    Oder hat z.B. einen Kompaktrechner oder ein Notebook, wo man die Grafikhardware eben nicht wechseln kann und da das Teil 3x teurer war als dein ganzer PC daheim, kann sich eben nicht jeder leisten jährlich ein neues System zu kaufen. Spielekonsolen kommen ja auch nicht jährlich auf den Markt und bieten somit über lange Zeit nur die gleiche, alte Hardware.

    > Komische Bude bei der du da arbeitest.

    Das war bei jeder "Bude" so. Ich spreche hier von Firmen, die Endkundensoftware für den Massenmarkt schreiben. Es ist was anderes wenn du Middleware schreibst, Auftragsarbeiten machst oder an Firmenkunden verkaufst, aber beim Endkundenmassenmark zählt nur noch Time to Market, alles andere ist egal. Und auch OpenSource ist kein Garant für Qualität. Ich kenne genug OpenSource Projekte, deren Code ist so grottenschlecht, so etwas würde ich mich nie trauen irgendwo unter meinen Namen zu veröffentlichen.

    > Glaubst du das bekommt man hin wenn der Code innen Pfuii ist?

    Man bekommt sogar ganze Betriebssysteme hin, die auf zig Mio von Rechnern Weltweit laufen, deren Code massive Pfuii ist. Du hast ja keine Ahnung.

    > Und trotzdem werden die Jungs entsprechend über OpenGL fluchen,
    > und Direct3D feiern...

    ... und sich damit als schlecht organisierte, planlose und höchstens mittelmäßige Programmiere outen bzw. das haben sie schon getan. Hast du schon mal Valve Code gesehen? Also ich meine wirklich durchgesehen, wie bei einem Code Review? Wir haben bei uns Erstsemester Programmierpraktikanten von der Uni, deren Code sieht in etwa vergleichbar aus.

    /Mecki

  14. Re: Man muss noch freundlich zu den Treiberentwicklern sein

    Autor: chrulri 14.05.14 - 18:24

    xmaniac schrieb:
    --------------------------------------------------------------------------------
    > Mach aus 5 Minuten 5 Stunden und füge keine Speicherleaks hinzu. Dann hat
    > ein Spiel releasequalität. Wo ist das Problem? Schon mal engines wie die
    > von UT angesehen? Die skalieren runter bis zu Handys, und unterstützen
    > diverse Renderer. Glaubst du das bekommt man hin wenn der Code innen Pfuii
    > ist? Und trotzdem werden die Jungs entsprechend über OpenGL fluchen, und
    > Direct3D feiern...

    Schonmal was von Battlefield 4 gehört? Time to Marke hat DICE, dank EA und ihrer CoD-phobie, ordentlich den "Release" versaut.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Computacenter AG & Co. oHG, München
  2. Landeshauptstadt Wiesbaden, Wiesbaden
  3. JEMAKO Produktionsgesellschaft mbH, Rhede
  4. TIMOCOM GmbH, Erkrath

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 149,99€ (Release noch nicht bekannt)
  2. 4,16€
  3. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Google Game Builder ausprobiert: Spieldesign mit Karten statt Quellcode
Google Game Builder ausprobiert
Spieldesign mit Karten statt Quellcode

Bitte Bild wackeln lassen und dann eine Explosion: Solche Befehle als Reaktion auf Ereignisse lassen sich im Game Builder relativ einfach verketten. Der Spieleeditor des Google-Entwicklerteams Area 120 ist nicht nur für Einsteiger gedacht - sondern auch für Profis, etwa für die Erstellung von Prototypen.
Von Peter Steinlechner

  1. Spielebranche Immer weniger wollen Spiele in Deutschland entwickeln
  2. Aus dem Verlag Neue Herausforderungen für Spieler und Entwickler

Probefahrt mit Mercedes EQC: Ein SUV mit viel Wumms und wenig Bodenfreiheit
Probefahrt mit Mercedes EQC
Ein SUV mit viel Wumms und wenig Bodenfreiheit

Mit dem EQC bietet nun auch Mercedes ein vollelektrisch angetriebenes SUV an. Golem.de hat auf einer Probefahrt getestet, ob das Elektroauto mit Audis E-Tron mithalten kann.
Ein Erfahrungsbericht von Friedhelm Greis

  1. Freightliner eCascadia Daimler bringt Elektro-Lkw mit 400 km Reichweite
  2. Mercedes-Sicherheitsstudie Mit der Lichtdusche gegen den Sekundenschlaf
  3. Elektro-SUV Produktion des Mercedes-Benz EQC beginnt

WEG-Gesetz: Bundesländer preschen bei Anspruch auf Ladestellen vor
WEG-Gesetz
Bundesländer preschen bei Anspruch auf Ladestellen vor

Können Elektroauto-Besitzer demnächst den Einbau einer Ladestelle in Tiefgaragen verlangen? Zwei Bundesländer haben entsprechende Ergebnisse einer Arbeitsgruppe schon in einem eigenen Gesetzentwurf aufgegriffen.
Eine Analyse von Friedhelm Greis

  1. ACM City Miniauto soll als Kleintransporter und Mietwagen Furore machen
  2. Startup Rivian plant elektrochromes Glasdach für seine Elektro-SUVs
  3. Elektroautos Mehr als 7.000 neue Ladepunkte in einem Jahr

  1. Urheberrecht: Youtuber sollen bei Snippets kein Geld mehr verlieren
    Urheberrecht
    Youtuber sollen bei Snippets kein Geld mehr verlieren

    Bisher konnten Urheber die Einnahmen von Youtubern komplett an sich ziehen, auch wenn diese nur ganz kurze Teile der eigenen Werke übernahmen. Das soll künftig auf Youtube nicht mehr möglich sein.

  2. Einrichtungskonzern: Ikea startet eigenen Geschäftsbereich für Smart Home
    Einrichtungskonzern
    Ikea startet eigenen Geschäftsbereich für Smart Home

    Der Einrichtungskonzern Ikea will mit einem eigenen Geschäftsbereich seine Smart-Home-Produkte voranbringen. Das Unternehmen will damit mehr bieten als nur gewöhnliche Möbel.

  3. Zoncolan: Facebook testet 100 Millionen Zeilen Code in 30 Minuten
    Zoncolan
    Facebook testet 100 Millionen Zeilen Code in 30 Minuten

    Das Entwicklerteam von Facebook hat ein eigenes Werkzeug zur statischen Code-Analyse erstellt und stellt nun erstmals Details dazu vor. Das Projekt habe Tausende Sicherheitslücken verhindert.


  1. 14:34

  2. 13:28

  3. 12:27

  4. 11:33

  5. 09:01

  6. 14:28

  7. 13:20

  8. 12:29