Nach dem Windoof Neustart und Version 32019 sowie 20210607 funzt wieder alles wie es soll! Zumindest weiß man jetzt das ein Windows Neustart hilft.
CommonAPI2 Entwicklungsdiskussion, Fragen & Antworten
Willkommen in der Transport Fever Community
Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.
Die Registrierung und Nutzung ist selbstverständlich kostenlos.
Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.
Das Team der Transport-Fever Community
-
-
Das entfernen der weißen Überlagerung beim erstellen von Linien war eine mehr als gute Idee. So sehe ich das ganze besser.
Ein Problem habe ich aber:
Ich habe den Town Development-Mod heruntergeladen mit dem man das automatische Städtewachstum ausstellen kann. Er ist aktiviert und auch korrekt eingestellt dass er normal nix mehr bauen dürfte. Leider funktioniert das ganze aber nicht und die KI baut weiter.
-
Ja, ist eingestellt.
-
Dann könnte™ es sein, dass in der Ladereihenfolge später ein anderes Mod die Stadtentwicklung wieder aktiviert.
-
Hallo eis_os,
ich habe noch einmal ein bissche mit meinem bug (#1, #2) rumgespielt.
Crasht nach ca. 20 Minuten.
Crasht nicht, ca. 90 Minuten gespielt.
Tropical an beiden stellen crasht auch.
Es liegt also irgendwie an der skybox oder atmosphere?
(Dazugehörige stdout.txt)
Edit: Temperate map generator mit tropical environment schmiert auch ab, liegt definitv am environment.
-
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=
Ich erstelle eine Random Karte (oder lade eine aus dem Workshop) gehe in die einstellung, stelle environment auf TROPICAL (der rest scheint komplett egal zu sein, da hab ich schon viele Kombis durch) und starte das Spiel.
Dann baue ich eine Linie auf, und lass die laufen. Nach 20-30 Minuten schmiert TpF2 ab. Ich glaube es passiert nicht, wenn man das Spiel einfach im Pause Modus belässt, vielleicht hatte ich da aber auch zu wenig geduld.
Im Moment spiele ich eine große Tropische Map mit environment auf DRY, keine Probleme seit ca. 11:30.
Edit: Und ja, das Menü ist sichtbar. (Wusste gar nicht, dass man das abschalten kann.
) -
Hast du vielleicht irgendeine Mod an, die etwas am Enviroment Tropical ändert oder hast du irgendetwas bei den Vanilla-Dateien verändert?
Andere Frage: Mit ausgeschalteter und deinstallierter CommonAPI hast du den Fehler nicht?
-
Hast du vielleicht irgendeine Mod an, die etwas am Enviroment Tropical ändert oder hast du irgendetwas bei den Vanilla-Dateien verändert?
Andere Frage: Mit ausgeschalteter und deinstallierter CommonAPI hast du den Fehler nicht?
Siehe die originale Fehlermeldung, der Fehler ist in CommonAPI, bzw. in der Renderkomponente. Soweit ich nachvollziehen kann pfuscht kein mod am Tropical Environemt rum. (AKA es hat kein mod ein res/config/environment/)
-
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
C
Alles anzeigenif (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 ...
-
Alles anzeigen
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
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
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.
I will auch nicht ausschließen, dass der mesa Treiber da mist baut, wer weiss. AMD ist bei gamern ja eher rar.
Das Komische ist halt, dass das nur mit einer von drei environment maps passiert, weil die machen an sich ja nicht so viel. Bisschen Licht, bisschen Skybox und Parameterisierung für den Wasser shader.
Mesa hat nur eine Stelle an der VK_ERROR_MEMORY_MAP_FAILED auftritt für RADV und ansonsten finde ich dazu nur einen obskuren vkcube bug.
Diverse Diskussionen rund um Vulkan behaupten man soll am besten seinen Speicher direkt beim Start mappen und dann behalten anstatt das in der Render Loop zu machen, wäre das hier eine Option?
Bis auf den allerletzten crash ist der auch immer am IndexBufferMemory gescheitert, nie am VertexBufferMemory. Kannst du einen großen Block mappen und dann die pointer offsets selbst ausrechnen? Ich habe vage Anspielungen auf mögliche race conditions gesehen und du machst da 2 map calls direkt hintereinander...
Ich mach gleich erst mal Updates und guck ob sich zufällig was am Treiber getan hat.
Edit: Keine Besserung. Hab sogar mal AMDVLK statt RADV ausprobiert, hat keine Auswirkung auf den Fehler.
-
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...
-
So wirklich Sinn macht das alles nicht.
Ich hab jetzt auch mal versucht den Button nach dem Spielstart abzuschalten (Close Menu), mit dem Ergebnis das TPF2 immer noch das Zeitliche segnet, aber jetzt komplett ohne Fehlermeldung. Einfach weg.
Schmeisst TPF2 dir was vor die Nase was so einfach nicht passt? Vielleicht ist ja auch einer von deren shadern problematisch, aber gerade noch gut genug, dass der durchrutscht wenn keiner zu genau hinguckt (aka n Overlay hinzufügt).
-
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...
HEUREKA!
Scheinst Recht zu haben. Deine Fehlermeldungen sind aber schöner...
Wie lasse ich diese Information denn jetzt möglichst effizient UG zukommen?
