Ich habe meine Compiletools ein wenig geändert (Im SDK umgeschrieben.)
Ich habe die Maxobjs Werte ETWAS erhöht.

Object names Objects/Maxobjs Memory / Maxmem Fullness
------------ --------------- --------------- --------
models 1/400 64/25600 ( 0.3%)
planes 50/32757 1000/655140 ( 0.2%)
vertexes 8/131070 96/1572840 ( 0.0%)
nodes 6/32757 144/786168 ( 0.0%)
texinfos 3/16384 120/655360 ( 0.0%)
faces 6/131070 120/2621400 ( 0.0%)
clipnodes 18/32757 144/262056 ( 0.1%)
leaves 7/16384 196/458752 ( 0.0%)
marksurfaces 6/131070 12/262140 ( 0.0%)
surfedges 24/1024000 96/4096000 ( 0.0%)
edges 13/512000 52/2048000 ( 0.0%)
texdata [variable] 48/16777216 ( 0.0%)
lightdata [variable] 0/16777216 ( 0.0%)
visdata [variable] 0/16777216 ( 0.0%)
entdata [variable] 160/131072 ( 0.1%)

So !

Nun kann ich die Texturen detallierter machen ! Nur jetzt habe ich ein Problem :

Wenn ich die Map mit Licht compile, dann Dauert das ganze vieeel länger als wenn ich die gleiche Map mit den Original Compilern compile.

Ausserdem hängt sich Vis bei der Normal-Option sozusagen auf (wird nie fertig!)

Wer weiss bescheid ? wer kennt sich aus damit ? Ich brauch mal n bissel Hilfe !

ja rate mal, warum der soviel laenger braucht. die maximalwerte sind evtl nicht nur aus den fingern gesaugt.

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Ja, neee, is klaar !

Aber das ganze ist bei beiden Compilern dieselbe Map, Nur der eine braucht länger !

ja. weil er `evtl' `leicht' mehr speicher verwalten muss?

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

Ausserdem bringt es nichts die Limits im Compiler zu erhöhen, denn das sind ja nicht ComplierLimits sondern EngineLimits, an die sich der Complier halt halten muss. Da kann der Complier rühig mit doppelt soviel XYZ-Objekten umgehen können, die Engine kann es dadurch trotzdem nicht. Also ist deine ganze Aktion unnütz.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Hmmm .... SH!T !

Das heisst ich müsste die hl.dll oder die hl.exe umschreiben ?!?!

Edit: Was bei der hl.exe sowieso mist ist, denn dafür habe ich kein SDK ! 8-(

und auch wenn du das SDK hättest, wäre es bestimmt nicht getan, einfach ein paar Definitionen zu erhöhen. Dann hättens sie´s nämlich damals gleich selbst gemacht, die Ventilköppe :P

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

Die Leben von der Vorgabe der Q1 Engine, also hätte man ja auch da erstmal Brainstorming ansetzen müssen. Bedenkt, es war 1996/1997 hehe :D

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Es reicht mir ja total wenn man die Karten so groß bauen kann, wie die Hammer vorgabe dafür ist.
Ich will ja nur Texturen mit höheren auflösungen benutzen ! Aber sobald das Level eine Bestimmte grösse erreicht, dann meldet sich HL mit AllocBlock: Full !
Das liegt an den zu großen Texturen. Deshalb hab ich die Werte mal im Compiler erhöht. Dann war ruhe ! Nur leider war der Compiler nach ner Zeit ZU ruhig. Der wird nämlich nicht mehr fertig !
Normalerweise steigt der RAM-Speicherbedarf ziemlich schnell bei RAD. Aber nach ner Zeit tut sich da garnichts mehr. Warum ?

Das wird deshalb langsamer, weill die Compile Tools mehr Speicher allozieren -> es wird mehr Arbeitsspeicher verwendet als physisch vorhanden -> Paging -> Swap ('Virtueller Arbeitsspeicher') -> geht alles über die HDD -> langsam.

mwcollect - mein Projekt | oxlog - mein blog | happyhardcore.com Stream - gute Musik

Hmmmmm ..... Bei 1,5 Gig Ram ????

Glaub ich net, denn qrad benötigt (laut Taskman.) maximal 450 MB