On 5/31/05, Hamish Marson <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Patrick McNamara wrote: > > > So after more discussion with Timothy, I have done some more work > > on the program to convert a text screen for the card. > > > > Here are the bounds I was working in for this program: > > > > Load/Store architecture Each non memory access takes 5 100MHz > > clocks Existence of a load block that take 20 + n clocks where n > > is the number of 32bit words. Existence of a store block that takes > > 5 + n clocks where n is the number of 32bit words. Indirect > > register access No load immediate instruction > > > > Given those parameters, here is what I got: > > > > 136 instructions 73 registers - this includes some "constant" > > registers needed due to the missing load immediate and scratch > > space used for the character blit ---------- 209 words - still > > under half the available space > > > > Now for the performance: > > > > I unrolled part of the blit loop since it is by far the most > > executed section. The end result is 13.1Hz screen update for 80x50 > > and 13.8Hz screen update for 80x25. The lack in refresh increase > > between 50 line and 25 line is due to the fact that 25 line text > > uses and 8x16 font where 80x50 uses 8x8 so the blit code does > > almost the same amount of work. > > > > Forgive me for being ignorant & only paying half the attention I > should do. > > But the aim of the game is to show a 'text' screen is it not? If so > why are you bothering to essentially redraw the WHOLE text display > every time? Why not allocate a second 'text' buffer area. And a > bitmap. Every x milli-seconds (Or continuously) run through the user > accessable text screen. If the character position is different from > the second buffer, then redraw that character on the bitmap & update > the second (Comparison) copy. If it's not changed, don't bother. > > The attributes can be used to control whether text blinks with a > simple timer... (blink ON/blink OFF). > > Admittedly text screens with LOTS of updates may run slower... But how > often do people run fast moving text displays? > > The display can then simply be the bitmap buffer... Which can use the > same display logic as any other bitmap graphics screen... > > or am I missing something?
You're not missing anything. This is certainly a viable solution. However, this approach does require more complexity and will actually perform more slowly for full-screen updates. But let's say that 10% of the screen is changing a lot and it therefore updates at better than the video framerate... will anyone really notice? A number of years back, I attempted to develop a VGA BIOS for a card that did not have any VGA hardware. One of my solutions was to hang on a timer interrupt and scan the screen (at 18Hz), looking for changes. If a character was found to have changed, I would update it in the graphics display. In this case, since I was using the host CPU, it was very important to minimize the computation time as much as possible. But for OGP, we have a surplus of bandwidth and a CPU (or logic) that is dedicated exclusively to the translation process. It is, therefore, less important that we attempt to optimize for execution time; if we optimize at all, we should optimize for worst-case framerate. But that's just my opinion. :) Also note that this technique doesn't help us at all for VGA graphics modes. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
