ech; sorry to bother and for the new thread, but having read all the forums here at vogons and at xcomufo site didn't find anyone to solve it; the problem is with mouse under win2k in xcom apocalypse; it gets stuck in the upper left corner of the screen (when i launch the game it's in the middle then any move moves it to top left position); the box it's stuck to is ca 80x25 pixels; i tried numerous ways to fight it:
a) ps2 and serial mice (two different ones 😉 )
b) switching video cards (to give another driver a try to emulate vesa better)
c) mouseset and mousectl utilities (the adress an issue where a mouse is stuck in window 640x200 i think, both don't change anything)
d) setting mouse range via before the game in my own program (launched the xcom from it) via int33 functions 7 and 8 (or so, anyway didn't help anything)
e) changing deafult dimensions of console (from 80x25) to lauch the game
f) vdms (i don't know why it should help but tried 😉 )
g) tried to disasm the ufo2p.exe but was lost as it's encrypted?
help, help, help needed, any suggestions appreciated
Yeah, 80x25 definitely looks like NTVDM.EXE thinks that the game is in text-mode. Can you check, from your TSR, if it's called? Your INT33 handler may be replaced by Windows when the game switches in p-mode, I really wouldn't know exactly.
well, thanks for suggestion, i learned something; btw: your (vladr's 😉 ) mouseset was an invaluable help; the first program you asked about which set the range for cursor wasn't even resident (i execl-ed the xcomapoc.exe from it), it just did set the range and launched xcom; now i know how naive it was; so, here's the log of int 33h executions i managed to get (yes, it's from "heavily" modified mouseset 😉 ) (it only looks big and messy) :
well, with proportional font it looks better...[note from Snover: fixed 😀]
this log never changes (all executions brought me the same)
you probably know it better than me but ax==7 is the func for setting horiz range and ax==8 is for vertical, ax==4 sets the pointer position (it works even though it's out of bounds, i think), and ax==0 resets the mouse...
now i'm smarter than before but still know nothing; i tried to set the range for cursor every time a cursor was moved or on all except the first reset and it all just didn't help; what i can think of now is that the range for mouse is set later during a func/int which sets the video mode; it's quite tempting 'cos would explain why the cursor first is in the middle of screen (it was correct when the range was set but invalidated later during setting video) and it jumps to the horrible 80x25 range when any mouse action is taken; well, please suggest anything more - i'll try to intercept int 10 or whatever is responsible for vesa video but i'm really not sure...
help, help, help needed;
and thanks for last clue and a great mouseset (w/source) i'm finally not afraid of int handlers in bc31 😉
Hmm if this looks like it sets a resolution of 5120X2048, then use set position to the mouse in the middle somewhat.
Normally mouse drivers take over the int10 handler and then get max ranges again on a videomode set. It just shouldn't do that on the setting of vesa modes, but the crappy win2k ones seems to do.
Would set the res back to 640x200 looking like 80x25 box since the game expect such a high resolution 😀
Might have to make a special int10 and int33, the int33 handler storing the last set resolution and mickey ratio. The int10 handler putting those values back into the real int33 handler after a modeset.
yes, perheaps it's a little strange, cos' if it was a text mode then it'd be set correctly (in text both dimensions are multiplied by 8, so this one would be 640x480); of course the sad part is that it's graph mode; bt even worse: the set pos works correctly but it shouldn't; well, it was quite late yesterday, so it's very good that someone that still can think clearly makes me know the basic conclusions coming from that log 😉 thanks, i'll check it
well, sorry to spam the forum again with some ridiculous log but it's what i got when logged ints 10h and 33h; xcom does perfectly (imo) what it should; but i doesn't work; the ranges are set AFTER setting the vid mode; i tried to set 640x480 (and some other vals) without 8 multiplier in the boundary values for mouse in int 33h but it seemed to have NO effect; no matter if i set 10 or 640 or 640x8 or whatever - the mouse was always stuck inside the same 80x25 box; this time I really NEED HELP; any clues, suggestions?
ps.: the last int 10 is for setting back the text mode - i tried to disable it (just in case - it was the dreaded 80x25 res so it better was killed) but it didn't change anything
Well the problem has to be that the win2k mouse driver doesn't call the callback with the correct values. Might want to try and setup your own one, setup the ranges and then see what values you get from win2k.
If the error is there, you should takeover int33 and place your own handler and when the game tries to set his handler you'll call that one. Then have to keep track of resolution yourself and the mickie/ratio. Although i think the win2k mouse handler has correct support mickey/ratio.
that seems sensible and i'm trying to implement it; i intercept int33 function for setting a handler and set my own one which mangles the coordinates the way i want and then passes the execution to the handler defined by the game; the new problem is that it crashes(i get something similar in shape to dos4gw exception msg, i don't see much though in graph mode) probably because xcom is in protected mode (dos4gw) and my function is in ordinary >1M memory (the way i see memory in borland c for dos); i'm trying to figure it out but i don't have much exp in dealing with low level prot mode; please explain a little (at least url, please) how can it be done
well, thanks for all the help, it's finally (or partially 😉 ) solved; in general it works so i can play now (and so i will 😉 ) the only problem that remains is that when you move your mouse the game loses the track of time and speeds up a little (how much probably depends on system); in xcom it's not a problem as there is pause... anyway, big thanks for help; the files are attached but please remember that it's alway better to recompile it from source to be sure it's free of virii (borland c 3.1 for dos)
😎 xcom works... i'm not going to university tomorrow... 😎
peter, there isn't really a way for virii to infect files here unless someone manages to get the SQL password and inserts into the database a new file. 😀
You could always just make an MD5sum of it, anyway...😀
Good job on this fix. If someone with expertise on the VOGONS team would like to look over it and write a short write-up that would be fab.
😜 i was thinking about those "end-users" and infecting possibly system where they'll execute this exe 'cos i can't guarantee that i'm virii-free; but i'm sure you understood me (you don't think i'm that silly, do you? 😉 ) nevermind (and the zip checksum is sufficient, i think 😉 ) i've just finished xcom: apoc with this patch - the timer problems mentioned before were solved by vdms (vdms rules 😉 )
Last edited by peter on 2003-01-09, 02:21. Edited 1 time in total.
Mouse2KV also works for System Shock, which MOUSESET did NOT work for.
It would be nice if it could detect the screen resolution and adjust accordingly, since for games where menus are at 320x240 and the actual game is at 640x480, it makes it really hard to do stuff in the menu. 😀
