Multiarch pnds?

[mcobit]

One thing that came to my mind:


What if you could specify different binaries and libs and configs for multiple systems?


Imagine you are playing a game on the Pyra and then decide to continue it on your or your friends PC running linux.


You could install libpnd on the linuxpc and put in your sdcard. The game would detect the x86 linux and run with a x86 binary instead of the arm one. This could also work with other open consoles like gcw0 or Pandora and all of them can have their own optimized binaries and share the datafiles and saves.


What do you think?

 

[Hồng Thất Công]

let's  do it

 

[Granitehead]

What about having a simple system to make .pnd-next packages for different systems instead?

 

[mcobit]

You would need multiple pnds then.

 

[Granitehead]

You would need multiple pnds then.

That's what I meant.They should still be compatible savegame and online gaming wise.

 

[Linux-SWAT]

I'm supporting this since a long time. I'd also like a distribution-aware field. That was needed to run some .pnd under Slackware.

The only problem with this may be the size of the pnd for things like wesnoth although i think most space is used by no-arch data.

 

[mcobit]

Most of the time the binaries are small in comparison to other data.


Although some libs you need could get big.

 

[mcobit]

You would need multiple pnds then.

That's what I meant.They should still be compatible savegame and online gaming wise.

What would be the advantage to installing the game ont he other platform and copying your saves over then?

 

[Granitehead]

You would need multiple pnds then.

That's what I meant.They should still be compatible savegame and online gaming wise.

What would be the advantage to installing the game ont he other platform and copying your saves over then?

You wouldn't need to copy the saves over, for one thing. They could still be automatically recognized.I just don't like the thought of all the overhead which would be possible with multi-arch .pnd-nexts.

What would maybe be a possibility, but probably add some work, is to separate binaries and data and then make it possible to install different combinations/amount of binaries into the same .pnd-next file.

 

[Askarus]

You would need multiple pnds then.

That's what I meant.They should still be compatible savegame and online gaming wise.

What would be the advantage to installing the game ont he other platform and copying your saves over then?

You wouldn't need to copy the saves over, for one thing. They could still be automatically recognized.
I just don't like the thought of all the overhead which would be possible with multi-arch .pnd-nexts.


What would maybe be a possibility, but probably add some work, is to separate binaries and data and then make it possible to install different combinations/amount of binaries into the same .pnd-next file.

For bog binaries you are right.

I don't want to waste lots of MB (or even GB if you have about 100 PNDs) for stuff I don't need.

If it's just a few KB, then I think it's a nice feature.

But as the Pyra will be strong enough to play lots of games, has HDMI and will get a docking station I don't see a reason why I want to play on a different Computer.

Even at a friend's house I can bring my HDMI cable and USB hub with me (or that friend already has the equipment. I think most people who care about computer and gaming do have a HDMI cable and a hub).

It might be a nice addition but I don't see a serious need for it.

 

[mcobit]

Well, if you want to play some 3d shooter for example you would need a hub, a hdmi cable, a mouse and a keyboard.


If you just need to put the Pyra in MassStorage mode and plug it into another pc it would be easier.

 

[levi]

How would the different binaries and libs be laid out? I seem to recall some people were working on a sensible way to have multiple libs on the same system and for them not to be laid out in the current unsymmetric and ad-hoc way libs generally are for cross compiling, but my search-fu is failing me at the moment, but if such work is underway I'd like us to follow that proposal as closely as possible if we're heading down that road.


I don't see this as a bad proposal for handhelds if it weren't for the fact I've not heard of a followup to the GCW Zero or any other non-android handhelds. While some of the Pandora games would also be able to run on the GCW Zero, that gap will widen with the Pyra. I guess it would work between Pandora/Pyra and Windows too, but getting PNDs running on Linux PCs sounds like a hiding to nothing with different versions of libs abounding. And I don't see anyway to package Android software alongside m0re traditional computer binaries, short of making it an Android apk and hiding other stuff inside it.


There are ways round these problems, but it all sounds like a lot of development work to me, and haven't our devs got enough to do at the moment?

 

[Askarus]

I don't see a problem here.

We'll get a docking station.

Most people who want to play shooters with mouse and keyboard will have a setup for that anyways.

Games you can't play well on the Pyra won't have an advantage as well.

I don't even play Jedi Knight and Shadow Warrior on the Pandora any more.

The right nub on my Pandora is simply not good enough to make it enjoyable.

I wouldn't have any advantage if I could plug my Pandora into my laptop.

I won't play them on Pandora anyways.

Same for Pyra.

If framerate is so bad that I need a PC to play it I won't play it on the Pyra so no need for it either.

Also I think the binaries will be Linux binaries.

Don't think there are so much Linux PCs out theres.

There's one further guy who studies with me who uses Linux.

For me it's not useful to use PNDs.

I would go further (and that would be awesome).

We have fast emmc, we have USB 3.0, we have a lot storage, we have a full Debian.

You remember SOLEIL? It was one of the most awesome Pandora moments as I saw my laptop booting the same Slackware that's also on my Pandora.

That's what we need.

Pyra will be fast enough to do some real heavy work in it.

Then, if you are anywhere else and need a big screen, plug your Pyra into any computer and here's your Pyra.

Of course this will use a lot of space and I don't think that it should be included by default (as not everyone will use it and it's a waste of space).

But if 32 GB of internal storage will be chosen I would love to have a bootable Linux with me all the time.

Linux-Swat mentioned that Slackware is good for such a thing, maybe it could be done with Debian as well.

If not I simply will use Slackware.

(If there's further interest let's start a new topic. I don't want to spam this thread. For me it's simply more useful than having executable PNDs on Laptops).

 

[Linux-SWAT]

Dependencies updates can break things in Debian.

I always say that Debian package management is both the best and worst thing in this distribution.

 

[Askarus]

Do you refer to the SOLEIL like idea or th the Multiarch PNDs.

If we have multiarch PNDs won't we have to include every lib and everything that's in the Pyra firmware into the PND then?

What about SDL Notaz did improve?

If a game uses it does it even work on other PCs?

Neon optimization (if we decide for ARM SoC) won't run on x86 PC as well.

Don't suppose we'll come any far with Multiarch PND. If you don't get the whole OS booting there are too much things that could fail I think.

 

[mcobit]

Not really. The pnd can for example have a x86 binary linked with normal GL while the Pyra binary will have gles.


The needed libs can either be in the root filesystem or included in a libs_86 or libs_arm folder. They can be preloaded when starting one of the binaries based on the system the pnd is run from.


Edit: You could also include statically linked binaries for other systems like desktop linux.

 

[vinipsmaker]

What do you think?

First, this would work only for more self-contained solutions like the flat-pnd or docker.io.

Second, you need to have the binaries for multiple architectures. I see two ways right now:

• Group several "PNDs" in one, which would probably replicate data files or complicate the PND system
• Something like FatELF (from Ryan C. Gordon)

Third, I just shared this thought and I won't follow the discussion in this topic. Both, Pandora and Pyra, use an ARM processor and I don't care about multiarch PNDs.

 

[PokeParadox]

Squashfs would help with size of multi-arch pnds? Or not?

 

[Linux-SWAT]

• Group several "PNDs" in one, which would probably replicate data files or complicate the PND system
• Something like FatELF (from Ryan C. Gordon)

Third, I just shared this thought and I won't follow the discussion in this topic. Both, Pandora and Pyra, use an ARM processor and I don't care about multiarch PNDs.

Grouping won't be necessary complicated. I'd say it will be very simple.

FatELF may not help here if libs aren't managed.

A8 and A15 don't have same compilation optimizations.

Yeah, the other discussion is much more interesting.

 

[_jr_]

Isn't this possible right now? What more than setting up the right LD_LIBRARY_PATH in the PND's run.sh is needed? What is gained by replacing the (trivial) logic inside the PND by rather more complicated (has to parse meta information to detect a multiarch pnd, which is probably more complicated than the actual switching itself) logic in pndrun.sh?