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.
Reply-To: "Geraldo Sazias"
From: "Geraldo Sazias"
References: <3D8EC516.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
Subject: Re: Simple Graphic Processors?
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
Date: Wed, 25 Sep 2002 10:37:43 GMT
NNTP-Posting-Date: Wed, 25 Sep 2002 12:37:43 MEST
"Lewin A.R.W. Edwards" wrote in message
> "Geraldo Sazias" wrote in message
> > > 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
> 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
> > graphics by way of writing them to the LCD bytewise? I think that's
> > too slow for my application as I'm trying to design a portable gaming
> > device.
> 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
> Commodore 64.
> 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.
Yes, I think you're right. Quick calculation: 320 x 240 x 2 (i.e. 16 bit
color) = 153.600 bytes per frame x 25 fps = 3.840.000 bytes / sec, which is
about 4Mhz computing power of 74Mhz power available for an ARM or about 6%.
OTOH the SW still has to render the frame by blitting in memory to a frame
buffer, which takes up another couple of percent (the 'blitting' can be done
with 32-bits so it's probably going to be less than 5% overhead). That still
leaves 90% of the processor power for game-logic and the like.
Thanks for the advice, I'll think it over.
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup