Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Display res..at last
#1
Raspberry's (though not the 4) have a very nice trick where you can set the size of your EGL buffer to be half, or quarter the size of your resolution and the display will zoom it to the full size of the screen.
This is handy because rendering a full 1080p screen is just ever so slightly beyond the power levels of most of our standard GPU's. But half size is quite possible. 


But I've never been able to do that on standard X11 systems, which has meant running them in windows, or just letting them fail to keep up the frame rate for their generally poor GPU's
I always set the Raspberrys to render at half scale and draw via zoom to full. Sadly I can't do that with the RPi4 since I'm using X11 to render..and at full res even that does struggle to keep the same frame rate as the 3B/B+. I could just render to a same size window but games really need a full screen display.

But today as I was tinkering, (literally, on a tinkerboard) I had a brainwave...Instead of trying to replicate the antics of a Raspberry, which does not seem to be viable, just change the res of the screen, when the game starts up... Now I didn't actually know how to do that, in code, but a bit of googling found that there is a nice library libxrandr-dev that gives you the ability to interrogate and SET the res..
I found this on stackoverflow which explains it really well
https://stackoverflow.com/questions/1138...-and-linux

The only issue  here is that it does not make it clear you need to have libxrandr-dev in place before you try to build, using
sudo apt-get install libxrandr-dev and of course reference them in your build config

I've tried this now on a few of the lesser non raspberry linux systems and the method works on all so far, and even dropping the res down on the really low end systems makes them all viable dev platforms.. I'll incorporate a change res function into the graphics files and provide a demo soon. But this is a very nice solution to a long standing problem which will make it easier to compare Raspberry and non Raspberry systems by levelling the playing field as far as their renderbuffers are concerned.

I also tried it on the Raspberry 4, and of course it has to be different, yup I can change the res, but strangely the performance is still poor on the test projects at 720, only picking up at sub par resolutions like 800x600, I really don't think the drivers are fully mature yet, but at least I can alter resolutions to suit the abilitiy of the target, thats a big step.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply
#2
As a follow up, some months later, I think I found the issue with regard to Pi4 speed. Anti aliasing on the Pi4 is painfully slow, especialy using OpenGLES3.0 (though I don't understand why) removing the sampling buffers from the EGL config brings the frame rate back up. still not quite capalbe of doing a 1080 project at 60hz, but all the other res's can maintain the 60hz, though that might change if you push a lot of poly's in a bad way. Of course AA is quite useful if you are using a low res...but really you have to make a decision on what works for you.

Trial and error found this, but I wish I could explain why.

I am also trying to find out if there is a faster compositor than X11 which, though universal (mostly), is again apparently slow on Pi4.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's 



Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)