Mail Archives: djgpp/1997/11/22/16:31:43
Fabrice ILPONSE wrote:
> Hi!
> Here's the topic back.
>
> That time have made a new test concerning video memory access.
>
> TEST: DISPLAY THE DATA SEGMENT/SELECTOR directly to the video memory
> (BLIT) 32000 words.
>
> For comparison: BC 3.1 and DJGPP.
>
> Befor ALL: even in BC 3.1, i've used 32 bits inline assembly.
> i haven't used any existing libraries!
>
> The PROG:
>
> - switch to video mode 320x200x256
> - loop
> - change color 0 to red
> - BLIT
> - change color 0 to black
> - wait retical retrace
>
> I've got a 486 DX2 66.
>
> Results:
> - BC 16 bits red takes 40% of screen height
> - BC 32 bits 45 - 50%
> - DJGPP 90 - 95%
>
> Those values are approximated. (humain looking)
>
> I repeat it, i do not say anything about the djgpp generated code. I
> think it's as good as the BC one. But what else can slow down the
> performances?
>
> Protected mode perhaps!
>
> SOON: i'll try to do the same under my modified protected mode BC 3.1
> version.
>
> Bye
> --
> ^ ^ ^
> | | |
> +-+-+ Fabrice ILPONSE
> | <fabrice AT asim DOT lip6 DOT fr>
> |
> |
> -
I had sort of the same problem with my 3D graphics program. I was using a for
loop to call _farpokeb(blah) 64000 times. As you can probably figure, this was
quite slow. However, when I switched to using movdata(blah) for both blitting a
page and clearing my draw_buffer, my program was suddenly 5 times faster!
movedata() is very well optimized, and so it works well for blitting pages to vid
mem.
Isaac Waldron <waldroni AT lr DOT net>
http://www.geocities.com/SiliconVally/Lakes/3574/index.html
- Raw text -