Re: [Announce] gpSP
 

WOW! Thanks...

Re: [Announce] gpSP
 

I have uploaded another small update (3.1.5). The emulator:

• Camera key can be used in the control scheme.
• Pause menu has a button to invoke the task switcher.

And the GUI:

• Added support for camera focus key in keys configuration.

With a volume button assigned to L and the camera button to R, it feels almost like holding a real GBA. :D

Unfortunately, this scheme is not usable with camkeyd. But to make up for it, I have added a button in the pause menu, which makes it possible to activate the task switcher without sliding out the keyboard.

Custom commands in the GUI are also pretty useful: with "sudo stop camkeyd" in "before" field and "sudo start camkeyd" in "after" I can automatically gain furious button mashing capabilities when the emulator is running and get fast window switching back after it is closed.

Re: [Announce] gpSP
 

Where to download update? I see gpspmgui 3.1.1-1 in synaptic.

Re: [Announce] gpSP
 

Update your catalogs first...

OT: I downloaded the the update and I like it a lot.
I doubt I'd use it much 'cause it easier to bind L and R to X and Y on my gamegripper, but I can definitely see myself using it when I'm out and about without it.
Good job man :D

Re: [Announce] gpSP
 

Already updated. Maybe i need to change *.list
Now i have skeiron.org repos enabled.

Re: [Announce] gpSP
 

Is there possible to add wifi battle support to gpSP?

Re: [Announce] gpSP
 

I've had a free while to test latest version of gpsp, and I must say that improvements are amazing. Thanks a lot, gdizzz, it won't be too bold to say that even desktops doesn't have so smooths GBA emulating experience, as your smoothly integrated GUI, (in pair with tweaked base gpsp), offers!

I have one maemo-specific feature request, that (I hope) shouldn't be hard nor time consuming to implement, yet would be *very* usefull to have:
It's about expanding a little (already present in gpsp) accelerometer support. I found that it works suprisingly well for many sim/arcade sim games (Wings, Tomcat F-14, Wing Commander, etc), allowing for even better control experience, than on native GBA - the thing is, that it assume "neutral" position at an angle that is *very* unpleasant to play, i.e. when N900 lies flat on table. So, to keep it without triggering directional keys, one need to "hang" above horizontaly positioned N900, tilting it to get input.

Now, there are two possible workarounds for this that I imagine - the best one is seen on most accelerometer-enabled Maemo games, already (including Open Source ones, like Alpha Strike, or "Accelemymote" tool, so approriate code could get "borrowed", if nothing else), and works in a way that device "calibrate" neutral point at accel. readings from when game is started.

In this variant, all the user have to do is to held N900 in comfortable position, while hitting "start" from gpspGUI. In case of accel. enabled globally/for that particular game, main gpsp application would set neutral point for accel. readout at startup.

Other, less comfortable, but absolutely acceptable solution, would be to set neutral point for accelerometer in gpsp config file (and/or from GUI "general settings"). There are many programs that give readouts for current gyro's position, so one would need to check them while holding N900 comfortably, then write it into config. Not as smooth as 1st solution, but would still work, nevertheless.
---

Last but not least, it would be nice to have control over what get mapped to acceleromete positions. Sure, anything else than directional pads are rarely required, but in some cases, it would help - from simple up<->down inversion (when game doesn't offer Y-axis inversion from its control), as basic example. And if we would be to give that control to the user, no reason to disallow assigning more weird things, like whatever button.

/Estel

Re: [Announce] gpSP
 

It can be that now this doesn´t work
the problem is that at 805 that is how I ususaly have the phone the battery consuption is very high and this custom command is not working at least for me

Re: [Announce] gpSP
 

If the program is being run as user, that command would need to be run via "sudo" (so "sudo kernel-config..."), as kernel-config should be run by superuser, maybe that's the case?

Re: [Announce] gpSP
 

it works thanks

Re: [Announce] gpSP
 

I don't have the knowledge to implement this by myself, but this certainly is an interesting feature. A few years ago there was an effort to add multiplayer in a fork of gpSP, but as far as I know, nothing came out of it. Maybe one distant day I'll sit down, learn GBA, and give it a try. ;)


Strangely it works without sudo for me. :eek:


Finally I've got some free time for Maemo, but I had to send my laptop for repairs. :( However, I've managed to borrow another one for a while and do some work on the accelerometer. I am not sure if flipped axes and arbitrary buttons are worth the effort, so I've implemented only basic configurability for now.

This is the changelog for gpspm 3.1.6:

• Allow D-pad diagonals to cancel each other out.
• Fixed accelerometer input in portrait mode.
• More sophisticated accelerometer handling.
• Configurable accelerometer options.

...and the GUI:

• Added accelerometer calibration dialog.

With diagonals canceling each other out, it is possible to bind only the diagonal directions to keyboard keys (e.g. A, S, Z, X) and still have full control. This might come useful in games with a lot of D-pad spinning (e.g. later levels of Kuru Kuru Kururin).

There are a few changes behind "more sophisticated accelerometer handling":

• The deadzone is radial, which means it takes the same amount of tilt to trigger a diagonal direction as a main direction.
• Uniform direction areas make it possible to trigger a diagonal direction without triggering one of main directions first.
  Attachment 34037
• All three acceleration vectors are taken into account during calculations to determine the real tilt rather than just an approximation along X and Y axes. Thanks to that it is possible to set the neutral pitch to 90 degrees, and another advantage is that the deadzone is not deformed at steeper angles. Unfortunately, there's also a possible downside to this approach: roll is measured relative to the ground rather than the device. However, uniform direction areas compensate it to some extent and perfect motion controls in every orientation are not possible without a gyro sensor anyway.

Re: [Announce] gpSP
 

Thanks a lot for your super-fast implementing of my suggestion - I have grabbed it as soon as it got released, bu only now I had time to properly test new features and drop a comment here.

Making it short, it just works great :) Settings are intuitive, everything seems to works as "advertised", and after short while of setting up and determining best dead zone, we (me and my son) had super-fun using it in actual gaming.

Now, for sure, control in some titles is *much* better than in native GBA - while lack of analog imput is still some limitation (of GBA titles as whole), clever usage of uniform directions neutralized it to some degree. As a result, playing V-Rally 3 (and other racers, but it's most noteworthy in pinnacle of GBA driving games) with accelerometer was almost like having virtual steering wheel, not to mention how well Wings, Tomcat, or Wing Commander behave. Heck, I was even able to steer sensibly (and kill something!) in Wing Commander on hardest difficulty, and that says something ;)

Overall, awesome work. Thanks.

Cheers,
/Estel

Re: [Announce] gpSP
 

espero poder jugar ponekmon en mi n800 les comento que tal corre en mi tablet despues de probar

Re: [Announce] gpSP
 

While I realize that this is no trivial task even if there is a source code to borrow from somewhere, if you ever decide to pick this idea, there is a FOSS vba-m project:
http://sourceforge.net/projects/vbam/

...that have link through bluetooth and WiFi figured out. They're mainly windo$e thing, but are supporting SDL version too, and I even saw mentions of ARM-Thumb optimizations in their latest changelogs, so they code should be borrow'able. I think. Well, for sure, having GBA multiplayer between N900's (or N900's and desktops/notebooks/whatever!) would be awesome.

/Estel

Re: [Announce] gpSP
 

gpspm 3.1.7 passed the autobuilder, should reach the repository soon.

• 100% battery-friendly pause. It no longer drains 50 mA or so.
• Improved autopause reliability.
• Fixed (or at least made VBA-like) day of week reporting in RTC. I tried to find a reliable specification of real time clock from GBA cartridges (without success) and I am not aware of any licensed games that differentiate between days of week, so I am not sure which way to return current time is correct. However, there is a certain Pokemon hack (Liquid Crystal) which had a problem with gpSP's implementation, so I have changed it to behave like Visual Boy Advance.