Messages

X_SCALING und X_SCALEMODEL unterscheiden sich in der Nutzung grundsätzlich und haben sicher beide ihre Berechtigung. Obwohl GLBasic mit möglichst wenigen Befehlen auskommen soll, würde ich dafür plädieren, beide zu behalten (solange es nicht zu viel Aufwand für dich wäre). Natürlich müssten dann auch beide Funktionieren.
Wäre die Verlangsamung denn sehr signifikant? Und würde sie den Befehl generell betreffen, oder nur beim Zeichnen von Schatten auftreten? Letzteres wäre sicherlich akzeptabel, da man den Spieler ohnehin die Chance geben sollte die Schatten zu deaktiveren, wenn seine Rechenleistung nicht ausreichend ist.
Das mit dem Nebel ist natürlich auch keine gute Nachricht, auch hier wäre wieder die Frage: wie stark fiele die Verlangsamung aus und ließe sie sich auf die Nutzung von Schatten beschränken?
Der mich am meisten störende Bug in der Schattenengine ist aber ohnehin der Umstand, dass Schatten werfende Körper immer dunkel sind (da sie sich vermutlich selbst vollständig in Schatten hüllen). Würde dies behoben werden, wäre das für mich persönlich schon ein großer Schritt nach vorn.

Grüße.

Ich habe jetzt V10 getestet, konnte aber keine Veränderungen zu meinem Test hier feststellen, die Probleme bestehen immer noch in der dort beschriebenen Form. Ist damit zu rechnen, dass sich dies in der nächsten Zeit noch einmal angeschaut wird? Ich bin immer gerne bereit diverse Tests durchzuführen, falls es nötig ist.

Grüße.

Backslider ich vermute, dass du damit recht haben könntest, drückt man F10 und dann zum Beispiel Cursor runter, kann man zwischen verschieben, minimieren, schließen,... wählen. Ist also irgendein windowseigenes Ding, aber es scheint möglich zu sein, dies zu deaktivieren, da F10 beispielsweise in Blitz3d diesen Effekt nicht hat.

Drückt man in laufendem Programm F10, wird das Programm so lange angehalten, bis wieder eine Taste gedrückt wird. Tritt sowohl im Debug, als auch im Releasemodus auf (sowohl in V9, als auch in V10), jedoch nur im Fenstermodus. Ist das ein Feature?

1. Ah, das funktioniert natürlich auch. Wobei F1 ja trotzdem frei ist. 
2. Gerade festgestellt bei Strg+G wird auch in den falschen Type gesprungen.
3. Die Ini wird gespeichert, wie es sein soll, nur wird danach eben unnötigerweise neu compiliert.
4. Ja, auto-auto war gemeint.

Danke für die Antworten.

Wenn ich das richtig gesehen habe, dann gab es in den neueren Betas nach 9.052 keine Änderungen an der 3D/Schattenengine? Wird daran im Moment gearbeitet oder haben andere Bereiche höhere Priorität?

Grüße.

Warum soll es denn versteckt sein? Dachte es soll ein freies und für alle zugängiges Gemeinschaftsprojekt werden? Sicher kann es nerven, wenn jeder Versuch eines Zwischenschritts beäugt und kommentiert wird, aber so schlimm wird es sicher nicht werden und der Blich von außen ist fast immer hilfreich. Ich denke ein eigener Unterbereich im Forum wäre ausreichend.

Es gab ja schon einige Minecraftversuche hier, hat dazu schon jemand etwas weiterführendes, dass auch bei größeren Menge flüssig arbeitet?

Keine schon blumige Bewerbung, aber dafür eine mit Wunsch des Einsatzgebiets wurde von mir bereits eingereicht. Ich würde gerne Code produzieren.

Grundsätzlich hätte ich auch Interesse, würde mich zum lösen kleinerer, klar abgesteckter Probleme anbieten.

Ich hätte ein paar Änderungsvorschläge:

1. Wenn man bei einem GLBasic-Befehl F1 drückt kommt man zur zugehörigen Hilfeseite, drückt man bei einer eigenen Funktion/Sub F1 wird jedoch nur die Hilfe (mit der aktuell geöffneten Seite) nach vorn geholt.
Ich hätte gern, dass wenn ich beim Nutzen einer eigenen Funktion F1 drücke, der Cursor automatisch zur Funktionsdeklaration springt. Sollte natürlich auch bei Funktionen funktionieren, die in anderen .gbas Dateien deklariert wurden.

2. Befindet sich der Curser auf einem Funktionsnahmen erscheint dieser ja unten links mit seinen Parametern und eventuellen Kommentaren. Gibt es jedoch in mehreren Types gleichnamige Funktionen, wird immer die zuerst erstellte (?) angezeigt, auch wenn es sich eigentlich um eine andere handelt, was im Falle unterschiedlicher Parameter verwirrend sein kann. Es wäre natürlich angenehmer, wenn immer die aktuell verwendete Angezeigt werden würde, jedoch vermute ich, dass dies zu aufwändig zu implementieren wäre? Wobei dieser Punkt auch für die Umsetzung von 1. relevant ist...

3. Ich speichere gern Optionen und ähnliches in .ini-Dateien, welche ich dabei auch gern in der IDE öffne. nehme ich jetzt lediglich Änderungen in der Ini vor und drücke dann F5, wäre es wünschenswert, dass die IDE die Ini zwar speichert jedoch den Code nicht erneut compiliert (ist ja nicht nötig, da keine Änderungen vorgenommen wurden) sondern die .exe sofort startet. Sollte natürlich nicht nur für Inis, sondern sämtliche nicht .gbas (oder .gbap) Dateien so sein.

Gibt es eigentlich mittlerweile eigentlich die geplante (optional aktivierbare) Autovervollständigung?

Wäre schön, wenn das eine oder andere umgesetzt werden könnte, vielen Dank.
Grüße

This dont work as expected, it should be:

Code (glbasic) Select Expand

FUNCTION DrawOval%: x, y, w, h, col%

w = w/2
h = h/2
INC x, w
INC y, h

STARTPOLY -1, 0
POLYVECTOR x,y, 0,0,col
FOR phi = 0 TO 360 STEP 5 // how poly do you want it?
POLYVECTOR x+COS(phi)*w, y-SIN(phi)*h, 0,0,col
NEXT
ENDPOLY

ENDFUNCTION

Or if you want to include drawing arcs:

Code (glbasic) Select Expand

FUNCTION DrawOval%: x, y, w, h, col%, arc=360, arcs=0 // arc MUST be >0! arcs=starting of the arc 0=top

w = w/2
h = h/2
INC x, w
INC y, h
INC arcs, 90
INC arc, arcs

STARTPOLY -1, 0
POLYVECTOR x,y, 0,0,col
FOR phi = arcs TO arc STEP 5 // how poly do you want it?
POLYVECTOR x+COS(phi)*w, y-SIN(phi)*h, 0,0,col
NEXT
ENDPOLY

ENDFUNCTION

If you need more speed, change the STEP 5 to higher number or try QSIN and QCOS.

Grundsätzlich hätte ich auch Interesse, würde mich zum lösen kleinerer, klar abgesteckter Probleme anbieten.
Eine saubere Modularisierung ist natürlich notwendig, damit die einzelnen Codeschnipsel verschiedener Mitwirkender zusammengesetzt werden können. Und jemand muss den Hut auf haben, aber das wurde ja bereits angesprochen.

Eine Belebung der deutschen Community ist sicher eine gute Idee, jedoch bin ich mir nicht sicher, ob jetzt der richtige Moment zum Start eines 3D-Projekts ist. In einer Menge der 3D-Befehle scheinen Fehler zu stecken, deren Behebung im Moment noch unklar ist. Möglicherweise wird es weitere Befehle geben, oder einige werden ersetzt (bspw. wird X_SCALEMODEL X_SCALING ersetzen?). Ein Projekt jetzt zu beginnen und nach Update der 3D Befehle möglicherweise umschreiben zu müssen, kann kann dann sehr frustrierend sein, daher liegen meine eigenen 3D-Projekte auch z.Z. nahezu auf Eis und auch von anderen Forumsmitgliedern weiß ich, dass die 3D-Engine von GLBasic z.Z. nach Möglichkeit nicht genutzt wird.

Aber Ideen können natürlich trotzdem gesammelt werden.

Die Aktuelle Beta hat die Nummer 9.052, einen Log der genauen Änderungen gibt es glaube ich noch nicht.
Zu finden ist sie (wie vorherige Betas) hier: http://www.glbasic.com/beta/glbasic_sdk.exe

Habe mir die Beta (V9.052) gezogen und die 3D-Änderungen ausprobiert. Bin damit nicht zufrieden, wurde das nicht vollständig implementiert?

Allgemein zur Beta:
- Installer behauptet er würde V9.033 installieren.
- Nachdem ein Programm compiliert, gestartet und wieder beendet wurde, reagiert die IDE manchmal für eine zweistellige Sekundenzahl nicht, manchmal hilft nur noch ein beenden des Prozesses. Ich benutze in Win 7 64 Bit das dringend mal neu aufgesetzt werden müsste, kann also auch an meinem System liegen, jedoch gab es das Problem bei V9.040 nicht.

Zu 3d in der Beta und den bisher von mir gemeldeten Fehlern (detailliertere Beschreibungen und Bilder/Beispiele, siehe frühere Posts), soweit ich es bisher testen konnte:
1. Schatten skalierter Objekte werden in falscher Größe und/oder an falsche Stelle projiziert.
- bei x_scalemodel behoben, jedoch scheint x_scalemodel nur vor dem ersten x_drawobj zu funktionieren. Versucht man ein Objekt später noch einmal zu skalieren, dann ändert sich zwar der die Größe des Schattens korrekt, jedoch bleibt die Größe des (sichtbaren) Objekts gleich.
- bei x_scaling keine Veränderung, Problem besteht weiterhin. Ich vermute der Befehl soll ersetzt werden? Ich würde ihn nach Möglichkeit jedoch gern behalten wollen.

2. Objekte die Schatten werfen sollen sind zu dunkel / liegen immer selbst im Schatten.
- keine Veränderung / Problem besteht weiterhin.

3. Schatten werden von Nebel nicht beeinträchtigt, sind immer zu sehen.
- keine Veränderung / Problem besteht weiterhin.

4. Schatten werden an falsche Stelle projiziert.
- sie 1.

5. x_sprite wird falsch beleuchtet.
- Problem behoben, funktioniert wie es soll.

6. x_line färbt die ganze Szene in der eigenen Farbe ein. Tritt nur im Releasemodus auf, nicht bei aktiviertem Debugger.
- keine Veränderung / Problem besteht weiterhin.

Außerdem neu:
7. x_getface funktioniert als ob das Objekt sich auf der Position 25,0,0 befinden würde und nicht mehr wie bisher üblich auf der Position 0,0,0 (siehe meine Funktion shadowlines()).

Grüße.

Bumblebee, interessant ist auch, dass Wumbo einige male korrekt beleuchtet, d.h. nicht "zu dunkel" gezeichnet wird. Das habe ich noch gar nicht gesehen, bisher wurde bei mir jedes Objekt zu dunkel dargestellt (wenn es Schatten werfen soll...), ich habe es auf 3 Grafikkarten probiert... Was mich zu der Frage führt: warum tritt das bei dir (einige mal) nicht auf?

Noch was anderes: funktioniert bei jemanden Bumpmapping korrekt? Wenn ich z.B. das samples/3D/BumpMapping nehme, dann wird zwar das Bumpmapping an sich korrekt durchgeführt, jedoch wird das Objekt (+eigentliche Textur) dann bunt (grün/blau/lila) texturiert.

Je mehr ich mich mit GLBasics 3D Befehlen veschäfftige, desto mehr glaube ich, dass diese in weiten Teilen überarbeitet werden müssten. Schade bei dieser ansonsten vorzüglichen Sprache.