Psuedogl

[skeezix]

USB-net is nearly free on linux-to-linux; it basicly just works. But God and Crom help you to get usb-net working from pandora to Windows or OSX (depending on version .. XP SP1 no prolblem, but christ help you on Win7 )

For me, I live with a pile of VMs, and oyu're just not going to get USB-net working reliably from a guest VM to a host USB Pandora (In that case, use native linux to pandora usbnet, then some tunnel from the VM to the host pandora, such as ssh tunnel in putty, etc.)

jeff

 

[torpor]

Oh right, Windows. I stand corrected. I am 100% not a Windows user.

BTW, I *do* have USB-Net working fine from a VM (VirtualBox) to my Pandora - works great, in fact! I also use it for Zii Egg development .. its not so hard. Just assign the USB device to the VM, and oila - same as it ever was.

 

[skeezix]

Really? Nice. I've never had any luck, using VMWare Workstation. I've been using VMware for years (since they started really) so have only done a little with VB (and PArallels and VirtualPC and qemu and so on ; vmwre USB support works pretty well for most things, but I find when it comes to usbnet linux guest, its not going to happen. And itunes seems to sync to ipod at USB1.1 speeds instead of USB2, which is weird.

(I think some of my troubles are due to using Ubuntu host, and its default USB scripts are pretty grabby; I should hack them so they don't automount or auto-fuck-with-usb, so the vmware guests can have first touch of the USB mounts..)

jeff

 

[WizardStan]

Geeze. Do I have to write a tutorial?

There's already one* for cross compiling to Cortex A8(ie, BeagleBoard specifically) with step by step instructions that require nothing more than cut and paste to a terminal. That previous one you wrote for getting the necessary tools onto the Pandora was helpful, but didn't include things like mounting the Pandora disk or compiling directly on the Pandora from your VIM window (that one's actually the neat trick) so probably wouldn't hurt to expand (and bump) that thread.


*: someone decided the information was "duplicated" without explaining where it was duplicated and decided to delete it, but you can still find the original tutorial in the history. For the most part it's just "git pull; waaaaaiiit; bitbake; waaaaaiiit soooome mooooore; CROSS_COMPILE=...; make". Some additional steps may be required depending on the libraries you want to compile against. For the most part they can be pulled directly off an on-board compiler enabled Pandora, and I'd gladly write a tutorial or script to do that if people were interested. Except GLES; I can't for the life of me figure out how to get this library anywhere. TI hates me or something.

p.s. I also do a lot of compiling on the Pandora, I'm just poking fun at how adamant you sometimes get about how much better on board compiling is to cross compiling

 

[skeezix]

While we're circle-jerking how awesome we all are..

And of course, everyone should be using Emacs (with its clever Tramp-mode stuff.)

You could ssh into the pandora and edit locally, but I just keep my standard Emacs up, and edit remotely to pandora filesystem (or edit locally, with auto-checking and have pandora auto-checkout from my local GIT, but that slows the dev cycle down.)

jeff

 

[PokeParadox]

FWIW I just cross-compile and transfer over wifi, then run on Pand...

For GL/GLES I have GL code for desktop and GLES code for Pandora obviously, but most of the actual render code is shared and what is available on both GL and GLES.

 

[darkblu]

FWIW I just cross-compile and transfer over wifi, then run on Pand...

For GL/GLES I have GL code for desktop and GLES code for Pandora obviously, but most of the actual render code is shared and what is available on both GL and GLES.

So do I. The most robust way to do GLES2 development on the desktop for me has been to stick to GL3 pure profiles/limit oneself to the appropriate GL2 subset. Then of course you need to actually build your stuff on the target platform and see what slipped through the gratings, but it's still the most portable approach.

As for GLES1x - it's pretty much a cleaned up, shader-less GL2. You might surely hit the odd texture- and/or texcoord sub-API incompatibility between the two, but it's still a rather smooth transition. The biggest hurdles usually come from porting legacy GL code, using GL sub-APIs that nobody in their right mind would dare use today.

 

[warmi]

FWIW I just cross-compile and transfer over wifi, then run on Pand...

For GL/GLES I have GL code for desktop and GLES code for Pandora obviously, but most of the actual render code is shared and what is available on both GL and GLES.

So do I. The most robust way to do GLES2 development on the desktop for me has been to stick to GL3 pure profiles/limit oneself to the appropriate GL2 subset. Then of course you need to actually build your stuff on the target platform and see what slipped through the gratings, but it's still the most portable approach.

As for GLES1x - it's pretty much a cleaned up, shader-less GL2. You might surely hit the odd texture- and/or texcoord sub-API incompatibility between the two, but it's still a rather smooth transition. The biggest hurdles usually come from porting legacy GL code, using GL sub-APIs that nobody in their right mind would dare use today.

If you target your code for OpenGL and GLES then that's a good idea .. on the other hand if you are using your desktop machine purely as a "GLES emulator" then using a wrapper library ( like the one from Imagination Technologies) is much more convenient ( they directly support a lot of extensions found on mobile devices (which you can enable/disable using different device profiles) as well as things like GLES specific GLSL keywords etc )