Pandora improved SDL for pandora

[notaz]

Could the reason be that you don't "upscale" the nub input to the scaled gfx? E.g. it seems that if you have an SDL_Surface of 320x240 scaled to 640x480 you can only move the mouse pointer in the first 320x240 pixels of the 640x480-area.

But that's how it's supposed to work, the program is supposed to see 320x240 "touchscreen", same as if you run it in a window with default SDL. You can try setting SDL_OMAP_NO_TS_TRANSLATE=1 but I doubt it will help.

 

[john4p]

Right, it should work this way. Which it did with the old "default" SDL. Hmm...now what could be the cause for the problem then...


Will try setting this env. variable but I also doubt it'll help. If it doesn't I'll try to just "double" the nub input in uae4all...

 

[john4p]

Okay, it seems like the old sdl gave always motion.xrel- and motion.yrel-events even when the theoretical borders of the sdl_surface had been reached whereas your sdl doesn't. The somewhat weird mouse handling in uae4all wasn't fully compatible with this. Implemented a change now in uae4all which takes this into account.

 

[dgame]

Hi john4p,


Could your uae4all mouse handling changes be applicable to the new dynarec Dosbox?


Thanks!

 

[john4p]

Could your uae4all mouse handling changes be applicable to the new dynarec Dosbox?

I don't know. That's what I did (maybe it's useful for the dosbox dev):


if there's an sdl mouse move event and motion.x==0 then I move the Amiga mouse pointer further to the left (so the invisible barrier gets broken). If motion.x==319 (coz of 320 pixel width) then the pointer is moved to the right. If motion.y==0 then further up and if motion.y==239 (logged the nubs values and 239 was the max y value) then further down.

 

[Dave18]

Hmm, using the 2.6 kernal all keys, dpad and buttons generate an event that can be polled using SDL_PollEvent, when I switch to the 3.2 kernal the normal keyboard still triggers an event but the dpad, abxy buttons, shoulder buttons and start/select/pandora do not.


However, this is not consistent across all programs, some register all key event using either kernal, even two of my programs that use identical input routines!


I don't think it's an issue with the code as it works fine on both kernals when using the default SDL. Code in question is FBA posted here https://github.com/dave18/FBA-Pandora , input code is in pandorasdk.cpp


I do not use a omapsdl.cfg so I'm not overriding the key bindings, It is very mysterious.....


Edit - ok, the cause is the fact that I change the nubs to joysticks. The way I do this is to write to /proc/pandora/nub(x)/mode , is this not an appropriate way to change them anymore?

 

[notaz]

Could be some bug, do you have a console/pndrun log from the case it doesn't work?

 

[Dave18]

If I change the nubs using the config tool, SDL_NumJoysticks returns 2 (used to be 3 but GPIO-Keys isn't returned anymore).


If I change them in code (and I do this before any call to SDL) then SDL_NumJoysticks returns 0.


In both cases opening the file /proc/pandora/nub(x)/mode reads 'absolute'


Does SDL now expect something else to be changed to set the nubs to joystick?


EDIT - in answer to your question above, no error messages are produced.


EDIT 2 - This joystick not found also happens in the standard SDL on kernal 3.2


EDIT 3 - I've think I've found the problem, /dev/input/js0 and js1 get created when the nubs are changed to joystick using config tool and are deleted when changing back. Is this behaviour? What is it trying to achieve as everything worked ok on the old kernal?

 

[notaz]

EDIT 3 - I've think I've found the problem, /dev/input/js0 and js1 get created when the nubs are changed to joystick using config tool and are deleted when changing back. Is this behaviour? What is it trying to achieve as everything worked ok on the old kernal?

It's how Linux input subsystem works, does that on the old kernel too. /dev/input/js0 was static and reserved for gpio-keys and was not functional on old kernel, this has been dropped now as porting those hacks to new kernels is pain (and doesn't make much sense too).

 

[Dave18]

Interesting...


If I check /dev/input after starting my code it has indeed created js0 and js1 but SDL_NumJoysticks still won't detect any joysticks.


If I do


mknod /dev/input/js0 c 13 0


mknod /dev/input/js1 c 13 1


then run my code, obviously js0 and js1 exist but now SDL_NumJoysticks returns 2. which leads me to believe the code might be executing too fast.


added between changing nub mode and starting SDL (and I know this is horrible code with potential to crash the system):

FILE * joyexists;

joyexists=NULL;

while (joyexists==NULL)

{

   joyexists=fopen("/dev/input/js0","r");

}

fclose(joyexists);

printf("js0 now exists\n");

joyexists=NULL;

while (joyexists==NULL)

{

   joyexists=fopen("/dev/input/js1","r");

}

fclose(joyexists);

printf("js1 now exists\n");

Everything now works, including keypresses. Strangely, I never needed to do this before, I wonder if it is an unexpected side effect of slower SD Card access in kernel 3.2.


Thanks for your help in pointing me in the right direction

 

[notaz]

If you use this code, I suggest you add some sleep in those loops so that you don't take CPU away from the kernel needlessly and it can create those files faster. Also a timeout would be good to not deadlock on people with custom kernels without joystick driver.

 

[mindlord]

Ok, help me out here. How do I keep the hardware scaling from changing the Aspect ratio. It seems no matter what resolution I try it gets stretched to fill the whole screen.

 

[mcobit]

Is it for PanMESS?


I added some code to export the right aspect on gamestart.

 

[mindlord]

Is it for PanMESS?


I added some code to export the right aspect on gamestart.

Yes it is. I didn't notice that change in the code when I glanced it over. I'll look again.

 

[mcobit]

In vsdl.c before sdl video initialisation.


Let me know, if you have any problems

 

[mindlord]

Thanks! fixed it.

 

[mordante]

Hi I'm a Wesnoth developer without a Pandora and ran into an SDL glitch.


I cross-compile my binaries with Ivanovic's toolchain and test the


binaries with qemu-arm shipped with Debian Squeeze. When using the


SDL shipped with the firmware and the toolkit all's fine. When testing with


the latest git version I get a visual glitch. Bi-secting pointed at this [1]


revision.


Since I only have access to an emulator I'm not sure whether the bug


is in SDL or in the emulator. I could reproduce the problem with starting


wesnoth with


wesnoth -t


which should end in the test-scenario, but the normal campaigns have


the same issue. The problems are the black HP bars, they should be


coloured and the black edge at the right hand side of the dialogue.


The attached screenshot shows the issue, but beware I haven't been


able to get pango working (yet) so most text is not drawn. Could


somebody please test and confirm whether or not it's an SDL bug or not?


[1] http://notaz.gp2x.de/cgi-bin/gitweb.cgi?p=sdl_omap.git;a=commit;h=a1f340810c4f9a4a617f1757d1ff0255e0e3fe58

 

[mcobit]

You could try to compile with sebt3s toolchain and check again. In PanMAME I had similar bugs in menuitems when I compiled with ivanovics one. With sebt3s the errors are gone.

 

[notaz]

I've pushed some code for minimizing when pandora key is pressed and was able to run Snes9x4P and PCSX at the same time, successfully alt-tabing between them. Might be useful feature for some, binary zip updated too.

Hi I'm a Wesnoth developer without a Pandora and ran into an SDL glitch.

Could you post some binaries for easy testing?

 

[Michoko]

Wow, that's a very nice addition! Thanks Notaz!