Re: fbcon

[Brett_A._Letner@notes.up.com]

Being new to game development (and graphics) I am not familiar with most of
these issues.  I'll just add my comments from a newbie's point of view and
hopefully you (and others) can fill in the gaps.  Please note that I am not
at all familiar with fbcon and posted the request in hopes that someone
else could give insight.

>>Quoting Brett_A._Letner@notes.up.com (Brett_A._Letner@notes.up.com):

>> Has anyone on this list looked into programming for fbcon, the frame
buffer
>> console, that has been added to the Linux development kernels?  I
believe
>> it will allow you to do graphics directly on the console (instead of
using
>> X, svgalib,...)

>Yes, it will allow access to the frame buffer - but that doesn't really
>solve a lot of our problems.

>A few examples:

>1. How do you create hardware accelerated surfaces with it?

I don't know what a hardware accelerated surface is.

>2. Do you have any backbuffer to avoid flickering. I'm not thinking about
a
>   backbuffer stored in software memory - I want hardware accelerated
>   flipping.

I was planning on setting the xres_virtual field of fb_var_screeninfo to
double that of the xres field.  Then I was going to either change the
xoffset field or do a FBIOPAN_DISPLAY ioctl to achieve page flipping.  Is
this correct?  Is it fast?  I don't know.

>3. How about some hardware accelerated system memory -> video memory
>   blitting? That isn't possible either with the frame buffer.

I was planning on mmap-ing the video memory to system memory and then doing
memcpy's to it.  I've never used mmap though, does this make sense?  Is it
too slow?

>Remember that all non-3D games use 99% surfaces and 1% direct access to
the
>framebuffer. If you want fast games - you'll have to deliver hw
accelerated
>surfaces...

Please explain this.  I'm planning on writing a 2-D action football game
and I don't want to head down the wrong path.

>--
>Magnus Norddahl
>ClanSoft

Thanks for your time and help,
Brett