Misc questions, graphics and games

[msx80]

Hi there, i finally got around and found the time to try out ultibo and i'm pretty impressed by what i saw, congrats to you guys! Things just work at first try without hassle.
I have some misc questions, i hope it's ok if i ask everything here in the same topic. I'm mostly hacking the OpenglEs example.

• First off, is there a way to send programs to the board without removing the sd card, putting it in the computer and then putting it back on the RPI? The debug cycle take forever this way.
  
• I would like to embed lua into my program. Has anybody managed to integrate lua in an ultibo project? I saw a topic talking about this but was not conclusive. I reckon it shoulnd't be that hard.
  
• I've set up a console in CONSOLE_POSITION_FULLSCREEN, with black background, but still see a white border all around the screen. How can i remove it? There's a property on the object returned by ConsoleDeviceGetDefault but it doesn't seem to work.
  
• I've verified that the screen starts at a resolution of something like 1920×1080 (not sure they're the exact values but close). Where is this set up? Can it be easily changed?
  
• I noticed that in the openGl example there's no FPS throttling, so i was wondering how the demo limits the FPS. Is it just running full speed or there's some call i missed? Perhaps the eglSwapBuffers also does a sync with the screen? 2° questions: is there some code to calculate and limit FPS already in the codebase?
  
• I can't seem to find support for USB Gamepad. I missed it or is it not available? Generic gamepad shouldn't be much harder than keyboards or mouse to handle.

Ok that's all for now. What i'd like to create is something like TIC-80, but running directly on the board (a raspberry PI zero) in baremetal (I guess that a physical fantasy console is just a console). I'm having a lot of fun with TIC-80, it has integrated editor and developing on it is a pleasure. Having a specific board with zero start time would be awesome, i think

[Gavinmc42]

For testing graphics coding I use a Zero plugged into a USB port on a Linux PC.
https://github.com/raspberrypi/usbboot

Scripting languages have been discussed, a search will find them.
http://luapascal.luaforge.net/
I think Pascalscript is the closest to working?

Initprog or initunit is unit that gets called first so a console framebuffer is not setup.
viewtopic.php?f=15&t=1156&p=7652&hilit=init#p7652
Then OpenVG, video, camera etc don't write over the default console screen.

Screen size is auto, but can be overwritten even to having a virtual 4K screen.

OpenGL is still new to me, requires Eric Anholts driver in Linux.
We only have the normal VC4 OpenGLES/VG stuff at the moment.
As OpenGL is a layer over OpenGLES perhaps one day it could work?
FPS? someone else might know?

USB support is still limited?
viewtopic.php?f=12&t=1027&p=6858&hilit=gamepad#p6858
Hmm I found I got a bluetooth gamepad to test this ages ago, now that bluetooth is more advanced perhaps?

We are messing around with Microbits now and they could be turned into a Wii type controller?

This could do both?
https://www.adafruit.com/product/3205

TIC80 could be emulated?
Zero with tiny LCD? Zero with TV output?

[Ultibo]

Hi,

First off, is there a way to send programs to the board without removing the sd card, putting it in the computer and then putting it back on the RPI? The debug cycle take forever this way.

This one has been asked a few times, go to the Forum Quick Reference and check out the Updating and deploying applications section at the bottom.

In addition to those methods there is also an FTP server available which can be found here.

I would like to embed lua into my program. Has anybody managed to integrate lua in an ultibo project? I saw a topic talking about this but was not conclusive. I reckon it shoulnd't be that hard.

See my answer in your other post.

I've set up a console in CONSOLE_POSITION_FULLSCREEN, with black background, but still see a white border all around the screen. How can i remove it? There's a property on the object returned by ConsoleDeviceGetDefault but it doesn't seem to work.

Add an InitUnit to your program as demonstrated in some of the examples (like the Sensormatic3000 example) and put the following line in it:

Code: Select all

 CONSOLE_DEFAULT_BORDERCOLOR := COLOR_BLACK;


I've verified that the screen starts at a resolution of something like 1920×1080 (not sure they're the exact values but close). Where is this set up? Can it be easily changed?

The default screen resolution is detected from the GPU during startup but can be changed via a number of methods.

The Bouncing Boxes example demonstrates how to change the settings of the framebuffer, while that example changes the bit depth you can keep that unchanged and simply modify the width and height instead.

It is also possible to use the InitUnit technique to override the default width and height during boot.

I noticed that in the openGl example there's no FPS throttling, so i was wondering how the demo limits the FPS. Is it just running full speed or there's some call i missed? Perhaps the eglSwapBuffers also does a sync with the screen? 2° questions: is there some code to calculate and limit FPS already in the codebase?

As far as I know eglSwapBuffers waits for vertical sync to switch frames which limits the FPS to the refresh rate of the current screen.

The Asphyre examples also demonstrate a method of timing the refresh rate that you might be able to make use of.

I can't seem to find support for USB Gamepad. I missed it or is it not available? Generic gamepad shouldn't be much harder than keyboards or mouse to handle.[/list]

We'd like to add USB gamepad support but we don't actually have one (does it surprise anyone we are not gamers?) but you can help to move it along if you are interested.

The reason why mouse and keyboard work out of the box is because we use the USB Boot mode for both of them, in order to support other input devices we need to get HID mode support working and we've recently been doing some experimentation with the information needed to do that.

In this thread we posted a small test program to obtain the HID descriptors from a device, if you want to obtain those from your gamepad and supply them to us we can use that information to compare with others and get closer to having a universal gamepad driver available.

You should note that from our understanding the Xbox 360 controller does not conform to the same specification as most other gamepad devices and so will likely not be supported by a universal driver.

[pik33]

[*] First off, is there a way to send programs to the board without removing the sd card, putting it in the computer and then putting it back on the RPI? The debug cycle take forever this way.

There are several ways to do this as it was mentioned. My way to do this is having Ultibo/Lazarus installed on the same Raspberry Pi, and then using shell script to copy and run Ultibo program. The program has to have several lines added, which then will restore Linux kernel so after reboot I am again in Raspbian and I can continue developing without swapping SD card.

[*] I've verified that the screen starts at a resolution of something like 1920×1080 (not sure they're the exact values but close). Where is this set up? Can it be easily changed?

There is config.txt file. If there is no resolution set in there, the RPi tries to determine the optimal resolution from the monitor. If there is any resolution entry in config.txt then you will get what you have written (including a mode which the monitor cannot display)
The framebuffer resolution is independent from video resolution, the RPi has a video scaler which will scale your fb to your screen (so you can declare a 320x200 framebuffer for an emulator ad the RPi will rescale it to your monitor resolution)

[*] I noticed that in the openGl example there's no FPS throttling, so i was wondering how the demo limits the FPS. Is it just running full speed or there's some call i missed? Perhaps the eglSwapBuffers also does a sync with the screen? 2° questions: is there some code to calculate and limit FPS already in the codebase?

There is a function FramebufferDeviceWaitSync which waits vor vsync.

[msx80]

Thanks everybody!

Sorry if it sound stupid, but the screen only have one resolution, or the framebuffer can have different resolution than opengl etc (DispManX is new to me)? Anyway, i'm mostly interested in OpenGL.

About updating and deploying, i'll try some methods but i have a zero w without network adapter. I understand wifi is not usable yet, will an usb network adapter work ?

We'd like to add USB gamepad support but we don't actually have one (does it surprise anyone we are not gamers?) but you can help to move it along if you are interested.

The reason why mouse and keyboard work out of the box is because we use the USB Boot mode for both of them, in order to support other input devices we need to get HID mode support working and we've recently been doing some experimentation with the information needed to do that.

In this thread we posted a small test program to obtain the HID descriptors from a device, if you want to obtain those from your gamepad and supply them to us we can use that information to compare with others and get closer to having a universal gamepad driver available.

You should note that from our understanding the Xbox 360 controller does not conform to the same specification as most other gamepad devices and so will likely not be supported by a universal driver.

Great! I'll try the HID program asap.

[pik33]

The screen can have any resolution you want and this is what you write in config.txt or - if not - read from the monitor while rpi starts - or else falback to 640x480
This is what the video core sends to your monitor. The normal situation is - there is nothing in config.txt and then the RPi uses the native resolution of your monitor. (eg. 1920x1080)

Then there is a framebuffer. Its size is independent from the screen and it can have any (up to 3840x2400) resolution you want. Then it can be (and normally is) resized automatically by HVS (hardware video scaler) in RPi to your screen size.

OpenGL uses a dispmanx layer, which is the same type object as the normal framebuffer and it is displayed over (or under, this can be defined) the main framebuffer and it also can be resized by the HVS

Dispmanx is a library which controls the low level video objects. You can declare graphic objects (layers) and then tell the dispmanx where and in which order they have to be displayed and how they have to be scaled. The main framebuffer is one of the dispmanx layers, the opengl stuff is displayed on another one. You can use them to create sprites, mouse cursor, etc.

[Ultibo]

About updating and deploying, i'll try some methods but i have a zero w without network adapter. I understand wifi is not usable yet, will an usb network adapter work ?

If you are using a Zero W then another option you might want to try is the USB boot mode that is built into the SoC and firmware, have a look at the USB Boot tool which can be built for either Windows or Linux.

This can be used in two different ways, first you can use it to boot the Pi Zero using your Ultibo generated image directly from the USB port of a host PC (so you don't even need to copy the image). And second it comes with a special version of the firmware which makes the Pi act as a Mass Storage Device (MSD) or a USB drive so you can simply copy files to and from the SD over the USB.

Sorry if it sound stupid, but the screen only have one resolution, or the framebuffer can have different resolution than opengl etc (DispManX is new to me)? Anyway, i'm mostly interested in OpenGL.

As pik33 points out you have a lot of options available, if you are mostly looking at OpenGL then in the GLESInit function of the HelloGLES example you will see a call to BCMHostGraphicsGetDisplaySize which is used to determine the default screen size as calculated by the firmware from the HDMI information.

This size is then used to pass to DispmanX and EGL to setup the display size but you can actually pass other sizes as well and setup the display in many different ways, you can even setup the framebuffer as one size (eg 800 x 600) and the OpenGL window as a completely different size (eg 1920 x 1080) and the hardware will scale and composite it all together for you.

You should also note that there is both physical size (ie the size displayed on screen) and virtual size so you can do things like panning and scrolling etc.

Best way to understand how it all fits together is to experiment a little and see what the different results are.