57 replies to this topic

[all for dnd]

Hi ghostdog, I noticed this mouse scrolling problem when playing the game, it's not a big deal but sometimes do be quite annoying. Is there any way to fix it? Thank you.

[ghostdog]

What is exactly the problem? Does the mouse lags while you scroll it? Is the movement a bit choppy when you scroll with the mouse to change the view of the area? If that is the case, I don't think the UI has something to do with it, it's more likely the fact that when you change the resolution to a much bigger one there may be framerate problems if you don't have a very fast computer, or maybe it's because of the engine's optimization for a small resolution, I don't really know. ( Of course I assume you've tried adjusting the in-game option for mouse-scrolling speed )

Anyway, there is a framerate setting in the Torment.ini that might help you. Go to the game folder folder open the torment.ini with a text editor and find the "Maximum Frame Rate" , fiddle a bit with it and see if it helps you. I currently have changed the value to 38.

[taplonaplo]

outside the old area the camera scrolls diagonally instead of straight (as u can see it on the image) when moving the mouse straight

[ghostdog]

I believe that in this particular screenshot it's impossible to go any further up since it's the end of the dangerous angles area map.

[Qwinn]

ghostdog:

What Tap said is true. In my 1280x768 game, the cursor goes diagonal up and to the right at about halfway across the screen, same as in that picture. Whether or not you've already gone as far as you can go doesn't really make a difference, the shape of the cursor tells you which direction you would go in if there -were- further you could go.

Qwinn

[all for dnd]

What is exactly the problem? Does the mouse lags while you scroll it? Is the movement a bit choppy when you scroll with the mouse to change the view of the area? If that is the case, I don't think the UI has something to do with it, it's more likely the fact that when you change the resolution to a much bigger one there may be framerate problems if you don't have a very fast computer, or maybe it's because of the engine's optimization for a small resolution, I don't really know. ( Of course I assume you've tried adjusting the in-game option for mouse-scrolling speed )

Anyway, there is a framerate setting in the Torment.ini that might help you. Go to the game folder folder open the torment.ini with a text editor and find the "Maximum Frame Rate" , fiddle a bit with it and see if it helps you. I currently have changed the value to 38.

This is one of the problem - though not what I meant for. It's not because our computers are not fast enough, and of course has nothing to do with your UI, but because they are too new for this old game. Actually I have a solution. You can go right click on the desktop ==> Properties ==> Settings ==> Troubleshoot, and drag the slide to where the DirectDraw and Direct3D acceleration are disabled. Alternatively, you can run "dxdiag" and disable DirectDraw Acceleration under tag "Display". Doing it this way will cause another problem which prints the cursor's trails on static backgrounds, but will also make the game run much smoother even under a "Maximum Frame Rate" of 60.

And the problem I meant in the picture, I apologize for not making it clear, just like what taplonaplo and Qwinn said, the screen scrolls diagonally when the cursor is outside the original screen area staring from the top left corner.

Here's another screenshot,

Edited by all for dnd, 10 December 2008 - 01:37 AM.

[ghostdog]

Yes, it seems that outside the original area the cursor points diagonal, the funny thing is I hadn't really noticed it up to now. This is probably affected by an offset somewhere in the torment.exe but as to where it is... I can't give you a solution right now, but I'll have it in mind. Maybe scient will come across this in one of his .exe hunts. Anyway, thanks for the feedback.

[scient]

So what would be the desired behavior? I don't remember how the original game does it off hand. Like if cursor is on all four sides, move in a straight line. If it's in the corners, move diagonally? Does the cursor behavior get altered from either bigg's res mod or your WS mod? Lastly, do you know what bam or other files relate to cursor? I imagine I could use some of the rect api's to locate how it is moving the screen and go from there.

Edited by scient, 10 December 2008 - 05:24 PM.

[ghostdog]

So what would be the desired behavior? I don't remember how the original game does it off hand. Like if cursor is on all four sides, move in a straight line. If it's in the corners, move diagonally? Does the cursor behavior get altered from either bigg's res mod or your WS mod? Lastly, do you know what bam or other files relate to cursor? I imagine I could use some of the rect api's to locate how it is moving the screen and go from there.

No, my UI mod does not alter anything about the cursor and I don't think Bigg's mod does either. The cursor file seems to be WMCPNTR.BAM. The original behaviour of the cursor is that it turns to a diagonal position about 30 pixels from each corner as seen in the pic:



Thanks for the help scient

[scient]

Ok, the main problem for me is that I cannot get the arrows in windowed mode. Trying to debug the game full screen is Russian roulette. I've already had it lock up so I couldn't get back to windows requiring hard reboot.

Anyone know how to run the game in windowed mode yet get arrows to show up? I couldn't get the test build of bigg's ws mod to install to see if that lets ya do it. Another cruder way is if anyone can give me a rough estimate +/- 5 of where it changes and I can do a scatter shot search.

[all for dnd]

Ok, the main problem for me is that I cannot get the arrows in windowed mode. Trying to debug the game full screen is Russian roulette. I've already had it lock up so I couldn't get back to windows requiring hard reboot.

Anyone know how to run the game in windowed mode yet get arrows to show up? I couldn't get the test build of bigg's ws mod to install to see if that lets ya do it. Another cruder way is if anyone can give me a rough estimate +/- 5 of where it changes and I can do a scatter shot search.

I made a few screenshots from the game, enlarge them in PS and did some raw counting. It may be 41+/-5 pixels from the corner. I'm pretty confidence about this result.

Edited by all for dnd, 11 December 2008 - 01:50 AM.

[taplonaplo]

from the ws mod forum, could be related:

The mouse bounding box in PST is at
0x432300 => 640
0x432307 => 480

4cd i believe
the arrows' .bam is cursarw, which is called at 0x1a0f80

[scient]

Ah ha! CURSARW is the one I wanted. You are correct that at the 4cd offset 0x1a0f80, the structure of CURSARW is setup however this happens only once on startup. I did locate the switch where it determines which direction the arrow should go in.

0: north
1: north-east
2: east
3: south-east
4: south
5: south-west
6: west
7: north-west

edit:
@all for dnd: you are correct with picture above, it does seem the box is offsetted 0-40. I'll have to do a bit more analysis but I've found the function which toggles which value to pass to the switch.

Edited by scient, 11 December 2008 - 07:18 PM.

[scient]

The value Z is set to location on whatever side cursor is on. This can be either x or y coordinate depending on if you're looking at top or bottom.

If cursor is on left/right side:

if(Z <= 40) -> north-west or north-east
else if(Z >= 439) -> south-west or south-east
else -> west or east

If cursor is on top/bottom side:
if(Z <= 40) -> north-west or south-west
else if(Z >= 599) -> north-east or south-east
else -> north or south


Can you give me an idea of what ranges you would need? That way I can determine whether or not I need to make room for more bytes. If you don't understand something let me know and I'll do my best to clarify.

edit:
Actually, after looking at how the original does it the problem is that the far side is too big and should follow (x - 41, y - 41). However, with larger resolutions it may be a good idea to make the lower bound corners a bit larger than 40? If you keep the lower end (40/40) under 127 then stuff doesn't have to be moved around to make room. The upper end (439/599) has enough space for up to 4294967295.

Edited by scient, 11 December 2008 - 07:59 PM.

[ghostdog]

Excellent job as always scient!
Let's keep this simple and leave the 41 range at each side. I would need the change for the resolutions 1280x800 , 1280x768 and 1280x1024. So if I understand correctly :
For x=1280 the cursor direction change will be at : 41 and 1240
For y=800 at 41 and 760
for y=768 at 41 and 728
for y=1024 at 41 and 984

[Qwinn]

I would suggest making it a mathematical formula, so that no matter what dimensions you plug in, you get roughly the same size corner in reality. That way you don't have to ever worry about it again when doing up new resolutions, and the boxes don't get smaller and smaller the bigger resolution you use.

40 out of 640 is roughly 1/16th of the screen. Vertically it's 40 out of 480, or 1/12th.

So... X and Y are your resolution. X1 is inside edge of left corners, X2 is inside edge of right corners, Y1 is bottom edge of top corners, Y2 is top edge of bottom corners.

X1 = X / 16
X2 = X - (X / 16)
Y1 = Y / 12
Y2 = Y - (Y / 12)

Still pretty simple, the corners stay consistently sized as a percentage of the viewable screen, and if you ever do more resolutions (or come up with a way to make it where it'll work for -any- resolution), you don't have to worry about it anymore.

Just a suggestion, of course Just saying you probably want to avoid hardcoding numbers based on specific resolutions in the engine anyway.

Qwinn

Edited by Qwinn, 12 December 2008 - 06:14 AM.

[scient]

Ya, a formula like the one above would be a good idea. At the moment, by that formula it will not require any additional bytes to fit in the new values for any of the res's. To make it follow the original exactly you'd have to subtract one from X2/Y2 like so.

X1 = X / 16
X2 = X - (X / 16) -1
Y1 = Y / 12
Y2 = Y - (Y / 12) - 1

Below are the search patterns you'll need to find twice (left/right, top/bottom) and in bold are the portions you'd want to change. Note that bold values for X2 and Y2 are in little endian order.

X1:
8B 55 08 83 3A 28

X2:
8B 45 08 81 38 57 02 00 00

Y1:
8B 55 08 83 7A 04 28

Y2:
8B 45 08 81 78 04 B7 01 00 00

Edited by scient, 12 December 2008 - 10:47 AM.

[ghostdog]

Qwinn, I suggested keeping the original 40 pixel margin because scient said that in that case he would not need to try and make room for more bytes. If it's easy for him to make the margin scale according to the resolution I have no problem of course I don't really know how exactly scient does this byte swapping but I have a feeling that it's probably best to avoid it if possible. Anyway, if the basic script is made I think it would not be very difficult to adjust it to check the current resolution and edit accordingly.

[scient]

Byte swapping would mean I'd have to optimize the code so nothing changes really just more stuff patched and more work. I just have to check something with Y1/2 offsets not keeping proper proportions. I may of just patched my version incorrectly.

edit: Nm, I was patching the wrong install dir, the 640x480 one so I can debug in windowed mode. My 1280x768 works perfectly!

Edited by scient, 12 December 2008 - 10:36 AM.

[ghostdog]

It works perfectly, thanks again !