User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Using the least memory

Tue Aug 07, 2012 2:24 am

I don't fully understand the coding interface to VG or GLES. There are many unexplained ideas, and the code to just get to the point of having a drawing surface is excessive bloat for all programs to have a copy linked in. I suppose the VG idea is a bit of a gimmick, as GL has had 2D since the days of Sun SPARC stations. Maybe it's something new but I'm just not seeing it. Talk about making a MESA GL.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Tue Aug 07, 2012 3:20 am

It looks like mmaping /dev/fb0 is the easy way to get full graphics bitmap access. VG and GL wil have to be for a later day when the libraries become sane.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
kulminaator
Posts: 23
Joined: Mon Aug 06, 2012 8:55 am
Location: estonia

Re: Using the least memory

Tue Aug 07, 2012 5:54 am

The only point to OpenGLES and OpenVG usage is hardware acceleration. You will never draw stuff into the framebuffer with the same speed on the raspberry pi's cpu "power". Running the omxplayer vs mplayer fbdev on an mpeg4 file is probably the best example of performance difference.

And i sort of tend to agree on the OpenVG part, it doesn't seem to have much point to it, i don't see it being more userfriendly or offering anything that you can't already achieve with OpenGL(ES).

I have my hopes high for DirectFB still, which would combine the best of the two worlds for me (pretty okayisch usage interface and hw acceleration at the same time), just seems a bit complicated to get on that wagon right now.

blu
Posts: 55
Joined: Tue Jul 17, 2012 9:57 pm

Re: Using the least memory

Wed Aug 08, 2012 1:53 pm

Both ES2 and VG have their definitive advantages over many other APIs, let alone 'direct access to fb0'. I really suggest you to start from here: http://nehe.gamedev.net/ (right-hand side column: Mobile Tutorials). Also, you can use the following API reference cards:

http://www.khronos.org/opengles/sdk/2.0 ... e-card.pdf (ES2)
http://www.khronos.org/files/openvg-qui ... e-card.pdf (VG)
http://www.khronos.org/files/egl-1-4-qu ... e-card.pdf (EGL)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23338
Joined: Sat Jul 30, 2011 7:41 pm

Re: Using the least memory

Wed Aug 08, 2012 2:00 pm

jackokring wrote:It looks like mmaping /dev/fb0 is the easy way to get full graphics bitmap access. VG and GL wil have to be for a later day when the libraries become sane.
See Blu's posts above for detail - but the libraries already ARE sane - they implement the standard Khronos OpenVG and OpenGLES interfaces. They are complicated because the case they need to do is, indeed, complicated.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

User avatar
ajstarks
Posts: 129
Joined: Fri Jun 22, 2012 2:14 am

Re: Using the least memory

Fri Aug 10, 2012 2:39 am

Here's a high-level API on top of OpenVG: http://github.com/ajstarks/openvg.

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Fri Aug 10, 2012 5:53 am

I understand they are very generally useful, but specifically, glInitViewportFullScreen should be a function, along with maybe glVeiwportScaleQuad. And the vec3 should display, passed as a parameter. Making it green later with hidden surfaces and moving shadowed specular comes later. The whole have to copy A4 just to get a model which is probly copied too, a bit later because the meaning of the code to 'ello wold' s ..... fiddling with a model is the best way to learn how to code displaying models, not scroll through hundreds of lines of code. The scaling of a square to a quad under prospective, for a texture map, does make squares/quads a more natural polygon to model in. I assume the quads of a modelled entity can one to one map to a texture square, and so the actual texture bitmap may benefit from a re-oder to quad rasterization order.

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Fri Aug 10, 2012 6:23 am

Even though I know not the command set yet, my old Java majiki library which I've since not got to hand, would see 3D transformation of a texture as bad, as twisting a texture pixel around z only has meaning because of the square nature of pixels. So a blend blit of a faded fractal with a delta z buffer without z rotation and a virtual radius/size depending on distance. Altering the apparent size depending on the edge on effect of x or y rotation, just changes the radius/size of the circle placed in the quad centre. In this way the specular and defuse calculation could do the radius scaling too.

Just wondering how to implement expand by vertex doubling as the distance to object halves.

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Fri Aug 10, 2012 5:29 pm

So after a quick flick through the quick reference cards. A GL render goes like this:

1) Rotate and translate the vertex list
2) Remove hidden surfaces, to make the quad polygon list
3) Render a black and white luminosity phong quad set to a temp buffer with light at viewpoint
4) Use the visible rendered quad2D quad list to make a unit square texture to quad transform set
4) Apply translation and skew (2D) to texture/colour to blend texture pels with luminosity map

Works if all light sources are white, and no shadows are needed. Collision detect based on bounding radii. Improvements such as light hidden/shadowed-by-z-buffer quad lists, and blending light colour or shadow if not visible from light, only need a recalculation if a light moves, by a re-use of process 3 with another 2D rendered raster surface which is not displayed directly.

Maybe slight simplicities such as using a constant viewpoint direction vector, even for close off to the side objects, so making slightly off but faster lighting renders.

So for a simple library, having:

Mode 1: black and white render with light source from viewpoint.
Mode 2: Add texture/colour to a quad set using pixels blocks and quad numbering. As many textures as the hardware can handle can be overlaid, using different blend modes.
Mode 3: Create another mode 1 projection and map it back to a lighting texture, and apply using mode 2.
Mode 4: Provide resolution scaling so small buffer renders can be expanded, dithered and Gaussian filtered to a higher resolution. This means mode 1 does not have to do anti-alias blending on a z-buffer, and even good 1080p renders can be done with a 260p render buffer.

In the sense that people need to spend time making models, and less time writing 'the wheel', a mode 5 concession is to use a hand coded replacement for the black and white Phong shader, and a replacement for the scale image larger mode 4 function, with null implying use default.

These 5 mode functions, are enough, and functions to build the vertex and quad arrays are the only others needed for learning to model 3D.

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Fri Aug 10, 2012 11:04 pm

Let's call it the unwheel£D engine. Having the lowest function name remember foot print, it could be on. I think the vertex group mapping functions would form the bulk of the function space. After all the moving things within the 3D space are the only reason for the model. :lol:

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Sat Aug 11, 2012 1:17 am

Of course textures would be part of wheel2D. The scaling function mode 5 could be part of this too. The raster surfaces of the 3D being 2D. Maybe using 3D co-ordinates for the 2D makes the z-buffer window overlay better. Maybe turn off the parallax on the 2D windows? No? Maybe a nice function to pad a 3D vertex group structure with a constant z. Maybe adding the build vertex group from font and string is a complicated function. A fixed width console font, and y axis twist kerning?

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: Using the least memory

Sat Aug 11, 2012 2:11 am

For best use a text mode serial tty driver would have to be made, and a mingetty (or such) line added to start up. This would on command switch on and off 3D text console mode on the main display surface. So texture font RAM, can be used to make text modes, and they do exist. It maybe a more complex indexing and blit of the characters, but that's beside the point. Should the display 'print' command have an output of a vertex group object for easy motion, and better display formatting options? This is opposed to just using the 'shown' variable, which can have no return value.

I'm unlikely to write most of this, but feel free to steal any of this output pattern. Now for some input design... 8-) ... Just to note though, a lot of input echoes back to an output, and also sometimes an input with echo and another output are pair connected. Most chat programs use this idea, to record input in context, not serial merge splurge order.

Cheers Jacko
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

Return to “Graphics programming”