Re: Re: stk and the Dreamcast

Mike Melanson <[email protected]> Tue, 22 Jul 2003 17:23:31 -0600 (MDT)
Newsgroups gmane.comp.embedded.stk.gui.devel
Message-ID <[email protected]>
On 22 Jul 2003, Darren Vincent Hart wrote:

> Exactly.  So what features do you have in hardware that you want to
> excellerate?  blit probably, fill_rect maybe?  Those are the ones you
> will want to implement in the surface_dreamcast class.  The surface
> class model is a bit confusing at first glance, but the templated

	draw_/fill_rect() and draw_/fill_poly() are some of the most
obvious choices. For extra coolness on the rectangle side, the class could
plot an 8x8 texture into VRAM (RGB565 format, occupies 128 bytes total)
and then tell the graphics chip to stretch it out to any size rectangle
requested. For the _aa function, activate the hardware bilinear
filtering? What color is the rectangle supposed to be filled with? Is that
set by another method in the class?

	How does the draw_text() method work? Is the surface class free to
use any font it wants to?

	Please fill in a few of the holes in the stk::surface
documentation. I would like to start hacking around with it sometime next
week.

> I suggest you model surface_dreamcast after surface_sdl or surface_dfb.

	I hope stk fits into my vision of how my program will operate. I
had the playback engine pretty well prototyped before I threw any
brainstorming at the UI (oops). I've since mapped out how I want all the
UI screens to look. Of course, I want this to be an on-screen display
(OSD) that pops up over the video window which is what dominates the
screen.

	One idea is to let stk do its thing in main system RAM, blit the
thing over to VRAM and display it, transparently, over the video frame.
Display the same UI screen over ever subsequent video frame. Re-render and
re-blit the UI when an event comes in that alters the state of a widget,
changes UI screens, or dismisses the UI altogether. I'm starting to think
that might be the most straightforward solution. That wouldn't provide
much opportunity to use cool hardware features, except DMA from system RAM
-> video RAM, and texture transparency; but oh well. 

	I trust that I can give stk an arbitrarily-sized frame to play
with? It would be nice to give it a 320x240 playground and then scale it
in hardware to 640x480, in order to save memory. By now I am just thinking
out loud...:)

	I'll be thinking about this.

	Thanks...
--
	-Mike Melanson