|
|
Post by blacken on Apr 23, 2006 17:14:22 GMT 1
I'm a dabbling PalmOS coder, and am looking at what I can do to provide wireless keyboard support for LJP. Two questions:
1) Before I burn too much time on this, has anyone else already done this/begun working on this?
2) What are the coding standards/rules/practices for submission to the LJP project?
|
|
|
|
Post by Tinnus on Apr 24, 2006 1:02:47 GMT 1
1) You see, it's not like we don't want/know how to implement that. It's just that it's very likely to slow all the emulation to a crawl because we would need to queue events. IIRC MetaView has going to give it a go though. 2) The current idea is trying not to change stuff in the framework because all that part is being re-written from scratch. Improvements to the emulators' codes is very welcome though  |
|
|
|
Post by mavsman4457 on Apr 24, 2006 2:16:58 GMT 1
good luck, blacken, in trying the impossible.
|
|
|
|
Post by blacken on Apr 24, 2006 14:28:41 GMT 1
It doesn't necessarily have to slow down all to hell. Queueing shouldn't be that much of a speed hit on most newer Palms (I have a Zire 72s, running LJP via Warpspeed at 500MHz, and SNES games under Scale 2xSAI [or is it Super? Whatever smooth 3 is] run at a steady 60fps, 90-100fps under turbo). Hell, even without Warpspeed the SNES emulation can run upwards of 70fps.
So it's unusable on older handhelds--they can always turn it off...
And like I said in another thread...there's not a lot left to tense in the emulator cores anymore.
|
|
|
|
Post by _Em on Apr 25, 2006 18:37:01 GMT 1
And like I said in another thread...there's not a lot left to tense in the emulator cores anymore. Actually, there's quite a bit left to tweak. For instance, TG-16 still needs to be tweaked to even work -- WonderSwan needs audio. IIRC, the SNES emulator is using snes9x 1.38 code, and snes9x is now at version 1.43, which fixes a LOT of issues (including sprite decompression, adding mappers, blitters, etc.). This holds true for the other emulators too -- most of them are using code from around 3-4 years ago; any advances made in emulating those platforms haven't been ported to ljp in that time; just Palm-specific fixes. After this, there's always the issue of adding NEW platforms to LJP/R -- it'd be great to have the O^2, INTV and Colecovision in there, for instance. |
|
|
|
Post by Tinnus on Apr 25, 2006 19:49:04 GMT 1
Colecovisionis going to be there in LJR |
|
|
|
Post by blacken on Apr 28, 2006 0:19:58 GMT 1
And like I said in another thread...there's not a lot left to tense in the emulator cores anymore. Actually, there's quite a bit left to tweak. For instance, TG-16 still needs to be tweaked to even work -- WonderSwan needs audio. IIRC, the SNES emulator is using snes9x 1.38 code, and snes9x is now at version 1.43, which fixes a LOT of issues (including sprite decompression, adding mappers, blitters, etc.). This holds true for the other emulators too -- most of them are using code from around 3-4 years ago; any advances made in emulating those platforms haven't been ported to ljp in that time; just Palm-specific fixes. After this, there's always the issue of adding NEW platforms to LJP/R -- it'd be great to have the O^2, INTV and Colecovision in there, for instance. Buy me the hardware, I'd be happy to put my back into making 'em! And when it comes to NES/SNES at least, there was little new to do in 3-4 years. I program what is useful for me, and since I play the well-supported ones...well, hook me on something new and I'll jump all over it. |
|
|
|
Post by vilmos on Apr 28, 2006 20:20:50 GMT 1
My quick tests with PalmMAME showed that allowing regular events to queue slowed the emulation to 1/100th of its current speed.
So your 60-70fps would clock in around 6fps. I'm sure you could improve this a bit, but just letting you know how much the event system slows things down.
|
|
|
|
Post by _Em on Apr 28, 2006 22:43:30 GMT 1
1/100th would be 0.6fps, wouldn't it?
|
|
|
|
Post by Tinnus on Apr 28, 2006 23:05:21 GMT 1
I think he meant 1/10th, 0.6 FPS is just too little...
|
|
|
|
Post by metaview on Apr 28, 2006 23:06:47 GMT 1
It seems I will try to add support for my own IR-keyboard (Palm, 4 rows) to duke soon. It's hard-coded to this keyboard, but might be easely adapted to others too.
|
|
|
|
Post by Tinnus on Apr 28, 2006 23:10:34 GMT 1
And then we'll only need a mouse to enjoy the FPS'es fully ;D
|
|
pavla
New Member
Posts: 20
|
Post by pavla on Apr 29, 2006 15:23:37 GMT 1
 Can't wait for some results, sounds fun to try. I wish i could clock my TX to 6Ghz, then i would have smooth fps with awsd on my thinkoutside bluetooth keyboard  |
|
|
|
Post by metaview on Apr 29, 2006 15:36:00 GMT 1
ah well, BT keyboards are at the moment a different level... They use the BT-HID profile and at the moment I don't know how it works.
|
|
|
|
Post by _Em on May 1, 2006 17:10:57 GMT 1
Has anyone checked into the feasability of incorporating some of the tech from mednafen? --Such as rewind, their net play module, PCE/CD support, etc. I presume most of the code is worthless, due to it depending on SDL/net_SDL, but I'd guess there's lots of good code ideas in there |
|
|
|
Post by Tinnus on May 1, 2006 18:21:10 GMT 1
"Due to the threaded model of emulation used in Mednafen (...)"
That likely kills it. But I'm taking a look anyway ;D
|
|
zeromusmog
New Member
Beans, beans, the magical fruit...
Posts: 2
|
Post by zeromusmog on May 7, 2006 10:17:51 GMT 1
I'm a programmer so I'm not just shooting my mouth off (I swear!) and I'm a little confused as to why the keyboard issue is so daunting. Sure, making the universal driver that as far as I know does fake Graffiti input would be slow as all hell for obvious reasons, but aren't there only a few popular keyboard devices for current palms? It seems to me that with a 500mhz machine you could spare a few clock cycles for a raw mode driver for some of the more popular hardware.  The only issue is, of course, finding a way to test the hardware without having it. Still, a few volunteers could probably fix this. Also the PalmOS event handler must be downright TERRIBLE. I mean, I figured this from playing with the old hardware (I had a IIIc back in the day) and making test apps and seeing just how slow it was when it came to things like graffiti input, etc but I figured it was par for the course... but on a 500mhz machine there's just no excuse to take up 90% of the processor D: |
|
|
|
Post by Tinnus on May 7, 2006 15:26:03 GMT 1
For emulation, yes there is. Using events is a no-go for sure--not only it slows it down, but makes things choppy--run, pause, run, pause. That's extremely annoying.
MetaView is currently researching raw mode though IIRC.
|
|
|
|
|
|
Post by Tinnus on May 30, 2006 12:45:22 GMT 1
Yeah LJP uses KeyCurrentState.
Oh and BTW, there are 3 or so "chars" sent along with the event IIRC. One of them is the same for all, but another one changes or something like that.
|
|
|
|
Post by huarifaifa on Jul 17, 2006 17:53:39 GMT 1
I noticed that LJP (and other emulators) slow down quite a bit (~5-10%) while I'm pressing the hardware keys of my Tungsten T2.
|
|
|
|
Post by Tinnus on Jul 17, 2006 23:15:42 GMT 1
Normal. The OS does something in the background that slows everything down on key presses. The amout of slowness depends on the model, though.
|
|
Can't wait for some results, sounds fun to try. I wish i could clock my TX to 6Ghz, then i would have smooth fps with awsd on my thinkoutside bluetooth keyboard 
