[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>> console, that has been added to the Linux development kernels? I
>> it will allow you to do graphics directly on the console (instead of
>> 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
> backbuffer stored in software memory - I want hardware accelerated
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
>Remember that all non-3D games use 99% surfaces and 1% direct access to
>framebuffer. If you want fast games - you'll have to deliver hw
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.
Thanks for your time and help,