Any way to get started on Pyra development without an OMAP 5?


Good luck. I suspect even with the GLShim it'll have some gotchas, but we'll see. :)
 
Good luck. I suspect even with the GLShim it'll have some gotchas, but we'll see. :)

Hmm... slightly non standard build scripts making assumptions that I'm targeting x86_64.. what I read on that link you posted it may not to like 32bit systems, let alone ARM ones.  It's late here, so when I get time I'll see about hacking around the build scripts.
 
Last edited by a moderator:
GLShim will probably be useless as UE4 needs shader. But it can be built for Android, so GLES path should exist (question is, is it GLES3.x or GLES2.0 is enough).

Also, build system needs mono and clang, are they available on the devboard?
 
What kind of performance does the Pyra have? Compared to Pandora, could it psuh 2x as many polygons? 1.5x? less? more?
 
GLShim will probably be useless as UE4 needs shader. But it can be built for Android, so GLES path should exist (question is, is it GLES3.x or GLES2.0 is enough).

Also, build system needs mono and clang, are they available on the devboard?

yeah every dependency prerequisites were met, the setup script spent a good halfhour downloading via the Debian repo. However it's the build scripts that seems geared to x86 Linux.
 
What kind of performance does the Pyra have? Compared to Pandora, could it psuh 2x as many polygons? 1.5x? less? more?

Pandora 1 GHz : PowerVR SGX530, 14 MTriangles/s, 200 MPixel/s,1.6 GFLOPS.

Pyra : PowerVR SGX544MP2, 35 MTriangles/s, 3.2 GPixels/s, 7.2 GFLOPS. And you should probably multiply that by its two cores.

So for the graphics part of the chip only, it's closer to 4 to 8 times the power, depending on the algorithm. And it's got a wider bus, plus probably a bit more clock, and also the TI 2D BitBit accelerator.

Add to that 4 times the RAM with double the speed, two better cores at 1.7x the clock, two lower cores for general purpose, and you've got something like 4 times the total computing power.

Am I good enough in maths, or did I forget something ? ^_^
 
What kind of performance does the Pyra have? Compared to Pandora, could it psuh 2x as many polygons? 1.5x? less? more?

Going from an SGX530 at 200Mhz in the gigahertz Pandora to an SGX544MP2 at 532Mhz in the Pyra is a huge step up; in general, you're looking at more like a 5-10x jump in 3d performance. I wonder if that's enough for UE4 games.

AFAIK the devboards don't have 3d drivers yet, but you could look at other devices with SGX544 to get an idea of its speed.

Argh, :ph34r: 'd.
 
AFAIK the devboards don't have 3d drivers yet
And this is, unfortunately, where the problem might arise.  It doesn't have 3D drivers yet, and there is a non-zero chance that it never will.  They're kind of there and someone may be able to hack something together, or it could prove to be an insurmountable task and we're stuck with just the 2D accelerator.  We'll probably get the 3D drivers working before too long but don't count on it being a sure thing.
 
Last edited by a moderator:
 

AFAIK the devboards don't have 3d drivers yet
And this is, unfortunately, where the problem might arise.  It doesn't have 3D drivers yet, and there is a non-zero chance that it never will.  They're kind of there and someone may be able to hack something together, or it could prove to be an insurmountable task and we're stuck with just the 2D accelerator.  We'll probably get the 3D drivers working before too long but don't count on it being a sure thing.
Well worse comes to worse we could use TI's old version 3.8 Linux kernel to get the 3D drivers working for the most part... From the mailing list conversation I saw, it seems that Ti can try to package something for us, but it may not be later this year or early next year before they can try it.
 
Last edited by a moderator:
 

AFAIK the devboards don't have 3d drivers yet
And this is, unfortunately, where the problem might arise.  It doesn't have 3D drivers yet, and there is a non-zero chance that it never will.  They're kind of there and someone may be able to hack something together, or it could prove to be an insurmountable task and we're stuck with just the 2D accelerator.  We'll probably get the 3D drivers working before too long but don't count on it being a sure thing.
Well worse comes to worse we could use TI's old version 3.8 Linux kernel to get the 3D drivers working for the most part... From the mailing list conversation I saw, it seems that Ti can try to package something for us, but it may not be later this year or early next year before they can try it.
It's a really bad thing. Personnaly I'm going to wait the release of this driver, it's a quite expensive handled machine, and I don't want to be disapointed with bad performances. The bad point is that I would like to preorder to help ED, but with this, I'm not going to.
 
I am convinced that the Pyra will flop badly if it doesn't get working 3D accelerator drivers in the default distro.
There are a couple things in the way to use the currently available binaries in a current debian install, they are however possible. It's a matter of someone doing it. I think currently we're all kind of waiting to hear back from Ti. If that falls through, hacks may be made.
 
God should have made this world 2D so we all would have flat bellies without exercising and no 3D driver issue.  Papal is coming to New York this week, and Trashy could ask him why God created a 3D world and now we all have to suffer.
 
Hacking up a working Pyra 3d driver is on my todo list. I haven't seen any major issues preventing it. It's nowhere near impossible. Mostly just annoying.
 
By the way, what would be the best language for Pyra games ? Everyone says C++, but what about C, or even ARM assembly ?

Whatever you want: C, C++, assembly if you really want.  Java and C# will be all but guaranteed.  Python will definitely be available and has a suite of game libraries.  BASIC, as was mentioned, both PandaBAS and probably GLBasic will be available.  There's even a Pascal environment that will probably find its way onto the Pyra.
Anything you want will probably be available.
 
Whoa, it's been a while. Just would like to update you guys that I started coding a game in C++ with SDL2 early this month and it's coming along nicely. A few quick questions:

1. Someone said a special version of SDL had to be used for OpenPandora. Will the same be true with SDL2 and Pyra?

2. Will a program incorporating pugixml work with Pyra? I'm using it for game save files.

3. Can I put a game on itch.io with a pay what you want model and still put a Pyra version in the Pyra repository, or do I have to choose? I would choose Pyra, just thought it might be fun to do the itch.io thing.
 
2. Will a program incorporating pugixml work with Pyra?
As long as it doesn't use any driver related or proprietary stuff it solely comes down to how much effort the author has spend into making it platform-independent. From my experience people tend to screw up the 32<->64bit differences a lot more than those of architectures that share the same address width and endianess, though - you haven't seen shit if you didn't run into issues before because someone thought it was a good idea to store a pointer in a plain int variable...
 
Back
Top