|
FuhQuake
https://fuhquake.net
|
View previous topic :: View next topic |
Author |
Message |
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Thu Jan 15, 2004 8:02 am Post subject: |
|
|
fuh wrote: |
hr = IDirectInputDevice_SetDataFormat(g_pMouse, &c_dfDIMouse2);
c_dfDIMouse2 <---- that is what makes > 4 mouse buttons works. |
and that's exactly the reason why you need "dinput.lib" and that's also the reason why a dynamic loading of "dinput.dll" is senseless (already loaded, also without -dinput!).
c_dfDIMouse2 is defined as an external constant, that means it have to be imported at link from "dinput.lib"
For old mouse code there also exists a constant c_dfDIMouse; but this would also prevent the code from being independent from dinput.lib.
So the initial code author builds the structure "df" himself (was it you Fuh?)
And that's exactly what has to be done for support of more buttons; here are the necessary code parts:
Code: |
typedef struct MYDATA {
LONG lX; // X axis goes here
LONG lY; // Y axis goes here
LONG lZ; // Z axis goes here
BYTE bButtonA; // One button goes here
BYTE bButtonB; // Another button goes here
BYTE bButtonC; // Another button goes here
BYTE bButtonD; // Another button goes here
BYTE bButtonE; // Another button goes here
BYTE bButtonF; // Another button goes here
BYTE bButtonG; // Another button goes here
BYTE bButtonH; // Another button goes here
} MYDATA;
static DIOBJECTDATAFORMAT rgodf[] = {
{ &GUID_XAxis, FIELD_OFFSET(MYDATA, lX), DIDFT_AXIS | DIDFT_ANYINSTANCE, 0,},
{ &GUID_YAxis, FIELD_OFFSET(MYDATA, lY), DIDFT_AXIS | DIDFT_ANYINSTANCE, 0,},
{ &GUID_ZAxis, FIELD_OFFSET(MYDATA, lZ), 0x80000000 | DIDFT_AXIS | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonA), DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonB), DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonC), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonD), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonE), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonF), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonG), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,},
{ 0, FIELD_OFFSET(MYDATA, bButtonH), 0x80000000 | DIDFT_BUTTON | DIDFT_ANYINSTANCE, 0,}
};
#define NUM_OBJECTS (sizeof(rgodf) / sizeof(rgodf[0]))
static DIDATAFORMAT df = {
sizeof(DIDATAFORMAT), // this structure
sizeof(DIOBJECTDATAFORMAT), // size of object data format
DIDF_RELAXIS, // absolute axis coordinates
sizeof(MYDATA), // device data size
NUM_OBJECTS, // number of objects
rgodf // and here they are
};
.
.
.
// set the data format to "mouse format".
hr = IDirectInputDevice_SetDataFormat(g_pMouse, &df);
|
I did this changes to BorisU's code but I'm not sure, if the values of the MYDATA and the rgodf structure are correct. It seems to work with my IntelliMouse, but how knows...
I tried to debug and find out what's in the original c_dfDIMouse2 constant - but it's difficult to find what's in "rgodf".
At least debugging my results seems to be similar
With that piece of code it removes the static dependencies to the dinput.lib
The resulting executable is still able to start under NT4 but I have no idea if it really works (I could only test it on one of my company servers and this one has no mouse and I also don't want to break it with installing additional drivers )
So it's only a few test away from a new Massa FuhQuake release
|
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Mon Jan 19, 2004 5:09 am Post subject: |
|
|
A new version, based on official version v0.31 Build650, is available now.
the dinput-code which we discussed here is included - it enables the usage of the buttons 5-8 with MS mice.
BTW, midn: I tried to send you a beta version to test via email (mail error) and also asked you via forum's PM here - both keeps unanswered
So reports are welcome...
I also tried to find information at MS how to program the new horizontal wheel, but did not find anything.
midn, if there are some SDK programming information at your driver CD, inform me.
Another extension is the possibility to add an extra directory where textures will be searched.
If the new cvar gl_textures_dir has been set (e.g. to "simplequake"), the executable will first search in that directory structure for it's textures and only if it does not find the corresponding texture it will search through the normal mechanism (gamedir, fuhquake, qw, id1, ...)
With that you can easily switch between different texture sets without changing the gamedir (and also without a restart).
Really useful if you sometimes use Drugs-Bunny's simplistic textures but normally use the regular ones...
For detailled informations look at the history at the beginning of this thread and at the changes file included in the packages...
Enjoy! |
|
Back to top |
|
|
fuh
Almighty King
Joined: 07 Sep 2002
Posts: 2086
|
Posted: Mon Jan 19, 2004 5:21 pm Post subject: |
|
|
Hey Massa, you are right in that it is needless to LoadLibrary(dinput.dll) if linking to the stub.
However keep in mind that you can use GetProcAddress() to get pointers to variables too, it is not just for functions!
It is tricky however because i) the variable has to be exported by the dinput code and ii) The name you give GetProcAddress() to get the variable is not always the name of the variable! It can be different.
In this case I do not know what the name to give to GetProcAddress() to get c_dfDIMouse2 is , and I'm not sure if c_dfDIMouse2 is even exported.
However if you can work it out this would be the best solution.
It is better than reverse-engineering c_dfDIMouse2 (or whatever) because c_dfDIMouse2 might be different depending on the OS or installed version of dinput. All you know is that c_dfDIMouse2 is guaranteed by microsoft to work. |
|
Back to top |
|
|
BorisU
Joined: 08 Sep 2002
Posts: 128
Location: Moscow, Russia
|
Posted: Mon Jan 19, 2004 7:50 pm Post subject: |
|
|
AFAIK c_dfDIMouse2 is not a part of dll. It is a constant structure very similar if not identical to the structure from the Massa's source. My conclusions come after viewing the disassembly of the corresponding part of dinput.lib. |
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Mon Jan 19, 2004 11:09 pm Post subject: |
|
|
sorry massa
ill try ur release
tkz
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Tue Jan 20, 2004 4:38 am Post subject: |
|
|
fuh wrote: |
Hey Massa, you are right in that it is needless to LoadLibrary(dinput.dll) if linking to the stub.
However keep in mind that you can use GetProcAddress() to get pointers to variables too, it is not just for functions! |
I did not know this!
the SDK only talks about "functions"
fuh wrote: |
In this case I do not know what the name to give to GetProcAddress() to get c_dfDIMouse2 is , and I'm not sure if c_dfDIMouse2 is even exported. |
Hmm,
It's, like BorisU told, a constant; it is defined as external in "dinput.h" and can not be found elsewhere (I searched through the whole SDK sources without success).
So it's either directly inside of dinput.lib or it's inside the DLL.
fuh wrote: |
However if you can work it out this would be the best solution.
it is better than reverse-engineering c_dfDIMouse2 (or whatever) because c_dfDIMouse2 might be different depending on the OS or installed version of dinput. All you know is that c_dfDIMouse2 is guaranteed by microsoft to work. |
100% agreed - if possible
Hmm, the old code for c_dfDIMouse works the same way I did it for c_dfDIMouse2 - so if I'm able to get the constant dynamically it would also work with the old one...
... but on the other side, why should we need the old method any longer?
|
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Tue Jan 20, 2004 3:16 pm Post subject: |
|
|
great work massa
it works great, all 5 buttons working
but the bug i noticed is that when trying to take a SS with a bind the fuhquake crashes, and return do desktop with high gamma
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Tue Jan 20, 2004 3:20 pm Post subject: |
|
|
ah
and there's no SDK in intellipoint cd
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Tue Jan 20, 2004 5:17 pm Post subject: |
|
|
midn wrote: |
but the bug i noticed is that when trying to take a SS with a bind the fuhquake crashes, and return do desktop with high gamma |
Tell me more about that.
What keymapping do you use (if you use one) and tell me exactly what your bind is and when it crashes (when you switch to supershotgun or when you take it or when you try to use it or...) and in which map(s)!
midn wrote: |
and there's no SDK in intellipoint cd |
And that's bad - so I habe to wait until I find something at the MS pages about that "tilt wheel"
|
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Tue Jan 20, 2004 11:37 pm Post subject: |
|
|
bind kp_1 sshot
alias sshot "screenshot"
map 2fort5, i didnt test in any other
no keymapping
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Wed Jan 21, 2004 5:07 am Post subject: |
|
|
hmmmmm
all maps, same problem, chashing when trying to take a pic
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed Jan 21, 2004 6:07 am Post subject: |
|
|
midn wrote: |
bind kp_1 sshot
alias sshot "screenshot"
map 2fort5, i didnt test in any other
no keymapping |
I can reproduce it. It happens with the sofware and the GL version, it does not matter which map or keybinding
It seems, that there's something wrong with the screenshot code.
But
a) I did not change anything regarding the screenshot command.
b) the crash does not happen when I add debug informations - so it's really hard to find
Until then screenshots will not work with my version...
|
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Wed Jan 21, 2004 9:36 am Post subject: |
|
|
Another small update.
midn: the screenshot problem should be solved.
My gl_textures_dir functionality has some issues:
a) if a luma texture exists in one of the original directories or pakfiles it will be loaded even when the texture itself lays in the gl_textures_dir.
That means that it's best to have always lumas which match the textures.
b) it did not load from pakfiles
c) it did not load outside from the given textures dir (e.g. if "basedir/textures/map/name" does not exist but "basedir/textures/name")
b) and c) are now solved with new code.
To solve a) you have to put lumas besides your textures (that also means, that you have to generate faked lumas for the simplequake textures).
And there are a few small changes in the quakec code.
For detailed informations look at the top of this thread and at the changes file inside the zip files (which of course have been updated).
Enjoy! |
|
Back to top |
|
|
midn
Joined: 27 Sep 2003
Posts: 97
Location: Rio de Janeiro - Brasil
|
Posted: Wed Jan 21, 2004 10:58 am Post subject: |
|
|
yeah massa!
SS is working
tkz
_________________
E:\QUAKE\fuhquake-gl.exe -width 1280 -height 1024 -conwidth 512 -conheight 384 -mem 40 -bpp 32 +set cl_confirmquit 0 +set s_khz 44 -particles 512 -zone 8000 -dinput -m_smooth |
|
Back to top |
|
|
fuh
Almighty King
Joined: 07 Sep 2002
Posts: 2086
|
Posted: Wed Jan 21, 2004 5:51 pm Post subject: |
|
|
does this screenshot bug affect my stuff? |
|
Back to top |
|
|
Massa
Joined: 19 Sep 2002
Posts: 196
Location: Germany
|
Posted: Thu Jan 22, 2004 4:28 am Post subject: |
|
|
fuh wrote: |
does this screenshot bug affect my stuff? |
No - otherwise I would have told you
I accidentely changed a line of code which lead to a string copy outside the buffer limits...
|
|
Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|