NightLight2D Preview und Features

rapso

Scorcher24 schrieb:

...Die GLew kann man sich runterladen auf der Projektseite. Der Fix der dort eingebaut ist, ist vital für OpenGL3 auf einem Core Profile.
...

ist das ein bug in glew? oder braucht nur dein NightLight2D etwas spezielles?

Scorcher24

rapso schrieb:

Scorcher24 schrieb:

...Die GLew kann man sich runterladen auf der Projektseite. Der Fix der dort eingebaut ist, ist vital für OpenGL3 auf einem Core Profile.
...

ist das ein bug in glew? oder braucht nur dein NightLight2D etwas spezielles?

Das ist ein Bug in GLew. GLew verwendet immer glGetString(GL_EXTENSIONS).Das führt unter OpenGL 3.x zu Warnungen. Ausserdem werden auch für OpenGL3 deprecated Extensions und Funktionen geladen. Richtig ist glGetStringi.

GLboolean glewGetExtension (const char* name)
{
GLubyte* p;
GLubyte* end;
GLuint len = _glewStrLen((const GLubyte*)name);
if (glGetStringi){
GLint i, num_extensions;
glGetIntegerv (GL_NUM_EXTENSIONS, &num_extensions);
for (i = 0; i < num_extensions; i++){
p = (GLubyte*) glGetStringi (GL_EXTENSIONS, i);
if (0 == p) return GL_FALSE;
if (len == _glewStrLen (p)){
if (_glewStrSame ((const GLubyte*)name, p, len)) return GL_TRUE;
}
}
}else{
p = (GLubyte*)glGetString(GL_EXTENSIONS);
if (0 == p) return GL_FALSE;
end = p + _glewStrLen(p);
while (p < end){
GLuint n = _glewStrCLen(p, ' ');
if (len == n && _glewStrSame((const GLubyte*)name, p, n)) return GL_TRUE;
p += n+1;
}
}
return GL_FALSE;
}

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293058#Post293058

Scorcher24

Der Internetauftritt wurde überarbeitet und ergänzt mit neuen Funktionen und allgemein etwas aufpoliert.

Ausserdem eine neue Adresse:
http://nightlight2d.de/

Und Version 0.0.3 der Bibliothek ist auch im Anmarsch!

Zusätzlich hab ich auf die Versionsverwaltung auf git umgestellt. Damit kann nun jeder das Projekt einfacher klonen.

Scorcher24

Wie versprochen: Version 0.0.3
http://nightlight2d.de/component/content/article/8-library/16-version-003-announce.html

xaoC

Das hört sich wirklich vielversprechend an

Da du das Thema Kollisionserkennung ja auch schon angesprochen hast:

Ich denke, dies ist eins der zentralen Themen in der Spieleentwicklung und sollte so einfach wie möglich und so mächtig wie nötig sein, wenn man nicht direkt auf eine Physik Engine setzt.

Meine persönliche Erfahrung dazu:
Ich habe seinerzeit einige 2D Frameworks angetestet (z.B. Torque2D, PopCap) und in meiner Jugend (ewig ist's her) gerne mit Klik'n Play und der Games Factory rumgeiert, und das Resultat ist irgendwie immer das Selbe gewesen:

Keiner bekommt vernünftige Kollisionen hin, Nicht nur die Detection, sondern auch das Response scheitert. So stecken Sprites gerne in Tiles, bewegen sich ruckelig und sind alles andere als vernünftig zu benutzen. Was ein Framework angeht, das schnell zum Erfolg führen soll, ist das tödlich. Es gibt zwar z.T. fiese Tricks, um diese "popeligen" Kollisionen irgendwie zu fixen, aber da steckt man dann meistens schon nicht mehr drin.

Physikengines sind allerdings meistens schon zu overpowered oder lassen sich nur schwer auf die einfachsten Bedürfnisse anpassen (Limitierung in bestimmte Richtungen zum Beispiel, wobei ich da aber auch nur reingeschnuppert habe).

Manche Dinge sollten halt einfach funktionieren wie man sie erwartet. Wenn ich eine "Box" oder rechteckige Textur ins Level setze und sie als Collidable markiere, sollte mein Char (Im Top Down Fall) smooth aussen entlang driften, mit der korrekten Geschwindigkeit und ohne zu zuckeln. Für einen Plattformer gilt das gleiche: Kein Einsinken in die Plattform, kein Zuckeln. So etwas geht auch ohne Physikengine dahinter, allerdings zugegebenermaßen kein Zuckerschlecken aufgrund des Tunnelingeffekts etc.. Es kann aber auch keine Zauberei sein.

Zum Thema GUI / Editoren:
Ich würde mir das gut überlegen. Erstens ist sehr aufwendig, allgemeingültige Game Editoren zu erschaffen. Zweitens sind eben viele Ideen überhaupt nicht mit der Standardfunktionalität realisierbar, obwohl sie extrem simpel sind. Drittens ist es schwer, so etwas für alle OSs zu realisieren. Mir wäre eine sehr intuitiv zu benutzende API mit funktionierender Standardfunktionalität lieber.
Sprite Editoren etc. pp. braucht eigentlich keiner, der Gimp und co benutzen kann. Level Editoren funktionieren nur solange, wie du vorgegebene Konzepte 1:1 umsetzen willst. etc. etc.

Zur Scriptsprache:
Spricht etwas dagegen, gängie Scriptsprachen zu benutzen, die man evtl. anderweitig nutzen könnte (lua)? Ich kenne AngelScript noch nicht mal vom Hörensagen, das macht mich etwas skeptisch.

Ich habe leider z.Z. mein eigenes XNA Projekt am laufen, und bin aus C++ lange raus, aber ich finde es toll, dass du so etwas auf die Beine stellst.

Scorcher24

Danke für deinen Beitrag.

@Kollisionen

Ich habe bereits chipmunk an Bord, allerdings habe ich bei der Integration einige Probleme. Das ist direkt auf 2D optimiert und afaik ein Fork von Box2D. Box2D ist rausgeflogen, weil es keine kompilierung als .dll unterstützt.
Ich hab noch nie mit Physik-Engines gearbeitet und die Dokumentation ist sehr spärlich bei chipmunk. Der Dev hat mir da Recht gegeben und ich warte derzeit Nachschub in die Richtung ab :D.

Derzeit sind nur einfache Kollisionsabfragen vorhanden wie "isPointInside" und "intersects", welches testet ob sich 2 Sprites berühren. Allerdings ist das nicht pixelgenau und auch nicht sehr effizient. Das ganze Thema ist aber wieder so ne Sache für sich und deswegen suche ich ja auch Helfer, die sich vielleicht mit sowas sogar schon auskennen.
Der Fachbegriff wäre AABB Collisions.

@Editoren

Nunja, da wird man sehen wie das zu lösen ist, oder ob ich einfach Editoren von anderen mitliefer. Mein ShaderEditor funktioniert aber bereits ganz gut und markiert auch veraltete Funktionen der Shadersprache GLSL, die mit Version 1.5 nicht mehr funktionieren. Fand ich wichtig für Umsteiger und wird auch weiter entwickelt.
Ich sehe mir derzeit diesen LevelEditor an:
http://www.mapeditor.org/
Das Format sollte nicht zu schwer einzubauen sein.

@AngelScript

AngelScript bietet eine sehr einfache Möglichkeit, C++ Klassen einzubauen. Daher meine top Wahl. Und es ist auch sehr effizient, da es auch für Konsolen entwickelt wird und eine C++/Java-Like Syntax bietet.
Ich finde es vor allem einfacher zu integrieren als LUA und Python und werde auch dabei bleiben.
Das ist nicht böse gemeint, aber ich nutze das schon seit einiger Zeit und finde es einfach toll.
Kleines Beispiel:

// Registering the interface to angelscript
void NLBoundingBox::registerWithAngelScript( asIScriptEngine* e )
{    
    AS_ERR_CHECK(e->RegisterObjectType("NLBoundingBox", 0, asOBJ_REF));
    AS_ERR_CHECK(e->RegisterObjectMethod("NLBoundingBox", "bool intersects(const NLBoundingBox@)", asMETHOD(NLBoundingBox, intersects), asCALL_THISCALL));
    AS_ERR_CHECK(e->RegisterObjectMethod("NLBoundingBox", "bool isPointInside(f32 x, f32 y)", asMETHODPR(NLBoundingBox, isPointInside, (f32,f32), bool), asCALL_THISCALL));
    AS_ERR_CHECK(e->RegisterObjectMethod("NLBoundingBox", "void translate(f32 x, f32 y)", asMETHODPR(NLBoundingBox, translate, (f32,f32), void), asCALL_THISCALL));
    AS_ERR_CHECK(e->RegisterObjectMethod("NLBoundingBox", "void translateTo(f32 x, f32 y)", asMETHODPR(NLBoundingBox, translateTo, (f32,f32), void), asCALL_THISCALL));
    AS_ERR_CHECK(e->RegisterObjectMethod("NLBoundingBox", "void rotateAroundCenter(f32 angle)", asMETHOD(NLBoundingBox, rotateAroundCenter), asCALL_THISCALL));

    // Behaviour: Factory and Refs
    AS_ERR_CHECK(e->RegisterObjectBehaviour("NLBoundingBox", asBEHAVE_FACTORY, "NLBoundingBox@ NLBoundingBox()", asFUNCTIONPR(factory, (void), NLBoundingBox*), asCALL_STDCALL));
    AS_ERR_CHECK(e->RegisterObjectBehaviour("NLBoundingBox", asBEHAVE_RELEASE, "void NLBoundingBox()", asMETHOD(NLBoundingBox, release), asCALL_THISCALL));
    AS_ERR_CHECK(e->RegisterObjectBehaviour("NLBoundingBox", asBEHAVE_ADDREF, "void NLBoundingBox()", asMETHOD(NLBoundingBox, addRef), asCALL_THISCALL));
}

Einfacher gehts nimmer. Ist aber, zugegeben, intrusive.
Ist aber zu verschmerzen.

xaoC

Dokumentation ist generell ein Riesenproblem, gerade bei Open Source Projekten, die nicht die große Masse erreichen. Man unterschätzt leider oft den Wert einer guten Dokumentation.

Trivial ist Collision und Response beileibe nicht. Ich hatte selber einige Kopfschmerzen davon und es irgendwann aufgegeben, da ich prinzipiell keinen Sinn darin sehe, das Rad neu erfinden zu müssen. Zu dem Zeitpunkt war ODE 'in', das hatte ich getestet, aber diese Engine ist extrem Abstrakt und war für meine Zwecke viel zu overpowered. Mittlerweile gibts da deutlich mehr Auswahl. Naja, dann kam der Beruf und seitdem bin ich diesbzgl. erst seit kurzem wieder ernsthaft dabei, allerdings w.g. nicht mit C++.

Ich wollte dich bzgl. deiner Script Wahl überhaupt nicht kritisieren, aber man muss im Hinterkopf behalten, dass viele Leute gängige Script-Sprachen können, und sich nicht NOCH eine Sprache aneignen wollen (die sie auch nur für EINEN Zweck nutzen können).

Der Editor schaut ebenfalls interessant aus.

Scorcher24

Ich habs nicht als derbe Kritik aufgefasst, nur meine Entscheidung dargelegt :).

Bei der Dokumentation gebe ich mir Mühe es nicht schleifen zu lassen!
http://docs.nightlight2d.de/

Scorcher24

Hab vorhin Version 0.0.4 hochgeladen.
Bei der letzten Version ist mir ein folgenschwerer Fehler unterlaufen und das Ding lief nicht auf NVIDIA Karten.
Ist aber jetzt behoben. Sorry dafür.
Desweiteren wurde bei allen Klassen das Prefix NL entfernt. Nur in einigen wenigen Funktionen und Macros ist es weiterhin vorhanden.
Bei Macros muss es ja leider sein^^.

Auf meiner Homepage ist mittlerweile auch ein Google GIT Tracker für Joomla von URKS mit drauf.
Schaut doch mal auf seiner Projektseite vorbei!
http://code.google.com/p/urks-post-commit-webhook/
Wir haben das Teil quasi zusammen entwickelt. Wobei der größte Teil vom Code von URKS kommt.

Scorcher24

Kleine Rückmeldung nach einiger Zeit:
Das Projekt ist nicht eingeschlafen. Ich hatte nur einige Rückschläge wie zuerst einen HDD Crash und nun auch noch der gesamte Computer kaputt gewesen. CPU im wahrsten Sinne abgeraucht :D.

Aber die Entwicklung schreitet nun voran und ich hab wieder einige Bugfixes ins GIT geschoben. U.a. hab ich den Vollbild Modus angepasst bzw verbessert.

Ich würde mich wirklich über Feedback freuen und ob jemand bugs gefunden hat.
Ich nutze es schliesslich meistens (:p) nur so wie es gedacht ist :D.

Wer es aus dem Trunk bauen möchte, braucht eigentlich nur das Paket mit den Abhängigkeiten von google runterladen.
Derzeit sind die Branches master und developer auf dem gleichen Stand.

Neuestes Feature:
Ein GameStateManager:
http://code.google.com/p/nightlight2d/source/browse/NightLightDLL/GameStateManager.hpp

Beispiel:
http://pastebin.com/c5nX14U9