spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hi Hannes,

solange es im header nuklear.h keine Referenzen auf dessen *.c gibt, musst du eine lib erzeugen, dies klappt(zu fuss), aber dann gibt es externe Referenzen die nicht aufgelöst werden, damit
ist der Versuch schwerst gescheitert. Es handelt sich dabei um 4 Refrenzen NKMEMCOPY MKMEMSET MKMEMMOVE auch andere Libs ver-pointern Systemelementare Funktionen mit Zeigern
damit sie die unterschiede von memcopy und memset unter linux austauschbar bleiben. Man müsste also forschen wo genau NKMEM..usw redefiniert werden müssten.
Und wenn man da erst anfängt herumzufingern , kann man auch getrost sich davon verabschieden.

Also nur das Header kann nicht reichen, es gibt ein Kompilat das man selber nicht mit vs herstellen kann ohne diese LNK. Fehler, mag sein das der CMake pyton -qwatsch andere
Options mit dem GCC verwendet, das holz kommt hier nicht im Windows rein.

Da kannst Du auch drei mal das selbe schreiben, es reicht nicht aus. So eine lib muss man auch später wieder kompilieren können, das steht mal außer Frage, läuft aber nicht so.

Danke für deinen Hinweise mit dem Include, das war ja in der doc das erste.
Gruß aus Berlin
Karsten

Hi Hannes,
danke für deine Antworten, ich werde es nochmal versuchen mit dem von Dir genommen Header,
fand auch selbst im Header diverse Self defines auf NKMEMCPY usw.. auch bei der Lua lib musste man einen eigenen callback anwenden um Speicher zu allozieren

Ich mach da mal die Tage nen Video. und Berichte über die Integration sollte es dann klappen.

Gruß
Karsten

Ja das Bild enthielt den Versuch das andere Header zu laden, das im Wurzelverzeichnis war null byte.

Jedoch wird glw verwendet, ich bin auf gls und da kollidiert es, wird auch in Zukunft unter glxx wieder problematisch .

Ich habe jetzt mal abgebrochen. www.twitch.tv/kahnsoft/

Danke für die Hinweise
Grüße Karsten

Hallo David,

okay.. das wusste ich so nicht, habe mich schon über die unterschiedlichen Demos dort gewundert.
Leider stürzt es nach der Initialisierung in einen Assert.

Unklar in allen Exempels bleibt woher der Font, NK_fon.. gibt es, eine leere var davon an den nk_begin.. führt schon zum abschied,
nach ein paar Stunden war ich durchweg gesättigt und habe es vom Rechner gelöscht.

Wieso sollte es abstürzen , in einem leeren Gerüst .. keine Ahnung, und wenn soetwas passiert passiert es nach der Integration
erneut, und man keinen Schimmer was der Fall ist, bin da reindebuggt , und beim Textfont ausgeben in der Tiefe stürzt es weg..

Also in der Zeit habe ich schon meine eigenen Layer über xml definierbar hereingehauen.. Runde Ecken sind schon mal der nächste Ansatz
In 2 Jahren bin ich dann auch weiter damit ...

Danke all der Hinweise!
VG Karsten

Hi Dave,

ja es ist die Hölle das alles selber zu machen, ich habe einen dynamischen PropertyTree für die GDI hergestellt, den nutze ich intensiv seit 15 Jahren, mit xml Parser, und html Export für dynamische Softwarebedienung vom Handy aus, das hat 10 Jahre gedauert, erst seit 5 Jahren muss ich daran nichts mehr ändern, alle meine Programme haben statt Dialoge dynamische Proptrees rechts.

Die Nuklear Engine scheint komplex, wenn sie sogar für gdi nutzbar ist, ist das schon ein Träumchen.

Vielleicht muss ich da noch mal sinnieren, man hat auch über die Jahre viel Mist integriert der wieder weg musste. Da ist man sensibilisiert.

Ich gebe bescheid wenn der Durchbruch kommt

Ansonsten zeig doch mal ein Bild deiner UI in Action , vielleicht können wir was Tauschen. Andererseits frage ich mich, ob ich meinen propertytree in ein unsichtbares fester abbilde und den Inhalt auf eine Plane "blitte". Dann muss ich nur noch die Maus Ordinaten translatieren. Oder ich stelle den Property-Tree an die Seite des Fensters aber so sieht halt kein Spiel aus.

Mir geht es nur um das Grundgerüst es gibt kein Fernziel.


Grüße gehen raus
Karsten