Slowdown vs Ruckeln, der Kampf um die Framerate | SambZockt Show

Wieso hatten Spiele früher Slowdowns wo Ruckeln fürs Gameplay besser gewesen wäre?
Unterstützt mich auf Patreon: / sambzockt
Folgt mir auf Twitter für Up-to-Date Nonesense! / samb_88
Kauft ein BlobCat Plüsch: www.powmediasho...
BlobCat auf...
Nintendo Switch:
www.nintendo.d...
Steam:
store.steampowe...

[@Itama22]

2 Wochen früher und ich hätte damit in der Vorlesung für Spieleprogrammieren klugscheissen können, da hatten wir gerade das Thema :p

[@nichtssagendernickname6931]

Wieder mal danke. Ich fühle mich jedesmal ein wenig schlauer und ein wenig dümmer zu gleich, das schaffen nicht viele. Schönes Wochenende

[@JamesJohnsonFisch]

Zu trocken? Niemals!

[@DerChrizzIX]

Würde nicht direkt sagen, dass es komplett egal ist wie sauber man codet, da es besonders bei größeren Gruppen so zu Verständnisproblemen auf Grund von unsauberen Code kommen kann. Klar wenn man alleine arbeitet ist das Problem sicher nicht so groß aber trotzdem sollte man immer auf sauberen Code achten (wenn auch nicht immer so unfassbar penibel wie manche Internetnasen es behaupten).

[@KogoroMX]

Es bereitet einem halt auf lange Sicht auf jeden Fall Probleme. Wenn man nämlich nach einer gewissen Zeit mal wieder in den Programmcode schauen muss, und diesen selbst nicht mehr versteht, hat man den Salat. Vielleicht ist bei Spielen und "Einmal"-Projekten die Einstellung "Spaghetticode rules" nicht wirklich tragisch, aber es gibt einen Grund, wieso schon unser Informatiklehrer uns eingetrichtert hat, sauber zu kommentieren etc.

[@Fauler420]

@@KogoroMX Ich kann was ihr schreibt nur doppelt unterstreichen :)

[@S4Luux]

@@KogoroMX Wie schon ausführlicher beschrieben, für "mein erstes Spielchen" mag das noch gut gehen, eine Skalierung ist mit schlechtem Code aber unweigerlich eine Katastrophe. Ich halte es für gefährlich, den Leuten selbstbewusst zu erzählen, dass Codequalität egal wäre. Ich habe selber schon genug Erfahrungen mit Leuten im Team, die so dachten...

[@DerChrizzIX]

@@KogoroMX Ja das stimmt. Hab gerade mit meinem Informatikstudium angefangen, bzw. bin jetzt am Ende vom ersten Semester und das erste was einem die Profs reindrücken ist seinen Code sauber zu halten und viel zu kommentieren. Es muss ja nicht mal unbedingt ein großes Projekt sein damit Probleme durch unsauberen Code auftreten können, es reicht ja schon wenn man im Team arbeitet und seinem Gegenüber erklären muss was der Spaghetticode bedeuten soll. Das frisst ja auch Zeit und kann zu weiteren Problemen führen...

[@S4Luux]

@@DerChrizzIX "Der Code ist Dokumentation genug"

[@nilsleusing3487]

ich mag deinen Kontent du bist einer meiner Lieblings KZbinr!

[@Samb]

Freut mich sehr zu hören! Danke :)

[@minishblobby8595]

Stimme dem voll und ganz zu 😊 Freue mich auch immer wenn ich in meiner abobox neues Video sehe

[@dersps5905]

Mir geht es genauso

[@dancle]

Man darf halt nicht vergessen das damals ja nicht aus Spaß auf Gleitkommadatentypen verzichtet wurde, sondern weil die auch ein vielfaches an Speicher gefressen haben. Wenn ich meinen Datentyp ohne Gleitkommazahl in ein halbes Byte (4 Bit) bekomme oder gar mehrere Bytes dafür brauche war schon ein extremer Unterschied, gerade weil man damals ja für alles irgendwelche Variablen genommen hat. Da ist wirklich jedes Byte wertvoll gewesen, eine Gleitkommaberechnung war da einfach nicht drin, abgesehen davon das es vermutlich auch den Ram der Konsole gesprengt hätte. Wieder mal ein sehr interessantes Thema, gefällt mir gut.

[@PhilippHorwat]

Davon abgesehen ist Gleitkommazahlberechnung auch um ein vielfaches komplexer als Integer oder auch Festkommazahlen. Aktuelle Rechner haben meist Schaltkreise in ihrer ALU, die solche Berechnungen in Windeseile machen, früher war das noch eine komplette Funktion mit mehreren Operationen.

[@christophb.453]

Es ist schwierig ein objektives Maß zur Beurteilung von Quellcode zu definieren, daher gibt es wohl verschiedene Maßstäbe mit jeweiligen Prioritäten und Abhängigkeiten von Hardware und verwendeter Sprache. Ich persönlich lege großen Wert auf (leichte) Testbarkeit und entwickel daher bevorzugt funktional. Bei stark IO-lastiger Software, wie z.B. Spiele, ist es daher schwer eine durchweg saubere Programmstruktur zu gewährleisten. Und mit steigender Komplexität erhöht sich auch die Menge an "nicht" vorhersehbaren Seiteneffekten die sich entsprechend als Bugs/Glitches zeigen. Mein Tipp wäre daher, IO so gut es geht von der Kernfunktionalität zu trennen und Methoden/Funktionen stärker zu parametrisieren und/oder mehr Methoden/Funktionen zu erstellen. Dies schließt somit jede Methode/Funktion ohne einen Parameter und/oder Rückgabewert mit ein.

[@BrianM180]

"PAL was a mistake" - European Guy 2020

[@Tom2404]

Pal hat allerdings ne höhere Auflösung. Die wird bloß in portierten Spielen nie genutzt.

[@Confruggy]

@@Tom2404 warum auch, man hätte ja auch ARBEIT investieren müssen, um Spiele von NTSC auf PAL anzupassen. Aufwand, der den meisten Entwickler zu der Zeit nicht wirklich wert war, deswegen man das auch nur für sehr wenige Spiele gemacht hat und wenn, dann auch nur die Geschwindigkeit angepasst hat und nicht die Auflösung.

[@checkerschaf]

Danke für das interessante Video! Leider kann ich dir bei deinem Fazit nicht zustimmen. Klar ist es heutzutage teilweise "egal", ob Code schön und optimiert programmiert wurde, doch besonders in Bezug auf größere Projekte, die in Teams entwickelt werden, muss ich dir da widersprechen. Der GameManager als Beispiel ist der purer Horror für jemanden, der sich den Code zum ersten Mal anguckt. Ich weiß, dass es ausreicht, wenn du dich damit auskennst, jedoch sollte man das ganze differenzierter Betrachten oder du hättest es jedenfalls erwähnen können. Möchtest du einen Bug mehre Monate im Nachhinein beheben oder etwas verändern, dann hast du oftmals den Salat. Das unterscheidet meiner Meinung nach ein richtigen Entwickler und jemanden, der hauptsächlich "skriptet". Auch wenn ich diesen Begriff hasse, aber ich denke du weißt was ich meine. Soll auch nicht böse gemeint sein, aber das ist mir sauer aufgestoßen als Software-Entwickler :D Danke für's Lesen!

[@JoDi2903]

Danke für diese mal wieder sehr interessante Thematik! Du hast alles so anschaulich und verständlich erklärt, dass es zu keiner Zeit trocken wurde. Ich freue mich schon jetzt auf das nächste Video!

[@kiriko3805]

Wieder ein sehr interessantes Thema, dank dir stelle ich mir übrigens Fragen auf die ich selber nicht kommen würde :D Und deine Videos sind auch wunderbar eingängig, z.b. fällt mir immer sofort wenn es um Engines geht sofort das entsprechende Video dazu ein. Ist wie ein persönlicher Samb welcher einem sofort Informationen zu einem Thema gibt :D

[@Samb]

Mini Samb für auf die Schulter packen! Redet über Game Dev, weint über Nintendo und hat ständig hunger! :D

[@mattir6276]

Da sind wir schon zwei nur das ich nicht so viel Ahnung von Video Spiel Entwicklung habe Lachs xd

[@TimAquila]

Sehr interessantes Video, da ich nur wenig von der Thematik wusste und ich demnach viel Neues hören konnte. Ich habe nur mal von diesem Unterschied zwischen PAL und NTSC gehört, weil dies bei Mario Kart Speedruns ein Thema war, wegen uneinheitlichen Timern.

[@SpeckObst]

Slowdown > Ruckeln, da meine Inputs nicht gefressen werden ;P

[@Lythowastaken]

Zum Teil mit dem Code kann ich nur bedingt zustimmen. Code sollte am Ende nicht irgendwie aussehen und Hauptsache es funktioniert. Man sollte schon mit einem Konzept an die Sache rangehen. Das zeichnet einen guten Entwickler auch aus im vergleich zu einem Hobbyscripter. Entwurfsmuster sind z. B. ein guter Punkt. Vor allem wenn man mit mehreren Leuten an einem Projekt arbeitet, macht es keinen Spaß irgendein Code zu lesen und zu warten der einfach dahin geklatscht wurde, aber Hauptsache er funktioniert. Als guter Entwickler wird halt nicht nur Code geschrieben, da gehört nun mal auch Dokumentation etc dazu und testen. Ich weiß auch, dass es anfangs extrem nervt und abschreckt, sich am Ende aber deutlich auszahlt. Man sollte sich einfach merken, klein halten und in kleine schritte planen. Hoffe der Text klingt jetzt nicht zu negativ. weil im Endeffekt ist es ein super Video und im deutschen Raum kann es ruhig mehr davon geben.

[@Samb]

Im Falle von VVVVVV gab es z.b. einen Switch Case mit 400 verschiedenen Fällen. Das ist Müll, das sollte man anders machen. Klar. Aber es war am Ende egal, weil es klappte. Wenn man ständig alles neu gelernte in das aktuelle Projekt einbaut, dann wird man nie fertig. Daher lieber: Fertig machen und beim nächsten Projekt direkt besser. Hätte ich besser ausformulieren können, das stimmt!

[@S4Luux]

@@Samb Nur stammte VVVVVV von einem einzigen Entwickler, von dessen Code nicht die Arbeiten von Teamkollegen abhängig sind. VVVVVV ist auch kein Riesenspiel geworden und programmiertechnisch sind die Mechaniken extrem simpel umzusetzen gewesen.

[@ForceHunterHD]

Ich arbeite nicht in der Spieleindustrie, daher die Frage: Werden da überhaupt Unit-Test, Integrations Test und sowas geschrieben? Weil ich glaube bei dem Punkt unterscheiden sich Spieleentwickler und Business Software Entwickler sehr. Wir versuchen die Software so wartbar wie möglich zu machen und nutzen auch viele Tools (zB Sonarqube) um die Code Quality zubehalten.

[@ZaraStocher]

@@ForceHunterHD Die Antwort auf deine Frage würde mich auch sehr interessieren.

[@Lythowastaken]

@@ForceHunterHD Für meine eigenen Projekte habe ich immer Tests geschrieben. Im Endeffekt ist ein Spiel auch nur ein Stück Software und ich denke, dass je nach Firma auch Tests geschrieben werden. Denn ich glaube nur durch manuelles testen wird keine Software stabil (Wäre vor allem auch ziemlich Teuer ggf.). Selbst kleine Tests, die keinen großen Aufwand bereiten, helfen ungemein. Sei es z. B. nur die Flugkurve eines Objektes oder das Freischalten eines Skills für X-Level. Tests zu entwickeln kann natürlich auch mit viel Zeit verbunden sein. Aber aus eigener Erfahrung kann ich sagen, dass ich schon genug Momente hatte wo ich froh war einen Test gehabt zu haben der mir sagen konnte "ehm, da ist irgendwas nicht ganz richtig". Aber ich glaube durch den Zeitdruck den Spielefirmen oft haben kommen Tests dann zu kurz. Das durften wir dann bei Spielen Assassins Creed Unity erleben. Umso mehr bin ich Froh, dass z. B. CD Project sagt das Cyberpunk verschoben wird obwohl es vom Gameplay her fertig ist, aber sie noch fixen müssen etc.

[@yaboiderrick]

Fand das Video sehr nett. Die Moral am Ende hat mich dazu gebracht, dass ich mal wieder einen Blick in GameMakerStudio werfen will, auch wenn es Chaos und Müllcode ist.

[@max4k0]

Nice. Freue mich immer auf alles was du machst. Das hier interessiert mich auch sehr. ^^

[@MellonSmith]

Sehr cooles und interessantes Video! Die SambZocktShow und die Technik Videos sind einzigartig auf KZbin. Danke!

[@Patrickk0890]

Tolles Video. Gerne mehr davon. Du bringst selbst die trockenen Themen so Interessant rüber wie kaum ein anderer. Mach weiter so.

[@kayselbeyli7360]

Je technischer Du wirst umso besser finde ich es.Auch toll finde ich deine motivierenden Aussagen. Toller Kanal!

[@Turkunjaydee]

Habe tatsächlich nicht so schnell auf dieses Video geklickt wie auf deine anderen aber ich bin, sehr froh es getan zu haben. Super interessantes Video. Gerne mehr davon.

[@Samb]

Mhm das sehe ich in den Statistiken aktuell auch stark. Aber hin und wieder muss so ein Video mal sein, wo mehr Leidenschaft als "Verdienst/Erfolg" hinter steht :)

[@kyagos1839]

Solche Videos gefallen mir auch sehr gut :) Wenn du ein VIdeo machen könntest, wie du Code strukturierst wäre das auch ziemlich cool. Habe selbst mal ein kleines Spiel programmiert, musste aber jedes Mal viel abkupfern, weil ich nicht wusste, wo man was implementieren musste. Ich selbst sehe das Spiel immer bestehend aus folgenden Parts: - Launcher: Verwaltet das wechseln zwischen Infoscreen, 2D-Gui und später das Objekt des Spiels - GameManager: Hier hatte ich i-ein Loop für GameUpdate und habe die verschiedenen Level geladen - GameObjekt: Hier hatte ich ALLE, wirklich alle Gameobjekts definiert - GameEnemy: Hier hatte ich die Eigenschaften eines erstellten GameObjekts aus einer XML Datei (geht das Design hier performanter?) geladen - GamePlayer: Hier hatte ich die Eigenschaften eines erstellten GameObjekts meines Spielers und FriendlyObjects aus einer XML Datei (geht das Design hier performanter?) geladen - Projectiles: Diese musste ich komplett anders behandeln als andere GameObjects, waren im Kern aber GameEnemy-Objects tl;dr: Gehe mit uns bitte einen Code durch mit Charts, wie du ihn aufbauen würdest. Soll kein ganzes Tutorial werden, aber die Übersicht klarer werden lassen für Leute, die ggf. schon programmieren können.

[@Lythowastaken]

Damals als ich mein erstes Spiel entwickelt habe, mein Kollege es testen möchte und er meint, dass das Spiel so viel schneller läuft und ich so lange versucht habe zu verstehen wieso... bis mir jemand dann das mit der deltatime erklärt hat ._.

[@lauramirabelle]

Auch wenn ich null Komma nichts mit diesen Themen zu tun habe, guck ich deine Videos echt gerne. 🤗 ist sehr interessant und man kann dir echt mega gut zuhören. Danke 💕

[@tobibecker5723]

Super coole Videos, mach bitte weiter so!:) Mega interessant und stark erklärt und auch die Themenwahl echt cool

[@masy_mezzetino]

Sehr gutes Video Christian, auf keinen Fall zu trocken!

[@Fauler420]

Gerne mehr von sowas!

[@LINK8543]

Ich fand das Thema mega spannend würde mich mega freuen wenn mehr solche Themen kommen würden.

[@philmarx]

Ich bin kein Spieleentwickler und bin schon bei manchem Video inhaltlich ausgestiegen (und doch immer zu Ende geschaut 😉). Aber dieses Video ist echt gut verständlich und weit weg von "trocken". Mach weiter so. Du hast einen tollen Channel.

[@konigdernoobs3465]

Ich liebe diese Technischen Videos die etwas tiefer gehen. Weiter so bitte🙏

[@Rutanachan]

Ich fand das Thema super interessant! Gerne mehr davon!

[@parzival4980]

Richtig gutes Video! Gerne mehr techniklastige Videos!

[@thewindwaker22]

cooles video mal wieder. Schön mal diese "Grundlagen" kennenzulernen. Ich will zwar zurzeit ein eigenes Spiel entwickeln, aber ich glaube das Programmieren wird ein großes Hindernis werden

[@SyncYu]

Delta Time war mir überraschenderweise sogar kein Fremdbegriff. Habe damals in einem Projektkurs in Informatik mit einem Schulkollegen ein kleines Spiel mit Jump'n'Run Elementen zusammengeschustert. Zuerst war das Projekt zwar abhängig von der Framerate, doch ich habe dann mal mir die Zeit genommen und den Code überarbeitet, damit es unabhängig von der Framerate wurde. Meinem Projektpartner das System zu erklären, war zwar etwas hakelig, aber sobald man diesen „Aha“-Moment hat, ist es gar nicht so schwer.

[@soap3010]

Diese Art der Videos sind mit deine besten. Ich übe mich selbst seit 2 Jahren am coden. Und es gibt einfach so unendlich viele Techniken. Welche alle iwie super interessant sind. Ich kann mir super gut vorstellen. Dass es hier viele gibt. Die zb die ersten egoshooter ala wolfenstein. Wie der 3d Effekt durch raytracing und Mathe gelöst wurde usw. Einfach mega interessant. Und das war nur ein Beispiel aus der Vergangenheit.

[@SynonymBoi]

Gott ich liebe diese Videos zu sehr. Eine Frage, woher kommt dein ganzes Wissen? besteht das immer aus Interesse und darauffolgendem herumgoogeln oder gibt es da einen Beruf den man erlernen kann?

[@motionbasti]

Es gibt auch viele Fachbücher zu verschiedenen Engines. Dort wird dir so ein Grundwissen oft erklärt. Wie halt zb. Delta Time. Was auch Engine abhängig auch mal anders heißen kann. Zb TimeStep.

[@EVILskamp]

Super Video und sehr informativ! Wollte das nur mal sagen.

[@bunte_Katze]

Sehr sehr gutes Video! Danke das du solche Video machst. Da werden noch viele nach uns ihre Freude daran haben 😍

[@roopey]

Ich finde deine Videos sehr interessant. Ich bin selbst auch Entwickler, jedoch aus einem anderen Bereich. Ich habe bisher nur zum Spaß ein paar kleine "Games" entwickelt und finde deine Video daher sehr aufschlussreich. Danke dafür

[@JanLuca1999]

Mega interessant! Bitte mehr davon

[@wildalfred]

Geil. Danke. Das mit der Deltatime hat Potenzial dazu mein Projekt zu verbessern

[@prototypextreme3762]

Ich finde es so unverdient das du so klein bist als KZbinr, denn dein Content ist meiner Meinung nach sehr gut

[@derernstzunehmendeheimwerker]

Gutes Video! Ich freu mich schon aufs nächste Entwicklertagebuch von Foggy Forest :)

[@Morgel_horner]

Noch nie konnte ich den Unterschied zwischen 60 und 30 FPS so gut sehen wie in diesem Video.

[@QuiVidet]

Sehr interessantes und gutes Video :) Top, wie man es von dir gewohnt ist.

[@ThreeMenHousehold]

Ich finde solche Videos echt spannend auch wenn oder vielleicht auch weil ich nicht programmiere! Mein Sohn möchte Programmierer werden und so haben wir beide Interesse daran. Mach doch bitte weiter solche Beiträge. Danke!

[@EinfachWolli]

Ich möchte mehr so welche Videos, Ich finde es zu interessant wie Spiele entwickelt werden und wie die funktionieren :3

[@XXYFilm]

Wow, das war ein richtig gutes Video. Danke dafür

[@leopoldvonwietersheim1212]

Am Ende ist es doch bei jeder (kreativer) Arbeit so, dass die Kulisse gut aussehen soll und der wacklige Teil dahinter nur für einen selbst zählt, Gaffa hält die Welt zusammen :D

[@TarikDaniel]

Klasse Video! Ich hab kaum bis keine Ahnung von Spieleentwicklung. Trotzdem sehr spannend, mal ein paar Hintergründe zu erfahren. Dann weiß ich das nächste mal wenigstens, warum ich fluche, wenn ein Spiel scheiße läuft ;P

[@lordhn6699]

Super video, ich hoffe es kommt mehr in richtung development

[@LetsPain]

War super informativ. Bitte mehr davon.

[@Merkrono]

Für mich war es absolut nicht trocken. Wie fast immer saß ich gespannt vorm Bildschirm und hab jede einzelne Bemerkung aufgesaugt weil es einfach interessant ist. Erneut möchte ich mich für dein tollen Videos bedanken. Falls du das liest würde ich dir obendrein noch gern fragen ob du mal Gothic 1 oder 2 gespielt hast. Für mich sind diesen beiden Spiele (immernoch) der Gipfel der Rollebspiele ^^

[@kugi7611]

Auch ohne Vorkenntnisse gut zu verstehen👍 Klasse video!

[@CEKROM]

12:00 Schöne Moral am Ende =D

[@Blueroyal3]

Ja bitte immer mehr davon. Die Wahrscheinlichkeit das ich mal ein Spiel entwickeln werde geht zwar gegen null, aber ich habe trotzdem freunde daran mehr darüber zu lernen. Ist allgemein praktisch mehr zu wissen, wenn mal wieder alle im Internet ihren Send zu xy dazugeben ohne überhaupt Ahnung zu haben und man sich eigentlich objektiv eine Meinung bilden möchte. Da gabs doch was mit so einen Wissens-Paradoxon: Je mehr man weiß, desto mehr wird einem Bewusst wie wenig man weiß. Frage zum Thema Code: Du hast doch mal erzählt das Sakurai bei Pokémon Gold und Silber den Code „aufgeräumt“ hat und dadurch noch die gesamte Kanto Region drauf gepasst hat. Ist code immer noch so Speicher intensiv oder ist das bei den heutigen Speichermedien kein Problem mehr?

[@deralufe9094]

Sehr schön! Vielen Dank für die Mühe :)

[@CyberFX97]

Super interessantes Video! Jetzt weiß ich auch, warum Unreal den Delta Time Output beim TickEvent hat :D

[@Killutaku]

Als Developer finde ich development-lastigere Videos natürlich immer toll^^ Und wenn man so deine Kommentare durchliest finde ich dass man merkt dass sich auf deinem Kanal auch immer mehr development-affine Personen rumtummeln. Und trotzdem denke ich dass es auch für Nicht-Developer ganz interessant war.

[@xatem093]

hab jetzt zwei plüschis von chris. die sind echt geil =D und das thema mit der zeit ist mal auch richtig interessant. wäre selbst nie darauf gekommen, das das ruckeln und so, von der zeit abhängt

[@FarmerSlideJoeBob]

Wie immer sehr sehr klasse und hochwertig :D

[@TheHeavensPride]

Witzig, wie der erste Teil dieses Videos den gesamten Teil zur Abwärtskompatibilität der Sony/PS5 Pressekonferenz 2 Monate später erklärt. Dort wurde kurz gesagt, dass sie auf Spiele testen müssen, die zB. noch ihre Physikengine an die Framerate gekoppelt haben. Mal wieder top aktuell, nicht schlecht!

[@Racefan81]

Gutes Video, wie immer sehr informativ von Dir. Danke!

[@ultri]

Danke für dieses Video ich bin Programmieranfänger und habe mir manchmal Sorgen gemacht ob mein Programmiercode ordentlich genug ist weil wenn das ein Profi sieht schüttelt er wahrscheinlich nur mit dem Kopf aber dein Statement am Ende fand ich richtig toll und ich hätte gerne noch mehr davon war sehr informativ mit freundlichen Grüßen der verrückte Rollstuhlfahrer

[@Technicellie]

Man kann nichts perfekt machen, allerdings kann man das Beste daraus machen. Wenn dadurch schon etwas Brauchbares entsteht, ist es doch super! Und selbst wenn es besser geht, bedeutet es nicht zwingend, dass es notwendig ist. Das ist die wichtigste Lektion von dem Video für mich.

[@Toxyped]

Finde solche Videos super! weiter so!!!

[@DrLemon-em1ix]

Ich würde mich über mehr Videos zum Thema Technik und Entwicklung freuen, da ich selber Informatik studiere.

[@BurstBlake]

Perfektes Video. Danke.

[@lukasrgl]

War in keinem Fall langweilig! Hab zwar keinen blassen Schimmer von programmieren (außer CNC Programme lol XD), aber finde es immer wieder interessant zu wissen, wie Sachen funktionieren :)

[@nintendoli]

Ach ja. Das Thema, bei dem wohl jeder halbwissende Gamer mit prahlt. Der maximalen Herzzahl, ohne wirklich zu wissen, was das überhaupt ist :D Super Video

[@Starwarsfun1-Leo]

Hab noch nie von Delta-Time gehört; sehr interessantes Thema!

[@kenan-nynor]

Mir sagen solche Sachen nicht, aber ich guck es trotzdem weil es Spaß macht :D

[@JP-dz4ot]

Mega cool

[@wupwupja1498]

Ich mag trocken! Gerne mehr :D

[@Trisumat]

Tolles Video und eine schöne Moral 👍🏼

[@bretzel30000]

Es ist oft so, das man manchmal programm code im nachhinein "häslich" machen muss damit dieser performanter läuft. Ein gutes Beispiel: statische methoden. die "code ästhetiker" werden einem steinigen wenn man static methods macht, aber tatsache ist, static methoden sind schneller. oder wenn wir beim thema unity3d sind, bei c# kann man colllections entweder mit loops durchlaufen (old school) oder nach dem geschmack der "code ästhetiker" mit linq queries manipulieren, aber linq performt wesentlich langsamer als as simple loops.

[@Zyyk0]

Diddy Kong Racing Musik, dafür direkt in den ersten 10 Sekunden ein like

[@Microchaosmac]

Danke für die Infos

[@terrawest9500]

War echt ein seht tolles Video

[@m0nky89]

Wegen der Physiken bei BotW und 60FPS: Man denkt immer, das sei so ein Konsolen-Ding oder kommt halt aus den 90ern... Aber dann kam Bethesda mit Fallout 76 und wieder FrameRate gebundener Logik-Berechnung... xD

[@togorle1749]

Hier ist irgend n Kommentar um den KZbin Algorithmus an zu kurbeln. Sehr Gutes Video und ein genau so guter Kanal

[@svenschmitt7189]

Ich hätte gerne mehr Videos wie dieses 👍👍👍

[@cedescc7986]

Sehr tolles Video, besonders beim letzten Statement bin ich absolut bei dir :D

[@EinfachJuri]

Tolles Video, danke für die Erklärung :D

[@s3uche]

EeeeesistwiederSambZocktZeit! 😍

[@Fabsxh]

Mehr solcher Videos! 🍿🔥❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️❤️

[@jago3798]

Man braucht keine Echtzeituhr, um die Zeit zwischen zwei Bildern zu bestimmen. Im N64 gibt es sehr wohl einen Timer der exakt jeden CPU-Takt zählt. Da man genau weiß, wie viele Takte pro Sekunde vergehen, kann man aus dem Zählwert die vergangene Zeit bestimmen. Diese Art Zeit in Takten zu zählen kommt zudem mit Ganzzahlen aus und man braucht kein Gleitkomma. Man kann mit dem Timer sogar Code per Interrupt zu exakt vorgegebenen Zeiten ausführen. Warum man dennoch kein Delta Time nutze? Keine Ahnung, ich schätze, dass es die Software viel zu kompliziert gemacht hatte und die Spiele dann noch langsamer geworden wären. Es kann auch gut sein, dass andere Konsolen solche Timer nicht hatten (habe mich nur mit dem N64 näher befasst), würde aber jede Wette eingehen, dass alle oder zumindest die meisten Konsolen der fünften Generation einen Hardware Timer hatten. Ansonsten mal wieder ein spannendes Video!

[@Lemstrauss]

Danke für deine Ergänzung. Hab mich schon gefragt, wie man ohne Uhr die Framerate bestimmen kann. Takt zählen, genial einfach. :)

[@MegaManNeo]

Ich denke, Du triffst es mit Deiner Aussage, dass fast jeder Code käsig ist, ziemlich gut auf dem Punkt. Aber auch fand ich es interessant zu erfahren, wie man ein Spiel konstant programmiert. Nur wie sieht das heute in Zeiten von Wiedergaberaten von 144, 240, 288 und 300Hz aus, zumindest für den PC? Muss da nicht mehrfach angepasst werden? Finde das Format trotzdem interessant, also Daumen hoch!

[@staubig]

Moin. Ich wollte nur kurz mal sagen wie toll ich deine Videos finde. Ich kenne niemanden sonst auf KZbin der so ins Detail bei den technischen Aspekten von Spielen eingeht, auch im internationalen Raum fällt mir da auf Anhieb niemand ein. Könnt ihr (als Team) bzw. kannst du als Einzelperson eigentlich von deinen KZbin Einnahmen leben? Ansonsten weiter so wir freuen uns alle über jedes deiner Videos 🥰

[@EnterTheFrayBand]

Schönes Video, Daumen hoch :-)

[@NicoyCaranthir]

Mega interessant, danke für das Tolle Video. Ich persönlich präferiere eher, dass mein Spiel langsamer wird, statt die Ruckler.

[@Yoshi92]

Kollege hat sich damals einen der ersten Zweikerner geholt, dann wollten wir Painkiller spielen und das Game lief einfach auf doppelten Speed, bis wir den 2. Core für das Spiel deaktiviert haben, ging irgendwie im Taskmanager iirc. "What a time to be alive", dachten wir uns 😂😎

[@rkqb]

Sehr geiles Video. Mehr davon :)

[@ll-Labberlippe]

Hallo Also ich ziehe immer wieder meinen Hut vor Deinen Techvideos. Es macht einfach Spass und ist im gegensatz zu div. Content was es bei YT gibt interresant zu sehen was technisch im Hintergrund abläuft. Frage: Hängen eigentlich die Microruckler, welche es gibt, auch in der Richtung zusammen? Könntest in der Richtung auch ein Video zu diesen Thema speziell machen? L.g Gerald

[@Samb]

Microruckler sind was anderes. Aber ja, da könnte man ein gutes Video drüber machen 🤔

[@julianX25]

mich würde noch interessieren wie bugs und glitches entstehen. Übrigens sehr gutes video, mal wieder was dazu gelernt!

[@motionbasti]

Bugs sind im Prinzip "Fehler", die sich beim Programmieren einschleichen, die vom Programmierer so nicht gedacht waren. Glitches sind da ähnlich zu betrachten. Es gibt natürlich viele Möglichkeiten, wie ein Bug entstehen kann. Ich habe aber auch schon gelesen, dass manche Gameplay-Idee'n durch Bugs entstanden sind. Kein Mensch ist perfekt...auch Programmierer nicht. :) Wenn du zb. eine neue Funktion in dein Spiel einbaust, musst du an vieles denken, damit nicht irgendwo wieder was kaputt geht. Je größer so ein Spiel ist, desto schneller passiert das. Und es passiert immer! Eine Analogie wäre zb. wenn du eine riesen Domino Lane aufbaust und mit deinem Hintern schon eine bereits fertige Lane umschubst. ;D

[@Kotentopf]

Ich sage nie "Du musst den Code so und so schreiben!" Sondern "Du solltest ihn so und so machen. Denn ansonsten entspricht er nicht den Coderichtlinien der Firma und deine Commits werden nicht in master übernommen"

[@kyagos1839]

Das, genau das ist auf der einen Seite eine tolle vorgehensweise, auf der anderen aber auch sehr schlecht. Code ist leichter zu lesen, wenn alles einen Einheitlichen Stil verfolgt und die Aufteilung sehr sauber ist. Leider habe ich die Erfahrung sammeln müssen, dass das Motto "so haben wir das schon immer gemacht" sehr oft verfolgt wird. Codestyles vorgegeben von Google und Co. habe ich mir zu Eigen gemacht, was wird in deinem Umfeld praktiziert?

[@ForceHunterHD]

@@kyagos1839 Wir nutzen auch die von Google (Java Codestyle) und nutzen auch die passenden Linting Settings, dass das automatisch gemacht wird.

[@Milplayza]

Ich finde, man sollte seinen Code aufräumen und zumindest kompliziertere Methoden kommentieren. Sollte ein Projekt mal größer werden, ist es wichtig, dass jemand anderes den Code versteht. Man macht es sich auch selbst leichter, wenn man nach einigen Monaten eine Funktionalität hinzufügen will, aber nicht mehr weiß, wie das System eigentlich funktioniert.

[@letsplayprojektorix545]

Bitte mehr von solchen Videos :) Ich nutze die Unreal Engine 4 ^^

[@Shorty99]

Sehr interessantes Video! Weiter so

[@yaise9328]

Ich liebe deinen Kanal!

[@Dome31071989]

Super Video! Mach weiter so :-)