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