Câte cadre creează PC-ul dvs. la Cologne-Koblenz Show topic; Forumul Zusi
Toate orele sunt UTC + 1 oră
Câte cadre gestionează computerul dvs. în Köln-Koblenz ?
.
Există vreo modalitate de a număra linkurile din fișierele ls, este puțin cam obositor de mână.
Apoi am putut vedea câte fișiere sunt legate în total în modulele ls. Dar sunt estimate aproximativ câteva sute (balustrade, componente catenare, marcaje de platformă etc.).
Am sugerat o dată ceva similar, în care gestionarea obiectelor din Zusi și-a făcut mișcarea, și anume să implementeze gestionarea legăturilor în mod corespunzător în ruta ED, răspunsul de la Carsten a fost foarte clar.
Pentru mine este întotdeauna între 15 și 25 fps.
(2,7 Ghz, placă grafică: ce știu (computerul este din mai 2003)
Pe toate celelalte rute sunt normal la 40 fps, doar cu Kö-Ko scade
rata cadrelor mai mică
(Acest lucru se datorează probabil peisajului bun; aproape credeți că peisajul a fost furat dintr-un alt joc)
Ultima modificare de Marcel Templin la 31 mai 2004 19:07:12, modificată în total de 1 ori.
Așadar, am pus versiunea integrată pe server, o puteți găsi aici.
Atenție: partea are dimensiunea de 16 MB (16.873.794 octeți).
Din păcate, nu devine mai mic. Ar trebui, de asemenea, să menționez că povestea vrea 140 MB de spațiu pe disc.
Am testat odată versiunea integrată pe computerul meu și nu am găsit nicio diferență. Rata cadrelor este absolut aceeași pentru ambele versiuni. B. 10 în Köln Hbf și 18 la semnalul de intrare Kalscheuren. Care poate fi motivul.
Sistemul meu: P 4 cu 2 GHz, Windows XP, 512 MB RAM, placă grafică 64 MB NVIDIA GeForce 3 Ti 200, 4 x AntiAliasing, 1024 x 768. Reglare: vizualizare 2400/2400.
Cu versiunea integrată, frânează 40 de cadre peste tot. Funcționează minunat.
@Stefan: Multumesc pentru efort.
@Holger: Poate că ați copiat ceva greșit sau un alt fișier str, astfel încât fișierul vechi să fie încă folosit?
Creșterea FPS funcționează de minune. Doar rezultatul.
Computerul meu face o mișcare sacadată cam la fiecare 200 de metri, ceea ce este cel mai puternic din Koblenz. O privire asupra informațiilor despre sistem arată că probabil se datorează HDD-ului meu. Deoarece fișierul swap este mândru de 650 MB pe acest traseu. Chiar dacă am 512 MB de memorie RAM 266 DDR. De ce este asta?
În principiu, am folosit metoda lui Stefan, dar am încărcat „* _AllLS-Dateien.ls” în editorul clădirii, am integrat fișierele legate și le-am salvat din nou. (Nu merge în cel mai scurt timp.)
Cu (până acum) 384 MB de memorie principală, nu a fost câștigat niciun ghiveci, deoarece paginarea era în desfășurare. De aici vine probabil bâlbâiala lui Patrick. (Uitați-vă la LED-ul pentru hard disk - ar trebui să fie în mare parte întunecat.)
Apoi i-am dat vechiului meu planer (PIII, 850 Mhz) încă 512 MB de memorie. Cu 768 MB acum, am aproximativ 19 fps în Köln, aproape 30 fps în Bonn și aproape 40 fps pe drum liber. Cu toate acestea, a fost necesară o reducere la 14 fps (în Köln) sau 24 fps (în caz contrar) pentru a evita sunetele tipice (salut Michael). EDIT: Sunetul este la bord cu mine.
La sfârșitul călătoriei de la Köln la Koblenz, rata cadrelor a scăzut la 2 fps, oricare ar fi aceasta. (Să vedem dacă acesta este cazul în fiecare călătorie.)
Ultima modificare de Christian Gründler la 06/01/2004 17:32:51, modificată în total de 1 ori.
Sub Windows, diferitele instrumente fac afirmații diferite despre cât de mare este memoria virtuală necesară, deoarece instrumentele folosesc nume diferite.
Dar acum am reușit să iau o decizie majoritară.
Conform instrucțiunilor lui Ștefan, integrarea și curățarea traseului după încărcarea traseului fără orar necesită sub XP cu 768 MB memorie principală:
- un set de lucru de 393720 KB cu maxim 414828 KB în timpul încărcării;
- o dimensiune virtuală totală de 926408 KB cu un maxim de 1208484 KB în timpul încărcării, din care 390676 KB este proces-privat, nedistribuibil.
Deci, dacă calculați doar paginile private (pe care Managerul de activități le afișează și ca „memorie virtuală” dacă se dorește), atunci aproximativ aceeași dimensiune este stocată în fișierul de pagină, în plus față de zona rezidentă în memorie.
Prin urmare, aș presupune că vor exista probleme grave de swap cu 512 MB de memorie.
În cele din urmă, soluția poate sta doar în tehnologia de încărcare a modulelor individuale oferită de Carsten. Până atunci, te poți descurca cu o forță brutală, desigur că nu este curată sau elegantă.
Carsten a scris:
Am descărcat din nou versiunea integrată, nimic nu s-a schimbat. Am dat fișierului de traseu „vechi” complet un nume diferit. Versiunea integrată este așadar pe computer ca fișier separat. Din păcate, nu acesta poate fi motivul.
Nu aș numi transformarea din peisajul conectat în peisajul integrat „violență brutală”. Și când considerați că accesul pe disc atunci când paginarea încetinește totul, mă întreb, desigur, dacă o reîncărcare programată a secțiunilor de pistă ar duce, de asemenea, la sacadări .
Ultima modificare de Christian Gründler la 06/01/2004 20:14:35, modificată în total de 1 ori.
Experimentele de anul trecut au arătat, așa cum Carsten a subliniat din nou, că ochiurile foarte mari sau foarte mici sunt redate mai puțin eficient decât cele de dimensiuni medii. Cu toate acestea, fără îmbinarea fișierelor .ls, în prezent este practic imposibil să creăm ochiuri mari semnificative pentru numeroasele modele 3D mici, cum ar fi structurile transversale și altele asemenea. Acest lucru este cumpărat cu prețul unor cerințe de memorie mai mari nu numai în fișiere, ci și în timpul rulării pentru ochiuri, deoarece se pierde avantajul de economisire a memoriei de a transforma ochiurile mici în locurile potrivite (plural) numai în momentul redării.
Doar o concluzie de scurtare care ar rezulta din aceasta nu ar fi corectă că ar trebui cumpărată o rată de cadre mai mare cu mai multe cerințe de memorie. În prezent, acest lucru este de facto - presupunând o placă grafică adecvată - dar nu există un motiv inalterabil pentru aceasta. Un alt model de stocare - cuvânt cheie: încărcare modul cu modul - va reduce semnificativ cerința de stocare din nou, fără a renunța la dimensiunile optime ale ochiurilor de plasă.
De aici și remarca mea despre „violență brutală”: Includerea fișierelor ls costă în prezent memorie. Așa că strângeți în memorie până când nu mai este posibil cu o bară. Acest lucru funcționează, dar devine din nou de prisos odată cu introducerea unui nou model de memorie.
Se poate datora și driverului grafic. Mai ales cu nVidia, efectele sunt raportate în mod repetat că rata cadrelor nu este constantă cu diferite versiuni ale driverelor. Anti-aliasing-ul poate avea o altă influență.
Pot confirma creșterile de performanță menționate în acest fir prin integrarea ls pentru driverul 53.03, cu anti-aliasing dezactivat. Cu versiunea actuală 56.72, însă, nu mi s-a întâmplat nimic. (Vă rugăm să nu supraestimați rezultatul. Pot exista motive specifice, în afară de numărul versiunii, pentru care noul driver nu a avut dreptate.
este, de asemenea, oficial documentat în profunzimea paginilor nvidia.
Posibilitatea de a crea dimensiuni efective de ochiuri va scădea cu Zusi 3 (deoarece 2 texturi diferite au întotdeauna nevoie de două ochiuri diferite). Cu toate acestea, ar trebui să fie posibil să se compenseze aceste dezavantaje în acel wg. încărcarea dinamică înseamnă că trebuie calculat mult mai puțin peisaj.
Desigur, taxarea costă și performanță, dar nu există nicio altă șansă. Sper că smucitul nu va fi vizibil, doar că rata cadrelor scade la încărcare.
Deci, ieri seară am muncit din greu. GF 2 Ti ceva mai vechi creează, de asemenea, o creștere semnificativă în principiu, cu cursa mea de 700Mhz din Köln, am aproximativ 15-16 fps în loc de 7 fps anterioare. Dar problema sacadată are un efect grav asupra mea, cu doar 448 MB RAM, iar vechiul meu W98 acționează ca o frână suplimentară pentru distracție. Ei bine, până când achiziționarea de hardware nou este deja planificată, voi rezolva mai întâi versiunea veche care cel puțin rulează constant la un nivel scăzut.
Toate orele sunt UTC + 1 oră
cine e online?
Membrii acestui forum: 0 membri și 1 invitat