The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: firstname.lastname@example.org (Lewin A.R.W. Edwards)
Subject: Re: Simple Graphic Processors?
Date: 24 Sep 2002 08:58:50 -0700
References: <3D8EC516.email@example.com> <firstname.lastname@example.org>
NNTP-Posting-Date: 24 Sep 2002 15:58:50 GMT
"Geraldo Sazias" wrote in message news:...
> > The ability to detect the end of a frame is essential, but hardware
> > blit assistance is absolutely not.
> Are you using a graphical LCD with a 'dumb' controller (such as SED1530)?
Yes. In one case, a Winbond W9971 (it has some simple hardware
assistance, but I'm not using any of it). In another case, a SED1355.
In a third case, I am using a dumb framebuffer integrated into the
Geode chipset. In a fourth case, I am using the dumb single-page,
no-hardware-assist LCD controller in the Cirrus CL-EP7312.
> So the framebuffer is simply located in physical memory and you transfer the
> graphics by way of writing them to the LCD bytewise? I think that's probably
> too slow for my application as I'm trying to design a portable gaming
It's adequate for full-screen MPEG-1 video playback and animated
"screensaver" type code that closely resembles a game, so it's more
than adequate for most 2D gaming applications. I think you should
study the problem a little more closely, in particular examine the
techniques used for 2D gaming developed on blitterless 16-bit
platforms like the Atari ST, and also some 8-bit platforms such as the
Also look at the design tradeoffs that have been made in similar
consumer appliances on the market. For sprite-based 2D gaming, the
normal hardware assistance that is provided is an on-chip tile-based
character generator (actually usually more than one, for multiple
layers of parallax-scrollable playfield), and hardware sprite
generators for characters and bullets. Hardware blitters are not
normally found in this application. Using tiles and sprites you can
obtain a satisfying gameplay experience, including audio, with a
single 8-bit main microcontroller (perfect example: Gameboy and
Gameboy Color). This minimizes overall system cost and power
consumption. In such a system, the bulk graphics data is never
normally in the processor's address space. The CPU only manipulates a
relatively small matrix of color attribute bytes and tile bytes, and a
couple of smooth-scroll registers. The tile and attribute RAM is DMA'd
by the tile and sprite hardware, which uses the information as
pointers into graphics ROM.
If you are using a 32-bit core like ARM, the tile and sprite hardware
is not necessary to achieve an enjoyable gaming experience. On a 74MHz
ARM7 core with a 320x240x8bpp display* it is perfectly possible to
have an entire playfield generated offscreen (double-buffering)
including a large number of sprites and at least two or three layers
of tiled playfield. In such a system you're effectively emulating tile
and sprite hardware using software. I wrote a lot of such code (an
"emulator" for a nonexistent piece of coin-op arcade hardware) on the
Macintosh. Again, simple dumb linear framebuffer code with no hardware
page-flipping or blitting of any kind. You generate the frame into an
offscreen buffer, wait for end of physical frame display, then
(software-)blit the new frame onto the live framebuffer.
* - This becomes a pain in the ass with certain display modes, however
- 12bpp in particular.
For 3D gaming, you are really out of the realm of 8-bit and preferably
hardware assistance should be available.
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup