CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten

Ich habe hier gerade mit einer Steam Windows Kiste sowohl mit 32019 als auch mit 31944 getestet.

Es könnte noch sein das ne alte CommonAPI2Native.dll irgendwo im System/Lua Pfad rumliegt, aber auch das wäre sehr unwahrscheinlich.

Die DLL bzw. das Spiel könnten so ungünstig im Speicher liegen via ASLR das ein Patch unmöglich wird, das wäre aber ein sehr seltenes Ereignis und ich wüsste nicht wie ich es testen könnte.

Der RTTI Code schaut eigentlich in den Binärcode, nach nem String und errechnet daraus dann die Speicherposition.
Haben andere Nutzer das selbe Problem? Wenn ja, bitte mal melden inkl. technische Daten: Arbeitsspeichergröße, Windows Build Version, etwaiger Virenscanner.

Das ist ein Mod von VacuumTube , TownsDevelopmentActive = false ist auch eingestellt via settings.lua des Mods? Einfach mal in den Ordner No_Town_Development_1 schauen,

Nur um ganz sicher zu gehen, Du bist im Karteneditor mit tropischer Karte, große Karte und im Karteneditor crasht es oder, so eine Karte gespeichert -> und dann laden und crash im weiteren Spiel?

Jetzt habe ich gerade in der letzten Version die imgui Stats deaktiviert, dann könnte man schauen wie groß das Vertex Array wirklich ist. I

Ist das CommonAPI Menü oben auf sichtbar oder unsichtbar geschaltet?

Hab mal mein 3200G mit einer großen Karte ohne Aktionen 20 Minuten mit Tropical laufen lassen, bis jetzt kann ich das leider nicht reproduzieren...

Es gibt an der Stelle eigentlich nur zwei Möglichkeiten, entweder ich bekomme den Speicher gemappt in der Größe oder nicht.

VK_ERROR_MEMORY_MAP_FAILED = -5 bedeutet ich bekomme meinen Buffer nicht mehr eingeblendet

if (draw_data->TotalVtxCount > 0)
    {
        // Create or resize the vertex/index buffers
        size_t vertex_size = draw_data->TotalVtxCount * sizeof(ImDrawVert);
        size_t index_size = draw_data->TotalIdxCount * sizeof(ImDrawIdx);
        if (rb->VertexBuffer == VK_NULL_HANDLE || rb->VertexBufferSize < vertex_size)
            CreateOrResizeBuffer(rb->VertexBuffer, rb->VertexBufferMemory, rb->VertexBufferSize, vertex_size, VK_BUFFER_USAGE_VERTEX_BUFFER_BIT);
        if (rb->IndexBuffer == VK_NULL_HANDLE || rb->IndexBufferSize < index_size)
            CreateOrResizeBuffer(rb->IndexBuffer, rb->IndexBufferMemory, rb->IndexBufferSize, index_size, VK_BUFFER_USAGE_INDEX_BUFFER_BIT);

        

        // Upload vertex/index data into a single contiguous GPU buffer
        ImDrawVert* vtx_dst = NULL;
        ImDrawIdx* idx_dst = NULL;
        VKRENDER_CHECK_DEBUG(vulkandldi.vkMapMemory(tpf_vkctx_wrapper->getVkDevice(), rb->VertexBufferMemory, 0, vertex_size, 0, (void**)(&vtx_dst)) );
        VKRENDER_CHECK_DEBUG(vulkandldi.vkMapMemory(tpf_vkctx_wrapper->getVkDevice(), rb->IndexBufferMemory, 0, index_size, 0, (void**)(&idx_dst)) );

        for (int n = 0; n < draw_data->CmdListsCount; n++)
        {
            const ImDrawList* cmd_list = draw_data->CmdLists[n];
            memcpy(vtx_dst, cmd_list->VtxBuffer.Data, cmd_list->VtxBuffer.Size * sizeof(ImDrawVert));
            memcpy(idx_dst, cmd_list->IdxBuffer.Data, cmd_list->IdxBuffer.Size * sizeof(ImDrawIdx));
            vtx_dst += cmd_list->VtxBuffer.Size;
            idx_dst += cmd_list->IdxBuffer.Size;
        }
        VkMappedMemoryRange range[2] = {};
        range[0].sType = VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE;
        range[0].memory = rb->VertexBufferMemory;
        range[0].size = VK_WHOLE_SIZE;
        range[1].sType = VK_STRUCTURE_TYPE_MAPPED_MEMORY_RANGE;
        range[1].memory = rb->IndexBufferMemory;
        range[1].size = VK_WHOLE_SIZE;
        VKRENDER_CHECK_DEBUG(vulkandldi.vkFlushMappedMemoryRanges(tpf_vkctx_wrapper->getVkDevice(), 2, range));
        vulkandldi.vkUnmapMemory(tpf_vkctx_wrapper->getVkDevice(), rb->VertexBufferMemory);
        vulkandldi.vkUnmapMemory(tpf_vkctx_wrapper->getVkDevice(), rb->IndexBufferMemory);
    }

Und die Vulkan Spec sagt:

https://www.khronos.org/regist…pMemory.html#_description

Der Treiber kann das nicht mehr Mappen, weil der Speicher vielleicht fragmentiert ist. Der Code wird technisch bei jedem Render Present Pass aufgerufen und technisch sollte es ja wenn es einmal in den Speicher passt, das auch zukünftig mappen können

Ergo kann es sein einfach nicht mehr genügend Platz gibt im VRAM gibt, das würde dann zum Crash führen. Ich kann versuchen die beiden Buffer nacheinander zu kopieren aber eine Lösung auf Dauer wäre das dann auch nicht.

Und für alle, sollte es morgen ne Beta Build geben:

Nein, CommonAPI2 wird nicht direkt darunter laufen bei der angekündigten Änderungsliste ...

Die Behandlung der Buffer basiert auf den imgui Beispiel Code und wird im Mesa Overlay für Vulkan ( Intel hat das zu Mesa hinzugefügt) genauso gemacht:

https://gitlab.freedesktop.org…y-layer/overlay.cpp#L1238

Also so total falsch kann das auch nicht sein

Technisch ist aber CommonAPI2 kein Vulkan Layer, sondern klemmt sich zwischen Vulkan und TPF2.

Es kann sein das TotalVtxCount zu groß wird und das der Inhalt der Daten nicht mehr dort rein passt. Ich muss mal schauen ob ich da mehr Debug Daten hinbekomme. Aber auch da ist die Frage, warum es dann TPF2 Klima abhängig ist

Ich denke also eher daran, das mein Code genau da Probleme bekommt, weil etwas anderes nicht stimmt. Sehr komisch und mein 3200G läuft ja auch mit Mesa GIT aber ich hab da ne 4GB Resizeable Bar Einstellung, das ist eher ungewöhnlich für ein APU...

Wenn es ohne Render aktiven Render Code passiert, kann es noch sein, das die Fonttextur (einmalig geladen, nicht jedes Frame) zu einer Kollision führt, ich würde dich daher bitte, das mal ganz ohne installierten CommonAPI2 zu schauen, ob es auch passiert.

Ich habe das Gefühl, das technisch der Renderer an der Stelle schon gestorben ist, wegen anderen Problemen und es erst an diesem Punkt auffällt...

Mal ohne CommonAPI2 und mit dem heutigen Sommer Update testen, vielleicht hat UG da schon einen Fix oder ne bessere Fehlermeldung...

Aus aktuellen Anlass: (Cross Post)

Bitte deinstalliert CommonAPI2 komplett wenn ihr die aktuelle Beta nutzt,

Ich weiß nicht was UG gemacht hat, aber mein ganzes UI System gebaut mit TPF2s Bordmitteln funktioniert seit Build 33262 gar nicht mehr. Und ich rede hier nicht von exotischer Nutzung oder das laden meiner C++ DLL / so.

Sprich der Entity Inspector und das untere CommonAPI2 Menü im Spiel crasht das Spiel mit wilden Fehlermeldungen wie diesen hier:

../../src/Lib/UI/MemoryManager.h:28: std::unique_ptr<_Tp> UI::MemoryManager::Remove(T*) [with T = UI::CComponent]: Assertion `it != m_data.end() && "Item is still owned by UI code."' failed.

Auch erhalte ich komische Fehler vom Texturmanager bezüglich element:destroy() unter Linux. Oder das ganze Spiel bleibt im Crashhandler einfach stehen. (Ein Dump wird erzeugt, das Spiel aber nicht beendet)

Auch funktioniert mein Failback UI auch nicht mehr. Ich habe keine Ahnung warum man alle UI Bemühungen immer torpediert... So funktionieren natürlich Failbacks nicht, wenn die UI implodiert.

---

If you use TPF2 Beta Build 33262 uninstall CommonAPI2 completely .

I don't know what UG changed, but my whole UI System build with UGs API Toolkit doesn't work anymore since Build 33262. Even removing all failback start menu code, dll and so on.

The entity inspector and the lower CommonAPI2 menu while in game crashes the game with odd error messages like:

../../src/Lib/UI/MemoryManager.h:28: std::unique_ptr<_Tp> UI::MemoryManager::Remove(T*) [with T = UI::CComponent]: Assertion `it != m_data.end() && "Item is still owned by UI code."' failed.

I get some random Texturemanager errors aswell, if I try to use element:destroy under Linux. The whole game stops in the crash handler after creating a dump, but the game won't quit properly.

I simply don't understand that all ui work get constantly get crashed, I can't write proper failbacks if the ug ui implodes...

WICHTIG:

Habt Ihr keine Beta/Testversion von TPF2, so nutzt bitte weiterhin:

CommonAPI2 - Neue Versionen und wichtige Informationen

Für Build 33262 Beta hab ich mal meinen jetzigen Stand zusammengepackt: 1.7.20210620-dev

Im großen und ganzen läuft diese Version mit der Beta Version.

Es gibt nun auch ein Rendermode Einstellung, wenn UG nicht ständig irgendwas an der UI herum bastelt, würde ich mehr Funktionen portieren, aber es gibt leider zu viele Stolpersteine bei jeder Release.

2 = Die CommonAPI2 Render Pipeline wird nicht genutzt, damit hat man leider keine Möglichkeit Mods zu verwalten, aber damit kann man meinen Vulkanrender komplett abschalten...

Für Build 33345:

Bitte nutzt buildoverwrite steam_33345_1