Lieber Besucher, herzlich willkommen bei: RPG Studio - Make your World real. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

325

RubyMediaFramework - Etwas erklärung gefällig?

Bewertung:

Von ITgenie98, Freitag, 2. März 2018, 08:32

Heute eine etwas genauere Erklärung des ganzen:

Das ganze ist in c++ geschrieben. Glew wird für das opengl binding genutzt und glfw ist der windowmanager. Openal liefert die soundapi. Stb wird dann fürs bilder und .ogg laden genutzt.

Generell funktioniert grob das ganze in etwa wie in gosu.

Du erstellst eine subklasse von Graphics::Window. Das ganze kann dann in etwa so aussehen:

Ruby Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Testwindow < Graphics::Window
  def initialize
    super (640, 480) #width, height
  end
 
  def update
    #logik update
  end
 
  def render
    #rendern des fensterinhaltes
  end
end
 
TestWindow.new.show

Das ganze packt man dann in ./scripts/main.rb , startet die exe und voilà: ein fensterchen!

Ich habe mich für einen unterordner deshalb entschieden, da es so einmal die scripts sauber von der binary trennt und der maker später ja eh alle scripts in einen unterordner packen wird.

Wie das genau alles unter der haube läuft ist dann schon etwas komplexer und beschäftigt sich viel mit den 3 grafik libs (opengl, glew, glfw). Grob gesagt wird ein glfw und opengl context beim ".new" erzeugt, das fenster jedoch noch versteckt und der mainloop bleibt inaktiv.
".show" macht das fenster dann sichtbar und startet auch den mainloop welcher fps berechnung, den call von "update" sowie "render" (in dieser reihenfolge) beinhaltet sowie danach einem buffer swap.
-----------------------------------
Als eingabe gibt es maus, tastatur und controller support.

Tastatureingabe:

" handleKeyboard(id, action, mods) "
Callback welcher aufgerufen wird sollte es tastatureingaben geben.
- id ist der keycode
- action ist ACTION_PRESS, ACTION_RELEASE, ACTION_REPEAT
- mods sind Modifikationen wie z.b. shift und strg

" getKeyState(id) "
Diese methode gibt den actionstate der angegeben taste zurück. (id muss ein keycode sein)

Mauseingabe:

" handleMouse(x, y, btn, action, mods) "
Callback für mauseingaben.
- btn: MOUSE_LEFT, MOUSE_RIGHT, MOUSE_MIDDLE
- action: ACTION_PRESS, ACTION_RELEASE, ACTION_REPEAT

Ist der mousemove flag aktiv (default) dann wird auch der callback beim bewegen der maus ausgeführt. Hier ist dann btn und action -1.

" getMouseState(btn) "
Gibt den action state der angegeben maustatse zurück.

" setCursorMode(mode) "
Setzt den mauszeiger modus: CURSOR_NORMAL, CURSOR_HIDDEN, CURSOR_DISABLED.
Bei disabled wird der cursor gefangen und nur die bewegung (also der vector) in die jeweilige richtung kann genutzt werden.

Genaueres zu controllern findet sich in der dokumentation, genauso wie eine liste aller konstanten für die keycodes etc.
-----------------------------------
" setFlag(flag, value) "
Setzt einen internen flag. Value muss true oder false sein.
Flags: FLAG_USE_MOUSEMOVE_CB

" postProcess(*args) "
Wendet den angegebenen shader auf alles gerenderte in dem übergebenen block an.
(In zukunft werden auch mehrere shader übergeben werden können)
-----------------------------------
Der rest ist relativ einfach:

Graphics::Image lädt eine datei mittels stb_image.
" initialize(path) " -- selbsterklärend
" render(x, y, opt={}) "
Rendert das bild an angegebener stelle.
Opt enthält dazu optionale Parameter. (Siehe Dokumentation)

Graphics::Shader lädt, compiliert und linkt einen opengl shader. Dieser kann dann z.b. in postProcess verwendet werden.
" initialize(frag, vert) "
Beides kann ein dateiobject ein fd oder ein string sein welcher den dateinamen bzw den pfad enthält.
(Für weitere methoden wie z.b. setzen von uniformen siehe Dokumentation)

Graphics::Font ist für das rendern von text zuständig.
" initialize(height, name , flags=0) "
Flags ist eine zahl, in der die bits für verschiedene optionen stehen:
1. Bit : bold
2. Bit: italic
3. Bit: underline
4. Bit: stroke out (durchgestrichen)

" render(x, y, text, opt={}) "
Rendert den text. Opt enthält optinale angaben. (Siehe Dokumentation)

Graphics::GLenv wird als argument bei einem ".gl" call beim window an den block übergeben. Dieses argument kann dann verwendet werden um opengl befehle auszuführen. (Kann zu bugs und fehlern kommen, da WIP!)

=================================
Sound kann auch ohne ein fenster zu haben abespielt werden. Dazu benötigen wir im allgemeinen nur diesen code:

Ruby Quellcode

1
2
3
4
5
sound = Sound.new ("datei.ogg", 50, 1)
sound.play
 
while (true) do
end

Die schleife am ende muss exestieren, da ansonsten die engine aufhört zu arbeiten und sich beendet. (Bzw im debug build beendet und dann noch auf eine tastatureingabe wartet bevor das konsolenfenster schließt)

Dieser code lädt bzw streamt die datei "datei.ogg" mit halber lautstärke (50) und einem normalen pitch (1) und keiner wiederholung.

Beim erstellen eines neuen sounds kann optional noch der stream flag angegeben werden. Default ist hier true.

Ruby Quellcode

1
sound = Sound.new ("datei.ogg", 50, 1, false)

Dieser code z.b. lädt die gesamte datei in den speicher, da der streamflag false ist.

Beim abspielen kann optional noch der loopcount angegeben werden. 0 steht hier für einfaches abspielen, -1 für endloses und eine ganz normale zahl halt für die anzahl der wiederholungen.
Sollte man vorher "sound.pause" ausgeführt haben kann mit "sound.play" bzw "sound.play (0)" der sound weiter espielt werden. Eine besonderheit an 0 ist es nämlich das vorher gesetzte loopcounts nicht überschrieben werden.

Intern funktioniert das folgendermaßen: bei ".new" werden einfach nur dateiname, volume und pitch in variabeln gespeichert. Die eigentliche magie begint erst bei ".play":
Falls pausiert, wird der sound weitergespielt und die methode endet. Wenn nicht wird geschaut ob die datei schoneinmal geladen worden ist, wenn ja dann wird diese auf den anfang zurückgestellt. Wenn nicht wird geladen.
Wird die datei gestreamt, so werden 2 buffer gefüllt.
Dann wird dem Soundwatcher der neue Sound mitgeteilt.

Der soundwatcher ist dann dafür zuständig das der sound nachgeladen wird und korrekt wiederholt wird, aber auch wenn der sound beendet wird das er automatisch entladen wird.

==============================
Future ideas:
Textureregistry welche die geladenen texturen bzw bilder verwaltet und aufpasst das keine doppelten geladen werden. Auch soll diese dazu benutzt werden können um eine textur zu laden und deren opengl texturid zu bekommen.

Hoffe es hat euch gefallen! Mfg IT8

Dieser Artikel wurde bereits 520 mal gelesen.


Kommentare (4)

  • 4

    Von Playm (Samstag, 10. März 2018, 16:46)

    Zum Thema quelloffen bin ich bei meinen eigenen Werken auch immer etwas knausrig, aber freu mich immer wenn die anderen ihren Quellcode veröffentlichen. :D Kann das also gut verstehen, wenn Du deinen Quellcode nicht zeigen magst.

  • 3

    Von ITgenie98 (Freitag, 9. März 2018, 15:05)

    Weil gosu selbst keine opengl befehle ausführen kann, und auch keine Schader / postprocessing bietet. Dafür bräuchte man extra gems bzw für gosu selbst ja auch. Ich bin eher ein freund davon alles benötigte in eine Binary zu packen und die Custom Skripts dann nur rumliegen zu lassen. Das reduziert auch die generelle Dateianzahl. Auch soll später auch im Maker selbst eine Archivunterstüzung geben wie beim XP/VX. Da lohnt es sich natürlich die Engine in eine Executable packen zu können.
    Auch sind die Parameter der Methoden etwas mehr nach persönlichem Geschmack angepasst ^^".

    Zum Thema Quelloffen: Bin noch unentschlossen was ich machen möchte. Auch ob der gesamte Maker später quelloffen sein soll, weiß ich noch nicht.

  • 2

    Von Playm (Donnerstag, 8. März 2018, 21:58)

    tl;dr lol :dance:

    Aber ernsthaft: Klingt nicht schlecht, aber was ist der Unterschied zu gosu? Wofür ein eigenes Framework schreiben und nicht gosu forken?

    Und: Ist dein Framework quelloffen? Frag für 1 interessierten Freund. :3

  • 1

    Von Josey (Freitag, 2. März 2018, 16:28)

    Sieht aus, als wäre das eher was für Playm XD
    *Micro drop* Bin raus XD

    Schöner, ausführlicher Beitrag, zum Inhalt kann ich aber echt nix sagen XD

Blog Navigation

Vorheriger Artikel

RubyMediaFramework - Eine kleine Engine

Von ITgenie98 (Donnerstag, 1. März 2018, 17:45)