Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - S. P. Gardebiter

Pages: 1 [2] 3 4 ... 17
16
oh. Der Puffer ist (glaub) nur 4 Zeichen pro SHOWSCREEN. Bist Du so schnell?

Ah, das könnte die Eklärung dafür sein.
Naja ich weiß nicht wie schnell man dafür sein muss aber es scheint wohl so zu sein. o: Selbst wenn ich mich nicht anstrenge besonders schnell zu tippen, mache ich durchschnittlich ca. 530 Anschläge pro Minute.
Gibt es einen Weg den Buffer zu erhöhen? Dann könnte ich prüfen ob es daran liegt.
Man könnte ihn auch auf die physisch maximal erreichbare Anzahl an Anschlägen ausrichten, (ca. 750 Anschläge pro Minute) falls ihn das nicht zu groß machen würde.

17
IDE/Syntax / Loadfont limit
« on: 2011-May-30 »
It would be cool to load more than 8 fonts into GLBasic O:
My program is able to output colored text but only 8 colors is a bit of a restriction. Is there anyway the limit could be increased to 16 or something?

18
Hallo. Ich habe mir eine eigene INPUT Funktion mit INKEY$ geschrieben aber INKEY$ verschluckt bei mir regelmäßig einige Tasten, da ich schnell tippe und meine eigene INPUT Funktion scheint manchmal etwas zähflüssig zu sein.

Irgendeine Idee? Für mich sieht das schwer nach einem Bug aus :S

Code: (glbasic) [Select]
IF Typing = TRUE OR Console = TRUE
NewChar$ = INKEY$()
IF ASC(NewChar$) = 8
NewLine$ = MID$(NewLine$, 0, LEN(NewLine$) - 1)
ELSEIF ASC(NewChar$) >= 32
NewLine$ = NewLine$ + NewChar$
ENDIF
IF Console = TRUE
IF FPSC > 30
PRINT NewLine$, 3, INTEGER((ScreenH / 2 + ScreenH / 8) / 16) * 16, TRUE
ELSE
PRINT NewLine$ + "|", 3, INTEGER((ScreenH / 2 + ScreenH / 8) / 16) * 16, TRUE
ENDIF
ELSE
IF FPSC > 30
PRINT "Say: " + NewLine$, 16, ScreenH / 2 + ScreenH / 4 + ScreenH / 8, TRUE
ELSE
PRINT "Say: " + NewLine$ + "|", 16, ScreenH / 2 + ScreenH / 4 + ScreenH / 8, TRUE
ENDIF
ENDIF
ENDIF

19
Danke für die Hilfe.
Ich versuche zwar in der Regel alles mit Arrays zu machen aber hier erscheint es mir sehr sinnvoll einen Type für den Layer zu benutzen, besonders wenn es anders nicht geht/zu kompliziert wird :)
Danke nochmal.

Edit: Sind Types eigentlich genauso schnell wie Arrays oder gibts bei sehr vielen Objekten die Type benutzen Geschwindigkeitseinbußen? o:

20
Hallo.
Ich weiß gerade nicht so recht wie ich das realisieren soll. In meinem Spiel gibt es mehrere Ebenen und in jeder Ebene können sich Objekte (Gegner, Gegenstände etc.) befinden. Ich weiß zwar wieviele Ebenen es gibt, weiß jedoch nicht die Anzahl der Objekte pro Ebene. (Sie könnten sich auch vemehren) Da ich RAM einsparen will, möchte ich wissen ob es eine einfache Möglichkeit gibt ein Feld anzulegen, in welchem die erste Dimension völlig statisch ist und dann die Größe in der zweiten Dimension dymanisch ist. Allerdings sollten die Größen der zweiten Dimension je nach erster Dimension optimal sein, dass heißt, ich möchte nicht, dass am Ende nur weil eine der Ebenen mehr Objekte hat, bei allen anderen Ebenen die Dimension auch vergrößert wird, wenn dies unnötig ist.

Sonst bräuchte ich ja keine dynamischen Felder, dann könnte ich mir gleich eine Liste anlegen, das Problem ist dann aber, dass sich die Daten im Laufe der Zeit fragmentieren können. Mit statischen Feldern arbeiten ist auch doof und Fragmente versus unnötiger Speicherverbrauch klingt nicht gerade toll.

21
Danke, gibts hier im Forum eigentlich irgendwo ein Tutorial wie man externe Bibliotheken korrekt einbindet und mit ihnen arbeitet bzw. gibts speziell was zu OpenAL? o:
Laut Wikipedia unterliegt die Libary ja der LGPL, kennt sich damit jemand aus? D:


22
Hallo,

für einige Projekte von mir benötige ich kompliziertere Funktionen was den Sound bzw. die Musik angeht.
Ich brauche folgendes:

 - Die Bibliothek muss in der Lage sein im Arbeitsspeicher abgelegte Sounddaten abzuspielen, sodass ich nicht immer alles voher auf die Platte kopieren muss
 - Die Bibliothek muss in der Lage sein, Sounddaten runter und hoch zu pitchen
 - Die Bibliothek muss in der Lage sein, in Echtzeit Sounddaten zu verarbeiten/generieren
 - Sie soll möglichst kompatibel mit Linux und Mac sein
 - Sie muss umsonst sein und eine vernünftige Lizenz besitzen
 - Sie sollte nicht zu groß sein und muss "sehr schnell" funktionieren

Also praktisch eine Eierlegende Wollmilchsau. O:
Kennt jemand eine Libary die einigermaßen meinen Anforderungen gerecht wird?

23
GLBasic - de / Re: 10^5 , wie?
« on: 2011-Apr-10 »
Ihr versteht das falsch, bei E benutzt man immer die 10 als Basis für die Exponentialfunktion.
1,2E5 heißt nicht "^ 5" sondern "* 10 ^ 5".
Normalerweise bevorzugt man in der Technik die E Schreibweise.

24
Off Topic / Re: I need translators
« on: 2011-Mar-31 »
I could do german if you want. The only thing I want for doing so is a readme entry or something o:

25
Achja, ganz vergessen, danke! :)

26
GLBasic - de / Array schnell Wert zuweisen?
« on: 2011-Mar-05 »
Moin, moin.
Ich möchte meinem Array einen Wert zuweisen, allerdings produziere ich einen haufen Code, wenn ich alles einzelln zuweise, gibt es eine Möglichkeit das ganze zu verkürzen?

z.B.

Array[] = {5, 4, 63, 23, 10, 11, 7}

28
GLBasic - de / Re: Kollision: Linie und Map
« on: 2010-Dec-08 »
puh!! Dann geht nur createscreen/drawline/sprcoll.

Dann hätte ich aber wieder das Problem mit der enormen CPU Last oder wie meinst du das? o:

Somit könntest Du jedes Rechteck (egal welche Form es nun genau hat) in die Außenlinien unterteilen und eine Linie-Linie-Kollisionsprüfung durchführen.

Dann wäre das aber noch genauso rechenlastig, wenn nicht sogar noch mehr oo'

29
GLBasic - de / Re: Kollision: Linie und Map
« on: 2010-Dec-07 »
Da liegt mein zweites Problem. Es muss nicht sein, dass das ganze Rechteck ausgefüllt ist.

Heißt, ich muss in etwa wie folgt vorgehen: Ich mach erstmal eine Linie/Rechteck Kollision (Folglich: Ich nehme an, dass ganze Rechteck ist gefüllt) und dann eine Pixel/Sprite Kollision (Für den 8x8 Block, in dem die Kollision passiert) um zu sehen ob da auch wirklich eine Kollision ist.
Die Frage ist wie ich das mit der Linie/Rechteck Kollision anstellen sollte, ohne meine CPU zu killen. (Bei Pixel/Sprite hätte ich schon eine Idee)

30
GLBasic - de / Re: Kollision: Linie und Map
« on: 2010-Dec-07 »
Es hat einen eher praktischen Grund.

Bei deiner Version müsste ich 60 mal in der Sekunde einen GRABSPRITE machen, ich weiß nicht wie schnell der Befehl ist o: Dann müsste ich den Endpunkt der Kollision wissen, folglich muss ich ihn noch ausrechnen. (Ich hab mich bei meinem Startpost vertippt, ich weiß den Endpunkt nicht, nur Startpunkt und Winkel) Das ist beides im Grunde kein Problem. (Ausser GRABSPRITE ist sehr langsam, was ich mal nicht annehme)

Das echte Problem allerdings werde ich zu spüren bekommen wenn ich mal viele Bullets auf dem Bildschirm habe. (100 z.B.) Die sind zwar im Grunde keine Linien, aber fliegen in "Linien", dafür bräuchte ich den selben Algorithmus. Ich hab 64x48 Tiles. Das sind 3072, bei 100 Bullets wären das 307.200 Durchläufe. (Und das wären nur die Tiles auf dem Bildschirm! Wenn mein Level scrollt töte ich meine CPU.) Wenn ich allerdings wüsste durch welche "Tile Koordinaten" das Teil "durchfliegt", verkürzen sich die Durchläufe drastisch.

Pages: 1 [2] 3 4 ... 17