Seite 3 von 6
Verfasst: 02.10.2005 19:32
von Kaeru Gaman
@Zeha
das ist im prinzip ähnlich, wie mein vorschlag, die Longs aufzuteilen.
falls du für beide arrays auch longs benutzt, brauchst du doppelt so viel speicher.
so weit ich mitbekommen habe, empfiehlt es sich grundsätzlich longs zu benutzen auf einem 32bit system,
weil die verarbeitung seitens der CPU ein klitzekleines bisschen schneller ist.
das wird wahrscheinlich dadurch ausgeglichen, daß du dann & benutzen mußt.
Verfasst: 02.10.2005 19:44
von ZeHa
Momentan benutze ich Words, weil meine Map wahrscheinlich nie größer als 65536² werden soll

aber die Idee mit dem Aufteilen ist gut!
Verfasst: 02.10.2005 21:07
von MVXA
Man sollte immer Longs verwenden. Mit Words muss der Prozessor erst
hoch rechnen.
Verfasst: 02.10.2005 21:59
von unix
Ihr solltet einen Z Wert mit einbauen.
Weil:
Eine Person im Spiel kann einmal hinter einen Baum sein und vor einen Baum sein kann.
Verfasst: 02.10.2005 22:58
von zigapeda
am besten mit einer structure oder:
ja viel mehr brauch ich ja erstmal nicht.
Verfasst: 02.10.2005 23:11
von PureLust
MVXA hat geschrieben:Man sollte immer Longs verwenden. Mit Words muss der Prozessor erst
hoch rechnen.
Der Meinung war ich auch.
Daraufhin hab ich mal 'ne kleine Testroutine geschrieben und war überrascht, dass der Unterschied doch sehr gering ist (zwischen 1-1.5%).
Selbst Byte-Berechnungen und Mixturen aus verschiedenen Typen haben kaum einen Einfluß auf die Rechenleistung.
Code: Alles auswählen
#Loops = 20000000
DefType.w a1,a2,a3
DefType.l b1,b2,b3,n
DefType.b c1,c2,c3
a2 = 3
a3 = 7
b2 = 3
b3 = 7
t1 = ElapsedMilliseconds()
For n = 1 To #Loops
a1 = a2 + a3
Next n
t2 = ElapsedMilliseconds()
For n = 1 To #Loops
b1 = b2 + b3
Next n
t3 = ElapsedMilliseconds()
For n = 1 To #Loops
c1 = c2 + c3
Next n
t4 = ElapsedMilliseconds()
For n = 1 To #Loops
a1 = b2 + b3
Next n
t5 = ElapsedMilliseconds()
For n = 1 To #Loops
b1 = a2 + a3
Next n
t6 = ElapsedMilliseconds()
For n = 1 To #Loops
b1 = c2 + a3
Next n
t7 = ElapsedMilliseconds()
MessageRequester("Info","Word : "+Str(t2-t1)+Chr(13)+"Long : "+Str(t3-t2)+Chr(13)+"Byte : "+Str(t4-t3)+Chr(13)+Chr(13)+"Long -> Word : "+Str(t5-t4)+Chr(13)+"Word -> Long : "+Str(t6-t5)+Chr(13)+"Byte+Word -> Long : "+Str(t7-t6))
Verfasst: 02.10.2005 23:28
von Zaphod
den z wert brauch man nicht, man sortiert am besten die figuren die auf dem bildschirm zu sehen sind nach ihrer y position auf dem bildschirm (ausgehend von karthesischen koordinaten; 0,0 punkt oben links). die objekte mit den niedrigsten y werten werden zuerst gezeichnet. ich sehe auch nicht, wie da ein z wert helfen könnte; da die figuren sich bewegen müßte man ja trotzdem ständig alles sortieren.
Verfasst: 02.10.2005 23:33
von zigapeda
er meint mit dem z wert wenn ein baum auf einem feld ist und eine figur das wenn die figur einen niedrigeren z wert hat das sie hinter dem baum ist und sonst vor dem baum
Verfasst: 03.10.2005 02:19
von Kaeru Gaman
trotzdem genügt es, objekte nach y zu sortieren..
wenn die objekte verschieden hoch sind, muss man den y-wert des unteren randes nehmen.
z.b.
ein baum steht auf einem tile, die untere y-koordinate sei 203.
wenn jetzt von oben (weiter weg) eine spielfigur kommt, ist sie solange hinter dem baum,
bis ihre untere y-koordinate größer als 203 wird.
Verfasst: 03.10.2005 12:52
von ZeHa
Es kommt nur drauf an, wie die Perspektive ist. Bei so 'ner Top-Down-Perspektive ist das mit der y-Sortierung kein Problem. Auch wenn die Tiles wie Parallelogramme aussehen, geht es. Nur bei 'ner Iso-Perspektive wird's schwierig, da kann man nicht einfach nach y sortieren, da muß man das ein wenig geschickter anstellen
Welche Ansicht hast Du Dir denn vorgestellt?