OskOut Speed Enhancement

[Stonedge]

After looking at the OskOut source code it seem that it can be speed enhance...

here is my observation

Please note: I didnt have the PSP Tool Chain installed... so I cannot do the final testing on my own system

ps: Sorry for my english.... I'm a french guy

Code:

ORIGINAL CODE:

char * standardkeys[4][3] =
{
{ ".,!?@\"'`:;()<>[]{}1", "abcABC2", "defDEF3" },
{ "ghiGHI4",              "jklJKL5", "mnoMNO6" },
{ "pqrsPQRS7",            "tuvTUV8", "wxyzWXYZ9" },
{ "",                     "/-~=_*\001\001+#\001\001$\001\001\001\001%&\\^| 0", "" }
};

int currx, curry;

// find the position of a given char in the keys array
//  (z is the number of presses required to get that char once in the right set)
void find_coords(char ch, int *x, int *y, int *z)
{
  int lx, ly, lz;

*x = 0;
*y = 0;
*z = 0;

for (lx = 0; lx < 3; lx++)
{
for (ly = 0; ly < 4; ly++)
{
for (lz = 0; lz < strlen(standardkeys[ly][lx]); lz++)
{
if (standardkeys[ly][lx][lz] == ch)
{
*x = lx;
*y = ly;
*z = lz;
return;
}
}
}
}
}

REPLACEMENT CODE:

int standardkeys [94,3] =
{
{0,0,2},  // !
{0,0,6},  // "
{1,3,7},  // #
{1,3,8},  // $
{1,3,9},  // %
{1,3,10}, // &
{0,0,7},  // '
{0,0,11}, // (
{0,0,12}, // )
{1,3,5},  // *
{1,3,6},  // +
{0,0,1},  // ,
{1,3,1},  // -
{0,0,0},  // .
{1,3,0},  // /
{1,3,11}, // 0
{0,0,19}, // 1
{1,0,6},  // 2
{2,0,6},  // 3
{0,1,6},  // 4
{1,1,6},  // 5
{2,1,6},  // 6
{0,2,8},  // 7
{1,2,6},  // 8
{2,2,8},  // 9
{0,0,9},  // :
{0,0,10}, // ;
{0,0,13}, // <
{1,3,3},  // =
{0,0,14}, // >
{0,0,3},  // ?
{0,0,4},  // @
{1,0,3},  // A
{1,0,4},  // B
{1,0,5},  // C
{2,0,3},  // D
{2,0,4},  // E
{2,0,5},  // F
{0,1,3},  // G
{0,1,4},  // H
{0,1,5},  // I
{1,1,3},  // J
{1,1,4},  // K
{1,1,5},  // L
{2,1,3},  // M
{2,1,4},  // N
{2,1,5},  // O
{0,2,4},  // P
{0,2,5},  // Q
{0,2,6},  // R
{0,2,7},  // S
{1,2,3},  // T
{1,2,4},  // U
{1,2,5},  // V
{2,2,4},  // W
{2,2,5},  // X
{2,2,6},  // Y
{2,2,7},  // Z
{0,0,15}, // [
{0,0,5},  // \
{0,0,16}, // ]
{0,0,0},  // ^ but not support by PSP, Replaced by .
{1,3,4},  // _
{0,0,8},  // `
{1,0,0},  // a
{1,0,1},  // b
{1,0,2},  // c
{2,0,0},  // d
{2,0,1},  // e
{2,0,2},  // f
{0,1,0},  // g
{0,1,1},  // h
{0,1,2},  // i
{1,1,0},  // j
{1,1,1},  // k
{1,1,2},  // l
{2,1,0},  // m
{2,1,1},  // n
{2,1,2},  // o
{0,2,0},  // p
{0,2,1},  // q
{0,2,2},  // r
{0,2,3},  // s
{1,2,0},  // t
{1,2,1},  // u
{1,2,2},  // v
{2,2,0},  // w
{2,2,1},  // x
{2,2,2},  // y
{2,2,3},  // z
{0,0,17}, // {
{0,0,0},  // | but not support by PSP, Replaced by .
{0,0,18}, // }
{1,3,2}   // ~
};

In the Default: case you can simply replace:

int x, y, z;
find_coords(ch, &x, &y, &z);

by:
// You Can add a validation to be sure that 32 < ch <127
int Nch = ch - 33;
int x = standardkeys[Nch,0];
int y = standardkeys[Nch,1];
int z = standardkeys[Nch,2];


these step remove a lot of loop and char compare that run each time you press a key
with a little to none additionnal memory consuption ( also can by set as a constant but I didn't know how it would react on the psp
since I never really code on that platform )

[kloplop321]

good observation, after I get toolchain working properly with including header files on linux I can try compiling it

[Fanjita]

Certainly this would optimise this piece of code.

But the more important question is - why would you want to?

I don't believe you'll see any material improvement in observed speed - mostly because that plugin spends a lot of time waiting for the OSK (if I recall correctly, there's a delay before each faked keypress to the OSK, so that it can keep up).  It shouldn't be important to save processor cycles for other threads, either - since the VSH is primarily a wait-state application, and games etc. won't be running when the OSK is active.

So it seems to be an overzealous optimisation, at the expense of readability of the config array (but that's down to personal taste, I guess).

I don't want to discourage anyone from improving pikey, so by all means keep on with it - but I don't personally see the advantage of unfocussed optimisations like this.

[Stonedge]

this is more a try to improve typing rate provide by pikey... with this method any key take ~ the same time to find the right coord...

With this fix I think It would be more easy to fine tune different delay to find the best time delay and improve typping rate...

on other hardware my ir keyboard have a better typping rate and I try to get closer as possible to these typping rate (side note: I know that all off the pikey process is slow down by the key emulation on top of the official OSK... but I dont tink its worst to try to improve it )

(if I recall correctly, there's a delay before each faked keypress to the OSK, so that it can keep up)

did you remember if there delay are managed by the OSK itself? this seem logical because it would be hard to reach the center column/row (with the psp button) without double trigger delay...

Stonedge

[Angelo]

Hmmm...

Very intersting.  

Tell you what, after we do the important stuff in Unofficial piKey, then we'll start perfecting it. I see Fanjita's point of view though. Don't spend time coding stuff that has no point...

Our main aim is to notify Dark_AleX to add a few extra NIDS to his resolver. piKey isn't 100% with 3.80 M33 still.  

Thanks guys!