Graphic help

2»

Comments

  • Now that
  • says who VESA is difficult to implement??

    I think I've done it.

    why are you running 16 bit emu?? You are running on a 486 or faster,right? that cpu is 32bits.

    use fpc.its faster, more efficient, and supports delphi syntax as well as bp modes.You can use windows if you want and the lazarus IDE for gui apps.I build under linux, but that is my specialty.Same compiler, same IDE.

    no, according to the BGI, xorput is faster. I actually had to remove the monolithic thing, I should know.Check the code for the graph unit in FPC.

    thanks for the assembler tip, but i dont think this fixes the math for 32 bits, you cant use 16bit math or mixed registers with fpc.Will give it a shot soon enough.

  • : says who VESA is difficult to implement??

    I didn't said is difficult, it is more complicated to do out of TP, so the code would be much harder to follow by beginners. Plus the memory limitations of the real mode... On the other hand you'd be surprised how loosely different video cards follow the vesa standard, that's why I mentioned interfacing with DirectX instead of going low level...


    : why are you running 16 bit emu?? You are running on a 486 or
    : faster,right? that cpu is 32bits.

    TP produces 16bit real mode binary code (except 32bit asm snippets or inline inserts). Windows runs under 32bit protected mode, so anything 16bit will be emulated on a virtual dos machine (ntvdm.exe, is in the windowssystem32 folder), google it for more info...


    : use fpc.its faster, more efficient, and supports delphi syntax as
    : well as bp modes.You can use windows if you want and the lazarus IDE
    : for gui apps.I build under linux, but that is my specialty.Same
    : compiler, same IDE.

    True, but unfortunately not everybody (including educational institutions here) upgraded to FP yet :( Hopefully this will change.



    : no, according to the BGI, xorput is faster. I actually had to remove
    : the monolithic thing, I should know.Check the code for the graph
    : unit in FPC.

    Xorput performs a bitwise xor between each respective pixel of the image and background, so for each pixel written three steps are needed: read background, do the xor math, output result. In assembler would be something like[code]

    mov al, es:[di] <-- es:[di] points at the background
    xor al,ah
    mov es:[di],al[/code]With xorput alone hardly possible to do animation, except for some monochromatic sprite maybe, for multicolor sprites an andput is needed before to mask the background (this requires an additional sprite mask, doubling memory usage). BTW, mouse cursors work this way... I covered this here: http://www.programmersheaven.com/mb/pasprog/385717/385717/graph-help/?S=B20000#385717 Also in hi color modes the mask usually holds the alpha channel permitting sprites with variable transparencies.
    The fastest (this method is not in BGI) is to choose a color as transparent and upon display skip those pixels, two steps per cycle...


    : thanks for the assembler tip, but i dont think this fixes the math
    : for 32 bits, you cant use 16bit math or mixed registers with
    : fpc.Will give it a shot soon enough.
    :

    16bit math is possible, same as 32 or 8 bit, but you cannot mix different registers. Ex:[code]mov eax, ebx <-- ok
    and ax, bx <-- ok
    or bh, bh <-- ok

    sub eax, bx <-- not ok
    xor bx, ah <-- not ok[/code]With FP's optimizations is not necessary to use asm, unless is no other way to get around or you really know what you doing. I had hard time beating the plain pascal code in speed with asm, something not true for TP...

  • Freightenting. Yeah, I grew up on TP.What a pain.

    Shame some schools haven't made the jump.TP is so limited these days.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories