Oversat fra FUTURE OF TRAIN SIMULATOR CLASSIC – DEVELOPER UPDATE

Vi indhenter seniorproducent Steve Dark for at få en opdatering om udviklingsfremskridt for Train Simulator Classic og besvare nogle af dine spørgsmål fra den sidste artikel.

Hej igen alle sammen! Som lovet er jeg her med en opdatering om vores nuværende fremskridt, og da den forrige artikel har rejst alle slags spørgsmål, teorier, ønsker, ønsker og bekymringer, ønskede jeg at komme i gang med at dykke dybere ned i detaljerne og hjælpe besvare spørgsmål og forhåbentlig overvinde eventuelle bekymringer.
Hvis du gik glip af den sidste udvikleropdatering, kan du læse den her.

Forøgelse af hastighed – fase 1

Før jeg kommer til vores nuværende fremskridt, tænkte jeg, at det ville være nyttigt for dig at forstå, hvordan vi går til arbejdet med at forbedre kernen. Vi har i det væsentlige taget vores overordnede vision om softwaren og delt den op i små håndterbare bidder. Hver del repræsenterer en sprint af arbejde med et kort testpas for at sikre, at vi ikke har ødelagt noget, og muligvis en eller flere alfa-builds, som vi giver til vores testere for at gøre de ting, vi ikke kan gøre i et klinisk udviklingsmiljø såsom bare at spille softwaren. Vi kalder disse faser.

Fase 1 handler næsten udelukkende om at rydde op i koden, fjerne overflødige eller ubrugte elementer og opgradere nøgleplugins (afhængige applikationer som Silverlining, OpenAl, PhysX osv.) alt dette med det formål at opgradere til en nyere version af Visual Studio ( den software, vi bruger til at kompilere vores kode til noget, du kan bruge). Nyere versioner af Visual Studio giver bedre compilere, bedre fejlfindingsværktøjer (finde fejl) og bedre profileringsværktøjer (gør mere effektiv kode). I starten af projektet var vi på Visual Studio 2010 (VS2010).

Når du arbejder med en så kompleks kodebase som Train Simulators, kan du desværre ikke bare gå fra VS2010 til den nyeste version af VS2022, fordi du risikerer at ødelægge koden. Det skal opgraderes gradvist, så vi kan sikre, at hver version er ren, før vi går videre til den næste – og med ren mener jeg, at vi skal rydde alle de advarsler og fejl, der bliver markeret af den tidligere version, før vi går videre til Næste. Der er også nogle begrænsninger i, at nogle af de 3. parts plugins, som Train Simulator er afhængige af, ikke kan kompileres forbi en bestemt version af Visual Studio (Scaleform er et klassisk eksempel på en, der ikke kan, siden den blev forældet for et stykke tid siden). Så vi er nødt til at tage det et skridt ad gangen eller en større version ad gangen, de vigtigste versioner er VS2010 > VS2013 > VS2015 > VS2017 > VS2022.

Nuværende fremskridt

I skrivende stund er vi nu på VS2017, og dette har afsløret et væld af nye fejl og advarsler, der ikke var til stede under VS2015. Dette kan forventes og indikerer opgraderinger i kodningspraksis, bedre måder at håndtere ting på osv. Vi mener, at det groft sagte antal fejl var i omegnen af et par tusinde, som alle skulle ryddes op og annulleres.

Vi har fjernet næsten al overflødig kode og fjernet næsten alle overflødige plugins, de eneste, der er tilbage, har en dybere integration i koden, som kræver væsentligt mere tid at fjerne og kan have en funktion et sted, der i øjeblikket er ukendt. Alle relevante plugins såsom OpenAl, Silverlining osv. kører nu alle under VS2017. Vi arbejder nu på den endelige Visual Studio-opgradering til VS2022 klar til implementering af DirectX12-oversættelsen.

Så du spørger måske, hvorfor alt dette er nødvendigt? Nå, det er ret vigtigt, at før vi kan bygge videre på koden og lave forbedringer, skal vi have et solidt fundament, som vi kan bygge ovenpå. Det arbejde, vi har udført indtil nu, handler om at sikre, at enhver mulighed for ustabilitet er blevet minimeret så meget som muligt.

En ting, vi har fundet ud af med det arbejde, vi har udført indtil nu, er, at softwaren er meget mere stabil end den version, du bruger lige nu. Selvom vi vil vente med at fejre den præstation, indtil I alle har haft mulighed for at prøve det.

Før vi går videre til den sidste (spændende) del af denne fase, ændrer vi, hvordan softwaren rapporterer problemer til dig med meget mere information om, hvad den lavede på det tidspunkt, hvor den løb ind i et problem. Dette betyder, at den frygtede “Out of Memory”-fejl vil forsvinde for altid! Det betyder også, at det burde være nemmere at afgøre, hvad der forårsagede problemet, uanset om det var et problem med det indhold, du forsøgte at indlæse, eller noget andet, der skal rapporteres til vores kundesupport. Når dette er afsluttet, skal vi teste, hvor vi er, så det betyder, at vi forbereder en build, som er klar til vores interne testere, så de kan prøve at bryde. Dette aspekt er vigtigt, fordi vi bliver nødt til at rydde eventuelle fejl ud, før vi fortsætter fremad, da 32-bit-udgaven bliver den build, der ikke vil se yderligere opdateringer. Vores arbejde ud over dette vil udelukkende være på 64-bit, da det er der, moderne pc’er er.

Vores næste skridt vil være at begynde at implementere DirectX12-oversættelsesværktøjet. På nuværende tidspunkt har vi ingen idé om, hvad det kommer til at indebære, eller om det vil virke, men vi vil prøve det og se, hvor det bringer os hen. Jeg er sikker på, at I alle vil være spændte på at høre om nyheder om dette, og vi vil vende tilbage så hurtigt som muligt for at opdatere jer. Indtil videre vil DirectX 12-oversættelsen forblive en eksperimentel funktion og leve adskilt fra hovedbygningen. Du bliver derfor nødt til at tilmelde dig det, når det bliver tilgængeligt. Der er en god grund til dette, fordi vi simpelthen ikke har ressourcerne til at teste alt derude, så vi har brug for din hjælp til at afdække eventuelle uønskede virkninger.

Så det er stort set der, vi er lige nu. Vi ser gerne, at du bliver ved med at komme med dine spørgsmål, så bliv ved med at sende dem igennem. Vi forstår, at ikke meget af det, jeg siger her, vil give meget mening, så hvis vi kan hjælpe med at afklare tingene, så lad os det vide.

Dine spørgsmål, teorier, ønsker og bekymringer

Consist Editor

Det er godt at se, at vi alle har vores egne ideer om, hvad ‘forbedring’ betyder for os individuelt, et spørgsmål og emne, jeg har set dukke op flere gange, er, om ting som Consist Editor vil blive rettet med det nærmeste.

Det korte svar er, at det med stor sandsynlighed vil se en form for forbedring, efterhånden som vi bevæger os fremad – snart er et relativt begreb, der kan betyde alt. Hvis du forventer det i næste uge, så vil svaret være nej. Men hvis du mener på et tidspunkt i det næste år, så er svaret sandsynligvis muligt, men det afhænger af flere andre faktorer.

Det lange svar er, set fra vores perspektiv, at der ikke er noget galt med Consist Editor, selvom vi ved, at det forårsager frustration overalt, især for dem, der bruger ommaling (reskins) eller har store indholdsbiblioteker, som den aldrig er designet til at håndtere. Vi ved, at hvis du har meget indhold, kan det være særligt langsom at katalogisere din samling, og du skal gennemgå denne proces, hver gang du bruger det – hvilket ikke er fantastisk. I fase 2 vil vi begynde vores arbejde med indholdsstyringssystemet, og da dette føres direkte ind i Consist Editor, vil det sandsynligvis medføre nogle fordele. Først skal vi dog forstå fra dit perspektiv, hvor Consist Editor ikke lever op til dine forventninger, så vi kan inddrage dette i vores tankegang, mens vi arbejder på det. At få en klar forståelse af, hvorfor du føler, at det ikke virker, samt hvordan du føler, det skal fungere, vil være uvurderlig information for os.

Bagudkompatibilitet

Vi kender et stort område, som folk har været bekymrede over, er, at når vi opgraderer kernen, vil det sandsynligvis ødelægge noget indhold. Det er en helt gyldig bekymring.

Vi har altid været særligt stolte over, at vi har været i stand til at nå så langt, samtidig med at vi har bevaret kompatibiliteten med omkring 95 % af bagkataloget over alt, hvad folk har lavet i løbet af det sidste årti eller mere. Det er noget, vi fortsætter med at tænke på, og vi kan forsikre dig om, at det forbliver fast i fokus, mens vi bevæger os fremad. Bagudkompatibilitet har altid været et kontroversielt emne, og det er hovedårsagen til, at vi har holdt ud med at foretage omfattende ændringer på grund af frygt for at gå i stykker. Men vi har nået et dødvande med TSC, der betyder, at hvis vi ikke gør noget, er det sandsynligt, at du slet ikke længere vil være i stand til at bruge det i en ikke alt for fjern fremtid. Dette arbejde er derfor vigtigt for at sikre, at du kan fortsætte med at bruge dit indhold for evigt.

Vi vil gerne garantere, at vi altid vil have bagudkompatibilitet, men sandheden er, at vi ikke har alle svarene endnu. Nogle ting skal vi prøve først, før vi kan besvare den slags spørgsmål. Vi har en ambitiøs plan, og der er ting, vi ønsker at opnå, men det er helt sandsynligt, at vi når et punkt, hvor vi bliver nødt til at træffe en svær beslutning om, hvordan vi skal komme videre. Vi håber, at vi kan komme til jer alle på det tidspunkt og få jeres syn på, hvordan I synes, vi skal gå videre.

Nogle ting, vi direkte ved, som vil påvirke bagudkompatibiliteten, og som er områder, vi i øjeblikket ikke kigger på, er ting som Fysisk-baseret gengivelse (aka PBR) og en hardkodet DirectX-versionsopgradering (ikke-oversættelse). Vi ved, at disse grundlæggende vil bryde alt i bagkataloget og sandsynligvis vil påvirke arbejdsgangen for alle, der laver indhold til Train Simulator, hvilket gør det meget sværere for folk at lave indhold.

Bagudkompatibilitet er vigtig, og vi hører dine bekymringer, og vi arbejder aktivt på at sikre, at vi forsøger at opretholde dette så meget som muligt, mens vi bevæger os fremad. Der kan være en eller to ting, der kan berettige opmærksomhed, mens vi går, men vi vil se på dem fra sag til sag.

Der er også ting, vi lærer, mens vi går. For eksempel har vi lige erfaret, at vi kan løbe ind i problemer med LUA og vores mål om at opgradere den nuværende version til den nyeste. Det ser ud til, at der er mange ændringer i LUA mellem versioner, og det er muligvis ikke muligt uden at bryde alt. Så dette kan være en af de ting, som vi ikke kan ændre for at bevare bagudkompatibilitet. Vi agter dog stadig at undersøge mulighederne, når vi når dertil, og vi vil selvfølgelig fortælle dig, hvad resultatet af vores undersøgelse er.

Sidste tanker (for nu)

Vi ved, at kerneydelsen måske er et af de vigtigste aspekter af softwaren, som den ser ud i dag – det kommer helt sikkert til at virke som noget, du er mest bekymret over i al den feedback, vi har set til dato. Så vi søger at prioritere dette i den næste udviklingsfase og flytte os et skridt tættere på at yde bedre support til multi-core processorer. I øjeblikket ved vi ikke, hvad dette vil indebære, men vi føler, at dette vil frigøre et stort potentiale i softwaren for alle, så det er værd at forfølge som en prioritet.

Til sidst, før vi melder af, vil vi blot gentage, at hvis du vil bruge DirectX 12 i vores kommende eksperimentelle build, skal du bruge en 64-bit version af Windows 10 eller 11. Desværre er DirectX 12 en funktion, der kun er Windows 10 og 11 og understøttes ikke til Windows 7 eller 8. Dette er helt uden for vores kontrol.

Hvis du har feedback eller spørgsmål om noget herinde, eller den tidligere udviklerartikel, kan du skrive i forumtråden, der er linket til nedenfor. Hold øje med Dovetail Live og vores sociale kanaler for fremtidige opdateringer.