I had no issues going into the hall of fame screen in 1920x1080 d3d9.
Also, the only truck I could see correctly textured in the garage was my small tires "Porsche 917 Kurzheck" (which I just noticed never uploaded to mtm2.com. probably I wasn't happy with the tire pos)Porsche917.rar here it is if you want to test it. it has a single 256p texture and single 64p for tires.
With the 2048 d3d textures config in monster.ini up & down town beta finally runs smoothly, no lag spikes, but it crashes if I race with computer opponents.
This was a painful bug. The spanfill (which deals with the software renderer) was originally in assembly code. Visual Studio 6 which i used so far, was using that to build the game. When I switched to VS2015, it refused to work with the old assembly stuff so I switched to a spanfill.cpp that was written by TRI but only half way. And guess what, there was one line of code for the truck preview that was only in the original assembly file. It was extremely hard to find it because all the tests the AI was doing was coming out correct despite the truck not working right. It was me who suggested that maybe we should look in the old assembly and turned out to be true. Without AI i would have never figured it out because I cannot understand a lick of the assembly code. Just random numbers thrown together.
Also what do you mean it crashes? Like the usual crash that we experience in MTM or something more specific?
Side note: That might be fixed in the meantime, DX9 is getting more and more ready. I have a pretty solid working copy right now but I want to try and improve performance a bit more, see how much I can squeeze with my limited knowledge.
Fila wrote: Wed Jun 17, 2026 3:48 amTbf it is not all doomsday but there will be bad stuff up ahead for general human population.
*Terminator theme starts playing*
Fila wrote: Wed Jun 17, 2026 3:43 am
Ooooooo I looked into it now. In cowpod you used to be able to register the game with windows so then it would know it is patched. I don't think it can do that anymore on Win11.
Honestly, putting out a new pod mounting program with AI is very easy. I'll add a note about it.
Please! I don't want to put up with Cowpod and PodIt any longer with these godforsaken pod cap limits built into them!
monsterextremo wrote: Tue Jun 16, 2026 10:13 pm
Just a quick note, hall of fame is broken for me, it crashes when i try to see that screen
I take it that this is all with something to do with MTM2 running at resolutions higher than 1920x1080? Cause my end is working fine on that particular resolution.
I will probably make the game point out in monster.ini what the current pod limitation is and when i create an app, it will look for the number there (with a default fallback to go). This way it would be future proof if/when i increase limits again.
I had zero issues doing my install method in Win11 ARM version so I doubt that's the issue. but you need to do the the registry patch when you still have the original, stock monster.exe.
cowpod sets a 30 pod limit (which is the stock limit as far as i remember) when it can't detect the version of the existing "monster.exe" executable and it does this by reading its size in bytes, so of course the new community patches are unknown to cowpod since their executable vary in size and go undetected. this has to be fixed in code: only set 30 pod limit when v41 (stock version) is detected, anything else: 99.
Fila wrote: Wed Jun 17, 2026 3:52 am
This was a painful bug. The spanfill (which deals with the software renderer) was originally in assembly code. Visual Studio 6 which i used so far, was using that to build the game. When I switched to VS2015, it refused to work with the old assembly stuff so I switched to a spanfill.cpp that was written by TRI but only half way. And guess what, there was one line of code for the truck preview that was only in the original assembly file. It was extremely hard to find it because all the tests the AI was doing was coming out correct despite the truck not working right. It was me who suggested that maybe we should look in the old assembly and turned out to be true. Without AI i would have never figured it out because I cannot understand a lick of the assembly code. Just random numbers thrown together.
x86 asm code is quite hard to understand compared to risc (arm) architectures. but no need to go that route, mtm2 can run fine in modern hardware without the need of assembly, which limits portability. and I bet mtm2 code can run excellent on modern memory-managed platforms also... just saying
Fila wrote: Wed Jun 17, 2026 3:52 amAlso what do you mean it crashes? Like the usual crash that we experience in MTM or something more specific?
a silent, nasty crash to desktop
Fila wrote: Wed Jun 17, 2026 3:52 am
Side note: That might be fixed in the meantime, DX9 is getting more and more ready. I have a pretty solid working copy right now but I want to try and improve performance a bit more, see how much I can squeeze with my limited knowledge.
yes, I did the same with Traxx GL; port first, then performance analysis at the end.
Hey Fila, with all the new found glory with Dx9 and Kmasters utilities I found the page that had the update VS code and I manage to get the mtm2_visualstudio14-Beta043 version of d3d render dll to compile, compiled with vs 2026 and was going to attempt to see yet again about a opengl renderer. Question is patch v0.43 that i built off of, you haven't change the rendering api for the dlls since v.43 have you? If so I might be better off workin from the new version. I haven't tried my dll compiled with .45 yet so... I suppose I could try that for now.
Fila wrote: Wed Jun 17, 2026 3:49 am
What resolution you running? Just wanna rule that out first in case I forgot something related to it.
Well, I'm testing in a Windows 11 laptop with the next spec sheet:
Vendor: Acer
Model: Nitro V 15
Processor: Intel Core i7 -3620H
GPU: Nvidia GeForce RTX 4060 Laptop
RAM: 16 GB DDR5 at 5200 MT/s single channel.
Storage: 1 TB SSD M.2 Western Digital SN740 PCIe gen 4x4
OS: Windows 11 Home Single Language (Spanish)
Screen: 1920x1080 at 165 hz
Also, when I finish a race with 8 trucks, the game crashes and it's stuck with "Determinating other truck times" or something like that.
DLL_INTERFACE int APIDLLendScene()
{
if (hDC_GL) {
SwapBuffers(hDC_GL);
}
sceneOpenFlag = 0;
return 1;
}
DLL_INTERFACE int APIDLLlockFrame()
{
return 1;
}
DLL_INTERFACE int APIDLLunlockFrame()
{
return 1;
}
DLL_INTERFACE int APIDLLselectTexture(textureStruct* t, unsigned char* tb, int txo, int tyo, unsigned char* pal)
{
if (!t) return 0;
return 1;
}
DLL_INTERFACE int APIDLLupdateTexture(textureStruct* t, unsigned char* tb, int txo, int tyo, unsigned char* pal)
{
return 1;
}
DLL_INTERFACE int APIDLLsetMipMapLevel(int l)
{
return 1;
}
DLL_INTERFACE int APIDLLdrawPolygon(vertexStruct* appVertexList, int n, int flag)
{
glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
glBegin(GL_POLYGON);
vertexStructDLL* v = (vertexStructDLL*)appVertexList;
for (int i = 0; i < n; i++)
{
float sx = ((float)v->x2d / 65536.0f) / (directPIXX / 2.0f) - 1.0f;
float sy = -(((float)v->y2d / 65536.0f) / (directPIXY / 2.0f) - 1.0f);
float sz = (float)v->z / 65536.0f;
Fila wrote: Wed Jun 17, 2026 3:49 am
What resolution you running? Just wanna rule that out first in case I forgot something related to it.
Well, I'm testing in a Windows 11 laptop with the next spec sheet:
Vendor: Acer
Model: Nitro V 15
Processor: Intel Core i7 -3620H
GPU: Nvidia GeForce RTX 4060 Laptop
RAM: 16 GB DDR5 at 5200 MT/s single channel.
Storage: 1 TB SSD M.2 Western Digital SN740 PCIe gen 4x4
OS: Windows 11 Home Single Language (Spanish)
Screen: 1920x1080 at 165 hz
Also, when I finish a race with 8 trucks, the game crashes and it's stuck with "Determinating other truck times" or something like that.
So i ssume you are running the game itself in 1920x1080 right? And no nglide/dgoovoo interferes?
It doesn't crash for me however I have also worked on the specific bug with the software renderer (which the hall of fame uses) so maybe it is tied to that. We will see when I have the next version ready.
Jpez1432 wrote: Wed Jun 17, 2026 2:05 pm
Hey Fila, with all the new found glory with Dx9 and Kmasters utilities I found the page that had the update VS code and I manage to get the mtm2_visualstudio14-Beta043 version of d3d render dll to compile, compiled with vs 2026 and was going to attempt to see yet again about a opengl renderer. Question is patch v0.43 that i built off of, you haven't change the rendering api for the dlls since v.43 have you? If so I might be better off workin from the new version. I haven't tried my dll compiled with .45 yet so... I suppose I could try that for now.
I have. 45 uses dx9 whereas 43 uses dx5. And I am also still working on it with lots of changes.