Seid ihr alle zufrieden mit BlitzBasic???

Übersicht

BlitzBasic

Allgemein

Gehe zu Seite Zurück 1, 2, 3, 4

	Dreamora	Mi, März 17, 2004 11:13 Antworten mit Zitat
es sind nur 10 instanzen net 5mio aber es sind zu testzwecken 5 mio abfragen eines wertes, um eine wirklich aussagekräftige zeit zu erhalten Man kann auch 5000 machen was einer normalen sekunde in etwa gleich kommt, auch da gehen die zwei wege schon aus einander. Nur net derart extrem logischerweise. Stellte sich mir dann einfach die Frage wie die Instanzen intern gespeichert sind, dass er sich so "verlaufen" kann im vergleich zu ner LinList Und wenn du wissen willst wofür ich derart komisch erscheinende Geschwindigkeitstests mache: Partikel System. Denn da kommt es doch extrem drauf an, mit for each läufts dann eben so katastrophal wie ParticleWorks das bei 400 partikeln kollabiert. Habe auch Sprite und ein entsprechende Mesh verglichen, aber da bleibt es auch bei sehr vielen Operationen in schleife so, dass sich die zwei nur îm 30ms bereich unterscheiden ... sprich die sind vom speed her identisch

Dreamora

Mi, März 17, 2004 11:13
Antworten mit Zitat

es sind nur 10 instanzen net 5mio
aber es sind zu testzwecken 5 mio abfragen eines wertes, um eine wirklich aussagekräftige zeit zu erhalten

Man kann auch 5000 machen was einer normalen sekunde in etwa gleich kommt, auch da gehen die zwei wege schon aus einander. Nur net derart extrem logischerweise.
Stellte sich mir dann einfach die Frage wie die Instanzen intern gespeichert sind, dass er sich so "verlaufen" kann im vergleich zu ner LinList

Und wenn du wissen willst wofür ich derart komisch erscheinende Geschwindigkeitstests mache: Partikel System. Denn da kommt es doch extrem drauf an, mit for each läufts dann eben so katastrophal wie ParticleWorks das bei 400 partikeln kollabiert.

Habe auch Sprite und ein entsprechende Mesh verglichen, aber da bleibt es auch bei sehr vielen Operationen in schleife so, dass sich die zwei nur îm 30ms bereich unterscheiden ... sprich die sind vom speed her identisch

	Omenaton_2	Mi, März 17, 2004 15:52 Antworten mit Zitat
Hi MasterK ! "...funktionen gab es in anderen sprachen wesentlich eher. um nun aber nicht den durchschnittlichen basic-programmieren mit seinen globalen variablen und spaghetti-code zu überfordern, hat man die krücke gosub eingeführt. " - Ich habe nicht von anderen Sprachen gesprochen, sondern über Basic. Ich kann mir nicht vorstellen, daß in der aller ersten Basic Sprache gleich Functions drin waren, aber Gosubs sicher. "sie sind äusserst leicht exportiertbar, wenn man mit localen variablen (wie es sich gehört) arbeitet. funktion markieren, kopieren, fertig. " - Das akzeptiere ich. Es kann viele Fälle geben, wo Functions sich leichter exportieren lassen als Subrutinen mit Gosubs. Die Subrutinen mit Gosubs lassen sich wenn sie gut gemacht sind auch leicht exportieren, aber vielleicht etwas weniger leichter als Functions. Dazu kommt aber noch, daß Exportierbarkeit nicht immer von Bedeutung ist, das hängt von der Aufgabe ab die man zu lösen hat und ob man mit anderen zusammenarbeitet oder nicht. "- der aufruf IST kürzer, da man wie im beispiel nicht vorher irgendwelche variablen setzen muss " - Das sehe ist nicht so. Der Aufruf ist gleich lang. Variablen müssen ihre aktuellen Werte irgendwie immer bekommen. Man kann das Beispielen gut erkennen, das es nur 2 Variatonen des Selben sind und das eine ist nicht kürzer als das andere. " man vergisst auch nicht variablen entsprechend zu setzen und sucht dann wie blöde nach dem fehler, denn die funktion erwartet ja direkt eine variable" - Ich sehe dieses Problem nicht. In der Subrutine steht doch irgendeine Aktion die mit bestimmten Variablen durchgeführt wird. Man sieht sehr wohl welche diese sind (außerdem weiß man als Programmierer was man macht und warum). Ich habe solche Probleme noch nicht gehabt. " funktionen können werte zurückliefern, mit denen man direkt weiter arbeiten, verkürzt den quellcode erneut. " Subrutinen mit Gosubs liefern ganz genauso die Werte zurück wie Functions. Da ist Null Unterschied. Das verkürzt an den Code gar nichts und wie kommst du hier auf das Wort "erneut" ? "- deine farbformatierung ist dir nur im entsprechenden editor von vorteil. gute editoren ziehen heutzutage übrigens waagerechte trennlinie zwischen funktionen" - Ich habe schon geschrieben, daß Farbformatierung nichts mit Functions oder nicht Functions zu tun hat. Übrigens Ich setze nicht jeden Stern oder Linie einzeln per Hand, sondern kopiere ich einen standartisierten Block. " arbeiten mehrere leute an einem projekt, kannst du dich mit deiner "stilfibel" erschiessen " - Wenn mehrere Leute an dem selben Projekt als Programmierer arbeiten dann hat normalerweise jeder seinen Bereich den er erstellt und betreut, das kommt kaum vor, daß mehrere Personen gleichermaßen den vollen Überblick über einen großen Code haben. Es gibt einen Hauptprogrammierer der im großen und ganzen den Code schreibt und andere übernehmen Teilbereiche und liefern diese ab, die werden dann integriert. Sie müssen sich natürlich absprechen. In jedem Fall, egal wie programmiert wird. Ich glaube nicht, daß ich mich erschießen sollte, falls mehrere Leute an meinem Projekt arbeiten müßten. Wichtig ist nämlich das überischtlich und verständlich programmiert wird, nicht ob man die einzelnen Programmteile mit Labels markiert oder sie Functions nennt. Übersichtlich und verständlich kann ein Code in beiden Fällen sein und umgekehrt auch. In meinem Fall ist es aber eindeutig so, daß ich alleine programmiere und es nicht vor habe meinen Code irgendjemandem zu übergeben. "- willst du dich mit diesem "wissen" über funktionen und gosubs mal in einer firma bewerben, könnte das äusserst peinlich werden. aber ich denke mal, das willst du nicht" - Ich bin in der Tat kein Berufsprogrammierer und ich habe es auch nicht vor einer zu werden. Ich weiß aber genug um alles was ich will - mag es noch so groß sein - insofern es technisch machbar ist, auch machen zu können. Das es peinlich werden könnte, wenn ich mich mit meinem "Wissen" über Functions und Gosubs bewerben würde kann sehr wohl wahr sein. Das würde aber lediglich daran liegen, das Menschen mit solcher unreifer, verblendeter und intoleranter Einstellung und Schulbücherweisheiten wie du in der Überzahl sind. Ich will jetzt darüber nicht ins Detail gehen, da das sehr lange dauern würde und ich will keinen Streit, nur eine sinnvolle Diskussion. "willst du später bmax nutzen, wirst du um funktionen kaum herumkommen, soweit ich gehört habe, soll das ja mehr in richtung OOP gehen." - Lassen wir die Gerüchte über die Zukunft bei Seite. Das BlitzMax keinen Gosub Befehl mehr hätte, bezweifele ich stark. "im übrigen muss ich sagen, spricht es nicht gerade für dich dass du seit ende der 80er programmierst und funktionen nicht kennst bzw sie nicht sinnvoll einsetzen kannst." - Ich habe nicht gesagt, daß ich seit den 80-er Jahren kontinuierlich programmiere. Ich habe in den 80-er Jahren meine erste Gehversuche gemacht und kleine, nette Spiele programmiert (die Rechner hatten nur ca 36 Kbyte Speicher wo alles samt Grafik reinpassen mußte und da war noch nix mit Maus oder Doublebuffering). Als dann Amiga und PC kam habe ich aufgehört, da die Basicsprachen die ich damals sah mir nicht gefielen und zu der zeit war es wirklich noch nicht möglich in Basic vernünftige Spiele zu machen. Damals mußte man unbedingt in Maschinencode oder C schreiben, sonst war das Programm viel zu langsam. Ich wollte immer nur Spiele schreiben, die sich von professionellen Spielen nicht unterscheiden. Man sollte es einem Spiel nicht ansehen können, daß es ein Basic Spiel ist. Erst mit den modernen, sehr schnellen und mit viel Speicher ausgerüsteten Rechnern und BlitzBasic ist das Basicprogrammieren wieder richtig interessant geworden. Jetzt ist in Basic fast alles möglich. Ich habe also bevor ich vor 1,5 Jahren BlitzBasic gekauft habe sehr viele Jahre lang gar nichts gemacht. Es war ein großer Sprung von 80-er Jahre Basic auf Blitz3D. Funktionen spielten in den 80-er Jahren bei Basic keine (oder kaum) Rolle. Was Functionen sind habe ich sehr wohl verstanden und ich könnte sie auch vernünftig einsetzen, tue ich aber nicht, weil ich immer noch keinen Grund dafür sehe. Nur weil viele Menschen irgendeine Sache glauben, wird es deswegen noch nicht wahr und nicht alles was du in einem Lehrbuch gelesen hast ist göttliche Weisheit dem man nicht widersprechen darf. Anstat alles blind zu akzeptieren und gehorsam die Herde zu folgen solltest du mal lernen kritischer zu sein und Dinge zu hinterfragen. Du würdest dich wundern, wie Viele Sachen es in der Welt gibt, die obwohl von vielen praktiziert werden, aber trotzdem nicht richtig sind. "ach ja, und noch was zu deinem case-block: der is auch recht deftig. du solltest dich noch einmal genauer mit dem konzept der arrays auseinandersetzen." - Was heißt hier "recht deftig" ? Übrigens van Arrays habe ich auch (schon lange) Ahnung. In dem Fall da ist mein Select Case ideal geeignet. Ich kann jetzt nicht alles darüber erklären, aber wir du vielleicht gemerkt hast, geht es da um verschiedenen Bodentypen, wie zum Beispiel Wiese, Straße oder Wasser. Durch diesen Select Case Struktur habe ich da eine Art Tabelle wo ich die einzelnen BodenTypen gut überblicken und aus verschiedenen Gründen auch mal leicht ändern oder asuklammern kann. Das ist nur ein ganz kleines Stück Code herausgerissen aus dem großen Zusammenhang. Was für mich letztendlich wirklich zählt, das sind die Ergebnisse. Das Problem ist, daß ich mir noch nich sicher bin, ob ich aus rechtlichen gründen das was ich mache zeigen kann oder nicht. Wenn ich es bald zeigen darf, werde ich es gerne tun und ich wage es vorauszusagen, daß du danach vor Scham erröten wirst

Omenaton_2

Mi, März 17, 2004 15:52
Antworten mit Zitat

Hi MasterK !

"...funktionen gab es in anderen sprachen wesentlich eher. um nun aber nicht den durchschnittlichen basic-programmieren mit seinen globalen variablen und spaghetti-code zu überfordern, hat man die krücke gosub eingeführt. "
- Ich habe nicht von anderen Sprachen gesprochen, sondern über Basic. Ich kann mir nicht vorstellen, daß in der aller ersten Basic Sprache gleich Functions drin waren, aber Gosubs sicher.

"sie sind äusserst leicht exportiertbar, wenn man mit localen variablen (wie es sich gehört) arbeitet. funktion markieren, kopieren, fertig. "
- Das akzeptiere ich. Es kann viele Fälle geben, wo Functions sich leichter exportieren lassen als Subrutinen mit Gosubs. Die Subrutinen mit Gosubs lassen sich wenn sie gut gemacht sind auch leicht exportieren, aber vielleicht etwas weniger leichter als Functions. Dazu kommt aber noch, daß Exportierbarkeit nicht immer von Bedeutung ist, das hängt von der Aufgabe ab die man zu lösen hat und ob man mit anderen zusammenarbeitet oder nicht.

"- der aufruf IST kürzer, da man wie im beispiel nicht vorher irgendwelche variablen setzen muss "
- Das sehe ist nicht so. Der Aufruf ist gleich lang. Variablen müssen ihre aktuellen Werte irgendwie immer bekommen. Man kann das Beispielen gut erkennen, das es nur 2 Variatonen des Selben sind und das eine ist nicht kürzer als das andere.

" man vergisst auch nicht variablen entsprechend zu setzen und sucht dann wie blöde nach dem fehler, denn die funktion erwartet ja direkt eine variable"
- Ich sehe dieses Problem nicht. In der Subrutine steht doch irgendeine Aktion die mit bestimmten Variablen durchgeführt wird. Man sieht sehr wohl welche diese sind (außerdem weiß man als Programmierer was man macht und warum). Ich habe solche Probleme noch nicht gehabt.

" funktionen können werte zurückliefern, mit denen man direkt weiter arbeiten, verkürzt den quellcode erneut. "
Subrutinen mit Gosubs liefern ganz genauso die Werte zurück wie Functions. Da ist Null Unterschied. Das verkürzt an den Code gar nichts und wie kommst du hier auf das Wort "erneut" ?

"- deine farbformatierung ist dir nur im entsprechenden editor von vorteil. gute editoren ziehen heutzutage übrigens waagerechte trennlinie zwischen funktionen"
- Ich habe schon geschrieben, daß Farbformatierung nichts mit Functions oder nicht Functions zu tun hat. Übrigens Ich setze nicht jeden Stern oder Linie einzeln per Hand, sondern kopiere ich einen standartisierten Block.

" arbeiten mehrere leute an einem projekt, kannst du dich mit deiner "stilfibel" erschiessen "
- Wenn mehrere Leute an dem selben Projekt als Programmierer arbeiten dann hat normalerweise jeder seinen Bereich den er erstellt und betreut, das kommt kaum vor, daß mehrere Personen gleichermaßen den vollen Überblick über einen großen Code haben. Es gibt einen Hauptprogrammierer der im großen und ganzen den Code schreibt und andere übernehmen Teilbereiche und liefern diese ab, die werden dann integriert. Sie müssen sich natürlich absprechen. In jedem Fall, egal wie programmiert wird.
Ich glaube nicht, daß ich mich erschießen sollte, falls mehrere Leute an meinem Projekt arbeiten müßten. Wichtig ist nämlich das überischtlich und verständlich programmiert wird, nicht ob man die einzelnen Programmteile mit Labels markiert oder sie Functions nennt. Übersichtlich und verständlich kann ein Code in beiden Fällen sein und umgekehrt auch.
In meinem Fall ist es aber eindeutig so, daß ich alleine programmiere und es nicht vor habe meinen Code irgendjemandem zu übergeben.

"- willst du dich mit diesem "wissen" über funktionen und gosubs mal in einer firma bewerben, könnte das äusserst peinlich werden. aber ich denke mal, das willst du nicht"
- Ich bin in der Tat kein Berufsprogrammierer und ich habe es auch nicht vor einer zu werden. Ich weiß aber genug um alles was ich will - mag es noch so groß sein - insofern es technisch machbar ist, auch machen zu können.
Das es peinlich werden könnte, wenn ich mich mit meinem "Wissen" über Functions und Gosubs bewerben würde kann sehr wohl wahr sein. Das würde aber lediglich daran liegen, das Menschen mit solcher unreifer, verblendeter und intoleranter Einstellung und Schulbücherweisheiten wie du in der Überzahl sind. Ich will jetzt darüber nicht ins Detail gehen, da das sehr lange dauern würde und ich will keinen Streit, nur eine sinnvolle Diskussion.

"willst du später bmax nutzen, wirst du um funktionen kaum herumkommen, soweit ich gehört habe, soll das ja mehr in richtung OOP gehen."
- Lassen wir die Gerüchte über die Zukunft bei Seite. Das BlitzMax keinen Gosub Befehl mehr hätte, bezweifele ich stark.

"im übrigen muss ich sagen, spricht es nicht gerade für dich dass du seit ende der 80er programmierst und funktionen nicht kennst bzw sie nicht sinnvoll einsetzen kannst."
- Ich habe nicht gesagt, daß ich seit den 80-er Jahren kontinuierlich programmiere. Ich habe in den 80-er Jahren meine erste Gehversuche gemacht und kleine, nette Spiele programmiert (die Rechner hatten nur ca 36 Kbyte Speicher wo alles samt Grafik reinpassen mußte und da war noch nix mit Maus oder Doublebuffering). Als dann Amiga und PC kam habe ich aufgehört, da die Basicsprachen die ich damals sah mir nicht gefielen und zu der zeit war es wirklich noch nicht möglich in Basic vernünftige Spiele zu machen. Damals mußte man unbedingt in Maschinencode oder C schreiben, sonst war das Programm viel zu langsam. Ich wollte immer nur Spiele schreiben, die sich von professionellen Spielen nicht unterscheiden. Man sollte es einem Spiel nicht ansehen können, daß es ein Basic Spiel ist.
Erst mit den modernen, sehr schnellen und mit viel Speicher ausgerüsteten Rechnern und BlitzBasic ist das Basicprogrammieren wieder richtig interessant geworden. Jetzt ist in Basic fast alles möglich.
Ich habe also bevor ich vor 1,5 Jahren BlitzBasic gekauft habe sehr viele Jahre lang gar nichts gemacht. Es war ein großer Sprung von 80-er Jahre Basic auf Blitz3D.
Funktionen spielten in den 80-er Jahren bei Basic keine (oder kaum) Rolle.
Was Functionen sind habe ich sehr wohl verstanden und ich könnte sie auch vernünftig einsetzen, tue ich aber nicht, weil ich immer noch keinen Grund dafür sehe. Nur weil viele Menschen irgendeine Sache glauben, wird es deswegen noch nicht wahr und nicht alles was du in einem Lehrbuch gelesen hast ist göttliche Weisheit dem man nicht widersprechen darf. Anstat alles blind zu akzeptieren und gehorsam die Herde zu folgen solltest du mal lernen kritischer zu sein und Dinge zu hinterfragen. Du würdest dich wundern, wie Viele Sachen es in der Welt gibt, die obwohl von vielen praktiziert werden, aber trotzdem nicht richtig sind.

"ach ja, und noch was zu deinem case-block: der is auch recht deftig. du solltest dich noch einmal genauer mit dem konzept der arrays auseinandersetzen."
- Was heißt hier "recht deftig" ? Übrigens van Arrays habe ich auch (schon lange) Ahnung. In dem Fall da ist mein Select Case ideal geeignet. Ich kann jetzt nicht alles darüber erklären, aber wir du vielleicht gemerkt hast, geht es da um verschiedenen Bodentypen, wie zum Beispiel Wiese, Straße oder Wasser. Durch diesen Select Case Struktur habe ich da eine Art Tabelle wo ich die einzelnen BodenTypen gut überblicken und aus verschiedenen Gründen auch mal leicht ändern oder asuklammern kann. Das ist nur ein ganz kleines Stück Code herausgerissen aus dem großen Zusammenhang.

Was für mich letztendlich wirklich zählt, das sind die Ergebnisse.
Das Problem ist, daß ich mir noch nich sicher bin, ob ich aus rechtlichen gründen das was ich mache zeigen kann oder nicht. Wenn ich es bald zeigen darf, werde ich es gerne tun und ich wage es vorauszusagen, daß du danach vor Scham erröten wirst Wink

	Omenaton_2	Mi, März 17, 2004 16:13 Antworten mit Zitat
TheShadow hat Folgendes geschrieben: Zitat: Ich bevorzuge JA und NEIN deshalb, weil diese Wörter für mich noch deutlicher ausdrücken was ich ausdrücken will. (Es liegt wohl daran, daß ich viel besser Deutsch als Englisch kann und weil ich das Wort Ja schon sehr viel öfters gehört und benutzt habe als true.) hehe mir ist gar nicht aufgefallen - sag blos dein Code ist kompl. Deutsch/English? Das macht man doch nicht... Dadurch sieht es verkrüppelt aus... Ich persönlich schreibe sogar Kommentare auf English, damit alles einheitlich ist. Ein guter Code sollte so aussehen: Code: [AUSKLAPPEN] [EINKLAPPEN] ;--------------------------------------------------------------------- ;bank: input bank handle ;offset: bank offset ;max: max chars ;RETURN: text string ;--------------------------------------------------------------------- Function memory_peekstr$(bank,offset,max) Local char Local i Local txt$ For i=0 To max-1 char=PeekByte(bank,offset+i) If char=0 Then Return txt$ txt$=txt$+Chr$(char) Next Return txt$ End Function Hi Shadow! Ja, netter Code, ich habe nichts daran auszusetzen. Ich würde das selbe so machen: (es wäre nicht besser oder schlechter, ist nur Geschmackssache.) Code: [AUSKLAPPEN] [EINKLAPPEN] ;*********** Auslesen von Text ********************************** .TextAuslesen For i = 0 To max - 1 char = PeekByte(bank, offset + i) If char = 0 Then return txt$ = txt$ + Chr$(char) Next Return Ich habe dein Code nur ganz kurz angeschaut, ich hoffe mir ist dabei nichts wichtiges entgangen. Die Locals müssen doch in meinem Fall gar nicht definiert werden. Es funktioniert als Subrutine ohne die Locals genauso gut. Das ist sogar Ersparnis. Übrigens ja, mein Code ist komplett Deutsch/Englisch. Ich empfinde das deswegen nicht als verkrüppelt, das ist subjektive Wahrnehmung. Ich schreibe den Code nicht für irgendeinen englischen Schönheistwettbewerb sondern nur für mich.

Omenaton_2

Mi, März 17, 2004 16:13
Antworten mit Zitat

TheShadow hat Folgendes geschrieben:

Zitat:

Ich bevorzuge JA und NEIN deshalb, weil diese Wörter für mich noch deutlicher ausdrücken was ich ausdrücken will. (Es liegt wohl daran, daß ich viel besser Deutsch als Englisch kann und weil ich das Wort Ja schon sehr viel öfters gehört und benutzt habe als true.)

hehe mir ist gar nicht aufgefallen - sag blos dein Code ist kompl. Deutsch/English? Das macht man doch nicht... Dadurch sieht es verkrüppelt aus... Ich persönlich schreibe sogar Kommentare auf English, damit alles einheitlich ist.

Ein guter Code sollte so aussehen:

Code: [AUSKLAPPEN]

;---------------------------------------------------------------------
;bank: input bank handle
;offset: bank offset
;max: max chars
;RETURN: text string
;---------------------------------------------------------------------
Function memory_peekstr$(bank,offset,max)
Local char
Local i
Local txt$

For i=0 To max-1
char=PeekByte(bank,offset+i)
If char=0 Then Return txt$
txt$=txt$+Chr$(char)
Next
Return txt$
End Function

Hi Shadow!

Ja, netter Code, ich habe nichts daran auszusetzen. Ich würde das selbe so machen: (es wäre nicht besser oder schlechter, ist nur Geschmackssache.)

Code: [AUSKLAPPEN]

;************* Auslesen von Text ************************************
.TextAuslesen

For i = 0 To max - 1

char = PeekByte(bank, offset + i)
If char = 0 Then return
txt$ = txt$ + Chr$(char)

Next

Return

Ich habe dein Code nur ganz kurz angeschaut, ich hoffe mir ist dabei nichts wichtiges entgangen.

Die Locals müssen doch in meinem Fall gar nicht definiert werden. Es funktioniert als Subrutine ohne die Locals genauso gut. Das ist sogar Ersparnis.

Übrigens ja, mein Code ist komplett Deutsch/Englisch. Ich empfinde das deswegen nicht als verkrüppelt, das ist subjektive Wahrnehmung. Ich schreibe den Code nicht für irgendeinen englischen Schönheistwettbewerb sondern nur für mich.

	BIG BUG	Mi, März 17, 2004 16:52 Antworten mit Zitat
Die Locals müssen auch bei Funktionen nicht zwangsweise definiert werden. Damit werden diese Variablen aber vom Hauptprogramm abgeschottet. Somit kann man sich keine globalen Variablen "zerschiessen", selbst wenn diese gleich heißen. Das Coding von TheShadow kann aus diesem Grund auch leichter in ein bestehendes Programm eingefügt und später einfacher gewartet werden. Die Lösung mit Gosub funktioniert zwar auch, im Hauptprogramm können aber alle hier verwendeten Variablennamen nicht mehr ohne Nebenwirkungen benutzt werden: bank offset max char i txt$ Man muss also schon beim Einfügen überprüfen, ob eine der benutzten Variablen verwendet wird und ob es hier zu Störungen kommen kann. Bei jeder späteren Änderung muss man hier dann natürlich wieder dran denken. Auch der Aufruf gestaltet sich mit einer Funktion einfacher und übersichtlicher: Code: [AUSKLAPPEN] [EINKLAPPEN] if memory_peekstr$(spielfeld,100,4) = "GRAS" then ... dagegen mit Gosub: Code: [AUSKLAPPEN] [EINKLAPPEN] max = 4 bank = Spielfeld offset = 100 Gosub TextAuslesen if txt$ = "GRAS" then ... Gosub hat aber auch eine Existenzberechtigung, zumal Funktionen in BlitzBasic weder statische Variablen noch eine Referenzübergabe unterstützen. Für die Einteilung von großen Codefetzen z.B. in Menü und Spiel sind Gosubs durchaus sinnvoll und besser zu "handeln" als Funktionen.
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Mi, März 17, 2004 16:52
Antworten mit Zitat

Die Locals müssen auch bei Funktionen nicht zwangsweise definiert werden. Damit werden diese Variablen aber vom Hauptprogramm abgeschottet. Somit kann man sich keine globalen Variablen "zerschiessen", selbst wenn diese gleich heißen.

Das Coding von TheShadow kann aus diesem Grund auch leichter in ein bestehendes Programm eingefügt und später einfacher gewartet werden.

Die Lösung mit Gosub funktioniert zwar auch, im Hauptprogramm können aber alle hier verwendeten Variablennamen nicht mehr ohne Nebenwirkungen benutzt werden:

bank
offset
max
char
i
txt$

Man muss also schon beim Einfügen überprüfen, ob eine der benutzten Variablen verwendet wird und ob es hier zu Störungen kommen kann. Bei jeder späteren Änderung muss man hier dann natürlich wieder dran denken.

Auch der Aufruf gestaltet sich mit einer Funktion einfacher und übersichtlicher:
Code: [AUSKLAPPEN]

if memory_peekstr$(spielfeld,100,4) = "GRAS" then ...

dagegen mit Gosub:
Code: [AUSKLAPPEN]

max = 4
bank = Spielfeld
offset = 100
Gosub TextAuslesen
if txt$ = "GRAS" then ...

Gosub hat aber auch eine Existenzberechtigung, zumal Funktionen in BlitzBasic weder statische Variablen noch eine Referenzübergabe unterstützen.
Für die Einteilung von großen Codefetzen z.B. in Menü und Spiel sind Gosubs durchaus sinnvoll und besser zu "handeln" als Funktionen.

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

Zuletzt bearbeitet von BIG BUG am Mi, März 17, 2004 17:12, insgesamt einmal bearbeitet

	MasterK	Mi, März 17, 2004 17:08 Antworten mit Zitat
also, ich geh jetzt nicht auf alles ein, ich glaube nämlich, du lässt dch eh durch nix überzeugen g Omenaton_2 hat Folgendes geschrieben: Ich kann mir nicht vorstellen, daß in der aller ersten Basic Sprache gleich Functions drin waren, aber Gosubs sicher. nein, das erste basic hat nur gotos Omenaton_2 hat Folgendes geschrieben: In der Subrutine steht doch irgendeine Aktion die mit bestimmten Variablen durchgeführt wird. Man sieht sehr wohl welche diese sind (außerdem weiß man als Programmierer was man macht und warum). Ich habe solche Probleme noch nicht gehabt. du weisst noch, welche variable eine subroutine braucht, die 10000 zeilen weiter unten irgendwo steht die du irgendwann mal implementiert hast??? Omenaton_2 hat Folgendes geschrieben: " funktionen können werte zurückliefern, mit denen man direkt weiter arbeiten, verkürzt den quellcode erneut. " Subrutinen mit Gosubs liefern ganz genauso die Werte zurück wie Functions. Da ist Null Unterschied. also ist mit gosubs zB das möglich (so extrem isses aber auch kein sonderlich guter stil, aber mal überspitzt gezeigt): Code: [AUSKLAPPEN] [EINKLAPPEN] x = blablubb (sin(sin(y) / cos(z)) * hastenichgesehen(x, cos(sin(z) * 6))) wie gesagt, leicht überspitzt (und programmtechnisch sinnlos, solche berechnungen trifft man aber nicht selten) Omenaton_2 hat Folgendes geschrieben: - Wenn mehrere Leute an dem selben Projekt als Programmierer arbeiten dann hat normalerweise jeder seinen Bereich den er erstellt und betreut, das kommt kaum vor, daß mehrere Personen gleichermaßen den vollen Überblick über einen großen Code haben. Es gibt einen Hauptprogrammierer der im großen und ganzen den Code schreibt und andere übernehmen Teilbereiche und liefern diese ab, die werden dann integriert. in der theorie... aber auch nur da. es arbeiten sehr wohl mehrere leute an gleichen teilprojekten, je nach aufwand Omenaton_2 hat Folgendes geschrieben: Das würde aber lediglich daran liegen, das Menschen mit solcher unreifer, verblendeter und intoleranter Einstellung und Schulbücherweisheiten wie du in der Überzahl sind. diese schulbuchweisheiten haben einen grund, denn ohne sie wäre objektorientierte programmierung (siehe nächster punkt) oder gar funktionale programmierung unmöglich. Omenaton_2 hat Folgendes geschrieben: Lassen wir die Gerüchte über die Zukunft bei Seite. Das BlitzMax keinen Gosub Befehl mehr hätte, bezweifele ich stark. wenn bmax wirklich OOP werden soll, wirst du mit gosub nicht weit kommen. und selbst wenn es dass noch gibt (in vb zB gibts das leider auch noch), wirst du ganz zwangsläufig deine programmierung ändern müssen Omenaton_2 hat Folgendes geschrieben: Nur weil viele Menschen irgendeine Sache glauben, wird es deswegen noch nicht wahr und nicht alles was du in einem Lehrbuch gelesen hast ist göttliche Weisheit dem man nicht widersprechen darf. Anstat alles blind zu akzeptieren und gehorsam die Herde zu folgen solltest du mal lernen kritischer zu sein und Dinge zu hinterfragen. Du würdest dich wundern, wie Viele Sachen es in der Welt gibt, die obwohl von vielen praktiziert werden, aber trotzdem nicht richtig sind. nur falls es dich interessiert: ich habe damals in QB nicht über ein lehrbuch von functions erfahren, sondern über den quelltext eines anderen programms. und ich habe sie übernommen weil sie sinnvoll sind. wie gesagt, danach habe ich kein gosub mehr angerührt. Omenaton_2 hat Folgendes geschrieben: In dem Fall da ist mein Select Case ideal geeignet. Ich kann jetzt nicht alles darüber erklären, aber wir du vielleicht gemerkt hast, geht es da um verschiedenen Bodentypen, wie zum Beispiel Wiese, Straße oder Wasser. Durch diesen Select Case Struktur habe ich da eine Art Tabelle wo ich die einzelnen BodenTypen gut überblicken und aus verschiedenen Gründen auch mal leicht ändern oder asuklammern kann. fast jeder case macht das gleiche, da nimmt man arrays. ich hab selbst schon ähnliche karten programmiert, mit arrays ersparst du dir unmengen an zeit. beim erstellen wie beim verwenden Omenaton_2 hat Folgendes geschrieben: Die Locals müssen doch in meinem Fall gar nicht definiert werden. Es funktioniert als Subrutine ohne die Locals genauso gut. Das ist sogar Ersparnis. wie gesagt, du hast die idee hinter funktionen noch nicht ganz verstanden. edit: "Wenn ich es bald zeigen darf, werde ich es gerne tun und ich wage es vorauszusagen, daß du danach vor Scham erröten wirst." na, da bin ich mal wirklich gespannt...

MasterK

Mi, März 17, 2004 17:08
Antworten mit Zitat

also, ich geh jetzt nicht auf alles ein, ich glaube nämlich, du lässt dch eh durch nix überzeugen *g*

Omenaton_2 hat Folgendes geschrieben:

Ich kann mir nicht vorstellen, daß in der aller ersten Basic Sprache gleich Functions drin waren, aber Gosubs sicher.

nein, das erste basic hat nur gotos

Omenaton_2 hat Folgendes geschrieben:

In der Subrutine steht doch irgendeine Aktion die mit bestimmten Variablen durchgeführt wird. Man sieht sehr wohl welche diese sind (außerdem weiß man als Programmierer was man macht und warum). Ich habe solche Probleme noch nicht gehabt.

du weisst noch, welche variable eine subroutine braucht, die 10000 zeilen weiter unten irgendwo steht die du irgendwann mal implementiert hast???

Omenaton_2 hat Folgendes geschrieben:

" funktionen können werte zurückliefern, mit denen man direkt weiter arbeiten, verkürzt den quellcode erneut. "
Subrutinen mit Gosubs liefern ganz genauso die Werte zurück wie Functions. Da ist Null Unterschied.

also ist mit gosubs zB das möglich (so extrem isses aber auch kein sonderlich guter stil, aber mal überspitzt gezeigt):
Code: [AUSKLAPPEN]

x = blablubb (sin(sin(y) / cos(z)) * hastenichgesehen(x, cos(sin(z) * 6)))

wie gesagt, leicht überspitzt (und programmtechnisch sinnlos, solche berechnungen trifft man aber nicht selten)

Omenaton_2 hat Folgendes geschrieben:

- Wenn mehrere Leute an dem selben Projekt als Programmierer arbeiten dann hat normalerweise jeder seinen Bereich den er erstellt und betreut, das kommt kaum vor, daß mehrere Personen gleichermaßen den vollen Überblick über einen großen Code haben. Es gibt einen Hauptprogrammierer der im großen und ganzen den Code schreibt und andere übernehmen Teilbereiche und liefern diese ab, die werden dann integriert.

in der theorie... aber auch nur da. es arbeiten sehr wohl mehrere leute an gleichen teilprojekten, je nach aufwand

Omenaton_2 hat Folgendes geschrieben:

Das würde aber lediglich daran liegen, das Menschen mit solcher unreifer, verblendeter und intoleranter Einstellung und Schulbücherweisheiten wie du in der Überzahl sind.

diese schulbuchweisheiten haben einen grund, denn ohne sie wäre objektorientierte programmierung (siehe nächster punkt) oder gar funktionale programmierung unmöglich.

Omenaton_2 hat Folgendes geschrieben:

Lassen wir die Gerüchte über die Zukunft bei Seite. Das BlitzMax keinen Gosub Befehl mehr hätte, bezweifele ich stark.

wenn bmax wirklich OOP werden soll, wirst du mit gosub nicht weit kommen. und selbst wenn es dass noch gibt (in vb zB gibts das leider auch noch), wirst du ganz zwangsläufig deine programmierung ändern müssen

Omenaton_2 hat Folgendes geschrieben:

Nur weil viele Menschen irgendeine Sache glauben, wird es deswegen noch nicht wahr und nicht alles was du in einem Lehrbuch gelesen hast ist göttliche Weisheit dem man nicht widersprechen darf. Anstat alles blind zu akzeptieren und gehorsam die Herde zu folgen solltest du mal lernen kritischer zu sein und Dinge zu hinterfragen. Du würdest dich wundern, wie Viele Sachen es in der Welt gibt, die obwohl von vielen praktiziert werden, aber trotzdem nicht richtig sind.

nur falls es dich interessiert: ich habe damals in QB nicht über ein lehrbuch von functions erfahren, sondern über den quelltext eines anderen programms. und ich habe sie übernommen weil sie sinnvoll sind. wie gesagt, danach habe ich kein gosub mehr angerührt.

Omenaton_2 hat Folgendes geschrieben:

In dem Fall da ist mein Select Case ideal geeignet. Ich kann jetzt nicht alles darüber erklären, aber wir du vielleicht gemerkt hast, geht es da um verschiedenen Bodentypen, wie zum Beispiel Wiese, Straße oder Wasser. Durch diesen Select Case Struktur habe ich da eine Art Tabelle wo ich die einzelnen BodenTypen gut überblicken und aus verschiedenen Gründen auch mal leicht ändern oder asuklammern kann.

fast jeder case macht das gleiche, da nimmt man arrays. ich hab selbst schon ähnliche karten programmiert, mit arrays ersparst du dir unmengen an zeit. beim erstellen wie beim verwenden

Omenaton_2 hat Folgendes geschrieben:

Die Locals müssen doch in meinem Fall gar nicht definiert werden. Es funktioniert als Subrutine ohne die Locals genauso gut. Das ist sogar Ersparnis.

wie gesagt, du hast die idee hinter funktionen noch nicht ganz verstanden.

edit:
"Wenn ich es bald zeigen darf, werde ich es gerne tun und ich wage es vorauszusagen, daß du danach vor Scham erröten wirst."
na, da bin ich mal wirklich gespannt... Smile

	Omenaton_2	Mi, März 17, 2004 19:00 Antworten mit Zitat
Hi BigBug! Du hast mit den meisten Sachen Recht. Ich hätte aber noch paar Anmerkungen. "Die Lösung mit Gosub funktioniert zwar auch, im Hauptprogramm können aber alle hier verwendeten Variablennamen nicht mehr ohne Nebenwirkungen benutzt werden: bank offset max char i txt$ " Also, "bank", "offset" und "max" sind Variablen die nicht in der Function definiert werden, hier werden sie nur benutzt (ich meine, die müssen vor Aufruf der Function einen Wert bekommen haben). Diese 3 Variablen können so weit ich es beurteilen kann auch in der Version mit Function nicht ohne Nebenwirkungen ganz anders benutzt werden. Die sind einmalig, die sind "Globals". Die stehen für eine ganz bestimmte Sache. Was die 3 Locals, Char, i und txt% angeht: Die können bei der Gosub-Variation fast ohne Nebenwirkungen überall benutzt werden. Das einzige was nicht geht ist, diese einmal als Integer, ein anderes Mal als Flot zu benutzen, dann gibts Ärger. Oder wo siehst du konkret Nebenwirkungen ? "i" wird an der Stelle "For i = 0 To max-1" (am Anfang) als Null definiert, egal was "i" wo anders für eine Rolle spielt. "Char" wird beim Auslesen der Bytes definiert, ebenfalls egal was Char früher an anderer Stelle für Wert hatte oder wofür es stand. "txt$" muß als einzige auch in der Gosub-Version beim Beginn der Subrutine (oder vor dem Sprung zu der Subrutine) irgendwie einen Wert bekommen, oder es ist einfach leer (was wahrscheinlich in diesem fall sogar erwünscht ist). Bei txt$ muß man tatsächlich aufpassen. "Auch der Aufruf gestaltet sich mit einer Funktion einfacher und übersichtlicher: Code: [code] if memory_peekstr$(spielfeld,100,4) = "GRAS" then ... [code] dagegen mit Gosub: Code: [code] max = 4 bank = Spielfeld offset = 100 Gosub TextAuslesen if txt$ = "GRAS" then ... "[code] Das muß eine sehr subjektive Sache sein, was übersichtlicher ist, denn ich finde das die Version unten, wo alles schön sauber aufgelistet ist, übersichtlicher ist. Mehrere, kurze Zeilen sind verständlicher als eine längere, kompliziertere Zeile. Es ist aber wahr, daß die Version oben etwas kürzer ist.

Omenaton_2

Mi, März 17, 2004 19:00
Antworten mit Zitat

Hi BigBug!

Du hast mit den meisten Sachen Recht.

Ich hätte aber noch paar Anmerkungen.

"Die Lösung mit Gosub funktioniert zwar auch, im Hauptprogramm können aber alle hier verwendeten Variablennamen nicht mehr ohne Nebenwirkungen benutzt werden:

bank
offset
max
char
i
txt$ "

Also, "bank", "offset" und "max" sind Variablen die nicht in der Function definiert werden, hier werden sie nur benutzt (ich meine, die müssen vor Aufruf der Function einen Wert bekommen haben). Diese 3 Variablen können so weit ich es beurteilen kann auch in der Version mit Function nicht ohne Nebenwirkungen ganz anders benutzt werden. Die sind einmalig, die sind "Globals". Die stehen für eine ganz bestimmte Sache.

Was die 3 Locals, Char, i und txt% angeht:
Die können bei der Gosub-Variation fast ohne Nebenwirkungen überall benutzt werden. Das einzige was nicht geht ist, diese einmal als Integer, ein anderes Mal als Flot zu benutzen, dann gibts Ärger. Oder wo siehst du konkret Nebenwirkungen ?
"i" wird an der Stelle "For i = 0 To max-1" (am Anfang) als Null definiert, egal was "i" wo anders für eine Rolle spielt.
"Char" wird beim Auslesen der Bytes definiert, ebenfalls egal was Char früher an anderer Stelle für Wert hatte oder wofür es stand.
"txt$" muß als einzige auch in der Gosub-Version beim Beginn der Subrutine (oder vor dem Sprung zu der Subrutine) irgendwie einen Wert bekommen, oder es ist einfach leer (was wahrscheinlich in diesem fall sogar erwünscht ist). Bei txt$ muß man tatsächlich aufpassen.

"Auch der Aufruf gestaltet sich mit einer Funktion einfacher und übersichtlicher:
Code:

[code] if memory_peekstr$(spielfeld,100,4) = "GRAS" then ... [code]

dagegen mit Gosub:
Code:

[code]
max = 4
bank = Spielfeld
offset = 100
Gosub TextAuslesen
if txt$ = "GRAS" then ... "[code]

Das muß eine sehr subjektive Sache sein, was übersichtlicher ist, denn ich finde das die Version unten, wo alles schön sauber aufgelistet ist, übersichtlicher ist. Mehrere, kurze Zeilen sind verständlicher als eine längere, kompliziertere Zeile.
Es ist aber wahr, daß die Version oben etwas kürzer ist.

	TheShadow Moderator	Mi, März 17, 2004 19:07 Antworten mit Zitat
ich glaube das hat keinen Sinn... Naja früher auf AmigaBasic/QB habe ich auch nie Funktionen benutzt - weil ich die nicht kannte... (AB hatte glaube gar keine). Dann, als ich die in QB gefunden habe, habe ich die natürlich ausprobiert und habe festgestellt, dass es so wesentlich einfacher ist... Heute würde ich sagen, dass es mir NIEMALS möglich wäre ein großes Programm ohne Funktionen zu coden... Code-Ersparnis interessiert mich nicht - viel wichtiger ist mir, dass es keine Variablenüberschneidungen gibt (nur DIM+ globale Variablen sind mir noch seeehr unsympatisch - weil alle Funktionen dadrauf Zugriff haben...). zudem finde ich, dass Funktionen deutlich besser aufgerufen werden können: memory_peekstr$(mybank,myoffset,100) - ist einfach eine Zeile - schön übersichtlich. Dass eine funktion mehr overhead produziert interessiert mich auch nicht - Zeitkritische Codes werden immer inline geschrieben...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mi, März 17, 2004 19:07
Antworten mit Zitat

ich glaube das hat keinen Sinn...

Naja früher auf AmigaBasic/QB habe ich auch nie Funktionen benutzt - weil ich die nicht kannte... (AB hatte glaube gar keine). Dann, als ich die in QB gefunden habe, habe ich die natürlich ausprobiert und habe festgestellt, dass es so wesentlich einfacher ist... Heute würde ich sagen, dass es mir NIEMALS möglich wäre ein großes Programm ohne Funktionen zu coden... Code-Ersparnis interessiert mich nicht - viel wichtiger ist mir, dass es keine Variablenüberschneidungen gibt (nur DIM+ globale Variablen sind mir noch seeehr unsympatisch - weil alle Funktionen dadrauf Zugriff haben...). zudem finde ich, dass Funktionen deutlich besser aufgerufen werden können: memory_peekstr$(mybank,myoffset,100) - ist einfach eine Zeile - schön übersichtlich. Dass eine funktion mehr overhead produziert interessiert mich auch nicht - Zeitkritische Codes werden immer inline geschrieben...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	MasterK	Mi, März 17, 2004 19:48 Antworten mit Zitat
Omenaton_2 hat Folgendes geschrieben: Also, "bank", "offset" und "max" sind Variablen die nicht in der Function definiert werden, hier werden sie nur benutzt (ich meine, die müssen vor Aufruf der Function einen Wert bekommen haben). Diese 3 Variablen können so weit ich es beurteilen kann auch in der Version mit Function nicht ohne Nebenwirkungen ganz anders benutzt werden. Die sind einmalig, die sind "Globals". Die stehen für eine ganz bestimmte Sache. halt mal, kennt BB denn nur call by reference? wenn nicht, laberst du müll. also, diese ratschläge, die dir hier alle geben, sind ehrliche gutgemeinte ratschläge. niemand will hier deinen codestil versauen, im gegenteil. aber wer ratschläge nicht annehmen will, muss es eben durch fehler lernen. das heisst zusätzlicher zeitaufwand, mühen, und deine codes kannst du später dann weghauen, oder du schreibst sie aufwändig um.

MasterK

Mi, März 17, 2004 19:48
Antworten mit Zitat

Omenaton_2 hat Folgendes geschrieben:

Also, "bank", "offset" und "max" sind Variablen die nicht in der Function definiert werden, hier werden sie nur benutzt (ich meine, die müssen vor Aufruf der Function einen Wert bekommen haben). Diese 3 Variablen können so weit ich es beurteilen kann auch in der Version mit Function nicht ohne Nebenwirkungen ganz anders benutzt werden. Die sind einmalig, die sind "Globals". Die stehen für eine ganz bestimmte Sache.

halt mal, kennt BB denn nur call by reference? wenn nicht, laberst du müll.

also, diese ratschläge, die dir hier alle geben, sind ehrliche gutgemeinte ratschläge. niemand will hier deinen codestil versauen, im gegenteil. aber wer ratschläge nicht annehmen will, muss es eben durch fehler lernen. das heisst zusätzlicher zeitaufwand, mühen, und deine codes kannst du später dann weghauen, oder du schreibst sie aufwändig um.

	IonPainter	Mi, März 17, 2004 19:55 Antworten mit Zitat
jao half-life 2 mit sicherheit, auch blitz3d is mit c++ und auch dbp eigentlich alles große komerziell erfolgreiche

IonPainter

Mi, März 17, 2004 19:55
Antworten mit Zitat

jao half-life 2 mit sicherheit, auch blitz3d is mit c++ und auch dbp Wink

eigentlich alles große komerziell erfolgreiche

Gehe zu Seite Zurück 1, 2, 3, 4

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Seid ihr alle zufrieden mit BlitzBasic???