home *** CD-ROM | disk | FTP | other *** search
/ Executor 2.0 / executorv2.0.iso / pc / linux / extra / docs / maillist / text / archive.96 / text1140.txt < prev    next >
Encoding:
Text File  |  1996-07-25  |  2.7 KB  |  55 lines
  1. >>>>> "GMangen" == GMangen  <gmangen@aol.com> writes:
  2.  
  3.     GMangen> Am I correct to assume that while UniVBE provides
  4.     GMangen> emulation of 2.0 BIOS extensions, it gives no access at
  5.     GMangen> all the the hardware acceleration features of the #9
  6.     GMangen> Video card?  If this is so, would a Win32 version using
  7.     GMangen> DirectDraw when available work with drivers that DO use
  8.     GMangen> all the hardware acceleration available, and would this
  9.     GMangen> in turn lead to even greater graphics performance?
  10.  
  11. VESA's VBE 2.0 standard, which is what UniVBE 5.1a implements, does
  12. not offer any way to access hardware acceleration features.  VESA
  13. recently came out with a new video driver standard, VBE/AF, which
  14. allows programs to use hardware acceleration.  I have not yet seen
  15. this standard, and a version of UniVBE that supports it has not yet
  16. been released.  Consequently, Executor does not yet use VBE/AF and we
  17. do no hardware accelerated graphics under DOS.
  18.  
  19. I have not seen the DirectDraw API, but it seems plausible that it
  20. would provide access to hardware acceleration features.  If it does,
  21. we'll use it.  Executor/svgalib already uses hardware acceleration for
  22. solid rectangle fills, and under X11 we use X calls to fill solid
  23. rectangles in some situations.  Adding hardware acceleration for
  24. bitblts and scrolling wouldn't be hard.  Using hardware acceleration
  25. for diagonal line drawing is a little tricky because we need the
  26. screen result to be pixel-for-pixel identical with what Executor would
  27. draw "by hand".
  28.  
  29.     GMangen> Furthermore (and I know this gets kinda murky) would the
  30.     GMangen> lessened time Executor spends doing graphics overhead
  31.     GMangen> lead to increased performance in other quarters of the
  32.     GMangen> emulations, ie enhanced CPU and math throughput maybe?
  33.  
  34. It depends what Executor is doing.  During the normal CPU and math
  35. Speedometer tests, there aren't really any graphics going on to speak
  36. of so it wouldn't make a difference.  Using hardware acceleration to
  37. support "refresh" mode would help performance across the board when
  38. running in "refresh" mode.
  39.  
  40.     GMangen> Also, the docs, and the mailinglist a while ago, got on
  41.     GMangen> the subject of the rough instruction ratio Executor
  42.     GMangen> encounters going from 68k to x86 code.  I have seen
  43.     GMangen> stated that it is pretty consistently 3:1 but that it was
  44.     GMangen> hoped in going to a certain new kind of dynamic
  45.     GMangen> compilation we could get to maybe 2:1 and I was wondering
  46.     GMangen> if anything more is known about such lofty prospects at
  47.     GMangen> this time.
  48.  
  49. I've been too busy working on Executor 2 related things to go back to
  50. hacking on CPU emulation.  It's a bit of a shame; once Executor 2 is
  51. out I should be able to adjust my priorities.
  52.  
  53. -Mat
  54.  
  55.