LWJGL working on Raspberry Pi in full screen mode

Started by spsn, November 09, 2012, 17:29:43

Previous topic - Next topic

spsn

I have managed to get LWJGL 2.8.4 to build and run on the Raspberry Pi.  In this github repository (https://github.com/spsn/lwjgl) you will find 2 archives with jars and libraries that you may use to build and run your applications on the Raspberry Pi; one for soft float (armel) and one for hard float (armhf).  The repository also contains helpful information for getting the Raspberry Pi set up to build LWJGL and the set of files that needed changing to use dispmanx on the Raspberry Pi to create the rendering surface.

For a demo of JWJGL for Raspberry Pi in action, have a look here: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=22341

Matzon

nice work, thats not a lot of changes to get it to work on the raspberry pi?
nice job on the Blocky too!

princec


kappa

Now with an official JDK that supports hard floats coming out, I'd say we should think about merging the LWJGL PI modifications into the main repo (looks like very few changes).

Even if we don't provide official PI builds, would be nice to have an option to compile for the PI straight from the main source.

rupy

I think official builds would be nice, is it too much work to maintain? Also will a Oculus Rift lib make it into lwjgl?

https://developer.oculusvr.com/forums/viewtopic.php?f=20&t=255

"It's like Homeworld in first person."

rupy

Sorry to wake this old lady up, but I did some wondering: Are the direct rendering routines present on mobile GPUs but just hidden by the OpenGL ES implementation? Or are the glBegin glEnd etc actually not there at all on the GPU? Because linear algebra is linear algebra, somewhere the logic to draw a triangle exists!

Basically porting my OpenGL 1.0 game to Android is a horrible mess, OpenAL is gone and OpenGL requires buffers... why? No backwards compatibility is really bad, specially when you remove the lower level methods!?

I also draw each triangle to morph the models in real time, to do that with OpenGL 2.0> I have to recruit some designer and build a huuuuge toolchain... programmer art FTW!

Can we interface with Mesa3D on the raspberry pi for example to reach direct rendering?

"It's like Homeworld in first person."

Cornix

The old functionality does not exist on mobile hardware. This is because these functions are horribly slow and memory inefficient. It would be too costly to implement these functions in mobile hardware with its limited space and resources. Furthermore since the performance would be abyssmal on the lower tier hardware it wouldnt be used anyway.

rupy

Ok, but that's not true, direct rendering with draw lists is really fast.

"It's like Homeworld in first person."

abcdef

On modern hardware the GPU will convert your display list code in to a VBO so what you think is a display list is actually a VBO. The GPU knows the best ways to create VBO's so it may seem fast but you can't get away from the fact that VBO's are being used regardless.

Also the fixed pipe line api has been deprecated for a long while now which is why GLES did not support it from the get go, no backwards compatibility was the best thing they could have done.

Also Openal is not gone on android, it was never there

QuoteI also draw each triangle to morph the models in real time, to do that with OpenGL 2.0> I have to recruit some designer and build a huuuuge toolchain... programmer art FTW!

Rubbish! I used to do fixed pipe line and converted over to modern opengl. My morph classes didn't change a single bit, I just changed the classes that used the new morph data. When you full understand opengl 2.0+ you will see how much easier you can do things. The shift mentally is quite a large leap but once you are there you will understand why its better. Stick with it :)

rupy

So again necro, but now it seems we have a driver for desktop OpenGL on RaspberryPi, doesen't that open up for all sorts of fun? See this post in particular about LWJGL: https://www.raspberrypi.org/forums/viewtopic.php?p=804047#p804047

How about a desktop OpenGL LWJGL build for the Rpi now?

Quote from: abcdef on March 03, 2015, 06:36:08
no backwards compatibility was the best thing they could have done.

I couldn't agree more, but how do you draw a triangle with less than 3 lines in OpenGL ES?

My game looks like this btw: http://aeonalpha.com if your curious to why the resistance.

Quote from: abcdef on March 03, 2015, 06:36:08
Rubbish! I used to do fixed pipe line and converted over to modern opengl. My morph classes didn't change a single bit, I just changed the classes that used the new morph data. When you full understand opengl 2.0+ you will see how much easier you can do things. The shift mentally is quite a large leap but once you are there you will understand why its better. Stick with it :)

I trust you are right, but I'm an old dog, can't learn to sit properly.

"It's like Homeworld in first person."

spasi

Quote from: rupy on August 17, 2015, 23:35:00So again necro, but now it seems we have a driver for desktop OpenGL on RaspberryPi, doesen't that open up for all sorts of fun? See this post in particular about LWJGL: https://www.raspberrypi.org/forums/viewtopic.php?p=804047#p804047

How about a desktop OpenGL LWJGL build for the Rpi now?

ARM support is not a priority right now. If you would like to help, getting Travis CI to cross-compile for armhf would be a big step forward. This includes LWJGL itself and all its dependencies. Instructions:

- Fork one of the LWJGL CI repositories. (easiest-to-hardest to get working: jemalloc/libffi -> openal-soft -> glfw -> lwjgl3)
- Create a linux-armhf branch
- Edit .travis.yml to remove the security tokens and the awscli stuff.
- Edit .travis.yml to propertly enable armhf cross-compilation (this is what I need help with)
- Go to https://travis-ci.org: create an account -> Github sync -> enable the forked repository

If you could get one working, I can probably handle the rest and do any necessary changes to LWJGL itself to support the new architecture.

rupy

I'm afraid all of those are way above my head. I code LWJGL because it's Java! ;)

But I understand that you have your work cut out for you, if you somehow get this up and running and my game runs at some kind of framerate on RPi 2 I will build a RPi VR head mount (wearality lenses, RPi 3?! compute module and Rift/Vive screens!) and open source my game engine! :)

"It's like Homeworld in first person."

rupy


"It's like Homeworld in first person."

rupy

There, now the OpenGL driver is in raspbian:

https://www.raspberrypi.org/blog/#another-new-raspbian-release
https://www.youtube.com/watch?v=lg2SikcRDZs

Maybe LWJGL should consider a port?

You could wait until the driver is tested and becomes the default I guess?

"It's like Homeworld in first person."

rupy

RPi 3 coming monday, apparently 64-bit possibly ARM8 which would do a lot for performance.

Still no go for LWJGL on RPi?

"It's like Homeworld in first person."