Some Litte Questions


josemdark

Still Fresh
Joined
Jul 24, 2009
Messages
19
Hi!

I'll be quick.

The applications need to be ported to the Pandora? I can't decompress an arm debian package (these are really tar.gz files) and it dependencies and place they on their respective directories? It won't work?

And another question. The Pandora can run OPENGL 2.0, SDL and OPENGL ES 2.0 (mobile version of opengl) applications or only SDL and OPENGL ES 2.0 applications? I've read some information about this but it's unclear.

Thanks if you answer :)
 
opengl ES and SDL, not regular OpenGL2. The graphics chip is capable of OpenGL2, but the driver doesn't support it.
As for your first question, I have no idea what you're asking.
 
josemdark said:
Hi!

I'll be quick.

The applications need to be ported to the Pandora? I can't decompress an arm debian package (these are really tar.gz files) and it dependencies and place they on their respective directories? It won't work?

And another question. The Pandora can run OPENGL 2.0, SDL and OPENGL ES 2.0 (mobile version of opengl) applications or only SDL and OPENGL ES 2.0 applications? I've read some information about this but it's unclear.

Thanks if you answer :)

Do you mean how easy is it to install applications? I believe there will be a package manager of some sort but I'm not sure of the details. The Pandora will be using a optimized version of Angstrom for the OS. If you search the forum with that you might find what you are looking for.
 
Last edited by a moderator:
josemdark said:
The applications need to be ported to the Pandora? I can't decompress an arm debian package (these are really tar.gz files) and it dependencies and place they on their respective directories? It won't work?

I'm not familiar with the ARM architecture, so I don't know whether an app compiled for an ARM will work on every ARM, and if I'd be to say I'd say no. I need the knowledge of someone who's already knocked about.
 
Last edited by a moderator:
Limestraël said:
josemdark said:
The applications need to be ported to the Pandora? I can't decompress an arm debian package (these are really tar.gz files) and it dependencies and place they on their respective directories? It won't work?

I'm not familiar with the ARM architecture, so I don't know whether an app compiled for an ARM will work on every ARM, and if I'd be to say I'd say no. I need the knowledge of someone who's already knocked about.

Any apps you want to run will have to be compiled for ARM. Running an app compiled for an x86 architecture will not work.
 
Last edited by a moderator:
The OP is talking about Debian ARM packages. I think that it'll work, but for the most part, installing packages like that isn't a great idea - it would probably be better to get someone to package the software in a PND and install it that way. I'm not sure how well the Pandora will play (at least initially) with .debs.
 
The Pandora will probably have lots of libraries built in, and any program that uses other libraries will be statically linked, i.e built into the program.

Non-issue about that.

The Pandora will have OpenGL 2.0 ES libraries. The programs will have to be converted to this if it is not. The difficulty depends on how complicated the program is.

The team said they will try working on getting Debian ARM packages compatible as well.
 
mawler said:
The team said they will try working on getting Debian ARM packages compatible as well.
They did? Wasn't there just a "collaboration" between Canonical and the devs that enables us to use Ubuntu ARM and Launchpad builds for the Pandora (and Ubuntu of course has access to Debinan ARM packages)?

Oh, I really wish that the Pandora would NOT have internal NAND; then we could use "real" package formats instead of the PND format, for example deb or IPKG.
 
Last edited by a moderator:
We've already had this discussion many times.
1) you can use "real" package formats. If you want to install a library or program directly to the NAND, you can do this. Nothing will stop you. It's just not recommended for many reasons that have already been explained several times. All the reasons that were given would still exist if the NAND didn't exist and SD were the only storage medium, so don't act like the NAND is a hindrance to you.
2) PND was designed to be simple and efficient. Download a single file to an SD card, insert that card, and it just works. If you want to remove that program you just delete that file, freeing up space.
 
WizardStan said:
We've already had this discussion many times.
1) you can use "real" package formats. If you want to install a library or program directly to the NAND, you can do this. Nothing will stop you. It's just not recommended for many reasons that have already been explained several times. All the reasons that were given would still exist if the NAND didn't exist and SD were the only storage medium, so don't act like the NAND is a hindrance to you.
2) PND was designed to be simple and efficient. Download a single file to an SD card, insert that card, and it just works. If you want to remove that program you just delete that file, freeing up space.
Dude, I made the PND Manager. I remade the PXML format. Trust me, I know :p

It would have been possible to use "real" package formats if we wouldn't have had NAND at all though.
 
Last edited by a moderator:
dflemstr said:
Dude, I made the PND Manager. I remade the PXML format. Trust me, I know :p

It would have been possible to use "real" package formats if we wouldn't have had NAND at all though.
If you understand the problems, why the complaint about not being able to use a "real" package manager. You know why it wouldn't work.
You'd still have the same problems if the OS was kept strictly to the SD card though. How do you install programs? What if the card runs out of space? How do you span across multiple cards?
 
Last edited by a moderator:
Thanks a lot to all people, I asked the question "Applications needs to be ported to the pandora?" because some posts confused me like this post http://www.gp32x.de/board/index.php?/topic/40388-your-most-wanted-ported-game-on-pandora/page__p__583042__hl__wesnoth__fromsearch__1&#entry583042 emphy says that he wants to see wesnoth ported to the pandora and in this post http://www.gp32x.de/board/index.php?/topic/47936-battle-for-wesnoth-1-6-2/page__p__727666__hl__wesnoth%20pandora__fromsearch__1&#entry727666 Cpasjuste says that he compiled the game.

And, Pandora can emulate by software the opengl 2.0 (not ES) graphics of simple games (like billard)?

Sorry for my bad english
 
Last edited by a moderator:
I think the issue with internal nand is that you don't want to write to it any more than you absolutely have to. Is that right dflemstr? That's probably true of external SDHC as well, but if one of those fails it's much simpler to replace. I'm guessing with ROM you'd have a boot loader that was hard coded to look for something on one of the SDHC cards, boot from there, and worry a lot less about the number of writes issue on a more or less disposable card.

Isn't this still possible since the Pandora should be able to boot from the SDHC cards, or am I missing something?

Edit:
As far as porting stuff, it depends on what you're talking about. Games need to be ported to Arm, and 3d games to OpenGLES 2.0, or at least to use the OpenGL wrapper I've seen in Pickle's ports. The wrapper seems to work pretty well. (Some things you don't have to convert to OpenglES, the wrapper works fast enough on the Pandora. Pickle would know much more about that topic.) There are different versions of Arm, but my understanding is they're largely backwards compatible, similar to the way an AMD64 will run something compiled for the 386sx, but the older code won't have access to a lot of the features of the newer chip. This is only an issue if those new features would significantly speed up something that's not working fast enough.

For packages from a standard distribution, I'd probably format an SDHC card so that you could boot from it and run that distribution, assuming that's easily doable. I don't know much about the boot loader and how easy it's going to be to switch from internal Nand to external SDHC on bootup.

Edit: Changed sentence for clarity.
 
There's a chance OpenGL will someday be supported by the Pandora through third party drivers, but don't take it for granted or even likely, I don't even know if that project is active.
 
WizardStan said:
If you understand the problems, why the complaint about not being able to use a "real" package manager. You know why it wouldn't work.
You'd still have the same problems if the OS was kept strictly to the SD card though. How do you install programs? What if the card runs out of space? How do you span across multiple cards?
It would work, because if you remove an SD card, everything that depends on that SD card is also removed, if the OS itself is on the SD card. Also, running out of space or having stuff spanning over multiple disks: That's issues you have on all Linux computers, so you would solve them in exactly the same way. But today we have 32 GB cards, and all the games you'll ever install for the Pandora combined will max take up 2048 MiB of space, so it's not like it's an imminent problem.

Etinin said:
There's a chance OpenGL will someday be supported by the Pandora through third party drivers, but don't take it for granted or even likely, I have don't even know if that project is active.
Probably not third-party drivers, but rather a community developed driver. There ARE people working on one, but I do not know with which velocity.
 
Last edited by a moderator:
Okay, if the applications of the deb packets don't run or run
slowly the best way is compiling they for/on the Pandora. Is it true?
 
wardred said:
As far as porting stuff, it depends on what you're talking about. Games need to be ported to Arm, and 3d games to OpenGLES 2.0, or at least to use the OpenGL wrapper I've seen in Pickle's ports. The wrapper seems to work pretty well. (Some things you don't have to convert to OpenglES, the wrapper works fast enough on the Pandora. Pickle would know much more about that topic.) There are different versions of Arm, but my understanding is they're largely backwards compatible, similar to the way an AMD64 will run something compiled for the 386sx, but the older code won't have access to a lot of the features of the newer chip. This is only an issue if those new features would significantly speed up something that's not working fast enough.

You're saying that someone here developped for the Pandora an OpenGL implementation based on OpenGL ES?
Do you have a link to Pickle's post? I'd want to know how it's reliable and fast, and also which version of OpenGL is implemented.
 
Last edited by a moderator:
Limestraël said:
wardred said:
As far as porting stuff, it depends on what you're talking about. Games need to be ported to Arm, and 3d games to OpenGLES 2.0, or at least to use the OpenGL wrapper I've seen in Pickle's ports. The wrapper seems to work pretty well. (Some things you don't have to convert to OpenglES, the wrapper works fast enough on the Pandora. Pickle would know much more about that topic.) There are different versions of Arm, but my understanding is they're largely backwards compatible, similar to the way an AMD64 will run something compiled for the 386sx, but the older code won't have access to a lot of the features of the newer chip. This is only an issue if those new features would significantly speed up something that's not working fast enough.

You're saying that someone here developped for the Pandora an OpenGL implementation based on OpenGL ES?
Do you have a link to Pickle's post? I'd want to know how it's reliable and fast, and also which version of OpenGL is implemented.
It only has implementations for basic "glBegin()"/"glEnd()" stuff and some other things related to GL 1.1 I think; basically, Pickle just wanted to make Quake 3 work, so he didn't implement the complete GL 2.0 specification or anything :p
 
Last edited by a moderator:
dflemstr said:
Limestraël said:
wardred said:
As far as porting stuff, it depends on what you're talking about. Games need to be ported to Arm, and 3d games to OpenGLES 2.0, or at least to use the OpenGL wrapper I've seen in Pickle's ports. The wrapper seems to work pretty well. (Some things you don't have to convert to OpenglES, the wrapper works fast enough on the Pandora. Pickle would know much more about that topic.) There are different versions of Arm, but my understanding is they're largely backwards compatible, similar to the way an AMD64 will run something compiled for the 386sx, but the older code won't have access to a lot of the features of the newer chip. This is only an issue if those new features would significantly speed up something that's not working fast enough.

You're saying that someone here developped for the Pandora an OpenGL implementation based on OpenGL ES?
Do you have a link to Pickle's post? I'd want to know how it's reliable and fast, and also which version of OpenGL is implemented.
It only has implementations for basic "glBegin()"/"glEnd()" stuff and some other things related to GL 1.1 I think; basically, Pickle just wanted to make Quake 3 work, so he didn't implement the complete GL 2.0 specification or anything :p

Well you say it handles all the OpenGL 1.1 specification? If so, then it's enough for me.
In fact, I'd like to get working on Pandora a 2D multimedia lib called SFML, which is a SDL-C++ counterpart, and which uses hardware acceleration thanks to OpenGL 1.1. Using hardware acceleration even for 2D enables it to be much faster than SDL (at least on devices that can accelerate 3D graphics!).
Do you have a link towards Pickle's explanations?

Another question about OpenGL ES: is it simply OpenGL without some functions (such as glBegin/glEnd) or have the other functions changed? What I mean is, if I make an SDL/OpenGL app which uses only vertex arrays and stuff that OpenGLES can cope with, can I directly compile it with OpenGLES or will I have to alter my code?
Second question - sorry -: Is it true OpenGL ES 2.0 doesn't computes itself all the matrix math (translate, rotate...), and that next OpenGL specifications are gonna do so?
 
Last edited by a moderator:
Back
Top