R: Sound-Engine...

Eine Ankündigung 😉 ...

Die nächste Version von CoH wird, wie auch die momentane Version ohne den PC-Speaker und den schrecklichen Sound auskommen (ist bei BlitzBasic auch "not supported"). Dafür werdet ihr in der nächsten Version wahrscheinlich grottenschlechte *.wavs zuhören bekommen, da mir ein freundliches (und sehr erfahrenes) Mitglied der BB-Community erklärt hat, wie ich wavs abspielen kann, ohne das sie manipuliert werden können.👿

Grüße,
LordEverything

PS: Um jetzt keine Verwirrung zu stiften, es sind *.wavs - aber so abgeändert das sie nicht abspielbar sind.

Habe die Beta durch!
Bitte programmiere mal neue Räume!

mfg

Robotfreak

Tjo... Ich denke das ich erstmal neue Funktionen für Gegenstände programmieren werde, damit ich die vorhandenen Räume vollstopfen kann. Nunja... aber es sollte schon noch ein paar mehr Räume geben...😉

Ausserdem denke ich, das ich irgendwan einmal ganz neue Szenen entwerfen werde, wenn der andere Kram (Engine) erledigt ist. Momentan arbeite ich neben dem Sound auch an den netten kleinn Textfenstern durch die Robot, denke ich, viel vom Adventure-Genre dazu gewonnen hat.
Momentan liegt das Problem beim zentrieren des Textes bei den Szenennamen.😖 Irgendwie bekomme ich das nicht ganz hin.

Grüße,
LordEverything

Also egal ob du eine Schriftart mit fester Zeichenbreite, oder eine mit variabler Breite verwendest, du brauchst eine Funktion, die dir die Breite des Textes entweder in Pixel (ist genauer) oder in Bloecken (1 Block = 1 Zeichen bei fester Breite) zurueckgibt. Hm, bin zum erklaeren schon etwas zu muede also in QBasic sehe das etwa so aus:


Function Center(a$) as Integer
Center = (Bildschirm_Breite / 2) - (Len(a$) / 2)
End Function


Diese Funktion gibt dir dann die X Position zurueck, an der du anfaengst den String auszugeben. Hat schon aufm C64 geklappt 😉 Aber achte darauf, das wenn Bildschirm_Breite in Pixeln angegeben ist, musst du Len(a$) noch mit der Blockbreite Multiplizieren bevor du den Wert durch 2 dividierst.

Hoffe das hilft. Und wenn ich gerade Mist getextet habe, sag mal wer bescheid 😉

Is' wohl alles korrekt, in C würde ich das in etwa so formulieren (ohne separaten Funktions-Aufruf):

void PrintCentered(int Xpos, int Ypos, int FieldPixelWidth, const char *Text)
{
Xpos += (FieldPixelWidth-GetPixelWidth(Text)) >> 1;
PrintText(Xpos, Ypos, Text);
}

Das >> 1 (Shift Right 1 Bit) ist nichts anderes als eine Division durch 2, geht nur deutlich schneller und steht unter C glücklicherweise als Operator zur Verfügung.

Natürlich gibt es noch zig andere Varianten, das zu implementieren, aber ich denke, unsere beiden Beispiele sollten den Zweck verdeutlichen...😉

Sorry. habe ich mich etwas undeutlich ausgedrückt. Den Text zu zentrieren ist ja garnicht so schwer. Doch dieser Rahmen... Das hat etwas zu tun mit den geraden und den ungeraden Szenennamen, glaube ich. Wenn ich, richtig denke sind es gerade Szenennamen von der Buchstabenzahl her (wenn man bei 0 anfängt zu zählen) welche das Problem machen. Die rechte Seite des Randes ist dann immer eine Einheit zuweit rechts.😰 😬

Grüße,
LordEverything

Gibt mind. 3 Möglichkeiten:

- Ignorier das leere Feld einfach, wir tun's dann auch 😉

- Zentriere den Text per Pixelkoordinaten (sollte bei ungerader Länge nur 1 Pixel anstelle eines Blocks sein, und das fällt nicht wirklich auf)

- Prüfe die Länge ob sie ungerade ist, wenn ja dann zieh einfach einen Block von der Breite des Rahmens ab.

* (Kannst ja auch irgendwo im Szenennamen ein Leerzeichen doppelt darstellen 😉 <- Nur nen Scherz 😉

Tjo, Punkt 3 ist wohl der Beste. Das Problem ist, dass ich nicht weiß wie ich das machen soll. Schon probiert.😰 😰 😬 😬 😬 😬 😬 😬 😬 😰 😰 😰 *verzweifel*

Grüße,
LordEverything

hm, du hast also jetzt die breite vom text, daraus errechnest du die breite vom rahmen.

IF (TEXT_BREITE MOD 2) RAHMEN_BREITE - 1

Ok, Andreas kann uns (hoffentlich) auch gleich sagen, wie das in C mit Bitoperationen aussieht. (Hab ich micht noch nicht mit beschäftigt, weiss aber das wenn das erste bit gesetzt ist, ist auch die zahl ungerade)

Wenn ich schon gefragt werde, will ich mich auch nicht lumpen lassen.... 😉

Mit ein wenig Überlegung kommt man da sogar ohne Division (Modulo) und Vergleich (IF) aus.

Vollig korrekt ist, dass ein Bit bestimmt, ob ein Wert gerade oder ungerade ist. Das ist das niederwertigste Bit, welches üblicherweise ganz rechts steht (wir schreiben die Einerstelle ja auch ganz rechts).

Betrachtet man nur dieses eine Bit, ist der Wert 1 bei ungeraden Zahlen und 0 bei geraden Zahlen. Da man genau bei ungeraden Zahlen etwas abziehen möchte, kann man auch gleich den Wert verwenden.

Bei C ist das dann völlig Easy auszudrücken:

RahmenBreite -= (TextBreite & 1);

Dahinter gehört natürlich ein sauberer Kommentar, da sich der Sinn dieser Kurzschreibweise nicht gleich jedem erschliesst... 😉

Also, so langsam finde ich an den Bits richtig Interesse. Erstaunlich was man so alles mit denen machen kann. Irgendwie schon peinlich für mich, das ich mich nie wirklich mit ihnen beschäftigt habe. Und jedesmal wenn ichs versucht habe, kam immer das gegenteil dabei raus 😉 (Ist wohl genetisch bedingt, das ich AND und OR grundsätzlich verwechsle, obwohl ich weiss was die machen *lach*)

Ist nur die Frage ob Lord Everything auch Bitoperationen in Blitzbasic findet?

@LordEverything: eMail ist angekommen, also die Funktionen werd ich mal ein wenig auseinander pflücken müssen 😉 Zu viel in eine Funktion gesteckt. Das Rahmenzeichnen würd ich in einer separaten Funktion verstecken. Denn du willst später sicherlich noch öfters einen Rahmen irgendwo zeichnen, und falls du irgendwas an der Art und Weise änderst, wie du ihn zeichnest, musst du nicht erst zig Funktionen anpassen, sondern nur die eine zum Zeichnen des Rahmens.

Prinzipiell sollte auch ein Basic-Dialekt Bitoperationen durchführen können. Nur sind die (soweit ich das weiss) immer über Funktionen definiert, was die Verwendung nicht ganz so eingängig macht, wie bei C. Und wenn dann tatsächlich auch Funktionen dafür aufgerufen werden, ist auch der Performance-Vorteil flöten. Ich kann mir schon vorstellen, dass bei Basic ein x = y * 4 schneller berechnet wird, als ein x = SHL(y,2).

Natürlich lässt sich aber auch in Basic mit ein wenig Kreativität die konditionale Bedingung entfallen:

RAHMEN_BREITE = RAHMEN_BREITE - (TEXT_BREITE MOD 2)

Andreas hat mal wieder Recht. y = x * 4 ist wirklich schneller. Er ist ja schließlich auch der ezOP. 😉
Allerdings ist es so, dass es scheint als hätte ich das Problem nicht richtig geschildert, oder meine Interpretation ist falsch . Hier nochmal ein Bild mit dem Problem:

<IMG problem_002.htm>

Falls ihr mit diesen Bit-Operatoren AND, OR, XOR und so meint, die sind natürlich bei Basic auch mit an Bord.

Grüße,
LordChaos

lol, gutes Bild 😉

vielleicht solltest du mal die URL überprüfen 😉

Quote:

---

Falls ihr mit diesen Bit-Operatoren AND, OR, XOR und so meint, die sind natürlich bei Basic auch mit an Bord.

---

ich bin mir nicht ganz sicher, aber ich glaube AND, OR und XOR können nur mit einstelligen Bits operieren.

Der Operator, den Andreas meint, arbeitet mit ganzen Binärzahlen:

so wird aus

4 & 1 = 0

-> umgerechnet in Binärzahlen

100 & 001 = 0

da

1&0 = 0
0&0 = 0
0&1 = 0


bzw. 5 & 1 = 1

101 & 001 = 1

da

1&0 = 0
0&0 = 0
1&1 = 1

He, moormaster, das ist moderne Kunst. Das Werk trägt den Namen "Unsichtbar". Das du darauf nicht gekommen bist. Ok, Scherz beiseite. Neuer Versuch 🙁 IMG problem.htm>

Grüße,
LordEverything

Vielleicht solltest Du da 'mal den Code posten, mit welchem Du die Boxen erzeugst. So kann man natürlich nur recht wenig dazu sagen.
Irgendwie hast Du da bei der rechten Kante ein Problem, welches bei einer geraden Buchstabenanzahl auftritt....

Jetzt muss ich hier auch nochmal den Code posten *schluck* *schäm*, aber was sein muss, muss sein.

Hier ist der Code:

  Function WriteSzenentitel (String$)

  ;--------Hintergrund sichern
  GrabImage STBack, 0, 144

  ;--------Szenentitel ausgeben
  FlushKeys()
  LocateFont 14, 20 - (Len(String$) / 2)
  WriteF String$

  ;--------Rahmen zeichnen
  DrawImage RahmenH, (20 - Len(String$) / 2 - 2) * 16, 13 * 12      ;---Horizontal
  DrawImage RahmenH, (20 + Len(String$) / 2 + 2) * 16, 13 * 12      ;
  DrawImage RahmenH, (20 - Len(String$) / 2 - 2) * 16, 14 * 12      ;
  DrawImage RahmenH, (20 + Len(String$) / 2 + 2) * 16, 14 * 12      ;
  DrawImage RahmenH, (20 - Len(String$) / 2 - 2) * 16, 15 * 12      ;
  DrawImage RahmenH, (20 + Len(String$) / 2 + 2) * 16, 15 * 12      ;
  For i = 0 To Len(String$) + 3                                     ;
   DrawImage RahmenW, (20 - Len(String$) / 2 - 2 + i) * 16, 12 * 12 ;---Waagerecht
   DrawImage RahmenW, (20 - Len(String$) / 2 - 2 + i) * 16, 16 * 12 ;
  Next                                                              ;
  For i = 1 To Len(String$) + 2                                     ;---Schwarz ausfüllen
   DrawImage Shadow, (20 - Len(String$) / 2 - 2 + i) * 16, 13 * 12  ;
   DrawImage Shadow, (20 - Len(String$) / 2 - 2 + i) * 16, 15 * 12  ;
  Next                                                              ;
  DrawImage Shadow, (20 - Len(String$) / 2 - 1) * 16, 14 * 12       ;
  DrawImage Shadow, (20 + Len(String$) / 2 + 1) * 16, 14 * 12       ;

  Flip
  While Not KeyHit(28) : Wend

  ;--------Hintergrund zurückschreiben
  DrawImage STBack, 0, 144

End Function

Ich denke (und hoffe) dass das selbsterklärend ist. WriteF ist eine eigene Function (Function kann man ja mit void vergleichen, denke ich) welche in meiner Bitmapfont den Text ausgibt. Die Function ist etwas groß, wie Fausti schon sgate, was allerdings daran liegt, das ich ja noch keine anderen Infoboxen erzeugen kann. Wenn das soweit ist, lässt sich das ja noch ändern.
Trotzdem kommt mir diese Funktion etwas "umständlich" geschrieben vor, aber mir ist kein anderer Weg eingefallen.

Grüße,
LordEverything

Na, ist doch easy! 😉

Erstmal würde ich eine gravierende Beschleunigung empfehlen, und die String-Länge nur einmal zu berechnen und in einer Variablen zu speichern.

Dein konkretes Problem ist, dass Du überall mit Len/2 rechnest und so von der Mittel-Position bei 20 relativ nach links und rechts positionierst. Wenn Du korrekt mit Fliesskomma rechnen würdest, wäre das natürlich OK, bei Integer bekommst Du aber bei ungeraden Werten für Len ein Problem (da Du einfach die 0.5 unterschlägst).

Vorschlag:

Berechne zuerst die linke Koordinate:

 
StrLen = Len(String$)
Xstart = 20 - StrLen/2

Dann arbeitest Du nur noch mit Xstart, also z.B.:

 
DrawImage RahmenH, (Xstart-2) * 16, 13 * 12
DrawImage RahmenH, (Xstart+StrLen+2) * 16, 13 * 12
For i = 1 To StrLen+2
  DrawImage RahmenW, (Xstart + i) * 16, 12 * 12
Next

Naja, Du wirst schon verstehen, was ich meine... 😉

Tolll! Bin ausser mir. Es funktioniert prima. Jetzt kann ich dich ja öfter fragen (und nerven). (autofahrn denkt: *schauder*).😉

Grüße,
LordEverything

Och, wenn die Probleme so leicht zu lösen sind, ist das immer einge angenehme, kurzweilige Abwechslung... 😉