Anything and everything about programming graphics with Ultibo
Posts: 1003
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Screenshot

Postby Gavinmc42 » Fri May 19, 2017 7:20 am

Screenshot in reverse, drawing bitmaps to screen on a B+.

Just for fun I grabbed 5 of my povray generated eyeball png images from C:\images.
I used fpimage to convert from pngs to bitmaps on the D: ramdrive

Code: Select all

 while True do
             DrawBitmap(Handle, 'D:\eyeball01.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball02.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball03.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball04.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball05.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball04.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball02.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball02.bmp', 30 ,30 );
             DrawBitmap(Handle, 'D:\eyeball01.bmp', 30 ,30 );

I originally had sleep(50) between but the drawing bitmaps was slow and a bit jerky anyway.
To give smooth animation it probably has to be 3-5 times faster on the 320x240 images?
Could it go faster if it was a stream and not fetching from a ram drive?

Hmm where my Pi3 and Ron's streaming example?
Not too bad on an old Pi2. Pi3 is missing.

I would say at 320x240 swapping bitmaps from a ram drive is one way to animate on a Pi 3.
Storing them as png and then converting to bmp takes a small amount of time on booting.

Would animated png be faster?
Posts: 576
Joined: Fri Sep 30, 2016 6:30 pm
Location: Poland

Re: Screenshot

Postby pik33 » Fri May 19, 2017 7:16 pm

If you want fast animation, do not use complex structures, ramdisks, libraries, etc, while animating as they need to be serviced and this takes time. Use these tools only to load the pictures and to prepare them to animation.

First, convert your bitmaps to simple 2-d arrays of pixels in the same pixel format as is used in your framebuffer so they don't need to be converted while animating - only moved.

Then write a fast procedure to move your pixels to your framebuffer. Fast means (1) asm or (2) DMA. Asm procedure can move full 1920x1200x32bit screen in time, it means ~10 ms on RPi3. DMA can do it in about 4 ms.

To avoid flickering, declare a virtual framebuffer 2x taller than your screen. While the first half is displaying, you can fill the second half with new pixels. This kind of algorithm is used in Ultibo moving boxes demo. I use it in the retromachine, too. The procedure looks like this:

Code: Select all


//(initalization here)

until terminated;

Posts: 1003
Joined: Sun Jun 05, 2016 12:38 pm
Location: Brisbane, Australia

Re: Screenshot

Postby Gavinmc42 » Fri May 19, 2017 11:12 pm

Thanks pik33,
I grasp the concept but lack the skills.
But if you want to add images to your windowing code, go for it :lol:

I am exploring the green boxes and doing rough bench marks at the moment.
What can be done with Ultibo and the existing units.
I picked 320x240 because it is a common small LCD size.
There is a fbtft library out there now that uses hardware scrolling and checks for pixel changes and only writes them.
Next step is to try this on an LCD.

The fact that even I can get animations just by playing with drives and files is a good sign.
I am thinking about Ultibo beginners, someone moving up from Arduino.

I'm still a long way from asm and DMA fb which will be needed for the large resolutions.
Pascal can have inline assembly code which means this could just be another unit.
Beginners could then have full screen animation without needing to know assembler.

The standard Ultibo framebuffer stuff could be extended to include all this too.
So many ways to do things, with nearly no restrictions or OS getting in the way.

Learning image formats etc is a bit of a pain.
We know jpeg could be accelerated by using the VC4, wonder if png decoding could be done on the VC4 too?
Yuk, VC4 assembler :lol:
Hmm, zlib on VC4 could be a useful unit.

Anything we can do now can be made better or faster as we understand and use the VC4 more.
Since I don't know how to use the VC4 I am learning what we already have.

Hmm, png to bmp to fb, then take screenshots to a buffer then play buffer back.
Since I know how to take virtual screenshots even I might be able to figure this out :P
Going to take lots of memory but it should be fast.

It could even be scaled automatically at the png to bmp stage for any size playback screen.
For best looking images a vector format like SVG to bitmap to fb?
Some games now are using vector based core images scaled to displays.
Vector images will make great GUI's too.
SVG/CSS to bitmap to fb, eventually/optionally skipping bitmap stage and draw direct to fb.

Time to try fpgui?
Got the basic stuff already in graphic console drawline etc. but that's a different post.
GraphicsWindowDrawImage? that might be useful?
GraphicsWindowImageFromStream 8-)
So much stuff is already there.

Just had a thought, could have a near sighted eyeball that tracks movement by using one of those cheap gesture sensors.
So many out there now. ... rboard.pdf

Return to “Graphics”

Who is online

Users browsing this forum: No registered users and 1 guest