Re: fbcon

[Magnus Norddahl <mbn@dark.x.dtu.dk>]

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

> >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.

Most modern games uses a set of images to draw its grapichs. A 2D football
game for instance has some images of the football players turning in
different directions; the playing field itself are also often assembled from
at set of images. Other examples include fonts and such. Such images are in
game development usually called sprites or surfaces.

There are two reasons to divide all the graphics into surfaces:

1. You save memory. If you didn't store the playing field in a soccer game
as sprites, you'd use much more memory describing the level.

2. Speed. All modern gfx cards can store the surfaces in videomemory and
draw them to the screen with using the CPU. Since gfx cards have chips that
are specially optimized to do this, it is _much_ faster than the CPU.

> 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.

Well, I haven't really used fbcon - only took a quick "tour" on the XFree86
pages.

> 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?

Yes, this is the official way to do it when using fbcon. It isn't as fast as
hardware flipping - but it will do the trick for most 3D games.

The reason why fbcon is good enough for 3D games is because everything is
redrawn in every frame.

--
Magnus Norddahl
ClanSoft