Topics

[vorerst zwar nur für windows - aber eine version für OSX ist in Planung - sobald die Windows-version zufriedenstellend ist werde ich schauen wie weit sich das umsetzen lässt - erste Tests sehen gut aus!]

Da der bei GLBasic mitgelieferte Zeichensatzgenerator (Tools\DiNGSFont.exe) leider nicht mit echtem Alpha-Werten umgehen kann (obwohl von GLBasic unterstützt) habe ich mir schon vor einiger zeit ein eigenes Tool geschrieben -  das habe ich jetzt etwas aufgeräumt, an Dingsfont angepasst und kompatibel gemacht:

vorerst zwar nur für windows - aber eine version für OSX ist in Planung - sobald die Windows-version zufriedenstellend ist werde ich schauen wie weit sich das umsetzen lässt - erste Tests sehen gut aus!

Anderungen zum ursprünglichen Dingsfont:
- kann 'DiNGSFont.exe' ersetzen (übernimmt den übergebenen pfad):
- Fullscreen & zoombar
- vollen Alpha Support -> ALPHAMODE -.999
- Schatten in alle Richtungen mit Alpha
- Farbverlauf für Font, Outline1 & Outline2
- Texture für Font
- Textfeld zum testen des Fonts (mit und ohne kerning)

v2:
- komplett neu aufgesetzt
- einfaches Licht bzw Kanten eingefügt.
- Gradient nun auch für Outline1 und Outline2
- Gradient lässt sich nun über einen (einfachen Editor) bearbeiten
- 4 Gradient-styles (linear, circular, boxed, conical)
- Texture für Font
- Alpha-support für font
- 2 verschiedene Schatten-modi (Clean und Blur)
- einfaches farbiges Licht (Kanten)
- abspeichern und laden von Styles (ice.glfont2 & bend.glfont2 gebe ich mal mit... so als beispiel  ) - Texture wird dabei noch nicht unterstützt...

v3:
- Unterstützung für Charsets
- CHR$169 (Copyright) auf 127 gemapt
- Photoshop-style Gradient-editor + updated Coloreditor (man kann einzelnde Verläufe exportieren und wieder laden)
- diverse kleine bugs gefixt

v4:
- Check für das richtige Seitenverhältnis bei Fonts mit 256 zeichen
- diverse Fixes
- alle Zeichen können frei abgeschalten und neu gemappt werden (Maus auf das Zeichen und rechte Mausetaste)
- Cleartype-Antialiasing (WinXP oder höher ist Voraussetzung) hinzugefügt - bringt bessere Ergebnisse aber verwischt kleinere Fonts stärker -> ausprobieren was besser ausschaut!
- beim speichern und laden von Styles (*.glfont2) wird nun auch auf die texture (wenn genutzt) als *.texture im gleichen verzeichnis zugegriffen (es handelt sich dabei um ein *.png)
- das Tool greift nun auf den Unterordner 'DF_RESRC' (=DingsFont_Resource) zu
- einige neue Styles (Blood oder Dark Chrome schauen gut aus), Farbverläufe (diese werden bei Start des GradienEditors aufgelistet) und Texturen hinzugefügt
- im ColorEditor gibt es ein neues aber nicht dokumentiertes Feature - einfach mit der Mause auf eine Farbe auf dem Screen und die rechte Maustaste drücken.

v5:
- "offizielles" GLB-Icon
- neuer About-Screen mit GLB-logo und link zu diesem Thread
- alle möglichen Sicherheitsabfragen eingefügt um den Verlust von geänderten Styles zu vermeiden (new, quit, load...)
- speichern der Fonts nun auch als *.bmp mit 24bit oder 8bit
- die "niedrigste" Farbe ist RGB(4, 4, 4) und wird automatisch gesetzt - damit kann auch ein schwarzer Font (=RGB(4,4,4)) auf einem schwarzen Hintergrund (=RGB(0,0,0)) einen schwarzen Schatten (=RGB(4,4,4)) werfen und GLB versteht das! ;-)
- pixelgenaue Abfrage des größten Zeichen und daraus Berechnung der Imagehöhe -> kleinere Images
- Positionierung der Zeichen erfolgt nun pixelgenau links/oben abhängig vom größten Zeichen

v6:
- mehrsprachig (beim starten wird immer eine interne englische Sprachdatei geladen, einfach eine *.lng unter DF_LANG\ kopieren &  editieren, diese wird später beim starten automatisch eingebunden)
- das TestFont-Bild lässt sich jetzt speichern (Rechtsklick -> Save)
- neue Remap-Funktion, im neuen Requester lassen sich nun Zeichen direkt eingeben oder per [CTRL-V] einfügen (weil unicode funktioniert dann auch mit CHIN, JAP, THAI, URDU usw...)
- die geänderte Zeichentabelle lässt sich nun abspeichern

[attachment deleted by admin]

hi,

habe seitein paar wachen wenig mit GLB machen können , gestern endlich wieder zeit gefunden und das autoupdate durchgeführt auf 7.320 (vorversion bin ich mir jetzt nicht sicher, war aber schon 7)... und da geht der print befehl nicht mehr! um auszuschließen dass es an meinem system liegt (win7-x64) das noch verfügbare installation-file 7.230 runtergeladen und da funktioniert das mit dem print, update auf 7.320 - kein print!

Code (glbasic) Select Expand

PRINT "Hallo Welt", 100, 100
SHOWSCREEN
MOUSEWAIT

hilfe, ohne print muss ich mit der älteren version arbeiten da ich print als debug-anzeige auf dem screen brauche! 

habe gesehen dass der bug schon 7.301 da war... und es einen workaround gibt: http://www.glbasic.com/forum/index.php?topic=4347.0... dann eben ein bug-resubmit! 

hi,
BREAK ist zwar eine super sache aber noch besser wäre ein optionaler Paramter mit dem man angeben kann um wieviele 'Ebenen' man herauspringen will... gerade bei einer verschachtelten FOR/NEXT -Schleife (zb um ein 2D-Array von Level-Daten durchzurattern) wäre ein BREAK 2 sinnvoll! ich kenne das von PB und ärgere mich immer wieder ein wenig wenn ich es unter GLB brauche!

[ABER]

den angehangenen Code mal f?r das iPhone compilieren und starten,
normale funktion: programm starten und mit einem druck auf das rote viereck beenden ABER:

- position des roten vierecks (exit button) merken
- 'power off' dr?cken -> standby
- mit home wieder aktivieren -> rotes viereck befindet sich an einer anderen stellen und auch der timestamp (oben rechts) hat sich ver?ndert!?
- jetzt einmal auf das rote viereck, dr?cken das programm beendet aber springt nochmal an mit einem dritten timestamp und dritter position des roten vierecks!?
- nochmals dr?cken und das programm beendet endg?ltig...

hmm, ist das ein bug oder habe ich was ?bersehen?
der fehler tritt (zumindest bei mir) auf dem iphone 3g sowie auf dem ipod touch 2g auf... egal ob ?ber das SDK kopiert und gestartet oder als IPA...

Code (glbasic) Select Expand

SETSCREEN 320,480,0
LIMITFPS 60

SYSTEMPOINTER TRUE

GLOBAL TIME$ = PLATFORMINFO$("TIME")
PRINT TIME$, 0, 0

GLOBAL EXIT_XPOS, EXIT_YPOS
EXIT_XPOS = RND(320-30)
EXIT_YPOS = RND(480-30-24)+24

DIM MOUSEINPUT[GETMOUSECOUNT()][4]

WHILE TRUE

FOR i = 0 TO GETMOUSECOUNT()-1
MOUSESTATE MOUSEINPUT[i][0], MOUSEINPUT[i][1], MOUSEINPUT[i][2], MOUSEINPUT[i][3]
IF MOUSEINPUT[i][2] > 0 AND BOXCOLL(EXIT_XPOS, EXIT_YPOS, 30, 30, MOUSEINPUT[i][0], MOUSEINPUT[i][1], 5, 5) THEN END
NEXT

DRAWRECT EXIT_XPOS, EXIT_YPOS, 30, 30, RGB(255, 0, 0)

PRINT TIME$, 0, 0
PRINT EXIT_XPOS, 0, 8
PRINT EXIT_YPOS, 0, 16

SHOWSCREEN

WEND
END

ich schreibe es mal auf deutsch!

Code (glbasic) Select Expand

Holt den Wert von "schluessel$" der Sektion "sektion$". [b]Wenn entweder sektion$ oder schluessel$ nicht vorhanden sind, wird "NO_DATA" zur?ckgegeben.[/b]

w?re es m?glich da einen (optionalen?) dritten paramter einzuf?gen so dass statt NO_DATA ein definierter standardwert zur?ckgegeben wird? so m??te nicht JEDER INIGET$-befehl zwingend auf NO_DATA ?berpr?ft werden!

w?re super!

hi@all,
ich arbeite rein auf softwarebasis also ohne die 3d-unterst?tzung von GLB - und jetzt habe ich da ein kleines(?) problem.

mein 3d-'welt' f?hrt eine etwas umst?ndliche rotation (ohne translation) aus mit verschiedenen gr??en die da einfluss haben. jetzt wollte ich allerdings nicht jedesmal die welt mehrere mal mitdrehen (aus performancegr?nden) sondern dachte einfach zwei dummy-punkte [100,0,0] & [0,100,0] zu drehen aus denen ich dann die vollst?ndige rotation r?ckrechnen kann um diese dann auf meine 'welt' anzuwenden...
aber ich bekomme es einfach nicht hin!!!!
hat jemand eine idee oder gar eine l?sung?

[überlappen]

mir ist eine abweichung bei dem befehl BOXCOLL aufgefallen, die function stimmt nicht mit der beschreibung überein:

" Überprüft, ob sich 2 Rechtecke überlappen... "

allerdings gibt der befehl auch TRUE zurück wenn sie die Rechteckte nur berühren.

start:
   IF BOXCOLL( 0,0, 16, 16, 16, 16, 16, 16)
       PRINT "collide!", 100, 100
   ENDIF
   SHOWSCREEN
GOTO start

ich wollte ein objeckt an einer "wand" entlang gleiten lassen was damit allerdings nichtböglich ist! :-( der workaround für mich ist es eines der objecte als "x +1, y+2, 14, 14 " zu deklrarieren anstatt "x, y, 16, 16"!

bug oder muss das so sein?

'bin gerade dabei ein wenig was mit dem GP2X anzustellen und wollte sowas wie CAMELTRY machen wobei sich der complette screen rotieren läßt... alles schön und gut aber auf dem GP2X erreicht der befehl ROTOSPRITE (selbst bei SMOOTHSHADING FALSE) nur 5 FPS (bei einer spritegröße von 400x400 = completter screen)... mache ich das ganze mit STARTPOLY/ENDPOLY ebenfalls mit dem kompletten 400x400-sprite erreiche ich 15 FPS!?!? allerdings müßte doch gerade die funktion STARTPOLY/ENDPOLY um einiges aufwendiger sein (textur-parameter & verzerrung) als ROTOSPRITE, oder? falls ich recht habe würde ich mich sehr über eine nachbesserung freuen!

test.zip - 1.16MB (rechts/links = drehen mit ROTOSPRITE, beim halten der rechten schulterstaste wird das ganze mit STARTPOLY durchgeführt - da sieht man den unterschied!?!)

["test.gbas"(31) error : wrong argument type : DIMDEL, arg no: 2]

habe mal mit linkedlists etwas rumprobiert und mir was zusammengebastelt... funktioniert soweit ganz gut aber irgendwie komme ich mit DIMDEL nicht zurecht. es kommt immer der fehler "test.gbas"(31) error : wrong argument type : DIMDEL, arg no: 2 obwohl es eigentlich richtig sein sollte - wo liegt mein fehler???

Code (glbasic) Select Expand

TYPE tSTAR
x; y; gx; gy
ENDTYPE

GLOBAL STARList[] AS tSTAR

SETSCREEN 320,240,0
LIMITFPS 15

WHILE TRUE
ADDSTAR(RND(316), RND(236))
MOVESTAR()
DRAWSTAR()
PRINT LEN(STARList[]), 4, 4
SHOWSCREEN
WEND

FUNCTION DRAWSTAR:
LOCAL b AS tSTAR
FOREACH b IN STARList[]
DRAWRECT b.x, b.y, 4, 4, RGB(255, 255, 255)
NEXT
ENDFUNCTION

FUNCTION MOVESTAR:
LOCAL b AS tSTAR
FOREACH b IN STARList[]
b.x = b.x + b.gx
b.y = b.y + b.gy
IF b.x > 320 OR b.x < -4 OR b.y > 240 OR b.y < -4 THEN DIMDEL STARList[], b
NEXT
ENDFUNCTION

FUNCTION ADDSTAR: x, y
LOCAL b AS tSTAR
b.x = x
b.y = y
b.gx = RND(7)-3.5
b.gy = RND(7)-3.5
DIMPUSH STARList[], b
ENDFUNCTION

GLBasic Code-Competition #1
Aufgabe:
- thema:
 raumschiff-shooter (2d oder 3d) mit 2d-gameplay (horizontal, vertikal)
- laufzeit:
 18.mai 2008 @ 23.59
- preis:
 der sieger darf den nächsten contest nach seinen wünschen ausrichten!
- max 300 befehle
- grafik:
 max 1mb
- sound:
 max 1mb
- weiteres:
 keine system-spezifischen sachen (inline API/DLL-calls usw) &  auflösung max: 320x240
 (oder 240x320) - sollte sich also auf jeder   von GLB unterstützten plattform problemlos
 compilieren lassen! 'sollte etwas helfen GLB für GP2X und PPC zu pushen!

Code (glbasic) Select Expand

// den screen dann mit diesem (oder ähnlichem) code strecken
GETSCREENSIZE sx, sy
GRABSPRITE x,0,0,320,240
STRETCHSPRITE x,0,0,sx,sy
einwände?
pinnen?

unter einer desktop-umgebung (habe jetzt nur win32 getestet) gibt der befehl MOUSESTATE die korrekten pixel-coodrinaten des mausezeigers zurück WENN er sich ÜBER dem OGL-screen befindet, verläßt er den screen zeigt er (je nach achse) '0' oder die max größe des screens an... gibt es eine möglicheit das auszulesen? am besten wäre es natürlich wenn der befehl MOUSESTATE bei einem verlassen des screen '-1' für X & Y zurückgibt! :-)

ja, schon wieder ich... mit dem nächsten problem! ;-)

startet man ein mit glbasic erstelltes programm auf einem rechner ohne OGL-hardware-beschleunigung bekommt man ein nettes fenster wo man (zweisprachig) darauf hingewiesen dass die OGL-dastellung per software erfolgt und unter umständen langsam sein kann! gibt es eine möglichkeit diesen modus zu erzwingen???

hintergrund:
ich bin bei meinen tests mit GLBasic auf einen rechner gestoßen auf dem mit GLBasic erstellte programme zwar ohne zu meckern funktionieren aber nicht richtig laufen (mit PB oder BMAX gibt es dort keine probleme!) , test ergaben dass u.a. die befehle GRABSPRITE & USESCREEN nicht bzw ins leere laufen. folgender code sollte ja den bildschirm zoomen aber zeigt dort keine sichtbare reaktion:

Code (glbasic) Select Expand

   SMOOTHSHADING FALSE
    GRABSPRITE 0, 0,0,320, 240
    STRETCHSPRITE 0, 0, 0, 640, 480läuft auf allen anderen rechnern die ich getestet habe problemlos aber nicht auf diesem - als ob der codeabschnitt im programm nicht existent wäre !? eventuell liegt es auch auch der OGL-Unterstütuzung der grafifkarte selbst (MATROX MLLENIUM P650). ich habe jetzt auch schon vielfache gößen von 8 ausprobiert zu grabben (256x256 oder 512x512) aber nix... als ob der code im programm nicht existent wäre!?!?

die gleiche binary läuft übrigens auf einem "terminalrechner" im SW-modus so wie gewollt!?

gibt es eine möglichkeit diesen OGL_software-modus (zum testen) zu erzwingen???

gibt es eine möglichkeit die auflösung des desktop (win32, osx, linux) zu ermitteln?

hintergrund ist der umstand dass ein fullscreen (egal ob 800x600 oder 640x480 usw) auf einem 16:9 oder 16:10 display (was sich ja immer mehr durchsetzt) verzerrt aussehen würde.

gibts da was?

arrays werden automatisch scheinbar IMMER als global gehandhabt, nicht weiter schlimm aber erzeugt im debugmode eine warnung:

Code (glbasic) Select Expand

DIM TEST[100]
-> "test.gbas"(1) warning : implicitly created GLOBAL  : TEST]allerdings will ich im debug-mode diese warnungen nicht sehen also habe ich versucht ein array als global zu erklären... problematisch!

Code (glbasic) Select Expand

GLOBAL DIM TEST[100]
-> "test.gbas"(1) error : syntax error

GLOBAL DIM TEST[]
-> "test.gbas"(1) error : syntax errormit ein wenig rumprobieren habe dann ich eine lösung gefunden aber der syntax ist nicht logisch... wo ist denn da das DIM?

Code (glbasic) Select Expand

GLOBAL TEST[]
REDIM TEST[100]
-> compiling...also kein richtiger bug sondern eher ein schönheitsfehler... oder habe ich einen denkfehler?

Who's down for a SHINDIG?

SYDNEY, AUSTRALIA (April 08, 2008) â€" Eegra.com, self-proclaimed industry leader in hilarity and radness, made the universe a slightly better place today with the unveiling of The 1st Annual Game Makin’ Shindig â€" an independent game creation extravaganza in which talented developers can win FABULOUS CASH PRIZES simply by sharing their work with the world.

“Primarily, The Shindig is a transparent ploy to drive visitors to the site,” says Eegra editor Dan Staines.  â€œBut unlike most promotional ploys, this is one where everyone benefits: we get visitors, indie developers get cash, and everybody else gets some neato games to play. It’s win-win-win â€" or win to the power of three, if you want to be scientific about it.”

For more information on The Shindig, including competition Terms & Conditions and Guidelines for Entry, please point your intertron browser to www.eegra.com.

The Competition opens on April 8, 2008 Australian Eastern Standard Time [AEST] and closes at midnight AEST on July 8, 2008 (“Competition Period”). The theme for the contest is "colour" and the first prize is AU$2000.

die hilfe bzw die einträge im forum haben mir fast immer weitergeholfen aber einige fragen bleiben offen... vielleicht habe ich ja auch was übersehen?

- gibt es soetwas wie SCREENRESIZE? also eine möglichkeit erst einen screen 320x240 zu öffnen und diesen dann auf zb 640x480 zu "ziehen" (also eine 2x2 vergrößerung)? idealerweise mit und ohne sampling...

- ist es möglich mit gl-basic bilder, sounds usw in die binary reinzuhängen... also dass ich zum schluss nur eine datei habe wo alles drinsteckt? bietet gl-basic vielleicht sowas wie ein containerformat?

'wollte mal die vorhanden samples bzw ein paar kleine test für meinen hp-jornada-720 compilieren... aber bekomme bei starten der anwendung immer nur die meldung:

`TEST_CE` (oder eine der zugehörigen Komponenten) wurde
nicht gefunden. Stellen Sie sicher, dass Pfad un Dateiname korrekt sind
und dass alle erfoderlichen Bibliotheken verfügbar sind.

ich habe jetzt unter projectoptions schon bei wince auf 320x240 und 240x320 gestellt und auch schon wince_mq (was ja nicht sein kann). GAPI Setup kennt mein gerät und die tests schauen gut aus. die datei(en) werden ohne fehler (shift-f8) erzeugt aber bringen auf dem gerät nur den fehler... dabei müsste doch das gerät unterstützt werden, oder habe ich was übersehen? muss ich irgendwas zusätzlich einstellen oder installieren!? habe die "GLBasic SDK premium (vollversion)" mit den neusten updates installiert

The Jornada 720 was released in 2000. It featured 32 MB of RAM, a Compact Flash slot, a PC card slot, a Smart card slot, 56K Modem, 640x240 16-bit display, and a 206 MHz StrongARM CPU. It ran under the Windows CE 3.0 based HPC2000.