Befehlserweiterung für B3D

Übersicht

BlitzBasic

Allgemein

Gehe zu Seite 1, 2 Weiter

	GERMAX Betreff: Befehlserweiterung für B3D	Sa, Okt 30, 2010 1:35 Antworten mit Zitat
Dabei geht es nicht etwa darum, Tesselation bereitzustellen, sondern ein paar nützliche Dinge, die mir schon immer sauer aufstiessen. Aufreger: smap%=smap or %1000 0000 oder:lmap=lmap Or $4000 stattdessen: smap=bset(7,smap) oder:lmap=bset(14,lmap) tack=bclr(3,tack) und bchg=bchg(8,zack) Befehle sind also: BitSet, BitClear, BitChange Werde das Ganze nach purem Gutdünken ausbauen (wobei ich nach Recherche im INET die ganze Sache auf max. SSE3 begrenzen werde, weil das von den allermeisten CPUs unterstützt wird. Wer kein SSE3 hat - naja... Wer noch eine Idee hat, kann sie hier kundtun - dann werde ich mal schauen, ob sich das rentiert mit einzubauen. Die DLL wird dann natürlich in ASS erstellt und auf HSpeed getrimmt.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Betreff: Befehlserweiterung für B3D

Sa, Okt 30, 2010 1:35
Antworten mit Zitat

Dabei geht es nicht etwa darum, Tesselation bereitzustellen, sondern ein paar nützliche Dinge, die mir schon immer sauer aufstiessen.

Aufreger:
smap%=smap or %1000 0000 oder:lmap=lmap Or $4000

stattdessen:
smap=bset(7,smap) oder:lmap=bset(14,lmap)

tack=bclr(3,tack) und bchg=bchg(8,zack)

Befehle sind also: BitSet, BitClear, BitChange

Werde das Ganze nach purem Gutdünken ausbauen (wobei ich nach Recherche im INET die ganze
Sache auf max. SSE3 begrenzen werde, weil das von den allermeisten CPUs unterstützt wird. Wer kein
SSE3 hat - naja...

Wer noch eine Idee hat, kann sie hier kundtun - dann werde ich mal schauen, ob sich das rentiert mit einzubauen.
Die DLL wird dann natürlich in ASS erstellt und auf HSpeed getrimmt.

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Eingeproggt	Sa, Okt 30, 2010 1:42 Antworten mit Zitat
Dass man nicht so direkt mit Bits arbeiten kann hat mich in BB auch schon oft gestört. Allerdings finde ich eine eigene DLL dafür irgendwie auch nicht die Lösung aller Probleme. Wenn man sich an die Anwendung der bitweisen Operatoren (wie in deinem Beispiel or) gewöhnt hat dann ist es wohl nur noch eine stilistische Frage, ob man diesen Ausdruck so haben will oder nicht. Ohne es auch nur ansatzweise getestet zu haben behaupte ich mal dass es außerdem mit DLL nicht schneller sein wird als die BB-nativen Operationen. Hinzu kommt noch, dass du ja keine neuen Befehle bereit stellst sondern nur "unschöne" Codes in einer Funktion ausdrücken willst? mfG, Christoph.
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Sa, Okt 30, 2010 1:42
Antworten mit Zitat

Dass man nicht so direkt mit Bits arbeiten kann hat mich in BB auch schon oft gestört.
Allerdings finde ich eine eigene DLL dafür irgendwie auch nicht die Lösung aller Probleme.
Wenn man sich an die Anwendung der bitweisen Operatoren (wie in deinem Beispiel or

) gewöhnt hat dann ist es wohl nur noch eine stilistische Frage, ob man diesen Ausdruck so haben will oder nicht.
Ohne es auch nur ansatzweise getestet zu haben behaupte ich mal dass es außerdem mit DLL nicht schneller sein wird als die BB-nativen Operationen. Hinzu kommt noch, dass du ja keine neuen Befehle bereit stellst sondern nur "unschöne" Codes in einer Funktion ausdrücken willst?

mfG, Christoph.

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	GERMAX	Sa, Okt 30, 2010 22:14 Antworten mit Zitat
Daß ich den hässlichen code umgehen will, ist absolut korrekt. Natürlich könnte man das auch mit einer function innerhalb bb lösen - aber jetzt behaupte ich einfach mal, dass meine Version schneller ist! Ausserdem werde ich da auch noch Befehle wie result=bsf(player%)-->sucht das 1. gesetzte bit in player (von bit 0 aus) result=bsff(player%)-->sucht das 1. freie bit in player dto result=bsr(player%)-->sucht das 1. gesetzte bit in player (von bit 31 aus) result=bsrf(player%)-->sucht das 1. freie bit in player dto einführen, und das ist dann in bb schon nicht mehr so einfach. Einige andere Sachen würde ich auch gern umsetzten, ist aber sinnlos. zB: h=a:a=b:b=h---->swap(a,b)... Dann werde ich da noch ne' Wurfparabel einbauen. Die kann ich für mein Katapult gut brauchen. Dann wäre da noch die Sache mit der Worldmatrix. Bei diesen cubeengines wird die Landschaft in sections zerlegt, die alle gleich groß sind und bestimmte Positionen einnehmen. Dann wird die Distanz zu diesen sections berechnet, um sie ein oder auszuschalten. Ist die Welt zb 88 groß muss ich also 64 Berechnungen durchführen: dist(camx,camy,camz) Sichtweite wird nicht übertragen, weil das extra vorher gemacht wird. Worldkoord werden vorher generiert. Anschliessend kann man die einzelnen sections mit for.... if MT64(0...63)=true then showentity(bla..) else hideentity(bla..) end if next testen und die entitys steuern. Ich bin mir sicher, dass diese Methode schneller ist. Aber trotzdem werde ich den speed dann testen. Damit die bits alle in ein Register passen, könnte man natürlich noch andere worlds machen (99,1010,1111) (bei 256 bits:bis 16*16) Man kann natürlich auch Bäume usw da reinpacken, weil sich die Standorte ja eh nicht ändern. Und wer weiß, vllt. fällt mir noch was ein.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Sa, Okt 30, 2010 22:14
Antworten mit Zitat

Daß ich den hässlichen code umgehen will, ist absolut korrekt. Natürlich könnte man das auch mit einer function innerhalb bb lösen - aber jetzt behaupte ich einfach mal, dass meine Version schneller ist! Wink

Ausserdem werde ich da auch noch Befehle wie
result=bsf(player%)-->sucht das 1. gesetzte bit in player (von bit 0 aus)
result=bsff(player%)-->sucht das 1. freie bit in player dto

result=bsr(player%)-->sucht das 1. gesetzte bit in player (von bit 31 aus)
result=bsrf(player%)-->sucht das 1. freie bit in player dto

einführen, und das ist dann in bb schon nicht mehr so einfach.

Einige andere Sachen würde ich auch gern umsetzten, ist aber sinnlos.
zB: h=a:a=b:b=h---->swap(a,b)... Sad

Dann werde ich da noch ne' Wurfparabel einbauen. Die kann ich für mein Katapult gut brauchen.

Dann wäre da noch die Sache mit der Worldmatrix. Bei diesen cubeengines wird die Landschaft in sections zerlegt, die alle gleich groß sind und bestimmte Positionen einnehmen. Dann wird die Distanz zu diesen sections berechnet, um sie ein oder auszuschalten. Ist die Welt zb 8*8 groß muss ich also 64 Berechnungen durchführen:

dist(camx,camy,camz)

Sichtweite wird nicht übertragen, weil das extra vorher gemacht wird. Worldkoord werden vorher generiert.

Anschliessend kann man die einzelnen sections mit

for....
if MT64(0...63)=true then
showentity(bla..)
else
hideentity(bla..)
end if
next

testen und die entitys steuern. Ich bin mir sicher, dass diese Methode schneller ist. Aber trotzdem werde ich den speed dann testen. Cool

Damit die bits alle in ein Register passen, könnte man natürlich noch andere worlds machen (9*9,10*10,11*11) (bei 256 bits:bis 16*16)

Man kann natürlich auch Bäume usw da reinpacken, weil sich die Standorte ja eh nicht ändern.

Und wer weiß, vllt. fällt mir noch was ein.

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Thunder	Sa, Okt 30, 2010 23:21 Antworten mit Zitat
Ich behaupte Mal, dass der "hässliche" Code schneller ist und ich würde auf jeden Fall die Version der DLL-Version vorziehen. Aus folgenden gründen: 1) Ich finde Bit-Operationen nicht hässlich 2) Für sowas brauche ich aber wirklich keine DLL 3) Ist es ziemlich sicher langsamer als die Bit-Operation in BB zu schreiben Außerdem: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] ;Statt: smap%=smap Or %10000000 ;geht auch: smap%=smap Or (1 Shl 7) So habe ich auch gleich das Bit, das ich setzen will, direkt im Code. mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Sa, Okt 30, 2010 23:21
Antworten mit Zitat

Ich behaupte Mal, dass der "hässliche" Code schneller ist und ich würde auf jeden Fall die Version der DLL-Version vorziehen. Aus folgenden gründen:
1) Ich finde Bit-Operationen nicht hässlich
2) Für sowas brauche ich aber wirklich keine DLL
3) Ist es ziemlich sicher langsamer als die Bit-Operation in BB zu schreiben

Außerdem:
BlitzBasic: [AUSKLAPPEN]

;Statt:
smap%=smap Or %10000000
;geht auch:
smap%=smap Or (1 Shl 7)

So habe ich auch gleich das Bit, das ich setzen will, direkt im Code.

mfg Thunder

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	GERMAX	So, Okt 31, 2010 2:26 Antworten mit Zitat
Jeder soll nach seiner Fason glücklich werden. Ich würde da zB nie auf die Idee kommen auch noch zu shiften. Und das das shiften schneller sein soll...wird sich zeigen. Und wie soll ich denn zB das 1. 0-bit (v. 0--->31) in smap finden? Ohne Schleife und so...denn der Befehl ist zufällig opcode. Und schneller wirst du das mit shiften (oder was-weiß-ich) nie finden. Völlig unmöglich.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

So, Okt 31, 2010 2:26
Antworten mit Zitat

Jeder soll nach seiner Fason glücklich werden. Smile

Ich würde da zB nie auf die Idee kommen auch noch zu shiften.
Und das das shiften schneller sein soll...wird sich zeigen.

Und wie soll ich denn zB das 1. 0-bit (v. 0--->31) in smap finden?
Ohne Schleife und so...denn der Befehl ist zufällig opcode. Und schneller wirst du das mit shiften (oder was-weiß-ich) nie finden. Völlig unmöglich.

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Lastmayday	So, Okt 31, 2010 12:29 Antworten mit Zitat
also das mit den Bits würde ich so lössen: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] Global getbit1,getbit2,getbit3,getbit4,getbit5,getbit6,getbit7,getbit8 Function decodebits(bit1,bit2,bit3,bit4,bit5,bit6,bit7,bit8) Local byte If bit1 Then byte=byte+1 If bit2 Then byte=byte+2 If bit3 Then byte=byte+4 If bit4 Then byte=byte+8 If bit5 Then byte=byte+16 If bit6 Then byte=byte+32 If bit7 Then byte=byte+64 If bit8 Then byte=byte+128 Return byte End Function Function encodebits(byte) If byte >= 128 Then byte = byte - 128 : getbit8 = True Else getbit8 = False If byte >= 64 Then byte = byte - 64 : getbit7 = True Else getbit7 = False If byte >= 32 Then byte = byte - 32 : getbit6 = True Else getbit6 = False If byte >= 16 Then byte = byte - 16 : getbit5 = True Else getbit5 = False If byte >= 8 Then byte = byte - 8 : getbit4 = True Else getbit4 = False If byte >= 4 Then byte = byte - 4 : getbit3 = True Else getbit3 = False If byte >= 2 Then byte = byte - 2 : getbit2 = True Else getbit2 = False If byte >= 1 Then byte = byte - 1 : getbit1 = True Else getbit1 = False End Function Local mybyte = decodebits(True,False,True,False,True,False,True,False) Print mybyte encodebits(mybyte) Print getbit1+":"+getbit2+":"+getbit3+":"+getbit4+":"+getbit5+":"+getbit6+":"+getbit7+":"+getbit8 WaitKey() wobei ich jetzt nicht weiß ob das auch die richtigen bit = byte umwandlungen sind. :/

Lastmayday

So, Okt 31, 2010 12:29
Antworten mit Zitat

also das mit den Bits würde ich so lössen:

BlitzBasic: [AUSKLAPPEN]

Global getbit1,getbit2,getbit3,getbit4,getbit5,getbit6,getbit7,getbit8

Function decodebits(bit1,bit2,bit3,bit4,bit5,bit6,bit7,bit8)
	Local byte
	If bit1 Then byte=byte+1
	If bit2 Then byte=byte+2
	If bit3 Then byte=byte+4
	If bit4 Then byte=byte+8
	If bit5 Then byte=byte+16
	If bit6 Then byte=byte+32
	If bit7 Then byte=byte+64
	If bit8 Then byte=byte+128
	Return byte
End Function

Function encodebits(byte)
	If byte >= 128 Then byte = byte - 128 : getbit8 = True Else  getbit8 = False
	If byte >= 64 Then byte = byte - 64 : getbit7 = True Else  getbit7 = False
	If byte >= 32 Then byte = byte - 32 : getbit6 = True Else  getbit6 = False
	If byte >= 16 Then byte = byte - 16 : getbit5 = True Else  getbit5 = False
	If byte >= 8 Then byte = byte - 8 : getbit4 = True Else  getbit4 = False
	If byte >= 4 Then byte = byte - 4 : getbit3 = True Else  getbit3 = False
	If byte >= 2 Then byte = byte - 2 : getbit2 = True Else  getbit2 = False
	If byte >= 1 Then byte = byte - 1 : getbit1 = True Else  getbit1 = False
End Function



Local mybyte = decodebits(True,False,True,False,True,False,True,False)
Print mybyte

encodebits(mybyte)
Print getbit1+":"+getbit2+":"+getbit3+":"+getbit4+":"+getbit5+":"+getbit6+":"+getbit7+":"+getbit8

WaitKey()

wobei ich jetzt nicht weiß ob das auch die richtigen bit = byte umwandlungen sind. :/

user posted image

	Thunder	So, Okt 31, 2010 18:30 Antworten mit Zitat
GERMAX hat Folgendes geschrieben: Und wie soll ich denn zB das 1. 0-bit (v. 0--->31) in smap finden? Also, wenn ich deine Frage richtig verstanden habe, ist meine Antwort: Eine DLL kann das auch nicht ohne Schleife. Für sowas ist zwar eine Funktion besser, aber ne DLL lohnt sich dafür imho trotzdem nicht. GERMAX hat Folgendes geschrieben: Ich würde da zB nie auf die Idee kommen auch noch zu shiften. Und das das shiften schneller sein soll...wird sich zeigen. ich denke schon, dass es schneller ist, denn im Endeffekt musst du in deiner bset-Funktion auch shiften mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

So, Okt 31, 2010 18:30
Antworten mit Zitat

GERMAX hat Folgendes geschrieben:

Und wie soll ich denn zB das 1. 0-bit (v. 0--->31) in smap finden?

Also, wenn ich deine Frage richtig verstanden habe, ist meine Antwort: Eine DLL kann das auch nicht ohne Schleife. Für sowas ist zwar eine Funktion besser, aber ne DLL lohnt sich dafür imho trotzdem nicht.

GERMAX hat Folgendes geschrieben:

Ich würde da zB nie auf die Idee kommen auch noch zu shiften.
Und das das shiften schneller sein soll...wird sich zeigen.

ich denke schon, dass es schneller ist, denn im Endeffekt musst du in deiner bset-Funktion auch shiften Wink

mfg Thunder

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	ToeB	So, Okt 31, 2010 18:56 Antworten mit Zitat
So könnte man es auch machen btw Code: [AUSKLAPPEN] [EINKLAPPEN] Const Bits = 7 Global glBits[ Bits ] Function SetBits( tmpBits[ Bits ] ) Local Byte = 0 For i = 0 To Bits If tmpBits[ i ] Then Byte = byte + ( 2^i ) Next Return byte End Function Function GetBits( Byte ) For i = Bits To 0 Step -1 tmpI = 2^i If Byte >= tmpI Then glBits[ i ] = 1 : Byte = Byte - tmpI : Else : glBits[ i ] = 0 Next End Function SeedRnd MilliSecs() For i = 0 To Bits glBits[ i ] = Rand( 0, 1 ) Next Local tmpBits = SetBits( glBits ) Print tmpBits GetBits( tmpBits ) Local tmpR$ = "" For i = 0 To Bits tmpR$ = tmpR + Str( glBits[ i ] ) Next Print tmpR WaitKey() End() mfg ToeB
Religiöse Kriege sind Streitigkeiten erwachsener Männer darum, wer den besten imaginären Freund hat. Race-Project - Das Rennspiel der etwas anderen Art SimpleUDP3.0 - Neuste Version der Netzwerk-Bibliothek Vielen Dank an dieser Stelle nochmal an Pummelie, welcher mir einen Teil seines VServers für das Betreiben meines Masterservers zur verfügung stellt!

ToeB

So, Okt 31, 2010 18:56
Antworten mit Zitat

So könnte man es auch machen btw Cool

Code: [AUSKLAPPEN]

Const Bits = 7
Global glBits[ Bits ]

Function SetBits( tmpBits[ Bits ] )
Local Byte = 0
For i = 0 To Bits
   If tmpBits[ i ] Then Byte = byte + ( 2^i )
Next
Return byte
End Function

Function GetBits( Byte )
For i = Bits To 0 Step -1
   tmpI = 2^i
   If Byte >= tmpI Then glBits[ i ] = 1 : Byte = Byte - tmpI : Else : glBits[ i ] = 0
Next
End Function

SeedRnd MilliSecs()
For i = 0 To Bits
glBits[ i ] = Rand( 0, 1 )
Next
Local tmpBits = SetBits( glBits )
Print tmpBits
GetBits( tmpBits )
Local tmpR$ = ""
For i = 0 To Bits
tmpR$ = tmpR + Str( glBits[ i ] )
Next
Print tmpR

WaitKey()
End()

mfg ToeB

Religiöse Kriege sind Streitigkeiten erwachsener Männer darum, wer den besten imaginären Freund hat.
Race-Project - Das Rennspiel der etwas anderen Art
SimpleUDP3.0 - Neuste Version der Netzwerk-Bibliothek
Vielen Dank an dieser Stelle nochmal an Pummelie, welcher mir einen Teil seines VServers für das Betreiben meines Masterservers zur verfügung stellt!

	GERMAX	Mo, Nov 01, 2010 18:16 Antworten mit Zitat
Also bitte Ich habe mir eure Versionen mal so oberflächlich angeguckt, ohne zu prüfen ob dass so funktioniert. Das Ganze in eine function zu packen ist ganz böse-das kann nie schnell werden. @Thunder Was sagst du denn dazu: MyBsf proc wdata:DWORD bsf eax,wdata ;kann auch- bit 0 sein, deshalb z-flag berücksichtigen---->eax=-1 ret ;könnte man evtl noch etwas beschl. MyBsf endp Das Einzige, was da noch fehlt, ist was im comment steht. Und wo ist da genau jetzt die Schleife? Da kannst du ein E-Mikroskop bemühen und wirst keine finden Eure Versuche, so Funktionen mit Bordmitteln zu beheben sind -was den speed angeht- zum Scheitern verurteilt.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Mo, Nov 01, 2010 18:16
Antworten mit Zitat

Also bitte Smile

Ich habe mir eure Versionen mal so oberflächlich angeguckt, ohne zu prüfen ob dass so funktioniert.
Das Ganze in eine function zu packen ist ganz böse-das kann nie schnell werden.

@Thunder
Was sagst du denn dazu:

MyBsf proc wdata:DWORD
bsf eax,wdata ;kann auch- bit 0 sein, deshalb z-flag berücksichtigen---->eax=-1
ret ;könnte man evtl noch etwas beschl. Smile

MyBsf endp

Das Einzige, was da noch fehlt, ist was im comment steht. Und wo ist da genau jetzt die Schleife? Da kannst du ein E-Mikroskop bemühen und wirst keine finden Wink

Eure Versuche, so Funktionen mit Bordmitteln zu beheben sind -was den speed angeht- zum Scheitern verurteilt. Smile

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	BladeRunner Moderator	Mo, Nov 01, 2010 18:20 Antworten mit Zitat
Also ich habe mirt den BB-Bordmitteln noch alles soweit gelöst bekommen. Du feilschst um Millisekunden wo es nicht nötig ist. Wenn Du ein Programm hättest was wirklich MASSIV Gebrauch von solchen Bitspielereien macht, dann wäre eine Erweiterung vielleicht sinnvoll, aber wenn es wirklich was zeitkritisches wäre würde ich mir eh überlegen es in was anderem als einem beginnerfreundlichen Einsteigerdialekt zu verfassen.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mo, Nov 01, 2010 18:20
Antworten mit Zitat

Also ich habe mirt den BB-Bordmitteln noch alles soweit gelöst bekommen. Du feilschst um Millisekunden wo es nicht nötig ist.
Wenn Du ein Programm hättest was wirklich MASSIV Gebrauch von solchen Bitspielereien macht, dann wäre eine Erweiterung vielleicht sinnvoll, aber wenn es wirklich was zeitkritisches wäre würde ich mir eh überlegen es in was anderem als einem beginnerfreundlichen Einsteigerdialekt zu verfassen.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	GERMAX	Mo, Nov 01, 2010 18:30 Antworten mit Zitat
@Bladerunner Ich habe ja nicht behauptet, das man es mit Bordmitteln nicht hinbekommt. Es ist nur langsam, also etwas was ausser dir offensichtl. noch keiner realisiert hat (zumindest von den Beitragsschreibern hier im Thema). Zum Thema Bitspielereien. Was soll man dazu sagen? Vllt., dass es keine Spielerei ist? tztz... Nee, ich feilsche nicht um Millisekunden, sondern um FPS- das ist was ganz anderes.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Mo, Nov 01, 2010 18:30
Antworten mit Zitat

@Bladerunner

Ich habe ja nicht behauptet, das man es mit Bordmitteln nicht hinbekommt. Es ist nur langsam, also etwas was ausser dir offensichtl. noch keiner realisiert hat (zumindest von den Beitragsschreibern hier im Thema).

Zum Thema Bitspielereien. Was soll man dazu sagen? Vllt., dass es keine Spielerei ist? tztz...

Nee, ich feilsche nicht um Millisekunden, sondern um FPS- das ist was ganz anderes.
Idea

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	BladeRunner Moderator	Mo, Nov 01, 2010 18:38 Antworten mit Zitat
Ob Du es Miilisekunden oder Frames pro Sekunde nennst bleibt sich gleich. (Wobei der FPS-Wahn meines erachtens nach recht übertrieben ist.) Und OR, AND und Konsorten sollten eigentlich sehr zügig laufen, da sie vom BB-Compiler aller Voraussicht nach sehr low-Level umgesetzt werden. Ich bezweifle dass Du einen massiven Geschwindigkeitsgewinn mit irgendwelchen Hacks (welche Du ja auch als Funktionsaufrufe per .dll realisieren müsstest) erreichen kannst. Nochmal: Wenn Du so viele Bitoperationen benötigst und sie flott benötigst solltest Du dir überlegen eine schlankere Sprache zu wählen, da BB sich nun mal von Umfang und Ausgestaltung an Einsteiger wendet und somit zugunsten des Komforts auf die ein oder andere Millisekunde verzichtet.Nenn uns doch deine konkrete Anwendung bei der es hapert und man kann schauen ob man irgendwo eine sinnvolle Optimierung hinbekommt, aber was Du versuchst ist glaube ich weitestgehends vergebene Liebesmüh. Zudem - schlag mich nicht für meine Meinung- finde ich das bla = bla OR blub wesentlich einleuchtender und übersichtlicher als ein bla = set(bla,blub) - hier habe ich wenigstens direkt die Operation im Blick die durchgeführt wird. Nur meine 2ct.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mo, Nov 01, 2010 18:38
Antworten mit Zitat

Ob Du es Miilisekunden oder Frames pro Sekunde nennst bleibt sich gleich. (Wobei der FPS-Wahn meines erachtens nach recht übertrieben ist.)
Und OR, AND und Konsorten sollten eigentlich sehr zügig laufen, da sie vom BB-Compiler aller Voraussicht nach sehr low-Level umgesetzt werden. Ich bezweifle dass Du einen massiven Geschwindigkeitsgewinn mit irgendwelchen Hacks (welche Du ja auch als Funktionsaufrufe per .dll realisieren müsstest) erreichen kannst.
Nochmal: Wenn Du so viele Bitoperationen benötigst und sie flott benötigst solltest Du dir überlegen eine schlankere Sprache zu wählen, da BB sich nun mal von Umfang und Ausgestaltung an Einsteiger wendet und somit zugunsten des Komforts auf die ein oder andere Millisekunde verzichtet.Nenn uns doch deine konkrete Anwendung bei der es hapert und man kann schauen ob man irgendwo eine sinnvolle Optimierung hinbekommt, aber was Du versuchst ist glaube ich weitestgehends vergebene Liebesmüh.
Zudem - schlag mich nicht für meine Meinung- finde ich das bla = bla OR blub wesentlich einleuchtender und übersichtlicher als ein bla = set(bla,blub) - hier habe ich wenigstens direkt die Operation im Blick die durchgeführt wird.
Nur meine 2ct.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	GERMAX	Mo, Nov 01, 2010 19:15 Antworten mit Zitat
Wenn du das FPS-wahn nennst, bitte. Ich nenne das optimierte Programmierung. In Zeiten von Multicore, Multiprocessing,HT usw sollte man da schon drauf achten, denn es ist nunmal ein Unterschied, ob ein PRG 20 oder 40% CPU-Zeit frisst, die dann einem anderen Thread zugutekommt. Und das genau das ein Thema ist, wurde hier im Forum schon 1000-mal besprochen, nur eben über timer (wobei ich nicht behaupte, so einen grossen Unterschied erzeugen zu können). Eine dll wiederum als Hack zu bezeichnen, geht schonmal gar nicht. Naja und das mit dem OR ist natürlich deine Meinung. Aber hier in Europa liest man immer noch von links nach rechts. Und übrigens ist die Operation >OR< hinten und damit keinen einzigen deut weiter vorn als bei mir. bla = bla OR 8 bla = set(3,bla) Und bei OR 8 muß man wiederum überlegen, welches bit das war (beim Lesen). Diese Methode, das nicht über Or sondern mit bts zu lösen, haben sich die Intel Ingenieure vor was weiss ich so vor 30 Jahren ausgedacht und ist auch bei allen zzT prod. CPU's onboard (und das wird auch vermutl. nie rausfliegen, weil es sich in der Praxis absolut bewährt hat). Wobei bts noch eine Besonderheit zusätzl. hat, die ich gar nicht nutze. Eine weitere Opt. wäre dann nur noch durch eine in BB/B3D implementierte Fassung denkbar-da die 2. schnellste Möglichkeit aber verfügbar ist, ist eine weitergehende Überlegung obsolet (was sich nicht speziell auf bts bezieht).
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Mo, Nov 01, 2010 19:15
Antworten mit Zitat

Wenn du das FPS-wahn nennst, bitte. Ich nenne das optimierte Programmierung. In Zeiten von Multicore, Multiprocessing,HT usw sollte man da schon drauf achten, denn es ist nunmal ein Unterschied, ob ein PRG 20 oder 40% CPU-Zeit frisst, die dann einem anderen Thread zugutekommt. Und das genau das ein Thema ist, wurde hier im Forum schon 1000-mal besprochen, nur eben über timer (wobei ich nicht behaupte, so einen grossen Unterschied erzeugen zu können).

Eine dll wiederum als Hack zu bezeichnen, geht schonmal gar nicht.

Naja und das mit dem OR ist natürlich deine Meinung. Aber hier in Europa liest man immer noch von links nach rechts. Und übrigens ist die Operation >OR< hinten Wink

und damit keinen einzigen deut weiter vorn als bei mir. Cool

bla = bla OR 8
bla = set(3,bla) Und bei OR 8 muß man wiederum überlegen, welches bit das war (beim Lesen).

Diese Methode, das nicht über Or sondern mit bts zu lösen, haben sich die Intel Ingenieure vor was weiss ich so vor 30 Jahren ausgedacht und ist auch bei allen zzT prod. CPU's onboard (und das wird auch vermutl. nie rausfliegen, weil es sich in der Praxis absolut bewährt hat). Wobei bts noch eine Besonderheit zusätzl. hat, die ich gar nicht nutze.

Eine weitere Opt. wäre dann nur noch durch eine in BB/B3D implementierte Fassung denkbar-da die 2. schnellste Möglichkeit aber verfügbar ist, ist eine weitergehende Überlegung obsolet (was sich nicht speziell auf bts bezieht).

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	hectic Sieger des IS Talentwettbewerb 2006	Mo, Nov 01, 2010 19:34 Antworten mit Zitat
Die Sache ist die, das Bitoperationen im großem Umfang kaum auftreten in einem Spiel. Wer es aus irgendwelchen Gründen dennoch braucht, kann sich überlegen die wichtigsten Sachen zwischen zu speichern um sie dann direkt vorberechnet auszulesen. Die andere Sache ist, das Bitoperationen auch unter Blitz recht schnell sind. Es lohnt sich erst (wenn überhaupt), wenn man mehrere 10'000 bis 100'000 Abfragen pro Sekunde benötigt. Der dann zusätzlich geleisteten Aufwand es über eine ggf. etwas schnellere DLL zu realisieren, kann man auch in anderen Bereichen leisten, und erreicht mehr dabei. Soll heißen: Bevor man sich den Kopf über wenige 0.1% Relevanz den Kopf zerbricht, wird man an anderer Stelle mehr Erfolg haben. Besonders bei einem RPG sind sehr viele andere Optimierungsmöglichkeiten vorhanden. Aber ich will dich auch nicht von deinem Vorhaben anhalten. Bin selbst gespannt was draus wird. Beachte aber, das eine Zeitmessung alá ms=MilliSecs(): For i=1 to 1000000: a=a or b: Next: Print ms-MilliSecs() der falsche Ansatz ist, da Bitoperationen in einem Spiel oder Projekt immer nur einen winzigen Teil eines Performanceverlustes ausmachen. Selbst wenn deine Bitoperationen 20mal schneller sein sollten, wird es sich bei einem Projekt um wenige % hinter dem Komma bemerkbar machen.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mo, Nov 01, 2010 19:34
Antworten mit Zitat

Die Sache ist die, das Bitoperationen im großem Umfang kaum auftreten in einem Spiel. Wer es aus irgendwelchen Gründen dennoch braucht, kann sich überlegen die wichtigsten Sachen zwischen zu speichern um sie dann direkt vorberechnet auszulesen.

Die andere Sache ist, das Bitoperationen auch unter Blitz recht schnell sind. Es lohnt sich erst (wenn überhaupt), wenn man mehrere 10'000 bis 100'000 Abfragen pro Sekunde benötigt. Der dann zusätzlich geleisteten Aufwand es über eine ggf. etwas schnellere DLL zu realisieren, kann man auch in anderen Bereichen leisten, und erreicht mehr dabei.

Soll heißen: Bevor man sich den Kopf über wenige 0.1% Relevanz den Kopf zerbricht, wird man an anderer Stelle mehr Erfolg haben. Besonders bei einem RPG sind sehr viele andere Optimierungsmöglichkeiten vorhanden.

Aber ich will dich auch nicht von deinem Vorhaben anhalten. Bin selbst gespannt was draus wird.

Beachte aber, das eine Zeitmessung alá ms=MilliSecs(): For i=1 to 1000000: a=a or b: Next: Print ms-MilliSecs() der falsche Ansatz ist, da Bitoperationen in einem Spiel oder Projekt immer nur einen winzigen Teil eines Performanceverlustes ausmachen. Selbst wenn deine Bitoperationen 20mal schneller sein sollten, wird es sich bei einem Projekt um wenige % hinter dem Komma bemerkbar machen.

Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

	GERMAX	Mo, Nov 01, 2010 19:46 Antworten mit Zitat
Doch - die Methode der Zeitmessung ist schon die richtige. Aber wie dann das Ergebnis auszulegen ist, hast du natürlich richtig dargelegt. Ausserdem geht es nicht nur um Bitoperationen. Momentan habe ich gleich noch eine (Einfallswink/Wandwink/Ausfwink) eingebaut. Die kann man für alles mögliche brauchen (zB Flipper/Arkanoid/Minigolf...) -und die wird man bestimmt nicht nur einmal in einem Programm benutzen. Trotzdem werde ich natürlich den speed testen.
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Mo, Nov 01, 2010 19:46
Antworten mit Zitat

Doch - die Methode der Zeitmessung ist schon die richtige. Aber wie dann das Ergebnis auszulegen ist, hast du natürlich richtig dargelegt.

Ausserdem geht es nicht nur um Bitoperationen. Momentan habe ich gleich noch eine (Einfallswink/Wandwink/Ausfwink) eingebaut. Die kann man für alles mögliche brauchen (zB Flipper/Arkanoid/Minigolf...) -und die wird man bestimmt nicht nur einmal in einem Programm benutzen. Trotzdem werde ich natürlich den speed testen.

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	mpmxyz	Mo, Nov 01, 2010 20:47 Antworten mit Zitat
Ein paar Hinweise zur Optimierung: Bevor man etwas optimiert, sollte man schauen, ob es sich überhaupt lohnen könnte. Und da kommt die Zeitmessung, die hectic als falsch ansprach, nicht ins Spiel. Du vermisst vielmehr logische Abschnitte deines Spieles und optimierst nur die, die relativ viel Zeit brauchen; in der Regel gibt es hier die größten Optimierungsmöglichkeiten. Wenn das Zeichnen des Bildes nur eine Millisekunde braucht, besteht hier kein Optimierungsbedarf. Wenn die Kollisionsüberprüfung aber bei 100 Objekten 10 ms pro Durchlauf braucht und bei 200 Objekten das Spiel stottern lässt, besteht eher Handlungsbedarf, wenn das Spiel überhaupt so viele Objekte unterstützen soll. Nun hat man einen Ort zum Optimieren gefunden. Wer ist dort der Schuldige? Mit Hilfe weiterer Tests ist er schnell gefunden: Es ist die ShapesCollide-Funktion. Sie braucht 95,126836% der verbrauchten Zeit. Nun sitzt man Stunden an dieser Funktion, um diese zu optimieren. Immerhin ist sie jetzt 25% schneller geworden. Das Problem: Während das Spiel bei 100 Objekten etwas flüssiger läuft, ruckelt es bei 200 Objekten immer noch. Die Funktion lässt sich nicht weiter optimieren; wo ist dann der Fehler? Es ist die Art und Weise, wie die Kollision überprüft wird: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] For obj=Each TObject For obj2=Each TObject If Kollision Then ... Next Next Hier wird die Kollision von jedem Objekt mit jedem Objekt überprüft - doppelt! Nun gibt es also eine Verbesserung von 50%: BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN] For obj=Each TObject obj2=After obj While obj2<>Null If Kollision Then ... obj2=After obj2 Next Next Jetzt läuft das Programm mit den 200 Objekten schon spürbar besser, aber noch nicht perfekt. Warum? Wenn man jetzt die Anzahl an Objekten verdoppelt, brauchen diese Zeilen viermal so lange! Es wird ja die Kollision zwischen jedem Objekt und jedem Objekt kontrolliert. (->n²/2 Kontrollen) Wie macht man es nun richtig? Auf alle Fälle ist es nicht schlecht, wenn man eine Vorkontrolle macht. Das heißt, dass man über die Abstände - besser: über das Quadrat der Abstände - kontrolliert, ob es überhaupt zu einer Kollision kommen könnte. In der Regel sollte das schon reichen. Es gibt zusätzlich auch die Möglichkeit, jedes Objekt in ein Raster einzusortieren und nur Objekte in gleichen/benachbarten Feldern miteinander zu überprüfen. Damit lassen sich große Massen an Objekten bearbeiten: https://www.blitzforum.de/foru...p?p=373011 Ich hoffe, dass dies einigen hilft. mfG mpmxyz
Moin Moin! Projekte: DBPC CodeCruncher Mandelbrot-Renderer

mpmxyz

Mo, Nov 01, 2010 20:47
Antworten mit Zitat

Ein paar Hinweise zur Optimierung:
Bevor man etwas optimiert, sollte man schauen, ob es sich überhaupt lohnen könnte.
Und da kommt die Zeitmessung, die hectic als falsch ansprach, nicht ins Spiel.
Du vermisst vielmehr logische Abschnitte deines Spieles und optimierst nur die, die relativ viel Zeit brauchen; in der Regel gibt es hier die größten Optimierungsmöglichkeiten. Wenn das Zeichnen des Bildes nur eine Millisekunde braucht, besteht hier kein Optimierungsbedarf.
Wenn die Kollisionsüberprüfung aber bei 100 Objekten 10 ms pro Durchlauf braucht und bei 200 Objekten das Spiel stottern lässt, besteht eher Handlungsbedarf, wenn das Spiel überhaupt so viele Objekte unterstützen soll.
Nun hat man einen Ort zum Optimieren gefunden.
Wer ist dort der Schuldige?
Mit Hilfe weiterer Tests ist er schnell gefunden:
Es ist die ShapesCollide-Funktion. Sie braucht 95,126836% der verbrauchten Zeit.
Nun sitzt man Stunden an dieser Funktion, um diese zu optimieren. Immerhin ist sie jetzt 25% schneller geworden.
Das Problem: Während das Spiel bei 100 Objekten etwas flüssiger läuft, ruckelt es bei 200 Objekten immer noch.
Die Funktion lässt sich nicht weiter optimieren; wo ist dann der Fehler?
Es ist die Art und Weise, wie die Kollision überprüft wird:
BlitzBasic: [AUSKLAPPEN]

For obj=Each TObject
   For obj2=Each TObject
      If Kollision Then ...
   Next
Next

Hier wird die Kollision von jedem Objekt mit jedem Objekt überprüft - doppelt!
Nun gibt es also eine Verbesserung von 50%:
BlitzBasic: [AUSKLAPPEN]

For obj=Each TObject
   obj2=After obj
   While obj2<>Null
      If Kollision Then ...
      obj2=After obj2
   Next
Next

Jetzt läuft das Programm mit den 200 Objekten schon spürbar besser, aber noch nicht perfekt.
Warum?
Wenn man jetzt die Anzahl an Objekten verdoppelt, brauchen diese Zeilen viermal so lange!
Es wird ja die Kollision zwischen jedem Objekt und jedem Objekt kontrolliert. (->n²/2 Kontrollen)
Wie macht man es nun richtig?
Auf alle Fälle ist es nicht schlecht, wenn man eine Vorkontrolle macht.
Das heißt, dass man über die Abstände - besser: über das Quadrat der Abstände - kontrolliert, ob es überhaupt zu einer Kollision kommen könnte.
In der Regel sollte das schon reichen.
Es gibt zusätzlich auch die Möglichkeit, jedes Objekt in ein Raster einzusortieren und nur Objekte in gleichen/benachbarten Feldern miteinander zu überprüfen.
Damit lassen sich große Massen an Objekten bearbeiten:
https://www.blitzforum.de/foru...p?p=373011
Ich hoffe, dass dies einigen hilft.
mfG
mpmxyz

Moin Moin!
Projekte: DBPC CodeCruncher Mandelbrot-Renderer

	BladeRunner Moderator	Mo, Nov 01, 2010 22:09 Antworten mit Zitat
Die Jungs nehmen mir die Worte aus dem Mund. Optimieren ist schön und gut, aber es macht nur Sinn wenn das was Du da optimierst auch wirklich der Flaschenhals deines Programmes ist. Wie hectic schon erwähnte ist BB recht optimiert was die Geschwindigkeit der Bitoperationen angeht, die Wahrscheinlichkeit dass Du dort viel für dein Programm optimieren kannst ist verlgeichsweise gering, falls dein Programm nicht explizit nur aus Bitoperationen besteht. Zur Leseweise: Mag ja sein dass es auf Prozessoreben seitens Intel so gehandhabt wird - meine Assemblerkentnisse beschränken sich auf den MOS6510, und der benutzt OR, AND so wie es auch bei nahezu allen gängigen Programmiersprachen angewandt wird, und da es alle Sprachen so handhaben die ich benutze bin ich das so gewohnt, und finde es wesentlich leichter zu lesen. Nebenbei würde ich auch nicht or 8 schreiben, sondern eher or %1000, wahlweise auch hexadezimal bei größeren Werten, einfach weil ich sie flüssig lesen kann. Und ob ich eine .dll als hack bezeichne, das überlass doch bitte mir - beziehungsweise häng dich nicht dran auf, denn wie man es nennt, ist schnurz, der Inhalt ist es der zählt. Und den habe ich Dir nun mehrfach zu vermitteln versucht. Ich ziehe mich hier zurück. Viel Erfolg weiterhin.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mo, Nov 01, 2010 22:09
Antworten mit Zitat

Die Jungs nehmen mir die Worte aus dem Mund.
Optimieren ist schön und gut, aber es macht nur Sinn wenn das was Du da optimierst auch wirklich der Flaschenhals deines Programmes ist. Wie hectic schon erwähnte ist BB recht optimiert was die Geschwindigkeit der Bitoperationen angeht, die Wahrscheinlichkeit dass Du dort viel für dein Programm optimieren kannst ist verlgeichsweise gering, falls dein Programm nicht explizit nur aus Bitoperationen besteht.

Zur Leseweise: Mag ja sein dass es auf Prozessoreben seitens Intel so gehandhabt wird - meine Assemblerkentnisse beschränken sich auf den MOS6510, und der benutzt OR, AND so wie es auch bei nahezu allen gängigen Programmiersprachen angewandt wird, und da es alle Sprachen so handhaben die ich benutze bin ich das so gewohnt, und finde es wesentlich leichter zu lesen.
Nebenbei würde ich auch nicht or 8 schreiben, sondern eher or %1000, wahlweise auch hexadezimal bei größeren Werten, einfach weil ich sie flüssig lesen kann.

Und ob ich eine .dll als hack bezeichne, das überlass doch bitte mir - beziehungsweise häng dich nicht dran auf, denn wie man es nennt, ist schnurz, der Inhalt ist es der zählt. Und den habe ich Dir nun mehrfach zu vermitteln versucht. Ich ziehe mich hier zurück. Viel Erfolg weiterhin.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	BIG BUG	Di, Nov 02, 2010 0:33 Antworten mit Zitat
Hmm ich würde jetzt auch erwarten, dass ein simples XOR / OR / AND ein gutes Stück schneller sein sollte als eine DLL-Funktion aufzurufen... Aber bin auf das Messergebnis gespannt
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Di, Nov 02, 2010 0:33
Antworten mit Zitat

Hmm ich würde jetzt auch erwarten, dass ein simples XOR / OR / AND ein gutes Stück schneller sein sollte als eine DLL-Funktion aufzurufen... Aber bin auf das Messergebnis gespannt Smile

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	GERMAX	Di, Nov 02, 2010 2:55 Antworten mit Zitat
@BladeRunner Ob du eine dll als Hack bezeichnest geht mich sehr wohl was an. Ich finde das sogar ziemlich erstaunlich, denn die Möglichkeit dll einzubinden wurde ja offizeill zugelassen - gibt den Ordner userlibs ja nicht umsonst. Also worauf fußt deine Wertung? Auf gar nix! Ansonsten sind deine persönlichen Vorlieben eher uninteressant, denn für die Allgemeinheit sind die irrelevant. Bei Motorola wurde das übrigens auch so gemacht, denn da kommt die Bezeichnung Bset ja her (bei Intel heisst der anders und funkt. auch etwas anders). So und jetzt was interessantes: 10 Mio OR mit B3D: 23 ms / 37ms (bset-dll) 50 Mio : 114 ms / 187ms 500 Mio :1128ms / 1889ms
Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

GERMAX

Di, Nov 02, 2010 2:55
Antworten mit Zitat

@BladeRunner
Ob du eine dll als Hack bezeichnest geht mich sehr wohl was an. Ich finde das sogar ziemlich erstaunlich, denn die Möglichkeit dll einzubinden wurde ja offizeill zugelassen - gibt den Ordner userlibs ja nicht umsonst.
Also worauf fußt deine Wertung? Auf gar nix!

Ansonsten sind deine persönlichen Vorlieben eher uninteressant, denn für die Allgemeinheit sind die irrelevant.

Bei Motorola wurde das übrigens auch so gemacht, denn da kommt die Bezeichnung Bset Smile

ja her (bei Intel heisst der anders und funkt. auch etwas anders).

So und jetzt was interessantes:

10 Mio OR mit B3D: 23 ms / 37ms (bset-dll)
50 Mio : 114 ms / 187ms
500 Mio :1128ms / 1889ms

Erfolglos begonnene BB-Projekte:TRON/CONVOY/MYSTIC

	Noobody	Di, Nov 02, 2010 8:48 Antworten mit Zitat
GERMAX hat Folgendes geschrieben: 10 Mio OR mit B3D: 23 ms / 37ms (bset-dll) 50 Mio : 114 ms / 187ms 500 Mio :1128ms / 1889ms Okay, falls ich also jemals auf die Idee kommen sollte, 10 Millionen mal Or zu verwenden, werde ich dran denken, dass ich dann nur noch 40 FPS habe. Jetzt mal im Ernst: Das ist ein typischer Fall, bei dem Herr Knuth die Stirn runzeln würde ("Premature optimization is the root of all evil"). Binäre Operationen gehören zu den Operationen, die in Spielen und generell in normalen Programmen sehr selten benutzt werden. Falls du eine SIMD-Lib geschrieben hättest, dann ja, eine sinnvolle Optimierung, aber ein Assembler-Befehl statt Bitshifting, um das höchste gesetzte Bit zu finden? Eine Winkel-Spiegel-Funktion? Die gehören normalerweise nicht zu den meistgenutzten Funktionen der Blitz-Welt.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Di, Nov 02, 2010 8:48
Antworten mit Zitat

GERMAX hat Folgendes geschrieben:

10 Mio OR mit B3D: 23 ms / 37ms (bset-dll)
50 Mio : 114 ms / 187ms
500 Mio :1128ms / 1889ms

Okay, falls ich also jemals auf die Idee kommen sollte, 10 Millionen mal Or zu verwenden, werde ich dran denken, dass ich dann nur noch 40 FPS habe.

Jetzt mal im Ernst: Das ist ein typischer Fall, bei dem Herr Knuth die Stirn runzeln würde ("Premature optimization is the root of all evil"). Binäre Operationen gehören zu den Operationen, die in Spielen und generell in normalen Programmen sehr selten benutzt werden. Falls du eine SIMD-Lib geschrieben hättest, dann ja, eine sinnvolle Optimierung, aber ein Assembler-Befehl statt Bitshifting, um das höchste gesetzte Bit zu finden? Eine Winkel-Spiegel-Funktion? Die gehören normalerweise nicht zu den meistgenutzten Funktionen der Blitz-Welt.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Gehe zu Seite 1, 2 Weiter

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Befehlserweiterung für B3D

Betreff: Befehlserweiterung für B3D