MTM2.com

Is there any way to trace what triggers the error, perhaps even tracing back from the error message string itself?

Also, a question for future pondering. Are there any "hidden" face types that BinEdit doesn't know about? Pretty sure there is already a "glowing" / unshaded type used in the classic startline model. Also wondering if there's an additive blending type, i.e. as used to render headlight glows/beams.

The error doesn't give me much. It's a typical access violation window with zero information other than "Integer - Divide by Zero". According to the internetz, the error is supposed to be a default library error and what means is that at some point there's a mathematical equation that it's impossible. For example 1 / 2.

The visible tiles get defined on two axis, the X and the Z. So it always goes 10 and 10, 20 and 20, 30 and 30. I can only assume that at some point there's an equation that with a higher tile number results in an illegal divide but for the life of me I can't find it. Makes it even worse that the debugging branch doesn't seem to have this problem (despite using the same source files) so I got no clue what's going on.

I think there might be some hidden stuff. I've yet to look thoroughly through the code until I manage to get the more "simple" things working right

Hey I thought you weren't allowed to give out patches? Or is this just a "mod"?

It's a mod. Maybe I should have made a different thread, dedicated to mtm2 modding and keep this thread open mostly for jpez and me to talk about our experience with the source code.

I tested it with my high-poly high-box track "up & down town" and some stock tracks + dgvodoo and everything was fine. Now we need an updated Traxx to test those increased track objects limits.

Question: What's the difference, in this particular context, between a patch and a mod?

One is legal

I wonder if I can hack traxx with new limits (like gamer initially hacked mtm2).

Anyway, realistically updates won't happen for a while. I have started going through the official c++ books to learn the language better. All my knowledge was very basic from 10 years ago. I want to finally be able to port the code to visual studio 2015 for easier debugging and just overall easier time to work on it (instead of having to use the virtual machine). By doing this it will just make it a lot easier to actually start working on the actual code and see if I can make the wildest dreams come true

Also my goal (among many others) is to try and port the game to DirectX 9. I can't do that with Win 98

If you're successful in porting to DX9, that also opens up the option to add support for Xbox 360 controllers, which have six axes, ten buttons, and built-in high and low frequency force feedback. The Xinput API is unbelievably easy to set up, and I can hook you up with some example source code if you're interested.

Doesn't the game make use of DirectDraw? That would be a royal pain to convert.

BTW, what the heck does flicker reduction in the menu actually do? My old machine used to flicker a lot and the flicker reduction did help slightly. But it always made me wonder why have that option at all and why was it flickering at all? I am curious what that option is actually doing to remove flickering.

Managed to get the source code to compile with visual studio 6.

Baby steps. \o/

Yes it does use directdraw... which is also partly the reason of why it has issues with modern systems.

I don't know. Visually I can't see any difference with flicker on or off. I'll search the code to see if there's anything.

Perhaps flicker reduction is something akin to vertical sync.

It most likely is, as it's referred to "SyncRetrace" in monster.ini.

as far as I remember, "flicker reduction" never limited the FPS, and that's basically what vsync is.

Another baby step. Managed to get the game to compile in VS6 under Win 7 \o/

Well my old system always sat at 20fps to 45fps. And my monitor was usually at 85hz so vsync wouldn't have been happening.

The flickering looked a lot like how games look when you only draw to the displayed buffer instead of flipping.
I wonder if maybe the flickering was something about DX not being able to make a backbuffer completely or flipping before it was fully drawn. The old system only had 4mb of VRAM.

Suggestion for mod.

Can you remove the 99 pod limit?

And possibly make it read more than the first 8 letters of a sit file name to be the tracks ID?

Just wanted to remind people that this isn't dead or anything. I'm just going through the extensive C++ book to learn what the heck I'm doing. I'm currently at page 220 out of 1000 pages and it's definitely helping me as I am slowly starting to make sense of the mtm2 code.

But I've also gotten extremely busy lately so in all likelihood it's going to be another month or 2 until I'm done with the book so I don't expect any updates, regarding the game, until January (at least not from my end, don't know how Jpez' time is looking). But I'm still dedicated to improving this

Sounds good, glad things are still in the works. Definitely understanding the real life events thing. Same thing here (which is why I haven't finished the truck I was making).