SoftPixel Engine (neu: SVN Repository & CMake files)



  • ok. ein wenig kritik 😃

    1. der extension loading code ist nicht ganz koscher 🙂

    glGenBuffersARB = (PFNGLGENBUFFERSARBPROC)wglGetProcAddress("glGenBuffersARB");
    

    führt zum beispiel dazu das bei ati opengl 2.0 treibern nüx geladen wird, da
    glGenBuffersARB() seit opengl 1.5 im standard ist und demnach jetzt auch glGenBuffers() heißt. dies wiederum führt dazu, das dein code bei api opengl 2.0 treibern (zumindest den ich gerade installiert habe 8D) keine erweiterungen "findet" und nach opengl 1.1 zurückfällt (zumindest zeigt er mir dies in der konsole an :)). dies ist ja noch nicht schlimm, allerdings scheint es so, dass du nichtsdestotrotz versuchst die nichtgeladenen erweiterungen zu aufzurufen, da sämtliche beispiele bei mir mit einem segfault sterben :D. kann natürlich auch an etwas anderem liegen, habe ich jetzt nicht weiter danach gesucht 🙂

    2. ich habe jetzt nicht genauer nachgeschaut, aber bemerkt, dass dein code glaux.dll benötigt. versuche dich davon zu lösen 🙂 ist uralt, und hilft beim portieren, wenn du glaux funktionen ausm code raushast 🙂

    3. den font code habe ich mir mal interesse halber genauer angeschaut. der ist wie ich finde eher suboptimal da er kein unicode (insbesondere ist hier kyrillisch interessant) unterstützt. eine möglichkeit textbreiten des gerenderten textes _vor_ dem rendern hast du dir auch verwährt. das könnte im gui segment einige probleme bereiten. kleiner tip: implementiere eine art fontmetrics-klasse, die statisch textbreiten der einzelnen glyphen hält mit der du dann textbreiten bestimmen kannst.

    ok, genauer hab ich noch nicht reingeschaut, aber das reicht auch erstmal, denke ich 🙂

    ansonsten weiter so 👍 🙂



  • Okay, danke schon mal.

    Das mit 'glGenBuffersARB' funktioniert bei mir mit meiner etwas älteren ATI Grafikkarte mit OpenGL 2.0 aber schon?!

    Mhh, wenn ich kurz nachdenke habe ich GLAUX glaube ich nur in Benutzung um Bitmap-Bilder (BMP) zu laden.
    (Das wollte ich sowieso noch selber programmieren weil die Funktion 'auxDIBImageLoad' das nicht perfeckt macht)
    Warum aber genau ist es nicht gut GLAUX zu verwenden? 😕

    Das mit der Textbreite stimmt, das hat mir bisher auch schon Probleme in der GUI bereitet.
    Allerdings: warum ist für Grafikanwendungen Unicode so wichtig? 😕

    mfG



  • Mhh, wenn ich kurz nachdenke habe ich GLAUX glaube ich nur in Benutzung um Bitmap-Bilder (BMP) zu laden.
    (Das wollte ich sowieso noch selber programmieren weil die Funktion 'auxDIBImageLoad' das nicht perfeckt macht)
    Warum aber genau ist es nicht gut GLAUX zu verwenden? 😕

    Gibt viele Gründe...
    Du hast dir sicherlich NeHes OpenGL Tutorials reingezogen. In den letzten Tutorials wird auch kein Glaux mehr verwendet. Musste mal nachschauen, ich glaube NeHe hat selber ne Lib für geschrieben.



  • LukasBanana schrieb:

    Das mit der Textbreite stimmt, das hat mir bisher auch schon Probleme in der GUI bereitet.
    Allerdings: warum ist für Grafikanwendungen Unicode so wichtig? 😕

    mfG

    ist es nicht unbedingt, vereinfacht aber vieles. du musst dich nicht mit codepages und sonstwas rumschlagen. angenommen irgendjemand möchte einen ingamechat für sein programm auf der basis deiner engine erstellen. erwarte nicht, dass jeder russe englisch kann, geschweige denn russisch mit dem unserigen alphabet schreiben will (wenn das überhaupt geht? :P). um eben nicht den codepagekram benutzen zu müssen, verwende von vornherein unicode, das macht das leben einfacher 🙂



  • Also gut, mal sehen wie sich das auch unicode umschreiben lässt.
    Ist bloß etwas nervig andauernd vor jeden Text 'L' schreiben zu müssen.
    Und mit Unicode muss man vür allerart Sonderzeichen (z.B. €) HEX '\u00FF' oder sowas schreiben.
    Die std::string Klasse arbeitet auch nicht mit Unicode, oder?



  • LukasBanana schrieb:

    Die std::string Klasse arbeitet auch nicht mit Unicode, oder?

    Nein, da sie ein typedef auf std::basic_string <char> ist. std::wstring ist ein typedef auf std::basic_string <wchar_t>.



  • naja, unicode hat eigentlich nichts im normalen code verloren. normalerweise gibt es irgendwo ne lokalisierungslib die normalen text dann in unicode wandelt und das gibt man dann aus.
    Oft nutzt man ein externes Tool, das erlaubt es english->andere sprache in eine uebersetzungsdatenbank einzutippen.
    Ausser den Zeichen gibt es noch andere dinge die man bei lokalisierungen beachten muss und die ueberall im code reinzuhacken waere wie jede API ohne wrapper zu nutzen.
    (mich wuerde kyrillisch weit weniger interesieren als Kanji, weil es nicht vom codeschreiber, sondern vom programm nutzer abhaeng, welche sprache eingestellt werden wird).

    dein stichwort fuer google oder sourceforge ist l10n tools bzw lib;)



  • ich bezog mich da hier aber eher erstmal auf den fontrender code, nicht das dass jetzt missverstanden wird 🙂
    ich meine WM_CHAR benutzt utf-16 und WM_UNICHAR utf-32 für den codepoint, unter linux mit X ist der KeySym heutzutage per default ucs4 afaik. in heutigen truetype fonts ist unicode grundsätzlich enthalten, wenn auch nicht alle glyphen, indiziert mit entsprechendem codepoint. um also kyrillisch oder kanji (was ist das?, lol) anzeigen zu lassen ist keine große zauberkunst notwendig 🙂



  • Vielleicht variiere ich das später noch zu:

    namespace io
    {
    
    template <typename T> class string
    {
    /* ... */
    };
    
    typedef string<char> stringc;
    typedef string<wchar_t> stringw;
    
    }
    

    Allerdings kann ich dann in der Klasse nicht sehr gut 'std::string' verwenden sondern musse das addieren und allokieren von speicher alles selber machen



  • wie gesagt, das ist nicht wirklich notwendig. solange du spaeter ueber eine l10nlib die fonts renderst und ausgibst.

    @sothis_
    dann sehen wir das wohl gleich 🙂
    btw. Kanji kennst du nicht? chinesische und japanische schriftzeichen.
    dafuer kennst du aber die kleine kyrillisch randgruppe? *hehe*



  • rapso schrieb:

    dann sehen wir das wohl gleich 🙂

    es ist dem thread nicht sehr zuträglich 500 zeilen code zu posten der nicht im geringsten mit dieser engine kombinierbar ist 🙂

    rapso schrieb:

    btw. Kanji kennst du nicht? chinesische und japanische schriftzeichen.
    dafuer kennst du aber die kleine kyrillisch randgruppe? *hehe*

    oh, wieder was dazu gelernt \o/, lol, nie gehört 😛



  • Okay, noch ne kleine Frage nebenbei.

    Ihr hab mit sicherheit gesehen dass ich meine eigene string Klasse 'cstring' genannt habe damit sie sich in keinem Fall mit der std::string Klasse überschneidet auch nicht wenn man die Namespaces 'ausgeschaltet hat'.
    Ich kahm auf den Namen cstring als ich in der IrrlichtEngine 'stringc' gesehen hatte (das ist auch eine Typen definition wie in meinem letzter Beitrag)

    Meine Frage: Findet ihr den Namen 'cstring' merkwürdig oder findet ihr vielleicht die Klasse wie in meinem letzten Beitrag besser (nur von der Schreibweise her)??



  • hm, die stringklasse der mfc heisst halt CString...



  • Bekanntmachung:

    Neue Release-Version: SoftPixel Engine 1.1

    Erneuerungen:
    * Einige Fehler wurden beseitigt (z.B. funktioniert die Funtkion "video::Texture::setTransFilter" jetzt richtig)
    * Mann kann nun die Transformations-Matrix für jedes Objekt (Node) komplett manuel erzeugen und verändern
    * "array" Klasse hinzugefügt (eigene Container Klasse)

    Rückfrage:

    bool Frage = Gibt es inzwischen schon ein paar Vereinzelte die die SoftPixel Engine nutzen oder die sich schon mal ein bischen damit beschäftig haben?

    `if (Frage == true) // Wenn ja, dann ... ^^

    {Was habt ihr damit bereits gemacht? Konntet ihr damit schon ein bischen was anfangen? Was gefällt euch an ihr/ was nicht?}

    else if (Frage == false) // Wenn nein, dann ...

    {Was habt ihr gegen die *SoftPixel Engine* auszusetzten?}`

    Danke schon mal für euer bisheriges Feedback 🙂



  • Ich fänd's cool, wenn's auf der Homepage ne Doxygen-artige Code-Doku gäbe, einfach zum reinschnuppern in die Interfaces ohne gleich den Quellcode runterladen zu müssen.



  • Ich denke das ließe sich einrichten.
    Vielleicht mache ich mal eine Doxygen Dokumentation 🙂
    Dauert dann aber erst mal noch ... 😉





  • Und hier ist auch schon Version 1.3

    (Ihr könnt die Links des letzten Beitrags benutzen)

    PS: Die Engine unterstützt jetzt Shader (GLSL)



  • So jetzt gibt's auch endlich eine Doxygen Dokumentation 😃



  • Eben gerade habe ich die Version "1.5 beta" veröffentlicht.
    Deutlich stabieler; neue Renderer: Direct3D9 (erst mal nur für 2D nutzbar), "Ray" SoftwareRenderer; anti alias; SkeletAnimationen für's B3D Format


Anmelden zum Antworten