Quality of input + graphics under linux
Author
Hello Linux game programmers,
I wonder about porting a simple 2d engine from windows to linux.
I''ve got some questions:
1. Can I get keypresses and releases from any key under linux ?
I mean not only getting a char but getting a ''key 23 is pressed down/released'' message ?
How easy is it to access every gamepad/joystick, what about USB joystick drivers ? Are more than 2 joystick supported, and is every button/key avaiable ?
2. How much slower is the gfx ? I think this shouldn''t be a matter in 2d but it would be great to know possible problems. Are there any things I should avoid ?
3. Are there ide''s like MS Visual Studio ? Or do I have to use emacs, vi, etc. ? If there are some which would you recommend ?
As you see I don''t know too much about Linux, I''m just starting to get comfortable.
Here are some partial answers. I hope some more come along.
1. Yes, you can. The question is how you do it. I personally use SDL, which works nicely and works under Windows, MacOSX (and older versions unofficially), Linux, FreeBSD, and possibly other platforms... I''m sure you can get keypresses directly from X, though i''m not the one to axe about that.
2. In general, not much slower, though it depends on any number of things, including the quality of the driver on the video card, program threading, god knows what else.
3. Hmm... Well, there''s Code Warrior for Linux, though i haven''t heard much good about that version. I don''t really know, because i personally use vim, ddd, make, and all that stuff.
-ben.c
1. Yes, you can. The question is how you do it. I personally use SDL, which works nicely and works under Windows, MacOSX (and older versions unofficially), Linux, FreeBSD, and possibly other platforms... I''m sure you can get keypresses directly from X, though i''m not the one to axe about that.
2. In general, not much slower, though it depends on any number of things, including the quality of the driver on the video card, program threading, god knows what else.
3. Hmm... Well, there''s Code Warrior for Linux, though i haven''t heard much good about that version. I don''t really know, because i personally use vim, ddd, make, and all that stuff.
-ben.c
2/ for 3d it depends very much on the card nvidia cards are not much slower and in some cases a bit quicker but for other cards performance is generally about 50-80% of windows.
3/ for the kde environment ive used www.kdevelop.org which is quite good
http://members.xoom.com/myBollux
3/ for the kde environment ive used www.kdevelop.org which is quite good
http://members.xoom.com/myBollux
As far as I know, 3Dfx Glide is faster in Linux than in Windows...
- JQ
Infiltration: Losing Ground
"You just don''t understand. Guys have to be immature and stupid. It''s some biological thing. It helps us hunt and gather and stuff." -Nazrix
- JQ
Infiltration: Losing Ground
"You just don''t understand. Guys have to be immature and stupid. It''s some biological thing. It helps us hunt and gather and stuff." -Nazrix
Hi,
1) You can get scancodes for mouse,keyboard and joystick in linux using SDL, svgalib etc
2) Opengl, 3dfx are more dependent on your card.
3) Try kdevelop for an IDE.
Regarding MFC - there are no MFC stuffs in Linux. Something similar - try fluid. Comes with fltk.
1) You can get scancodes for mouse,keyboard and joystick in linux using SDL, svgalib etc
2) Opengl, 3dfx are more dependent on your card.
3) Try kdevelop for an IDE.
Regarding MFC - there are no MFC stuffs in Linux. Something similar - try fluid. Comes with fltk.
Actually, Qt more or less fills an MFC-like role. If you''re using KDE (which I highly recommen), you''re going to use the KDE classes which are based on Qt. They aren''t exactly MFC-alike, but they have the same role.
BTW, Qt OOP is very clever (it needs an additional MOC-compiler though - don''t worry, everything''s C++), and beats MFC any time.
cu,
Prefect
---
Sanity is the trademark of a weak mind.
BTW, Qt OOP is very clever (it needs an additional MOC-compiler though - don''t worry, everything''s C++), and beats MFC any time.
cu,
Prefect
---
Sanity is the trademark of a weak mind.
I wouldn''t rely on the existence of KDE (or just Qt) on the system when writing games, if it can be avoided. I don''t really suggest it with many applications, but games less so. The Linux gaming audience is small enough as is, no need to cut it another 60% (or whatever).
Don''t worry though, i feel the same way about GNOME.
-ben.c
Don''t worry though, i feel the same way about GNOME.
-ben.c
Answers to 1:
To get keypresses or keyreleases (aka key board events)
it depends on what kind of application you are writing.
You have three choices; Xlib, ETI, or raw terminal.
I''m going to assume Xlib, since that is more graphical
based and most Linux games use that. In which case you will
need to look at ''man XNextEvent'' to fetch the next event
(also look at `man XPending'' to check if there is a next event
instead of blocking. Then you need to handle that event,
in which case you need to check if its type. For example
XEvent event;
if(event.type == KeyPress)
Look at `man XEvent'' and `man XKeyEvent'' for details on
this structure.
Next you will need to tie in the `keycode'' that you get
from the above structure with a `keysym'' the keysym
name is fetched with first converting the keycode
to keysym using XLookupKeysym() then once you
have the keysym, use XKeysymToString() to convert it to
a string.
Now you need a list of string names to relate to ASCII
characters. For example you can compare the string returned
by XKeysymToString() to "greater" which would be the ''<''
character.
Look in the keysym header files in /usr/include/X11/
for a table. Note that the names returned by XKeysymToString()
are basically those of the #defined values without
the prefix.
To get keypresses or keyreleases (aka key board events)
it depends on what kind of application you are writing.
You have three choices; Xlib, ETI, or raw terminal.
I''m going to assume Xlib, since that is more graphical
based and most Linux games use that. In which case you will
need to look at ''man XNextEvent'' to fetch the next event
(also look at `man XPending'' to check if there is a next event
instead of blocking. Then you need to handle that event,
in which case you need to check if its type. For example
XEvent event;
if(event.type == KeyPress)
Look at `man XEvent'' and `man XKeyEvent'' for details on
this structure.
Next you will need to tie in the `keycode'' that you get
from the above structure with a `keysym'' the keysym
name is fetched with first converting the keycode
to keysym using XLookupKeysym() then once you
have the keysym, use XKeysymToString() to convert it to
a string.
Now you need a list of string names to relate to ASCII
characters. For example you can compare the string returned
by XKeysymToString() to "greater" which would be the ''<''
character.
Look in the keysym header files in /usr/include/X11/
for a table. Note that the names returned by XKeysymToString()
are basically those of the #defined values without
the prefix.
Answer to 1, part 2
Linux supports most analog/digital joysticks
(version 2.2.15 or newer), newer
versions of Linux may support USB joysticks.
In any case, Linux has a wrapper for Joystick
device in the form of event IO (similar to Xlib).
You will need to use libjsw for this, see
http://wolfpack.twu.net/libjsw
`man JSIntro'' to see the tutorial about its API.
Linux supports most analog/digital joysticks
(version 2.2.15 or newer), newer
versions of Linux may support USB joysticks.
In any case, Linux has a wrapper for Joystick
device in the form of event IO (similar to Xlib).
You will need to use libjsw for this, see
http://wolfpack.twu.net/libjsw
`man JSIntro'' to see the tutorial about its API.
Answer to 2.
When you reffer to gfx, is that a typo reffering
to glx? or do you mean `graphics''?
Graphics under Linux/X is a tad slower compared to
Windows (in my experiance) however the slowness is at most,
df 0.00001 fps differance so its minimal.
Linux is always sync''ed processing (unless you use threading) however Windows'' glw is threaded by default.
glx is basically a wrapper just like glw, however in my
porting experiances with two apps on the same comptuer,
the Windows version runs much faster in graphics generation
and initialization however in normal runtime performance
is roughly the same.
When you reffer to gfx, is that a typo reffering
to glx? or do you mean `graphics''?
Graphics under Linux/X is a tad slower compared to
Windows (in my experiance) however the slowness is at most,
df 0.00001 fps differance so its minimal.
Linux is always sync''ed processing (unless you use threading) however Windows'' glw is threaded by default.
glx is basically a wrapper just like glw, however in my
porting experiances with two apps on the same comptuer,
the Windows version runs much faster in graphics generation
and initialization however in normal runtime performance
is roughly the same.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
