Release Jedi Knight 3: Jedi Academy


If there is no /dev/dsp, well, use openAL if you have it? Not sure on how to help here. There is a cvar variable for that (and by default, it start without OpenAL on the Pandora).
Got sounds working. Not tested how much it affects speed.

There was one more openAL-hack left for you to revert:


code/client/snd_dma.cpp

@@ -495,7 +497,7 @@ void S_Init( void ) {
        s_UseOpenAL = !!(cv->integer);

        #ifdef LINUX
-       s_UseOpenAL = true;
+//     s_UseOpenAL = true;
        #endif

It should check ifdef OPENAL

About the mouse. Mouse is Grabbed in this game. But there is cvar to not grab it, you can probably try that.
I compiled code for desktop Ubuntu and mouse behaves exactly as expected. On N900 (which is compiled with DPANDORA) cursor is moved in very hard way. Do you understand what I'm talking about? (It is not even about relative/absolute in context of drawing tablets or touchpads). I checked whole diff, but still didn't find place.

About your config, I see your multisampling, maybe that will be a lot to handle by the SGX chip, it should work even without the twe EGL_SAMPLES lines.
I found reason for bad config. This is enough to get it running (I don't know why):


        const EGLint attribs[] = {
-               EGL_RED_SIZE, 5,
-               EGL_GREEN_SIZE, 6,
-               EGL_BLUE_SIZE, 5,
                EGL_ALPHA_SIZE, 0,
                EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT,
                EGL_SURFACE_TYPE, EGL_WINDOW_BIT|EGL_PBUFFER_BIT,

The lost of keyboard focus is strange. Probably something fishy in the same place where the EGL context is created, in the X11 Windows, but that's strange.
This is still issue. Seems to me to it has all needed keyboard masks.
 
About mouse & keyboard, look at install_grabs inside linux_glimp.cpp and see if forcing/disabling dga_mouse helps. Try fullscreen/non-fullscreen code also.

Did you had some problem like that with a software before on N900 or is it the first time?
 
Keyboard (resolved):

inside install_grabs


if (vidmode_fullscreen)
was false (even game is fullscreen) and it didn't grab keyboard. With if(qtrue) keyboard works.

----

Mouse:I'm still not sure do you understand what I'm talking about.


I think this mouse thing is not bug, but feature. But in Maemo case it is mis-feature. I watched video on post #8 and there cursor (on menus) is moved solely with nubs, and not by touching the screen. As N900 doesn't have nubs I'm trying to move cursor with touchscreen (what I previously called mouse).


I expected it work as absolute pointing device. I.e. where ever I touch the screen, cursor jumps there and makes button click (this is the very default way how touch screen works).


Instead (this is what are happening now): let say center of the screen is origo (0,0) and positive axes are up and right.
Touching screen on
 50,0 -> cursor moves slowly to the right
 200,0 -> cursor moves fast right
 -50,0 -> cursor moves slowly left
 -200,0 -> cursor moves fast left
 0,50 -> cursor moves slowly up
 0,200 -> cursor moves fast up
 0,-50 -> cursor moves slowly down
 0,-200 -> cursor moves fast down
 50,50 -> cursor move slowly up and right
 ...
 0,0 (with some threshold): produces mouse click

In game this might be good, but for menu it is too hard (because there are no any visual hint where origo is).

Menus can be partially used with keyboard only, e.g. game can be loaded, but setup needs mouse.

I haven't seen this kind of cursor movement before.

I tested with external USB-mouse and it moves mouse cursor normally.
 
Keyboard (resolved):

inside install_grabs


if (vidmode_fullscreen)
was false (even game is fullscreen) and it didn't grab keyboard. With if(qtrue) keyboard works.

----

Mouse:I'm still not sure do you understand what I'm talking about.

I think this mouse thing is not bug, but feature. But in Maemo case it is mis-feature. I watched video on post #8 and there cursor (on menus) is moved solely with nubs, and not by touching the screen. As N900 doesn't have nubs I'm trying to move cursor with touchscreen (what I previously called mouse).

I expected it work as absolute pointing device. I.e. where ever I touch the screen, cursor jumps there and makes button click (this is the very default way how touch screen works).

Instead (this is what are happening now): let say center of the screen is origo (0,0) and positive axes are up and right.


Touching screen on


 50,0 -> cursor moves slowly to the right


 200,0 -> cursor moves fast right


 -50,0 -> cursor moves slowly left


 -200,0 -> cursor moves fast left


 0,50 -> cursor moves slowly up


 0,200 -> cursor moves fast up


 0,-50 -> cursor moves slowly down


 0,-200 -> cursor moves fast down


 50,50 -> cursor move slowly up and right


 ...


 0,0 (with some threshold): produces mouse click

In game this might be good, but for menu it is too hard (because there are no any visual hint where origo is).

Menus can be partially used with keyboard only, e.g. game can be loaded, but setup needs mouse.

I haven't seen this kind of cursor movement before.

I tested with external USB-mouse and it moves mouse cursor normally.
Ok, yes, I understand now.

Indeed, it's not useable with touch screen as-is.I haven't looked at how make it absolute and not relative. It could be quite difficult yes.
 
Ok, yes, I understand now.

Indeed, it's not useable with touch screen as-is.I haven't looked at how make it absolute and not relative. It could be quite difficult yes.
If I use any other application on n900, touch screen is behaving exactly same as external usb-mouse. I can even claim that applications do not even know if they are used with mouse or touch screen. So somewhere in jedi academy code is something to detect it. Any hints where?
 
Ok, yes, I understand now.

Indeed, it's not useable with touch screen as-is.I haven't looked at how make it absolute and not relative. It could be quite difficult yes.
If I use any other application on n900, touch screen is behaving exactly same as external usb-mouse. I can even claim that applications do not even know if they are used with mouse or touch screen. So somewhere in jedi academy code is something to detect it. Any hints where?
IIRC, when the mouse is Grabbed, it is in "relative mode", and when not-grabbed, it's in absolute mode. But I'm not sure that's even enough.

For example, if you look in client/cl_input.cpp, you'll see that CL_MouseEvent and UI_MouseEvent is expecting delta movement, and not absolute movement.

I guess you'll have to modify CL_MouseMouse (of the same file) to completely remove the mouse acceleration and so on and to just change that to an absolute mode. But I'm not really sure on what behavour you want for the touchscreen. I understand what you'll want for the GUI (but you can use keyboard for most of the GUI interaction), not sure it will work well in-game.

How is this working with ioquake3 (or any other FPS ported on the N900)?
 
IIRC, when the mouse is Grabbed, it is in "relative mode", and when not-grabbed, it's in absolute mode. But I'm not sure that's even enough.
Grabbing mouse and no-grabbing mouse work exactly same.

For example, if you look in client/cl_input.cpp, you'll see that CL_MouseEvent and UI_MouseEvent is expecting delta movement, and not absolute movement.
I guess you'll have to modify CL_MouseMouse (of the same file) to completely remove the mouse acceleration and so on and to just change that to an absolute mode. But I'm not really sure on what behavour you want for the touchscreen. I understand what you'll want for the GUI (but you can use keyboard for most of the GUI interaction), not sure it will work well in-game.
I didn't yet complete recoding this part. One remark: there are ifdef AUTOAIM inside ifdef AUTOAIM. Outer starts on row 651 and inner on row 680. Thus it is not critical, I first read it that inner has else-branch.

I'm not yet sure how touchscreen should work during game, but on menus it must work as an absolute pointing device.

Settings can't be changed with keyboard only.

How is this working with ioquake3 (or any other FPS ported on the N900)?
I checked ioquake3 on N900, and it worked very silly. It is almost as using touchpad, i.e. swiping anywhere on the screen from left to right moves pointer to it's original position from left to right. But 'sometimes' clicking (=pressing screen with more pressure) warps pointer to the clicking point.
 
Yes, the AUTOAIM was a bit experimental, and made a few atempts before freezing the code. I left some useless code (I do that very often, and it's bad, I know),

So, on quake3, they basically left the relative mouse mecanism (with a slow acceleration), and a use a trigger thing (pressure=3rd button? right click?) to rapidly move the mouse ?
 
New build on the repo (both full game and demo). I recompiled every thing, and added the noshouldermb switch. And the powervr.ini trick also to have trully tearfree gameplay.

Enjoy :)

Build 05
-----------


  • Added "noshouldermb" support
  • Tear free glSwapBuffer
  • Fresh compile (faster?)
 
Last edited by a moderator:
powervr.ini trick
What powervr.ini trick ? :)
You put that file in the "current" folder, and the GLES driver read it to select another driver.

By default, the powervr.ini that is used is the one in /etc and use "libpvrPVR2D_FRONTWSEGL.so" driver: that the "only 1 buffer, Front only" driver that work for everything.

By changing that to libpvrPVR2D_FLIPWSEGL.so, you swith to FrameBuffer Flip method, with 2 Buffer, and the eglSwapBuffer just Swap Front & Back (no bliting involved). It's the prefered method, but not always working.


This trick has been discribed by Notaz (I think int the SGX beta driver thread).

In 2 words, the and fastest visual are obtain if you can do FrameBuffer acces (that is, create your EGL context with default display and NULL window) and use the FLIP method (by putting the right powervp.ini in the right place), and it's compatible with all drivers too.

(but some software don't like this, like Blender or TORCS).
 
So it can also be applied to all games using glshim I guess ?
Yep. Force framebuffer with LIBGL_FB=1 and put the powervp.ini at the right place (I have added a printf with the current folder on my version of libgl to ease that, because it's sometimes not trivial to know where the right place is).
 
New build, with the same added support for Hardware Gamma as in JK2.

Build 06
-----------

  • Added support for Hardware Gamma
  • Fresh build
 
Back
Top