Re: MTM2 Beta Patch 0.48 - and we have Dx11

[OG_RuDeE]

First impressions:

Snow no longer seems to break. However, ground shadows seem to get covered up by the snow.

I didn't see any glitching of the sky's reflection in the water.

Out of all the tracks I tried, no shadows were drawn for 2d facing trees. (Edit: I tought treasure bay was an exception, but the facing models are not 2d!)
If we're going to keep 2d facing tree's shadows stationary, my suggestion is to bake them as if the models are facing the player's starting position ignoring how the models were positioned in Traxx (and I guess the .sit) file. Another (maybe better) possibility is to bake them as if they are facing perp to the sun's direction, which I think would maximize the shadow they cast. Whichever is easier, if either are even possible.

Other than that, I haven't noticed anything so far, and things are running as smoothly as before.

Edit: Almost no ground shadows are being cast by models (and ground boxes?) in Zoonette Euro.

Flickering models in Fila's Holiday.

[Fila]

Edit: Almost no ground shadows are being cast by models (and ground boxes?) in Zoonette Euro.

Flickering models in Fila's Holiday.

Omg about Zoonette. That's another edge case i tried to fix and it broke that. I think I probably have to get the AI to do a shadow map logic rewrite.

Snow/Shadow is an easy fix.

[Fila]

Ruddee, is the flickering in Fila's Holiday on those houses by the swamp area?

Side note: There's a boat there with an animated sail and the shadow catches the animation too ^_^

[OG_RuDeE]

I'll report back when I get home in an hour or so.

Ps. What about the 2d facing tree shadows? Waiting to hear from Kmaster?

[Fila]

Still undecided about that one. The only alternative would be to have them do the still shadow as if they are facing the sun. If you start with them as they are facing the truck, some will be at 90 degrees towards the sun so will forever be stuck with a thin line of shadow.

[OG_RuDeE]

These are the flickering buildings:



And just a nice screenshot:

[OG_RuDeE]

Total sidequest, but I'm curious, do you have any idea why that particular shade of blue on the Treasure Bay backdrop would get rendered as transparent by the engine? (Attached.)

As I mentioned in another post, just rebuilding the raw file "fixed" it (no longer transparent).

[Fila]

Have you tested that bar during clear? It shows up as a gray bar during clear for me. It gets darkened to almost black during dusk because every backdrop gets a dark pass.

The blue itself is not transparent. If you remove the water reflections, the blue will show up. This has been a longstanding quirk since the original game. Have always been on the fence whether to fix it or not. It was mostly not noticed because up until these performance improvements, running water reflection was a death sentence.
I also didn't want to touch it in Dx9 as it could have resulted in weird issues. Might fix it for DX11 only and leave it as is for 9.

I might have accidentally fixed the buildings when I was doing a different shadow work as they are not flickering on my end. I also discovered that some models were having clear shadow issues on Egypt/Fila's Holiday and that got fixed too (their shadow not showing up).

[OG_RuDeE]

Yes, for me on clear it has a small checkerboard background as if it were transparent. It's not solid grey, which would be fine.

Interesting to know about the reflections. I didn't know that conflicted with the backdrops.

[Fila]

Oh interesting. The treasure bay and skull island are identical backdrops except either the blue is replaced by grey or the track palette itself changes the color. Because otherwise they are identical and one shows up as solid grey and one as checkered grey.

[Fila]

But yeah that small band of blue that is above the deep blue gets rendered incorrectly into either grey or checkered grey. Will take a look into it. In the meantime I discovered that the background can be seen through the water (only easy to see with water reflection off and if the background has more obvious artifacts)

[Ford-chan]

I actually implemented Kmaster's desire to have the spinning trees not cast shadows other than their original big square thing. Let's see how people feel about it. Otherwise they dim according to the weather and whether they are in shade or not (from other objects, caves etc)

Not sure where my desire on having a visual course line drawn in front of you sits right now? But sooner or later given that I want to start driving on Enocell's tracks, which are notorious for off road and course excursions and whatnot, hence why I left most of them podded out till then.

JSTrackViewer and the in game track map HUD isn't as effective for when I simply want to jump straight in the track without going through such a timely process.

[Ford-chan]

By the way, I tried out some of those Evo Conversion tracks on my end, all I notice so far is both Treasure Bay having that flickering transparent wooden bridge when crossing over water, and that first bridge in Tibet Cliffside, when once you drive under, some weird kangaroo jump effect happens to the trucks once you pass underneath it, whether or not this was always a bug prior to DX9/11?

[Fila]

Mal implemented some workarounds for AI trucks to be able to work on the evo conversions.

The visual course is in the adding features once I am done with the graphical updates.

[OG_RuDeE]

Finally got a chance to try the newest updates on my old a** Asus Q405UA laptop. Dx11, 1080p, and the game runs smooth! Only 20-30 fps, because the "gpu" is the bottleneck here (90+% gpu usage and teens cpu), but totally playable and enjoyable!

I found it interesting that lowering the resolution on this machine increased the fps (only slightly!), but also increased the cpu usage and decreased gpu usage, which made it feel less smooth. So, it seems that being in a situation where the gpu is the bottleneck is optimal for the game in our current situation. Still, very cool that it runs and looks great on this trash laptop (minus the trash, dark screen)!

[Fila]

It's probably because the CPU still calculates the physics. And if it goes below 25fps (which the CPU calculates at), it actually has to stop and wait for the video card. So if you lowered the resolution to give it a little more fps, it also makes the CPU work more to calculate the physics.

The max the cpu works at is 25fps (and past that it's the magic of video renderer doing the frames interpolation to give the user the smooth feel). But if the fps goes below 25fps, the physics also go below and less work for the CPU.

[OG_RuDeE]

I'm just not sure that matches my experience. I find that changing the resolution can have quite a big, unexpected effect on performance. Examples, all Dx11:

On the laptop, it runs a smooth 20-30 fps at 1080p, but lowering the resolution does not increase the smoothness. The gpu is used less and I get slightly higher fps, yes, but the game feels less smooth, I think because the cpu is now doing more work and slowing instructions down.

On the 5600 xt, where the gpu is nowhere near its capacity, I still only manage to get ~60fps at 1080p. According to what you're saying above, I should get perfectly smooth gameplay, because I'm running over 25 fps, but it's just ok. Lowering the resolution does not offer significant improvement in smoothness. The one core the cpu is running on gets maxed out and can't send more instructions to the gpu, as far as I understand.

On the 6650 xt, the sweet spot is running at 1080p. I get a smooth 75 fps with gpu underutilized and cpu remains around 15% (less than 100% of the core it's running on). If I up the resolution to 1440p, it maxes out the cpu core, and I get over 60fps, but it's no longer smooth like 1080p.

I don't know why changing the resolution would affect the physics calculations going on on the cpu side, but it seems to.

Edit: Just to test the more gpu = better theory, I tried the 5600 xt at 1440p on Dx11 just now, and while fps were in the 30-50 range with 7 hd Cale trucks, the gameplay does "feel" smoother than even 1080p (I think quantitatively this means a tighter band between high and low avg. fps). On 5600 xt, gpu only ever got up to 50% utilization at 1440p. I'll have to test more on the 6650 xt tomorrow. Time to kick back.

[Fila]

Man, AMD just makes no sense

But on a more serious note, my original comment was specifically for the weak laptop. The other stuff you mentioned, there's a variety of issues affecting it. Without going too much into it, apparently I am able to decouple the game from the menus which means I can do optimization work before I move onto doing the menu work. The menus have got to go regardless for ease of maintenance and to actually be able to add new features but I will prioritize the optimization first. And this is good news for DX11 overall and for 1440 because the 2D overlay (the cp finder, the map, the speedometer and the lap info) was absolutely killing the FPS, which I then had to move it back to the CPU who in turn ends up going 100% usage when in 1440 (yes, that's what cranks up your CPU usage). So yeah, just those silly draws do a lot of damage due to the DX11 architecture (DX11 was not meant to handle the HUD the way it is handled in MTM2).

[OG_RuDeE]

Man, AMD just makes no sense

I know! Making me feel like I'm going crazy over here.

That's very curious / interesting about the menus, and nice to have a little peak at what's coming up next. Thanks for the info.

[Cale]

So a couple of things:

First, I've uploaded a Bigfoot (Shine Test) truck. This is the HD Bigfoot with the bed cover, KC lights, and full undercarriage all set to "normal" face type, which should give the new reflections effect the best look. Let me know what you think - this is easy but tedious so it could be a while before I do the rest of the fleet: mtm2.com/~trucks/T2026/bigfootshinetestbycale.zip

Second, I tried Castle Rock Too and...this happened. The bridge was actually floating up and down, which is weird. Drivable but visually bizarre.

Monster Truck Madness 2 7_14_2026 7_45_22 PM.png