Mail Archives: djgpp/1997/12/15/13:15:48
In article <34950998 DOT 37ED AT rug DOT ac DOT be>, Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be> wrote:
>> >[snip]
>> > It this way of plotting a pixel the same as the farpokeb (...) version??
>>
>> Using __djgpp_nearptr_enable should be a bit faster because you avoid
>> loading the ES register. But !..., It may not work from a DPMI server to
>> an other.
>
>If you use the 'no selector' versions of the _far* function you don't
>have this load.
>BTW this load takes more cycles than you may think because loading a
>selector register involves loading a descriptor, checking access rights,
>....
>
>One advantage by using the near pointer versions is that the compiler
>generates the code and that maybe further optimizations can be
>performed. But do not expect too much from that. IMHO it is not worth it
>using the near pointer functions. Now that I think of this, these
>optimizations may even break your code, since accessing video memory is
>always tricker than accessing 'normal' RAM. If the compiler manages to
>combine two consecutive by writes into a single double-byte write, your
>code may not work anymore. I do not know whether the gnu compiler is
>intelligent enough at this time to do this, but I wouldn't be surprised
>and eventually this optimization strategy may get in, and your code that
>once ran perfectly won't run anymore after recompilation.
*** And what about writing the pixel to an off-screen buffer and then blitting
the whole frame when finished. You could just use an array and there's no need
to fuss with pointers. I use this technique in my 3D engine and have no
trouble with drawing 100000 poly's a second (including sorting, shading and
scan conversion, of course). I like to think that's reasonably fast...
Regards,
Steven Don
- Raw text -