Gut, hört sich dramatisch an und ich will nichts schlecht reden.
Dieser simple Sortiercode Code:
DIM A[10000]
FOR I = 0 TO 10000-1
A = 10000 - I
NEXT
T = GETTIMERALL()
FOR I = 0 TO 10000 - 1
FOR J = I TO 10000-1
IF A > A[J]
A[0] = A ; A = A[J] ; A[J] = A[0]
ENDIF
NEXT
NEXT
PRINT (GETTIMERALL()- T)/1000, 10,50
SHOWSCREEN
KEYWAIT
Dauert bei mir knapp 6 Sek., der gleiche Code mit Double Variablen in VBNet 0, 22 Sek.
Warum ist der Unterschied so gewaltig ?
Habe ich was übersehen oder wird bei so was in VB Assembler Code benutzt ?
0,22 sec..... scheint mir eine recht otopische Zahl zu sein :D
evtl. weil 'i' und 'I' was anderes is in GLBasic?
Nein, im Ernst. Wie hast Du A definiert? Kannst Du 'A' redimensionieren? (REDIM PRESERVE), oder ist's ein statisches Feld? Die sind tatsächlich schneller.
Hier der Orginal VbNet Code, mit Redim.
Fakt ist, dies geht bei mir knapp unter 0,2 Sek.
Dim A(1000) As Double
ReDim A(10000)
Dim I%, J%, T%
For I = 0 To 10000
A(I) = 10000 - I
Next
T = Environment.TickCount
For I = 0 To 10000 - 1
For J = I To 10000
If A(I) > A(J) Then
A(0) = A(I) : A(I) = A(J) : A(J) = A(0)
End If
Next
Next
Label1.Text = ((Environment.TickCount - T) / 1000).ToString + " sek. sortieren"
Mit der neuen Version ist das Beispiel ca. 23% schneller geworden.
Brauch jetzt 4,4 Sek , statt 6 Sek.
Weiter so.
Hi .....
Der VBNet code legt den Code als Cachable ab. Er wird nur einmal in den Processor Speicher geladen. Das bewirkt den geschwindigkeits anstieg. (Sollte es.......) Das gehört zu den internen Code Optimirungen. So wie es GFA BAsic schon zu WIN 95 Zeiten gemacht hat.
Du kannst ja mal einen Sprung in eine Funktion einfügen und schauen ob es immernoch schneller ist. Wenn ja. Ist etwas anderes daran schuld.
bei mir leuft er 2.567655
in Blitz3D mit debugger 13.0 und ohne 0.7
mach doch mal ne exe dafon und Leg es zum dounload bereit. Würde mich interesieren obs bei mir auch so ist. ... denn speed ist geil.
LIMITFPS -1
WHILE TRUE
dtime = GETTIMER()
fps = ((1000/dtime)+fps)/2
delay=delay+dtime
IF delay>500 // 1/2 sec
delay=0
showfps=fps
ENDIF
PRINT "FPS: "+showfps+" dtime:"+dtime, 0,0
SHOWSCREEN
WEND
diese rutine macht eigentlich nichts wirklich wichtiges. Aber bringt es trotzdem nur auf 255 FPS.
Da gibt es noch einiges was Optimirungs bedürftig ist. Bei B3D komme ich auf 1455 FPS.
hi tft,
zum Frame ausgeben, nutzer lieber Gettimerall(), Gettimer() mist von Showscrenn zu Showscreen und die zeit wo das Flippen braucht wird nicht beachtet.
probier mal das hier:
LIMITFPS -1
WHILE TRUE
PRINT getfps(), 0,0
PRINT GETTIMERALL()-dtime,0,10
dtime = GETTIMERALL()
SHOWSCREEN
WEND
FUNCTION getfps:
STATIC fps_time,fps_counter,fps,fps_temp
fps_time = GETTIMERALL()
fps_counter = fps_counter + 1
IF (fps_time-fps_temp)>1000
fps_temp = fps_time
fps = fps_counter
fps_counter = 0
ENDIF
RETURN fps
ENDFUNCTIONDas sollte auch bei Dir so um die 500fps ausgeben.
Was mir aufgefallen ist, das ich nie über 500 fps komme!? (Ist das nur bei mir so?)
Aber GLB hohe Frameraten sehr gut halten kann.
Nochmals aber ;) , wenn man Frameunabhängig programmiert, gibts oftmals etwas probleme wen die Frames über 500 liegen,
ist mir bei BB aufgefallen.
Kann vieleicht sein das sich die "Rundungen/fehler" stark bemerkbar machen.
Hier kann das VbNet Progamm geladen werden, braucht min. Framework 2.0
http://ligapro.de\nurso\VbNetSort.exe
Habe das tauschen ( A(0) = A(I) : A(I) = A(J) : A(J) = A(0) ) in eine Function gepackt und komme trotz mehraufwand auf ca. 0.23 Sek.
Hi ....
ja . Bei mir ist es genauso schnell.... 0.24 - 0.29
hmm hört sich schon etwas seltsam an. Aber mal eine Frage: In oben gezeigtem Beispiel wird das Array ja absteigend mit den Zahlen belegt, sodaß ein Bubble-Sort ja wirklich die volle Arbeit leisten muss. Da es sich hier um konstante Werte handelt, wäre es u.U. denkbar, daß ein schlauer Optimierungsalgorhitmus des Compilers dies erkennt???
Könnte man das Beispiel mal wiederholen, indem man das Array mit Zufallszahlen zwischen 0 und 10.000 belegt? Würde mich mal interessieren, ob das einen Unterschied macht.
Zu den Werten:
der VB-Code kommt bei mir auf 0,45 sec.
der GL-Code auf 1,78
Denke nicht das da Optimiert wird, glaube das VbNet bei Schleifen auf Assembler Code setzt.
Wenn man bei VbNet Mehrdimmensionale Felder oder Felder mit Typen hat geht die Performence etrem nach unten.
Der Code mit z.B A(1000, 0) ist dann 5 x langsamer, obwohl die Durchläufe gleich sind.
verstehe nicht ganz, was du mit Assembler-Code meinst. Letztendlich übersetzen sowohl VB als auch GL die Programme in Maschinencode, GL halt gleich beim Kompilieren und VB vor der Ausführung des Programmes, wenn ich mich recht erinnere.
könntest du es spaßeshalber mal mit Zufallszahlen versuchen? Täte mich wirklich mal interessiern. Bei GL macht es keinen großen Unterschied (1,8 Sec. statt 1,78, natürlich Mittelwert aus mehreren Durchläufen)
Schonmal dran gedacht, das GLBasic keine --> Hochsprache <-- ist?
Und somit ist der vergleich auch wohl ein wenig Krass !
Vergleicht doch mal, PureBasic, SDLBasic, BlitzBasic, BlitzMax usw... mit GLB !
der vergleich wär gerechtfertigt.
Alleine so einen Thread zu starten, ist schon fast ne frechheit !
na endlich merkt jemand das dieser thread sinnlos ist. wenn du meinst das vb.net besser ist dann bind da directx ein und schreib damit deine spiele... ich hab sämtliche sprachen durch die etwas mit open gl , directx und sdl zu tun haben und glbasic ist mit abstand einer der besten. interessant wäre ein vergleich mit einer kompilierten sprache und nicht son interpreten müll wie vb. danke fürs zuhören
Oops:
Aber bitte immer freundlich bleiben.
Hi ...
bleibt mal alle schön locker. Jede der Basic Dialekte hat seine Stärken und schwächen. Ich kenne sie eigentlich alle. Und Geschwindigkeits vergleiche gab es schon immer. Damit muss man leben.
Ich habe einige Test durchleufe gemacht. Und GLBasic ist insgesamt gesehen im Mittelfeld. Trotzdem habe ich eine Licence gekauft. Weil ich denke das da noch einiges an Potenziel drinn ist. Wenn Gernot den Step aus der Forschleife nimmt. Den man ja auch anders lösen kann wenn man es braucht. Dann solten die Schleifen auch schneller gehen. Abes es bedarf da noch etliches an Optimirungs arbeit. Auch auf seiten den Assembler Parts gibt es etliche Feinheiten, die man erst nach einigen versuchen richtig hinbekommt. Denn oft wird vergessen das sich bei solchen Schleifen konstruckten jede Microsecunde und jede Tackt ersparniss auszahlt. Den es handlet sich im Beispeil ja um 10000*10000 durchleufe. Und der sortier Algo ist ja nun alles andere als Optimal angelegt. Zudem ist ja noch entscheidend ob zur Schleifen Bildung Register oder Speicher adressen herangezogen werden. Da sich das mit den registern von Processor zu processor ja unterscheidet. Geht es fieleicht unter diesem Aspect keine schnellere Lösung. Das zu beurteilen sind nur wenige in der Lage. Und ich selber kann es Aczeptieren , da mein Hauptaugenmerk auf Windows Mobil liegt.
Fiel Spass noch
@Quentin
Mit Zufallzahlen das gleiche, mall etwas lansamer, mal schneller.
Es ist immer wieder Erstaunlich zu sehen wie andere sich aus dem Nichts angemacht fühlen.
Niemand hat behaupet das etwas schlecht oder etwas anderes besser ist.
Geht's mal locker an und seht mehr den Informativen Hintergrund und den Spaß, als wie "Kräftemessen von Programmiersprachen"
mir gehts nur gegen den strich dass einer daher kommt der noch null komma nix gemacht hat und es mit einer interpretierten *'!+! vergleicht die zudem noch nichtmal directx eingebunden hat.
noch schlimmer ist es zu behaupten das man alle basic dialekte kennt und weiß wo die stärken und schwächen sind. nichts für ungut tft aber du bist sehr egozentrisch.
allein einen terz draus zu machen ob ein programm nun ein wenig länger brauch als in einer anderen sprache finde ich zum "brechen"... nehmt es so hin wie es ist oder lasst es... mir macht keiner glbasic madig.. nur damit das klar ist!!!
und gernot falls du das hier liest bitte mal melden geht noch um den cross compiler für den mac... habe ein patch gefunden mit dem man gcc für universal darwin bins patchen kann. jedoch weiß ich nicht für welche version.
Nun mal langsam!
Keiner macht hier was madig!
Ich muss mich mull anschliesen, bleibt locker.
Und was tft angeht, der programiert schon etwas länger als manch anderer hier der windel enstiegen ist.
Ich mach mal nen anderen Thread auf.
muuuuuuuuuhhaarrrr
fangen jetzt schon Glaubenskriege hier an? Die sind wirklich fehl am Platze.
Die Unterschiede sind definitiv da und es wäre interessant dafür den Grunde zu erfahren. Daß jeder Compiler anders optimiert und somit auch jeder seine Stärken und Schwächen hat, ist nichts Neues, das ist so alt wie der Compilerbau selbst. Ich beurteile GL auch nicht danach, ob es FOR-Schleifen schneller oder SPRITES schneller bearbeitet als andere Sprachen. GL gefällt mir wegen seiner Einfachheit und was man damit anfangen kann.
Aber zu eurer Erbauung:
Auch wenn ich ich Sortieralgorhitmus etwas anderes formulieren würde, hier mal ein Beispiel mit INLINE-C++. Diese Version arbeitet doch schon um einiges schneller als die reine Basic-Variante. (1,35 sec stat 1,78 sec im langjährigen Mittel :) )
DIM A[10000]
FOR I = 0 TO 10000-1
A[i] = RND(10000)
NEXT
T = GETTIMERALL()
LOCAL i, j
INLINE
for(i=0; i<9999; i++)
{
for(j=i; j<9999; j++)
{
if(A(i) > A(j))
{
A(0) = A(i); A(i) = A(j); A(j) = A(0);
};
};
};
ENDINLINE
// FOR I = 0 TO 10000 - 1
// FOR J = I TO 10000-1
// IF A[i] > A[J]
// A[0] = A[i] ; A[i] = A[J] ; A[J] = A[0]
// ENDIF
// NEXT
// NEXT
PRINT (GETTIMERALL()- T)/1000, 10,50
SHOWSCREEN
KEYWAIT@mull
danke für die Info. War nur mal so eine Idee.
Quote from: mull...
Dauert bei mir knapp 6 Sek., der gleiche Code mit Double Variablen in VBNet 0, 22 Sek.
Warum ist der Unterschied so gewaltig ?
Ums nochmal zu sagen:
GLBasic ist keine Hochsprache, denn er muss den Code erst Interpretieren.
Frage beantwortet, und Thread kann geclosed werden !
Das geflame hier ist ja wie im Kindergarten..
Ist schon schlimm genug, das manche Leute anfangen mit GLB zu arbeiten, ums dann auf anhieb zu kritisieren. Diesen Leuten empfehle ich, Klappe zu, sich seinen Teil denken, oder ne andere Sprache suchen!
Wenn VB so toll ist, dann macht eure sachen in VB, aber wie trucidare schon sagte, macht mal DX rein und schreibt mal ein Spiel!
1. erheblich mehr aufwand
2. dadurch demotivierend, da ergebnisse erst nach massig Code sichbar werden.
Also nochmal zum Mitschreiben:
Mir ist es egal das leute hier reinglotzt werden, die schon(VOLL ERFAHRUNG HABEN, sogar da, wo ich noch in die Windel gepupst hab) erfahrung haben mit Programmieren.
Wenn die so toll drauf sind, sollen sie mal selber eine Sprache entwickeln, die den Comfort von GLBasic hat, und eine For-Schleife like" C++ Speed" hat!
Ist einfach nur lächerlich.....
Quote from: Schranz0rGLBasic ist keine Hochsprache, denn er muss den Code erst Interpretieren.
ähhh Schranzor, was verstehst du jetzt unter Hochsprache? Natürlich ist GL eine. Und interpretiert werden muss hier auch nix, schließlich erzeugt GL standalone EXE-Dateien. Verstehe auch wirklich nicht, warum man sich aufgrund diese Vergleiche auf den Schlips getreten fühlen muss.
Aber noch mal back to topic:
@tft
mit dem Hinweis auf STEP bei der FOR-Schleife könntest du durchaus recht haben. Möglich daß VB da Optimierungen vornimmt, wenn der Zusatz fehlt. In GL-Basic gibt es jedoch noch eine Variante der FOR-NEXT-Schleife. Sieh mal in der Hilfe nach FOREACH. Diese Variante sollte deutlich schneller arbeiten. Mal sehen, daß müsste man eigentlich hinbekommen, aber nicht mehr heute ;)
@ Quentin:
Mal frei aus kopf raus:
Hochsprache ist eine Grundsprache, aus dene andere Dialekte erzeugt werden.
Hochsprache VB:
BlitzBasic
GLBasic
SDLBasic
FreeBasic
....
Verstehst du nun was ich meine?
Kann ja nicht so schnell gehen wie die "Muttersprache".....
Und sich wegen 1 Sec dermassen auf zu plustern ist schon der hammer !
Kanns nur nochmal sagen, Thread schleissen , bzw. Löschen!
Weil das nimmt sonst noch überhand hier !
Hi
@Schranzür ... das was ich jetzt sage mache ich nicht gerne. Aber eine Hochsprache im sinne der Computertechnik, ist nicht zu verwechseln mit einer Hochsprache in der Sprachwissenschaft. Alle Basic Dialekte sind Hochsprachen, Da diese den eigentlichen grundwortschatz. Nämlich ASM befehle nicht... oder kaum unterstützen. Eine Hochsprache ist der grund Programmier Sprache übergeordnet, weil sie in ihren Befehlen und Struckturen dem Menschlichen unvermögen mit abstrackten befehlsfolgen klarzukommen entgegenwirkt.
Ein Processor kann zwischen 10-156 grundbefehle zum abarbeiten von informationen verfügen. (Mehr oder Weniger.) Die fürsich genommen nicht wirklich zusammenhängende dinge machen. Die Hochsprache erzeugt Befehlsmuster die einen Sprachlichen sinn ergeben. Und erst dieser sinn ermöglicht es den nicht ASM begabten programme zu schreiben. Es gibt nur noch wenige die ASM so beherschen das sie keine Hochsprache benötigen.
Und VB ist auf jeden fall nicht die Grundsprache der anderen Basic Dialekte. Eine der ersten Basic Varianten gab es bereits zu Zeiten des ZX80 und C64. Da hat man an VB noch nicht mal ansatzweise gedacht. Und C gab es auch noch nicht. Höchsten experimentel auf universitäts Rechnern. Grossrechner wurden in ASM Programiert.
Ich weis ... das gehört jetzt nicht hierher. Aber das muste ich noch loswerden. :) SORRY
So. Jetzt die echte Erklärung:
Das VBnet macht das Feld statisch. So wie in C++ double feld[10000]; Das ist ganz was anderes, als ein dynamisches Feld, das intern 4 dimensionen haben muss (feld[100000][1][1][1]) - geht nicht anders.
Darum ist das schneller. Ob das jetzt bei einem Spiel wirklich zu Buche schlägt, ist fraglich, da i.d.R. die Grafik- und Soundfunktionen den größten Leistungsanteil bringen.
Wer tatsächlich so zeitkritische Berechnungen in Echtzeit benötigt, hat in GLBasic aber trotzdem den Vorteil INLINE C++ oder ASM zu schreiben - schneller geht's nicht.
Insofern sehe ich hier kein echtes Problem. Sicher ist das ein Test, bei dem GLBasic langsamer abschneidet als VB, aber so einen Test finde ich in jeder Sprache. Frage ist nur - ist dieser Test für ein Spiel relevant?
Sorry für die teilweise sehr emotionalen Antworten. Das sollte so nicht sein.
Jetzt ist für mich die Sache aufgelöst und geklärt.
Jow, jetzt ist es von Tisch und gut ist :D
Sorry wenn ich ruppig war ... ;)
Hallo Gernot
Wäre es für dich schwer die Directive Statisch einzufügen Die sache mit den Redimensionierbaren Dim Feldern ist zwar recht pracktisch. Aber ich selber bin mer Geschwindigkeits bezogen. Und For Next Schleifen gibt es in einem Spiel zu hauf. Selbst bei B3D nerft mich die geschwindigkeits verluste durch Schleifen. Obwohl man bei inteligenter vorgehensweise fiele Schleifen Konstruckte minimieren kann. Das der zugriff auf Felder langsamer ist wenn sie Dynamisch verwaltet werden ist klar.Aber sind den die Types nicht für Dynamische felder besser geeigent? Habe ich nach INLINE volle Register kontrolle. Oder muss ich vorher alle Register retten und selber restaurieren?
Ein Tipp: Wenn Du dynamische Felder von TYPEs machst, kann FOREACH unglaublich schnell durchlaufen.
I.d.R reicht das für ein Spiel.
Das ist bei weitem nicht der einzige Grund. Ich hab bereits ziemlich viele Speedtests gemacht und und die .Net Sprachen hängen die "Hobbysprachen" dabei immer ab. Für PureBasic gibt es demnächst einen .Net Compiler (eine Art Addon von einem PureBasic User), der hat das originale PB schon bei den Betatests speedmäßig weit hinter sich gelassen. Der Hauptgrund dafür liegt in der JIT Compilierung von .Net. Beim ersten Ausführen einer Codestelle wird diese in Maschinensprache übersetzt wobei sie gleichzeitig auf die jeweilige Plattform optimiert wird. Mit anderen Worten: beim ersten Ausführen einer .Net exe wird diese langsamer laden und anfangs auch etwas langsamer laufen als eine normal-kompilierte exe. Dannach geht es aber ab.
Ach: Und ein native C++ compiler ist langsamer als ein JIT? *Hüstel...*
Hier mal ein echter Test:
int main(int, char**)
{
#define COUNT 20000
DWORD t1, t2;
printf("GLBasic, native\n");
{
DGIntArray arr;
DIM(arr, COUNT,0,0,0);
for(int i=0; i t1=GetTickCount();
for(double i=0; i<=COUNT-1; ++i)
for(double j=i; j<=COUNT-1; ++j)
{
if(arr[i] > arr[j])
{
arr[0] = arr[i];
arr[i] = arr[j];
arr[j] = arr[0];
}
}
t2=GetTickCount();
printf("Time: %.2f sec\n", (double)(t2-t1) / 1000.0);
}
printf("C++, native\n");
{
double* arr = new double[COUNT];
for(int i=0; i t1=GetTickCount();
for(double i=0; i<=COUNT-1; ++i)
for(double j=i; j<=COUNT-1; ++j)
{
if(arr[(int)i] > arr[(int)j])
{
arr[0] = arr[(int)i];
arr[(int)i] = arr[(int)j];
arr[(int)j] = arr[0];
}
}
t2=GetTickCount();
printf("Time: %.2f sec\n", (double)(t2-t1) / 1000.0);
delete[] arr;
}
printf("C++, optimized\n");
{
double* arr = new double[COUNT];
for(int i=0; i t1=GetTickCount();
for(int i=0; i for(register int j=i; j {
if(arr[i] > arr[j])
{
arr[0] = arr[i];
arr[i] = arr[j];
arr[j] = arr[0];
}
}
t2=GetTickCount();
printf("Time: %.2f sec\n", (double)(t2-t1) / 1000.0);
delete[] arr;
}
printf("C++, std::sort\n");
{
std::vector arr(COUNT);
for(int i=0; i t1=GetTickCount();
std::sort(arr.begin(), arr.end());
for(int i=0; i t2=GetTickCount();
printf("Time: %.2f sec\n", (double)(t2-t1) / 1000.0);
}
}Und hier das Ergebnis:
GLBasic, native
Time: 9.88 sec
C++, native
Time: 4.47 sec
C++, optimized
Time: 1.50 sec
C++, std::sort
Time: 0.00 secDaran sieht man:
- Der notwendige GLBasic overhead macht etwas aus
- einige Optimierungen sind nicht ohne INLINE möglich
- die Wahl eines anderen Algorithmus (hier qsort statt bubble sort) ist unerreichbar
- es gibt keine schnellere Sprache als C++, ausser optimiertem ASM, und das besser zu machen als ein Compiler ist heute fast nicht mehr möglich.
na endlich is die diskusion vorbei mit dem c++ beispiel sollte nun alles gesagt sein. ich wäre dankbar für keine weiteren speedtests weil ich darin keinen sinn sehe. wenn einer meint das seine lieblingssprache besser ist soll der die nehmen und nicht anfangen mit speedtests etc pp. mir ist das vollkommen wurst wie schnell mein program läuft hauptsache es erfüllt seinen sinn.
punkt aus pasta und nun wieder zum urlaub *hrhrhrhr* ;)
Ja. Ausserdem muss man immer die Sprache als Ganzes ansehen. Es gibt 100e von Sachen, wo GLBasic klar schneller ist als VB. Aber wie gesagt - jetzt is' erstmal Schluss ;)
richtig und nun will ich das glbasic programme für mac kompiliert ;)
Die Auffassung, dass C++ die schnellste Sprache ausser ASM ist, ist schlichtweg falsch.
1. hängt das stark vom verwendeten Compiler ab
2. Ist ANSI oder ISO C nochmal ein Stück schneller als C++
3. der BlitzMax Compiler erzeugt Programme, die durchaus etwas schneller sind als der GNU C++
4. Speedtests liegen mir keine vor, aber ich denke Visual C# kompilierte JITs sind ebenfalls schneller als GNU C++ Programme, zumindest in den meisten Fällen
=> Langsamkeit lässt sich nicht durch irgendwelche Gegebenheiten in der Sprache entschuldigen. Je besser der ASM Output des Compilers, desto besser das resultierende Compilat. Wenn GLBasic Programme langsamer sind als GNU C++ Programme, dann nur deshalb weil der ASM Output nicht so gut optimiert wird. Was auch kein Wunder ist, das an GLBasic lange nicht so viele Leute arbeiten wie am GNU C++. Der Vorteil von .Net liegt eben darin, dass hier mehrere Schritte erfolgen:
Code -> MSIL
MSIL -> JIT -> native Exe
Und das, was ich hier als JIT bezeichnet habe drückt eigentlich nur folgendes aus: was ein "normaler" Compiler am ASM Output selbstständig optimieren muss um konkurrenzfähig zu sein, dass passiert bei dotNet 100% automatisch. Ein GLBasic.NET wäre ganz automatisch schneller als die heute kompilierten Programme.
Hmmm, ich enthalte mich jetzt mal der Stimme :) :)
Möcht nicht nochmal in ein kleines fettnäpfchen treten ;)
Naja fast,
Sebe macht gute vorschäge,
Du verteitigst GLB wo es nur geht.
Entscheiden muss halt Gernot, was wo wie eingbaut wird ohne das die Kompatibilität unter den unterschiedlichen OS leidet
und es nicht zu verwirrend wird.
Dazu muss man natürlich auch beachten das GLB "Nebenberuflich" gehegt und geflegt wird, das auch noch sehr gut.
Mein vorschlag wäre einen neuen Thread, besser noch eine eigen Rubrik zu erstellen, wo die Wünsche und anregungen ein kommen, und nur das.
Gespame und sonstiges in einem Offtopic rein mit einem Link zu diesem.
Dann bleibt die übersichtlichkeit vorhanden ;)
Interessant wäre auch noch eine Rubrik "CodeTemplates" das sich ein bisschen von Codesnippets unterscheiden soll.
Es sollten reine Functionbibliotheken sein die sofort, bzw. nur mit geringster anpassung benutzbar sind.
Hier kann man nicht einfach rein Posten sondern nur ein Moderator kann Code, z.b. eben das mit Keyhit, Savefunctionen, Laderoutinen.....usw,
reinschieben oder löschen kann.
Quote from: Sebe@ Slayer: ah, ein Bekannter Name aus dem Blitzforum =) Wie hat es denn dich hierher verschlagen?
Naja, BM ist mir zu Kompliziert geworden, hab zu wenig zeit.(Wenn ich nicht so ein Sammler wäre, wär das Ding schon längst verkauft)
GLB finde ich sehr gut :)
Mein Englisch wortschatz kann man an denn Fingern ablesen.
Gernot ist meiner meinung nach Top.
Bis auf kleine Haarspalterreien ist die Community ganz OK.
Hier habe ich auch meine Post gelöscht !