Release KAMI RETRO - half price weekend


It looks to me like its a little late!  I seem to swipe earlier.  The last 2 definitely.  the first I would have thought should be close, will have to again myself.

Edit:  Nope, just did it again and didn't miss once, but checked closer and I can even have my path behind him slightly (even more than yours and he jumps).  Seems to me, there's definitely an issue as those same path seem to work fine for me.
 
Last edited by a moderator:
It looks like a bug to me.  I have no idea, why would this happen only on some Pandoras?

FWIW I had no trouble swiping (used my finger).  Someone needs to send Steven a KAMI-failing Pandora so he can debug this!  lol
 
Last edited by a moderator:
Finally I also got the time to try again. After watching the video by Steven I made it from Level 1 to Level 9 (before I was stuck at Level 5). Now I am stuck there, because I fail badly when the Kamis go from right to left ...

What made it better was not to try to swipe through the Kami (which is what ED is doing in his video), but to hit the Kami from below.

I think intuitively one tries to "drag" him up, but actually you have to "push" him up. So unless you hit his feet from below, nothing is going to happen. I started out with imagining the trail of the swipe to be a bridge the Kami will walk on. That was the only way to make me swipe early enough to hit him from below.

I still find it awfully hard and I usually miss most of them! If I make it through a level, it is with just one Kami, maybe 2 if I am lucky or the level does not involve too many jumps ... and as I said: when the Kami is coming from the right I miss 9 out of 10 times. So level 9 is a killer for me: it involves 2 jumps from right to left, and even if I manage to do them I am doomed to miss one of the other two jumps ...

If it worked the way ED is trying to play the game I'm sure I'd be able to do it. Maybe it is possible to introduce a different difficulty-level where it works this way?

The "Clumsy Pandorian mode". It is unlocked when failing a level more than 10 times in a row :p
 
Hmm, when I look at the reviews of the game, it looks like it should actually work the way I do it.
 
@EvilDragon: Thank you for the video. It is very interesting to see. If I am honest, I didn't really believe this bug would exist, I believed you would somehow be doing your input wrong. But I can confirm you are gesturing in a way is completely fine, you should be seeing KAMI's jumping happily around.

We are puzzled at the moment as to how this can happen (and how it can happen only on selected devices). One idea that has surfaced is that instead of your gesture coming through as a single gesture (one press event, a bunch of movement events and finally one release event) it is actually coming through as lots of little movements (e.g. press, move, move, release, press, move, release, press, move, move, release, press, move, release, etc.)


What I will do tomorrow is rebuild KAMI RETRO against all our latest code and data and get it onto the repository, then perhaps someone who experiences the same issue as ED (or ED himself) could see if it has magically been fixed. If it has, well that would be great, but more realistically, if the issue still persists, we will make a special version of the KAMI RETRO PND which has a lot of debugging logging. If someone is able to run the build and send us the log file we'll be able to look through and find out what input is taken at the engine level, and how the games gesture recognizer processes said input.

If anyone experiences this issue and is able to get a Pandora to me to debug in Chester, UK then that would obviously make the whole process much more straight forwards, but that is a very long shot I know!

Again, thanks for the video and apologies to anyone with this issue, hopefully we'll get to the bottom of it soon!
 
We are puzzled at the moment as to how this can happen (and how it can happen only on selected devices). One idea that has surfaced is that instead of your gesture coming through as a single gesture (one press event, a bunch of movement events and finally one release event) it is actually coming through as lots of little movements (e.g. press, move, move, release, press, move, release, press, move, move, release, press, move, release, etc.)
I've done some experimenting with touchscreen input on the pandora in xev and I certainly saw that type of behaviour. To my mind this scenario seems very likely to be correct.

- Neelix
 
I'm happy to try any test builds and send you the logs, or I can also send you a Pandora to test yourself in worst case :)
 
Huh, so it is a bug after all? Good to know. I will also be happy test any new versions and also send any log files if needed (provided I find the time to do so).
 
@F_Slim: Well the gesture ED was performing is correct. My suspicious is either a hardware fault or driver bug. It isn't impossible that it is a game bug, but it still seems relatively unlikely to me with all things taken into account.
 
Hmm, when I look at the reviews of the game, it looks like it should actually work the way I do it.
You're right, it should and does work the way you were doing it - but not on every Pandora.

On my older "rebirth" Pandora it's very easy to launch the KAMI's and I got through 2 worlds easily, but with my new 1GHz it's very difficult and most strokes do not work, just like in your video.

I know there is a major problem with my 1GHz touchscreen, and some other people had a similar problem.  Testing In the desktop, the pointer moves up to 100 pixels away from center toward the edges or corners, depending on pressure.  A very light pressure puts the pointer toward the center, while a stronger pressure moves it outwards.  This makes it difficult to do a simple "click" without "drag".  I'd love to know how to fix this, and whether it is a common problem - it's the only major fault with my 1GHz, everything else about it is peachy!  What could be causing this?

But looking at ED's video (and when I played it), it seems KAMI RETRO is mostly tracking sensible lines from the strokes, and should be able to make sense out of them.  Maybe a small hack-around in the program would fix it?  Perhaps excluding the first and last few points from each stroke.  But this is going to be hard for Steven to fix without access to such a misbehaving Pandora...  (and I'm a bit reluctant to part with my new 1GHz, even for a few weeks!  maybe...)
 
Last edited by a moderator:
But looking at ED's video (and when I played it), it seems KAMI RETRO is mostly tracking sensible lines from the strokes, and should be able to make sense out of them.  Maybe a small hack-around in the program would fix it?  Perhaps excluding the first and last few points from each stroke.  But this is going to be hard for Steven to fix without access to such a misbehaving Pandora...  (and I'm a bit reluctant to part with my new 1GHz, even for a few weeks!  maybe...)
Actually the first thing I'd be trying is treating consecutive drags (as Steven described earlier) along a line or slight curve as a single drag, and see if that fixes the problem.

- Neelix
 
actually the first thing I'd be trying is treating consecutive drags (as Steven described earlier) along a line or slight curve as a single drag, and see if that fixes the problem.
I can drag and drop stuff okay on the desktop, so I doubt this is the problem unless X is magically compensating for it...   Does KAMI run on X or talk straight to the kernel?
 
Same here, when multiple-selecting items on the desktop, the frame that appears works fine.


The touchscreen is okay.
 
For what it is worth, the input code is along these lines:


XEvent xev;

while( XPending( m_XDisplay ) )
{
case ButtonPress:
{
xInputPress( xev.xbutton.x, xev.xbutton.y, 0 );
}
break;
case ButtonRelease:
{
xInputRelease( xev.xbutton.x, xev.xbutton.y, 0 );
}
break;
case MotionNotify:
{
xInputMotion( xev.xmotion.x, xev.xmotion.y, 0 );
}
break;
}

 
Beyond the code above, everything is handled generically across all platforms.
 

I've done some experimenting with touchscreen input on the pandora in xev and I certainly saw that type of behaviour. To my mind this scenario seems very likely to be correct.
 
This is interested, so you have experienced a single input stroke (a stroke being stylus down, stylus move, stylus up) being recoded as multiple strokes? If so, do you find you are able to drag icons around the desktop? If you are then it would suggest that either the desktop is doing some compensation, or it is using a different way to process touch events, or the touch events get altered by a intense GPU application running maybe?
 
I haven't had a chance to make a new build of KAMI RETRO yet, although I am not holding much hope a simple new build is going to fix anything, it feels like I am going to need some logging in a build first to get anywhere. If I have a chance I am going to make a little test PND that displays information about a given stroke which will help track it down.
 
EDIT: And for what it is worth, the reason I mention the screen perhaps behaving differently when under graphical load is because we had some issues with this a long time ago. During some PMs with Notaz he said: "I've finally been able to track it down, it turns out to be a noise issue (crosstalk between LCD data lines and TS signals) that causes readings to be dropped by the driver since they get too inconsistent. It seems to depend on patterns on screen." this particular issue should be resolved now (has been resolved for a while) but the fact patterns on screen affected input back then, I leave it on the table for a potential for the current issue.
 
Last edited by a moderator:
I must admit it's been a while since I did that testing...   I do seem to recall having trouble with dragging icons on the desktop  on that unit though. Since then I've switched which pandora I use as my primary unit. (having damaged the shoulder button on the other one)  The two pandoras have different screens,  (the touchscreen on the newer one has one of the much less responsive touchscreens, requiring a stylus or fingernail rather than just a fingertip) and the newer one does give me an easier time with dragging icons,  but I still sometimes find they get dropped partway through a drag.

I'll do some more testing on both units with and let you know what I find.

- Neelix
 
Yes, I can confirm there's noise that affects the touchscreen, however, notaz was able to compensate it in the driver (tslib) so that it should not be multiple strokes.

I can easily drag and drop icons around on my desktop and I can also click, hold and move to make a selection frame without ever losing it.
 
I am at work, and don't have my Pandora with me, but I built a test bed application (which I tested on a few platforms):

http://repo.openpandora.org/?page=detail&app=com.pawprintgames.testbed

There is every chance it won't actually run (if it doesn't, sorry about that, I will look at it tonight when I have my Pandora). If it does run, it will display text at the top of the screen about the number of:

Down : Touching the screen

Up : Releasing the screen after a down/touch

Drag : Movement between press and release

Move : This shouldn't happen on Pandora, this is movement that occurs outside of a press/release pair

If you do a gesture (like you would in KAMI RETRO), you should see:

1. When your finger/stylus touches the screen, 'Down events' go up by one

2. As you move your finger you should see 'Drag events' go up (the amount of times it goes up corresponds to how many times the screen captures movements for your gesture)

3. When you release your finger from the screen 'Up events' should go up by one

I am interested in any cases that do not follow the above (or any cases where the move event goes up at all). One theory is that during a single stroke (press, move, release) it will actually record multiple 'Down' and 'Up' events.

EDIT: If it does run, excuse the horrible font ;)
 
Last edited by a moderator:
Seems to work properly for me.

Successfully registers down, drag and up.

I'll make a video for you later.
 
Back
Top