D3D Performance



  • @rapso

    mir ist da gerade noch was aufgefallen.

    dein untergangsscenario ist etwas übertrieben.

    wenn ein fehler auftratt, dann so zu tun als wäre nichts passiert ist ziemlich gefährlich, weil es folgefehler geben kann und am ende hast du ein spiel das nach 20h spiel plötzlich abpfeift und alle savegames dabei löscht... schwer reproduzierbar... und das liegt vielleicht nur daran weil auf der cd irgendwo ein kleiner 'flip im bit' vorgekommen ist den du in der laderoutine vielleicht bemerkt, aber die ganze zeit nicht als fehler behandelt hast

    warum sollte ein spiel alle savegames löschen 😕 nur weil vielleicht ein paar klassen werte zurückgeben, die keinen sinn machen (aus sicht des benutzers)

    wer sowas programmiert, der hat einen sehr üblen programmierstil!!!

    😃


  • Mod

    KXII schrieb:

    @rapso
    deine annahme, das ein programm, welches einige "fehler" nicht behandelt, irgendwann hochfliegt (nach 20h oder so oder wegen falschen bits auf der cd) ist für mich nachvollziehbar, aber nur wenn man sehr schlecht programmiert, und die fehler tatsächlich so betractet werden, als ob sie nie eintreten würden. ausserdem, wie gesagt, meine ich nicht alle, sondern nur die unötigen, sollte man weglassen/ignorieren (nicht ganz ignorieren, sondern nur nichts machen und alles auf default stellen, oder sowas)

    wenn eine datei die länge 0 hat, dann kann man natürlich, wenn man will, ein programm so schreiben, das es abstürtzt, aber wenn man ordentlich programmiert dann sollte das kein problem sein und nie zu fehlern führen. auch falsche werte auf einer cd sind kein problem. man kann ja einfach werte die man ließt auf ihr gültigkeit prüfen und falls sie falsch sind dann einfach die klasse als "not initialized" makieren. ich weiß nicht was daran schwer sein sollte, dies im programmcode umzusetzen. folgefehler sehe ich dann wirklich keine, denn eine gekapselete klasse die load, move und draw hat, macht dann halt einfach nichts und liefert unter umständen für position oder winkel immer 0 zurück egal was man mit dem auto macht. egal ob "load" fehler hat oder sonst was.

    mir ist ein spiel, das bei "fehlern" falsche darstellungen produziert (wie z.b. ein auto das sich nicht bewegt oder nicht sichtbar ist) lieber, als ein programm, das bei jeder kleinigkeit eine msgbox aufpoppt, und dessen programmcode übertrieben viel komplexer und schwerer zu lesen und viel länger und umständlicher zu entwickeln ist. wie gesagt, das weglassen von fehlerbehandlung zwingt nicht automatisch zu folgefehlern, sofern man immer alles überprüft (auch wenn man dann nichts macht, was dazu führt, das es dem benutzer mitgeteilt wird)) und für die ganz wichtigen sachen kann man ja fehlerbehandlung einbauen, sei es mit exceptions oder ohne.

    falls du dem nicht zustimmen kannst dann bring ein konkretes beispiel, wo man erkennen kann, das "leichte" fehler, mit einer "ignorierenfehlerbehandlung" so wie ich es meine, zu nichtreproduzierbaren fehlern führen und das programm zum abturz bringen kann.

    <sarkassmuss>
    du magst also kein spiel dass dir dauernt abpfeift weil etwas nicht vorhanden ist, du mußt also spiele mögen die dich nach studenlangen suchen nach dem 'gral' in den warnsinn treiben, denn da hat dann jemand, so smart wie er ist, keine abfrage dafür eingebaut ob der gral überhaupt geladen wurde und stellt das 'nichts' erfolgreich dar.</sarkassmuss>

    fehlerabfragen sind hauptsächlich für die entwicklung wichtig, nicht fürs finale spiel. irgend ein grafiker schreibt ein script dass eine bestimmte resource benötigt (eines von hunderten scripts), natürlich geht er davon aus dass es läuft, das script wurde vom compiler verifiziert und fertig, dass er eine resource dabei nicht findet bzw. sie deiner "ignorierenfehlerbehandlung" unterliegt und deswegen misst zurückliefert, das kann er ja nicht vorher wissen. vielleicht ändert ja auch jemand die versionsnummer und das script findet die resource dann erst nicht mehr.. aktuelle spiele haben durchaus mehr als 10'000 dateien und dort könnte eine fehlen, sowas ist qualitätstechnisch nicht gut, wenn man es einfach ignoriert.

    im ausgelieferten spiel sollte natürlich keine fehlermeldung wegen fehlender resourcen kommen, dieser fehler wird aber nicht deswegen fernbleiben weil er ignoriert wird, sondern weil vorher mittels fehlermeldungen die qualität gesichert wurde.

    ein konkretes beispiel darf ich dir nicht nennen, aber ich war bei einem Betatest eines grossen publishers dabei und die haben für die deinstallation den subfolder in einer datei gespeichert. ihr resourcemanager hat gross und kleinschreibung beachtet, jemand der das deinstallationstool geschrieben hat aber nicht, er hat also die datei auf platte gesucht, gefunden, wollte sie laden (aber falsche gross und kleinschreibung gehabt), dann hat er den standart path bekommen (sowas wie c:\\programme\) und dann hätte er alles von meinem rechner gelöscht was ich dorthin installiert hätte, ich hatte es zum glück unter d:\\beta\, aber viele viele andere leute durften danach ihren rechner neu installieren.... wegen "ignorierenfehlerbehandlung".
    und dass diese software unsicherwar, das kann man nicht direckt sagen, immerhin hat er erstmal die datei auf platte gesucht gehabt bevor er sie aufmachte... hätte deren resourcesystem eine exception geworfen, wäre das nicht passiert. und aufgefallen ist es denen wohl nicht, weil auf einem testrechner auf dem eh nix anderes installiert ist als deren spiel, wurde es sauber aus dem ordner entfernt (mit der "ignorierenfehlerbehandlung" lief es ja)

    ich hab schon oft erlebt dass leute ein catch(...) eingebaut hatten um einfach festzustellen dass ihre funktion fehlschlug und dann weitermachten, aber es tratten dann folgefehler auf an denen ich oft tagelang nach dem bug suchte.

    um es nochtmal zu sagen, exception und fehlerbehandlung sind für die entwicklung wichtig, nicht für das fertige spiel. und in einem größerem team mit tausenden von resourcen überblickt niemand das komplette projeckt, aber jeder sollte versuchen sich und andere vor fehlern abzusichern, denn je später man einen fehler beheben bzw finden muss, desto höcher ist der aufwand, das steigt mit einer e^x funktion.

    rapso->greets();

    btw: "nur die unötigen, sollte man weglassen/ignorieren"
    da stimm ich dir zu, da stimmt dir jeder zu, der satz klingt aber zu öko 🙂



  • Um nochmal auf das Argument "Ohne Fehlerbehandlung ist der Code viel kürzer und klarer" einzugehen:

    Genau dafür sind Exceptions doch da.

    Objekt * neuesObjekt = erstellMirEinNeuesObjekt();
    neuesObjekt->blablabla();
    

    Würde ich ohne Exceptions arbeiten müßte ich sicherlich prüfen, ob die Funktion nicht 0 zurückgeliefert hat, weil anderenfalls ja der Methodenaufruf schief geht. Insofern ist die Fehlerüberprüfung mehr Aufwand, ja.
    Wenn die Funktion aber so geschrieben ist, daß sie eine Exception wirft, wenn etwas schief geht, dann kann ich mir die Überprüfung sparen, weil ich entweder ein funktionstüchtiges Objekt bekomme, oder ich die gefährliche Codestelle garnicht erreiche.

    Exceptions wurden genau zu diesem Zweck eingeführt, um die Fehlerbehandlung aus dem restlichen Code herauszulösen. Also nicht an jeder Stelle überprüfen, ob alles geklappt hat, sondern immer wenn was schiefgeht ne Exception werfen. Dann brauchen sich keiner der die Funktion benutzt noch Gedanken über Fehlerbehandlung machen.

    MfG Jester



  • @rapso

    ich habe keine lust (wie das früher auch schon oft der fall war) auf deine "seltsamen beispiele" einzugehen. ließ die erst mal den text von anfang an durch, dann wirst du feststellen, das ich gesagt habe, das man nicht vorhandene dateien schon abfragen sollte, weil sowas zu den wichtigen sachen gehört. wenn jetzt aber eine datei die vorhanden ist, nur die länge 0 hat, dann ist das was 99.9999% aller fälle sowieso nicht eintritt, weil der grafiker bestimmt kein 3dobjekt generiert, das eine leere datei hat. (ich weiß man könnte jetzt wieder gegenargumentieren, wenn aber doch, was dann,.... blablabla... das kann man aber immer. ein spiel entwickelt sich und man muss die fehler die enstehen nach und nach eliminieren, und dann weiß man auch grob woran es liegt, wenn ein objekt nicht oder nur teilweise dargestellt wird)

    hier nur ein paar kurze worte zu deinem beitrag:

    a) wenn von 10.000 dateien eine fehlt dann würde ich das natürlich auch bemerken, weils zu wichtigen sachen gehört (wie ich ganz am anfang geschrieben habe).

    im ausgelieferten spiel sollte natürlich keine fehlermeldung wegen fehlender resourcen kommen, dieser fehler wird aber nicht deswegen fernbleiben weil er ignoriert wird, sondern weil vorher mittels fehlermeldungen die qualität gesichert wurde.

    ^^das ist doch lächerlich. meine vorgehenseweise schließt das doch nicht aus (wie oben geschrieben)! und selbst wenn ich es nicht überprüfen würde (wie bei NFSU) was solls. glaubst du etwa ich würde ein spiel ausliefern das nicht getestet wurde??? sowas würde ich dann "blind argumentieren" nennen!

    b) wer ein setup/deinstallationsprogramm schreibt, das einfach ordner samt inhalt löscht, ist selber schuld! sowas nenn ich pfusch, bzw. sowas ist schlecht programmiert und verantwortungslos. besser man erstellt eine datei mit allen dateien samt pfad und löscht nur exakt die die in der datei stehen. wenn sie nicht existiert dann passiert halt nix. im normalfall (99.999% aller fälle) sind die dataien aber da und sie werden gelöscht. ein fehlerscenario wie du es beschreibst kann dann nicht eintreten.

    die dinge, die ich ignoriere, sind sachen die in der entwicklung nie eintreten werden, wie z.b. "out of memory bei new", und die auch beim enduser nie eintreten, weil z.b. gesagt wird das das programm mindestens 150 mb freien arbeitsspeicher braucht. wer dann halt schon seine 1.96 GB ram belegt hat und dann das spiel startet, der hat dann halt eben pech gehabt, weil eine "hauptabfrage" am anfang testet wieviel speicherplatz noch frei ist und wenn es weniger als 150 mb sind dann gibts ne fehlermeldung. jetzt aber beim tatsächlichen reservieren mit "new" zu testen ob noch genug speicherplatz da ist, das macht keinen sinn, da der fall zu 99.932764% (um genau zu sein) nie eintritt. oder wer schafft es nach dem doppelklick auf die spiel.exe noch schnell im hintergrung 150mb ram zu allokieren. das machen doch nur vollidioten! im spiel selber kann man ja auch an verschiedenen stellen nochmals das ram testen, z.b. kurz bevor ein level geladen wird. dann wiederholt sich der fall wie oben beschrieben nocheinmal.

    prinzipiell habe ich den eindruck, du hast gar kein interesse an neuen ideen. ich habe gesagt das man nicht alle fehler ignorieren soll, aber genau das machst du. deine argumente sind ganz spezielle einzelfälle, die man IMMER konstruieren kann. das hat aber mit dem was ich sage nichts zu tun. wenn du spass daran hast jede kleinigkeit zu überprüfen, dann mach es halt! mir ist es lieber, ich habe in 1-2 jahren ein geiles spiel programmiert das unter "standardbedingungen" läuft und das mir und meinen freunden spass bereitet, als ein programm das alle weltuntergangsmöglichkeiten beachtet, aber 20 jahre braucht bis es fertigentwickelt ist; dann aber gibt ja directx 77 und ich muss wieder alles umschreiben :((, das dauert dann wieder 10 jahre, und dann kurz bevor ich fertig bin und noch nie spass mit dem spiel haben durfte, schlägt ein 50-kilometer-durchmesser-komet auf der erde ein und das wars dann!

    also wenn du keine konkreten fälle nennen kannst, die meine vorgehenseweise unter allen umständen als sinnlos wiederlegen, dann lass es gut sein!



  • Du irrst dich. Genau DU brauchst mit deiner Methode 20 Jahre, davon suchst du 19 Jahre nach einem Fehler.


  • Mod

    ja ich hab auch keine lust drüber zu diskutieren,

    falls du dem nicht zustimmen kannst dann bring ein konkretes beispiel, wo man erkennen kann, das "leichte" fehler, mit einer "ignorierenfehlerbehandlung" so wie ich es meine, zu nichtreproduzierbaren fehlern führen und das programm zum abturz bringen kann.

    ch habe keine lust (wie das früher auch schon oft der fall war) auf deine "seltsamen beispiele" einzugehen.

    ich bin immer offen für neue sachen, ich habe keine preferenzen opengl oder d3d gegenüber, ich code pascal/delphi/java/assembler/profan/c#... genau so gern wie c++, ich mag es auf algorithmenebene zu optimieren genau wie auf assembler ebene und ich hab früher auch 'tolleranten' code geschrieben und alleine zu coden war so ok und vielleicht mit 1 oder 2 grafiker zusammen zu arbeiten war so auch ok, denen konnte man mit der zeit vermitteln worauf sie achten müssen.

    ich hab aber gelernt dass es zuviel aufwand beim bereinigen dieser tolleranten fehler gibt. dennn ein fehler bleibt ein fehler bleibt ein fehler und irgendwann möchte jemand dass der fehler weg ist und dann sitzt man lange dran anstatt das problem bei der wurzel zu packen.

    du ließt meine posts midestens so ungenau wie ich deine, aber in deinem lese ich wenigstens wertneutrale aussagen heraus wie "wenn es nicht nötig ist macht man es nicht", "soviel davon dass es ausreicht", ich hab nichts anderes je behauptet.
    das ist auch nicht der unterschied unserer auffasungsgaben. der unterschied ist, dass ich ein programm kontrolliert abbreche sobald ein fehler auftaucht, damit er bereinigt werden kann. du lässt es weiterlaufen. DU weißt was mit deinem coden passieren kann wenn der fehler drinne ist und es weiter läuft, aber wenn du von 10 leuten 'tolleranten' code hast, dann weißt du am ende nicht ob die auftrettenden nebeneffeckte wirkliche bugs sind oder nur durch die 'fehlertolleranz' von deren code verursacht wurden.
    und solange man den fehler nicht fixen muss, wird in der entwicklung jeder den fehler dahinschleifen lassen bis zur masterphase in der man panisch versucht alles auszumerzen und hofft dass jeder noch weiß wo ein 'tolleranter' bug drinne war.

    rapso->greets();



  • bugs können immer enstehen, weil man mal was vergessen hat, egal ob mit ODER ohne fehlerbehandlung. wenn aber eine klasse in AUSNAHMESITUATIONEN 0 zurück gibt oder nichts macht dann ist das kein bug. man muss natürlich immer im hinterkopf haben, das die klasse sich so verhält! wenn man das einfach wegignoriert, dann ist es klar das man sehr lange braucht um rauszufinden wo der fehler liegt. aber sowas ist schidzoooofreeehhhhhhn.

    genauso schidzoooofreeehhhhhhn ist es zitate zusammenhangslos zu bringen.

    wenn ich sage (um dein zitat von mir vollständig anzugeben)

    deine annahme, das ein programm, welches einige "fehler" nicht behandelt, irgendwann hochfliegt (nach 20h oder so oder wegen falschen bits auf der cd) ist für mich nachvollziehbar, aber nur wenn man sehr schlecht programmiert, und die fehler tatsächlich so betractet werden, als ob sie nie eintreten würden. ausserdem, wie gesagt, meine ich nicht alle, sondern nur die unötigen, sollte man weglassen/ignorieren (nicht ganz ignorieren, sondern nur nichts machen und alles auf default stellen, oder sowas)

    dabei meine ich mit "ignorieren", man soll die fehler so behandeln, das die klasse sich neutral verhält. es ist also keine wertneutrale aussage. nur wenn man den satz alleine hinschreibt, dann ja. "nur die unötigen, sollte man weglassen/ignorieren" <- das ist wertneutral, ja, aber das habe ich so nicht geschrieben.


  • Mod

    ein schönes schlusswort


Anmelden zum Antworten