Hey, had a thought -- everyone, is it worth me putting it on the TRX site

I would say , for those new to the scene having everything centralized would be very helpfull.

I didn't understand. The work is going on or not? 😕

No, it's only half finished and I don't think anyone is still working on it currently. That doesn't mean it won't be finished someday, though! 😀

Oh noooooooooooooooooooooooooooooooo!!! I could cry... this new has made me feel sad... sniff... 🙁

I stopped working on my UB triggers some months ago, because it's very time-consuming. That, and checking them again recently, I realized some of them were just not working properly in all conditions.

JC wrote:

I don't know how it happened but the current Audiopack is triggering the wrong track when Lara grabs the first piece of the Scion in Tomb of Qualopec. I have fixed this and have attached a replacement 'Locations' file that will correct it

Hmmm, forgot about this for ages. I've just sorted it out now (v1.5 of the Audio Pack is up).

Also I've noticed that, although v1.4 had been uploaded ages ago, the Glidos web site still had a link to v1.2, so a lot of people probably don't have the last few updates (a few cut scenes I think).

Where might I find v1.5 of the Audio Pack Paul?

The link on the main Glidos site has been updated to point to v1.5

Hmm, so it's ground to a halt. 3 years and less than half done? When all that's left is giving the trigger points?

It strikes me that you need to give up and start again. The method of setting up triggers (looking out for certain textures being drawn in certain positions) is far too difficult. I can see that it was easy to hook this minimal level of support into Glidos, but it's clearly not a viable system.

So, if we were to abandon that, what about a more obvious route - directly obtaining Lara's location from the engine?

I assume you can't just peek its memory when running natively (although this would be an option if using an emulator like DOSBox).

So, what about patching the binary to report player position. One thought is that it could be patched to regularly make an otherwise illegal/pointless call to some Glide API function containing useful information like room/level/X/Y/Z. That way you only need a pretty minor patch to the engine (a few dozen instructions, hopefully), and the bulk of the intelligence could remain in Glidos.

Is there a reason why it wasn't done like in the first place? The current trigger-defining method seems so complex that part of me thinks it must have been a last resort. I can see that it's desirable to avoid patching an executable, but this seems like a case where it's warranted.

I'm willing to attempt such a binary patch, unless there's some sort of arcane copy protection that's going to get in the way. I'd have to leave it to you lot to modify Glidos and finish off the triggers, but those triggers would be a lot easier.

I'm certainly not against the idea. I just don't have the time for any method that involves a lot of work. Make the Glidos side simple, and I could probably find time to do it.

Continuing the current method is certainly a possibility. If we'd managed just 10% or so then I could see your point, but it's almost half, and any method that can do half job can certainly do the whole job. Just need to find some people willing to put in the same amount of work we have already put in.

Okay, so maybe nearly 40% is done, but that's taken a long, long time. It appears to be tedious, boring intricate work, and error prone, looking at this thread. I wouldn't bet on it taking less than another couple of years. Whereas I reckon the tomb.exe binary can be hacked fairly rapidly, and that would allow each level to be done in only a few minutes, if we've already got the trigger points to hand in the form of savefiles.

I've started disassembling tombub.exe (as it's the only one I've got to hand - presumably tomb.exe will be very similar), and it doesn't appear to be obfuscated in any way. It shouldn't take me many hours of work to figure it out.

Here's my proposed approach.

1) Find the code that saves the game.
2) Use a savefile editor to find out where in the savefile the position is.
3) Find out where that information is coming from in the file writing routine; then we know where it's stored during play.
4) Find the central loop, maybe by tracking down a once-per-frame Glide call. Ideally, find the existing trigger code (where the music cue would have started - maybe a remnant is left in?)
5) Insert into that spot a Glide API call that somehow encodes the position information.

Now, maybe you could suggest a suitable Glide API call. It needs to be something that takes multiple parameters. But it also should be essentially harmless - a call that wouldn't do anything on an existing version of Glidos or any other Glide implementation. Perhaps it would just return immediately with a "bad reason code error". That way it won't cause a problem if a player has mismatched TR1 and Glidos versions.

So then I can make an upcall like

SomeGlideFunction(DuffParameter, Lara's X-pos, Lara's Y-pos, Lara's Z-pos, Level number, Room number)

every frame. Then, if "TR1 audio support" is enabled, Glidos can do whatever with the information it gets from those calls - something very similar to to the existing script code for the audio triggers, but now they'd be defined simply in terms of Lara's position.

For debugging purposes it would be useful if Glidos could continually output the values it's getting from the upcall.

There may be other things that need to be done, like a signal when entering the menu. If the audio support already deals with that, we can leave it as is, but another upcall could be hacked into the binary if necessary.

While your there, see if you can find where the 3D coordinates are clamped. If you could just write noops over those instructions you could greatly improve the look of the game at high resolutions.

You might see 3<<18 as a float being added to them.

Man, this stuff is getting way over my head, which is a good sign (considering my programming expertise). It would be great to see the sound cues completed. The sound was my main attraction to the original game, and I concur how hard it is to put the triggers in the game currently, though it's rewarding to see them there. It gave me a massive headache, though.

Having the music throughout the game will make it more interesting to compare this to the anniversary edition, since it will be able to be seen at its best, even better than the originial.

Hi slube. Hopefully when I complete my patch, you'll be able to finish off the triggers very quickly. Each trigger condition will be no more complex than:

level=2
x>=25
x<=30
y=52
z=10

I'm making good progress on my investigation of the TR1 binary. Although for the last few days I've gotten sidetracked into finding out why the FMV colors are funny on my Nvidia card (when running with dgVoodoo - Glidos has its own solution). The FMV player's rather complex, and a pretty large proportion of the total TR1 code...

My current feeling is that there's some error in TR1's handling of 16bpp VESA modes. The FMV player asks for mode 110h (640x480x32K) by preference, and if not available it goes for 111h (640x480x64K). My new 7600GT card doesn't do 110h; presumably earlier ones did. So now it's trying to render in 16bpp instead of 15bpp, and failing.

BTW - Glidos, would you care to expand more on the clamping you're talking about, to help me find it? What values are the coordinates clamped to? I'm not that familiar with 3D programming.

Interesting going through the code - it's odd what little clues you find to help figure out what memory locations are. One big one was the code for the cheats - the little state machine that looks for you going forward, backward, round three times and jumping. A rather obvious pattern, and once I spotted it, that immediately gave me lots of information about Lara movement, not to mention level numbering+completion, and ammo/weapons.

re VESA: have you tried using VDos32 with the software rendering version of TR. Be interesting if that gest the colours right on your system.

Re clamping: I'm not surewhat you should look for. Every screen coord passed to the draw polygon/triangle methods should be processed in some
way to clamp to the nearest pixel. 3dfx suggest adding then subtracting a large float (float)(3<<18)

Ah, gotcha. By clamping I assumed you to mean range-limiting, and I didn't really understand what that had to do with anything.

But the Glide APIs accept fractional coordinates, I see, and the game is rounding the coordinates to whole pixels. (Can't see anywhere in my Glide 2.2 docs that requires that, mind).

Adding and subtracting a large float would be a nifty trick, but it looks like they don't do it that way. In one routine I've found, where they're doing some calculations on a vertex list for GrDrawPolygonVertexList - towards the end of it they seem to do a cast to (int) and back.

Should be quite easy to knock that out for you.

Magic. The int cast might be good for running at 640x480, but when under Glidos and scaling up the resolution, it makes the texture corners pop around. You can see it especially in lara's face when she is turned towards you breathing. Knocking out the casts might be a big improvement.

Looked around a bit more, and I haven't found all the places it's doing it. The first lot I found was in the geometry clipping - rounding the newly-calculated screen edge intersection vertices to whole pixels. But I haven't found where it is in the main calculations yet. I'll keep looking at it.

Okay, Glidos, here's the bad news. TR1 doesn't use floating point coordinates. Remember, the Glide capability was a bolt on to an internal 3D software renderer. The 3D plot calls basically take the form:

1do_op(TrVertex *vertices)
2{
3   if (glide_enabled)
4        do_op_with_glide(vertices);
5   else
6   {
7       original code
8   }
9}
10...
11do_op_with_glide(TrVertex *vertices)
12{
13   GrVertex gv[];
14   transfer original vertex information to gv
15   clip_geometry_to_screen(gv);
16   GrDrawPolygonVertexList(gv);
17}

The original geometry passed around in TrVertex structures is in integer pixel coordinates. It would be very difficult to change that. The only easily removable rounding to whole pixels is in clip_geometry_to_screen, and that's not going to make much difference.

TR1 inherently operates at a 640x480 resolution. (And, playing TR2 at the moment, watching Lara's ponytail throb alarmingly, I suspect TR2 is the same).