Pandora improved SDL for pandora

[mordante]

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.

Thanks for the hint will give it a try.

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

Could you post some binaries for easy testing?

If it's reproducible I expect it to happen with the official release [1] as well.


To be sure I also attached my Wesnoth executable, which works with the


data files of the official release.


[1] http://sourceforge.n...-1.pnd/download

 

[notaz]

If it's reproducible I expect it to happen with the official release [1] as well.


To be sure I also attached my Wesnoth executable, which works with the


data files of the official release.


[1] http://sourceforge.n...-1.pnd/download

It looks like this for me, I suppose correct? (this was taken on pandora)

You probably want to build latest qemu from source, I've been hit by their ARM bugs before.

 

[Edglex]

So I tried running homeworld with this, and it segfaults once the environment variable is set.


As I understood it I shouldn't need to rebuild against your new library, or am I wrong?


I tried a quick run through with gdb and it crashes doing something with libts. Tried fiddling with the env vars for SDL_OMAP ts stuff, which doesn't help. Don't have debug version of homeworld so not sure exactly where it crashes.


Thanks

 

[notaz]

So I tried running homeworld with this, and it segfaults once the environment variable is set.


As I understood it I shouldn't need to rebuild against your new library, or am I wrong?

You should not, where can I get it for testing?

 

[Edglex]

It's available on the repo here: http://repo.openpand...=homeworld-r907


You also need the original game data files


EDIT: I am checking whether the demo data files will work with it. Will get back to you after it finishes downloading!


Hmmm. Doesn't work.

 

[mcobit]

I may be mistaken, but opengles and the omapscaler don't work together, or do they?

 

[Edglex]

I may be mistaken, but opengles and the omapscaler don't work together, or do they?

Ah, thanks, if that's the case it would explain it. Though not sure why it is failing in tslib then. Can scaling be turned off?

 

[mcobit]

Yes, just don't set the layersize and you should be good to go. I am not sure, if you the touchscreenstuff works with gles, but notaz may be able to clarify. Also, what benefit would notaz sdl have in this game?

 

[mordante]

It looks like this for me, I suppose correct? (this was taken on pandora)

Yes thanks for testing it. (The missing text is due to me not being able getting pango to work yet.)

You probably want to build latest qemu from source, I've been hit by their ARM bugs before.

Thanks for the hint I tried with the latest version and the glitches are gone.

 

[Edglex]

Yes, just don't set the layersize and you should be good to go. I am not sure, if you the touchscreenstuff works with gles, but notaz may be able to clarify. Also, what benefit would notaz sdl have in this game?

Ah, then I don't think it's the scaler as simply setting SDL_VIDEODRIVER="omapdss" is enough to make it seg fault.


I'm not that sure it would do anything to help, but I wanted to try it in case it is an easy way to fix the problem with the offset between the nubs and touch screen.


Homeworld messes about with the mouse cursor a lot and not in a strictly normal SDL way (it gets the cursor coordinates and then draws a cursor manually at that location), so it wasn't immediately obvious how to fix it and what with one thing and another I haven't found the time to look at it much


I've got it more-or-less working now. The offset is fixed but now two cursors are being displayed, with one dragging slightly behind the other.


Ok, fully working now.


I also want to sort out the controls a bit in general, will have a look at this and then make a release. Just have to remember how to make a PND!

 

[mcobit]

If it is an sdlapp, you can have a look at this touchscreenoffsetfix from djwillis:


http://blogs.distant-earth.com/wp/?p=293#more-293


Edit: Making a pnd in sebt3's or ivanovics toolchain is pretty easy, as they come with the genpxml and pndmakeauto scripts.


You will need to fix the PXML before uploading to the repo a bit though.

 

[Edglex]

If it is an sdlapp, you can have a look at this touchscreenoffsetfix from djwillis:


http://blogs.distant...?p=293#more-293

Yeah, this doesn't really work for homeworld because of the strange way they use the cursors. But something similar (that djwillis alludes to on that page) does work, so it's working great now, finally!

Edit: Making a pnd in sebt3's or ivanovics toolchain is pretty easy, as they come with the genpxml and pndmakeauto scripts.


You will need to fix the PXML before uploading to the repo a bit though.

I figured I'd just change the existing PND, it's only the binary itself and the startup script that have changed. Though I'll also update the version numbers.


It's just controls now. I don't have time today but I think I've come up with some good ideas for controls that I'll try and wrap up tomorrow night. The only slight issue with changing all the controls is that the tutorial will now instruct you to use the wrong ones, but that can't really be helped.

 

[mcobit]

I figured I'd just change the existing PND, it's only the binary itself and the startup script that have changed. Though I'll also update the version numbers.

You may want to add licenseinformation and sourceurl etc. too, if you're at it.

 

[Edglex]

You may want to add licenseinformation and sourceurl etc. too, if you're at it.

Now there's a tricky topic. It's not hard to get the source code (email the homeworldsdl maintainer at the nekomimicon.net forums for access), though the licensing rules are complicated, not entirely clear, and most worryingly, literally impossible to adhere to. I'm pretty sure I'll get some of this wrong, but as I understand it homeworldsdl should not exist at all according to the terms of the license. For starters, the license says you must be a member of the relic developer network to have source, and that doesn't exist any more. The license seems to say, more-or-less, here's the source, you can look at it on our web site (that no longer exists), but that's about it.


Relic have assured the homeworldsdl guys that the issues were due to over-zealous lawyers, and that such a stringent license wasn't what they intended when they decided to release the sources, but legally that doesn't improve my position very much, if at all.


The short version is that I think I'm safe supplying binaries, but I can't distribute changes or any source code. I will submit the changes upstream, and I'm pretty confident they'll be accepted. I'll put what information I can in the PND with a link to the nekomimicon forums and the homeworldsdl site.

 

[mcobit]

Ok, didn't know that it has such a restrictive license...

 

[Edglex]

Ok, didn't know that it has such a restrictive license...

Yeah, it's a bummer


Sorry if that came across as heavily stated, it's just hard to explain such a confusing license clearly

 

[john4p]

Hello notaz, this quote is from the old gp32x-board:

Try adding this at the end of flush_block():

gfx_mem = (char *)prSDLScreen->pixels;

init_row_map();

then remove "static _INLINE_" from init_row_map() in drawing.cpp so that it all compiles.

This advice helped getting doublebuffering to work with UAE4All (and your sdl).


Now with the new UAE4All "2.0" the screen is flashing again - similarly to what it did before following your advice.


But now in sdlgfx.cpp both lines are still at the end of flush_block() yet the screen is flashing.


The drawing.cpp (containing init_row_map()) has changed a lot.


Attached are the new and the old drawing.cpp.


Please have a look and see if you get an idea what could cause the problem.

drawingcppOldnNew.zip

 

[notaz]

Where is SDL_Flip() called? Maybe try adding those lines just after SDL_Flip() instead?

 

[john4p]

Thanks for the advice - tried it but that doesn't fix the problem.


Well, it's not related to your sdl. With the standard sdl it occurs, too.


Something's wrong in uae4all's code, but I lack the knowledge to find the bug(s).

 

[_wb_]

Can I use the nubs in joystick mode? In the default SDL, I can set /proc/pandora/nub{0,1}/mode to "absolute" and then it will find two joysticks called "nub0" and "nub1". When I set SDL_VIDEODRIVER=omapdss and do the same thing, it does not find the joysticks and it also the dpad and ABXY buttons stop working. If I don't put the nubs in absolute mode, I can use the dpad and ABXY buttons, but the nubs generate mouse events.


In short: I want notaz' SDL, use all buttons AND use the nubs in joystick mode. Does anyone have any idea how to do this?