Lost World Missing Pointer

[HarryTuttle]

Last ramblings for today.

From SuperDebugger it seems that the select stage scene contains in fact the two pointers (red + green squares). For some reason they're not displayed. Also the round shape could be just due to the application of a texture.

I think that for the same reason in the (in)famous night stage with the T-Rex chasing you, the torch effect could be a giant black poly superimposed to the scene with a "hole" texture (where alpha = 0). Moving the cursor to the bottom the poly gets squashed, hence the torch shape becoming more ellipsoidal. The rest of the scene is just rendered fine.

Too bad I can't load on the SuperDebugger the relative savestate floating around this forum to confirm this.

Also I don't think spotlight is used there since most of its parameters are set to 0.

In this picture the two pointers overlaps:

debug01.jpeg (246.38 KiB) Viewed 11641 times

[Ian]

I am pretty sure those polygons are just junk. Firstly they are co-planar, it's impossible to draw them without z fighting with depth testing enabled. Secondly the matrix for them never updates ..

If you multiply their model matrices by say 0,0,0,1 and see where they end up, their position never changes.

It's possible the pointers are drawn in the 2d layers and we are not displaying them somehow. Really need someone that can dig into the assembly and trace from where it reads the inputs to where it draws in that particular scene, to find out what should be happening.

[HarryTuttle]

My theory was that we're somehow missing a link between the registered gun aim position and those poly, so their matrices don't updates. I should check what also happens during the aim calibration screen and see if the players' square poly "cursors" are on the same plane.

[Ian]

Have a look at the rom addresses used in the test menu for the laser pointers. If they are the same as 8d836a then maybe there is a link :p

[HarryTuttle]

I've just loaded Superdebugger, I'll check that.

One last thing: if you see the snapshots, I've selected those polys at culling node level, that way they're re-positioned and aligned to an origin that's not that of the root node (the scene). That could be the reason of having them co-planar; I've just checked the gun calibration screen and they're again overlapped if selected alone.

[HarryTuttle]

Have a look at the rom addresses used in the test menu for the laser pointers. If they are the same as 8d836a then maybe there is a link :p

Yes it's the same address

[Ian]

This is where it's used ..



In the test menu. That rom model draws the horizontal and vertical line

[HarryTuttle]

I see...

I was mislead by the initial square-like shape of those polygons, after transformation they become lines.

[Ian]

I had a look at this bug again the other evening.

There is also this

https://www.youtube.com/watch?v=F38OnpIHGaU&t=25m24s

For some reason in supermodel the real3d headlight is never updated. I am 90% sure it is the real3d headlight and not some other post processing effect, because it only seems to effect the 3d layer. Also if you set the video to 60fps and slow it down you can see the head light swapping position every frame. This also makes me think it's the real3d headlight because the headlight effect can only produce 1 light per viewport.

I think the too lazy didn't read version is. We can't find the laser pointer because it's simply never updated in memory, the same as the real3d headlight. Both of these bugs must be the same bug because they are both tied to the input of the controller. For some reason the game never updates the memory in these scenes.

[Bart]

If you suspect this has something to do with how the gun data is read, I would try to find that code and poke around. See if it's reading some other register in the control area as well. Might it also be the case that there is an unemulated (or improperly timed) IRQ? The game just polls the input device but maybe it also uses uses one of the IRQ handlers to do something. A starting point would be to disassemble the IRQ vector (address 0x500, IIRC) and then find the bit of code that dispatches to each of the different IRQ handlers (one for each bit in the IRQ pending register). Does it look different than other games? Most Step 1.x games do the following:

1. Check for SCSI interrupt (there is no bit in the IRQ controller for this; the SCSI registers have to be checked).
2. Check each bit in the IRQ register.

IRQ 0x2 is usually handled as well as the sound IRQ. The other ones are usually stub handlers that do nothing, although some of them will record a time stamp value of when the IRQ was triggered.