Prima Shareware 3/DuCom_Prima-Shareware-3_cd1.bin/PROGRAMO/C/ATOLKIT/TWEAK.DOC

Text File | 1991-12-14 | 16.2 KB | 332 lines

/*****************************************************************
tweak.h

    The following functions make up Fabco's current
    VGA Animation/Graphics/Multi-media Toolkit as of 12-8-91
    The functions below amount to an "Abstract Data Type"
    of a "Sprite" that can be animated or moved around
    on the screen in 320x200x256 color mode.

    In order to do "page flipping" and eliminate flicker,
    a special "tweaked" video mode was used (as described
    in "Power Graphics Programming" by Michael Abrash).
    This video mode is not compatible with MCGA mode 13h,
    and a special conversion program, (supplied as convert.c)
    must be used on MCGA mode 13h files before they can be
    used in this mode. Actually, all the functions in this
    toolkit should work in any of the "tweaked" modes. All
    you have to do is supply your own mode set routine if you
    want to do 320x400x256 or 380x400x256 etc. I have chosen
    320x200 for it's compatability with normal mode 13 paint
    programs etc. The other tweaked modes and "mode X" offer
    higher resolution at the cost of this compatability.

    Currently, only ColoRIX.sc? files are supported by the
    convert program, since that is the only paint program's
    file format I could get any legal information on. (Rix
    thoughtfully makes their uncompressed format available,
    unlike most other companies). However, any file format
    could be converted, if you know the format. Just
    look at the program convert.c and make the needed
    adjustments. Also, the popular shareware program: "Vpic",
    will translate many different formats (including ".GIF")
    to "Rix" format merely by pressing "R" while viewing
    the picture. Be sure you are in the video mode you want the
    final output in though.

    With all the outside support for different file formats,
    I decided not to bother writing a lot of code for interfacing
    to different paint programs. I chose instead to concentrate
    on the bit-blt graphics, that are so hard to find anywhere else.
    However, anyone with information on AutoDesk Animator ".CEL"
    or ".FLI" file formats, please send it in. Anyone who knows
    any slick method to compress/decompress video in real time
    likewise get in touch. I have just never been able to figure
    a way to do that "on the fly", in real time so to speak.


    The toolkit's current function list is not yet complete,
    and in a state of flux. This is only a sampler, but it is
    already a core group of functions that have been tested
    to perform on a wide variety of VGA cards, with no problems.
    Bounds Checking is up to you, however. It is possible to
    write sprites to illegal addresses, especially if a
    protected mode program (like QEMM) is running. If you
    are moving a sprite around by calculating the index into
    a one of your video buffers, and that calculation places
    some of the dimensions of the sprite rectangle off of the
    screen, unpredictable things can happen. Sometimes the
    buffer area will just wrap, sometimes (especially for
    negative destination coords above or to the left
    of the upper left hand corner of the screen), you might
    get a processor exception.


    This Toolkit is currently provided only as a small model
    "linkable .obj" made with Microsoft "C". This is ShareWare,
    it is not free. I will provide other memory models,
    for other languages only for registered users.
    So register today. I cannot continue to improve this
    product unless you support it.


    The current registration price is $39.95. It will
    probably have to go up when more functions are added.
    I am poor, and sympathetic, if you cannot afford this,
    send what you can. All donations accepted. However,
    support levels drop with price. Also, I am not hard to
    get along with, and I am very interested in the concept of
    working together in a group cooperative effort. Two
    people can do more than one; Five people can do even more.
    It's just so hard to get five people to cooperate on anything.
    It's just impossible if they aren't getting paid.
    I am no genius at this stuff, and I'm not stuck up about it.
    A willing attitude toward assembler, registers,
    flip-flops, or graphics, goes a long way with me.
    And, people who really contribute go even farther.
    So, if you want to collaborate, talk about enhancements
    etc., drop me a line at my work address below, or leave
    me e-mail on Compuserve. (ID# 73530,2105). All comments
    and suggestions are welcome. Sorry, I am just not available
    by phone, unless you want me to call you back collect
    or something.



    Masm 5.1 Source code is available for only $99.95.
    Believe me, you can't write it yourself for that.
    No extra Royalties are charged, although I do ask that
    you keep me posted on any enhancements that you make, or plan
    to make. (To avoid duplication of effort).I will even
    be happy to suggest areas where I think the most
    improvement can be made.

    Send check or Money Order to:

                    James Faubus
                    Rt.1, Box 37
                    Godley, Texas 76044




    Limits of Liability and Disclaimer of Warranty:

    The author has used his best efforts in preparing this
    toolkit, and the programs contained within it. These
    efforts include the development, research, and the
    testing of the theories and programs to determine their
    effectiveness. The author makes no warranty of any kind,
    expressed or implied, with regard to the programs or the
    documentation contained in this toolkit. The author shall
    not be liable in any event for incidental or consequential
    damages in connection with or rising out of the furnishing,
    performance, or use of these programs.

******************************************************************/







/*****************************************************
Animation Toolkit Functions

All Routines are highly optimized, and very fast.
(Or at least as fast as I could make them).
However, I have used some 286 instructions, and the
code won't run on 8088 machines. I chose not to
support XT's because even on 12MHz AT's some of these
highly optimized assembler routines start to become
a little sluggish. Let's face it, a 12Mhz AT is sort
of the minimum system for 256 color graphics, even
in 320x200 mode. Especially if there is a sound
interrupt occurring 10,000 times a second. Although,
if you just have to make the code run on an XT for
some reason, purchase the source code. The only
conversion required will be to change a few
"shr ax,4" to "shr ax, 1" four times.

******************************************************/

extern int active_page;
/* Current video page segment of the screen being displayed.
   A000h for page1 A800h for page2. I'm not sure why you
   would want to know it, but it's here if you need it. */

extern void set_mode            (int mode);
/* Sets the screen to any of the normal VGA modes, set_mode(3);
   returns you to normal text mode. */

extern void set320by200TweakMode(void);
/* Sets the screen to 320x200x256 tweaked mode. It could also set it
   to 320x400x256, but there are no paint programs that support it
   so I don't either. See "Power Graphics Programming" by M.Abrash
   for more details. */

extern void set_palette         (char huge *buf);
/* Loads the palette regs with the data it finds in buf. Note
   that all data buffer pointers are SEG:OFFSET far pointers.
   This way "halloc()" can be used to allocate buffers larger
   than 64k, or multiple buffers of 64k each can be used,
   even in small model code. */

extern void move_backgnd        (char huge *buf);
/* This routine moves the data it finds in buf to the current
   video page. Buf must be exactly the size of the screen,
   and already in planar format (as supplied by convert.exe).
   No checking is performed. */

extern void write_pixel_twk     (int x, int y, int color);
/* Sets any pixel at any screen (x,y) coordinate to the 8-bit value
   specified by color. (The upper 8 MSBits are ignored).
   Can also be used for lines, circles, etc., since they
   are not currently supported as such. */

extern void fill_rectangle      (int x, int y, int w, int h, int color);
/* Similar, but fills a rectangular area to the specified color.
   Good for windows, menus etc. */

extern void get_rectangle       (int x, int y, int w, int h, char huge *buf);
/* Saves any rectangular area of the screen in the buffer you provide.
   Could be used for a whole screen save, or just a partial screen save. */

extern void put_rectangle       (int x, int y, int w, int h, char huge *buf);
/* Restores the rectangle you previously saved with get_rectangle(); */

extern void switch_pages_poll   (void);
/* Switches to the next page of video memory, at the next occurring
   vertical retrace. Successive calls toggle back and forth between
   the two video pages. VGA cards could support 4 pages w/ 256k
   or 8 pages w/512k in this tweaked mode. Currently, I only support
   toggling between the first two pages. If there is enough demand,
   I will add support for all 8 pages.*/

extern void set_page            (unsigned int pg);
/* Used the Bios write pixel to bank switch the video card any one of 8
   pages. This does not work on all cards, use sparingly. Also,
   set_page(4); causes subsequent writes to go to our page 2;
   Which will then be seen by a call to switch_pages_poll();
   This is only useful for starting your writes on a known page.
   Switch_pages_poll(), changes the page for all future writes,
   to the unseen page automatically. */

extern void draw_sprite         (int x, int y, int w, int h, char huge *buf);
/* Draws a sprite located in buf. Sprites must have the color "Black"
   hex 00, as the cutout color. In other words, anywhere you want the
   background to show through on the sprite, erase that spot with the
   special color black00. Anywhere you want to look black, use a shade
   that is almost black. This is easy with most paint programs that
   allow you to adjust the palette. ColoRIX will show you the numeric
   value of the color while you are adjusting the palette. */

extern void erase_sprite        (int x, int y, int w, int h, char huge *buf);
/* Restores only the rectangular area at (x,y) from a larger background
   screen pointed to by buff. This routine requires buf to be exactly
   the size of the screen. If you need to erase from a bigger virtual
   screen use scroll_screen(); instead. */

extern void scroll_window       (int sourceX, int sourceY,
                                 int destX, int destY,
                                 int w, int h, char huge *buf);
/* Grabs a rectangular area from a larger source buffer that can be up to
   the size of a full screen, and places it on the screen at the
   destination coordinates. By varying the source coordinates in a loop,
   the object in the window will appear to scroll. By varying the
   destination coordinates at the same time, a rectangle can appear to
   have live video going on in a moving window. */

extern void scroll_zoom_window  (int sourceX, int sourceY,
                                 int destX, int destY,
                                 int w, int h, char huge *buf,
                                           int Vzoom, int Hzoom);
/* Similar to above, but can also vary the vertical and horizontal zoom
   factors. This routine is restricted to integer zoom factors, and the
   width and height of the source area must be evenly divisible by
   the zoom factor. (Otherwise bizarre things might happen.)
   For example: A width of 96 and a height of 96 can be zoomed
   at factors of 2, 3, 4, 6, 8, 12, 24. This is critical in the
   width but more forgiving in the height. I have used this
   technique to produce a nice screen fade that just fades into
   bigger and bigger pixels. */

extern void scroll_screen       (int sourceX, int sourceY,
                                 int destX, int destY,
                                 int w, int h, char huge *buf,
                                 int buf_wid, long bytes_per_plane);
/* Similar to scroll_window above, but supports buffersizes larger
   than one screen. A 640x400x256 color pic can be 4 backgrounds.
   This routine can be used to scroll inside this virtual screen.
   Due to optical effects, scrolls in the vertical direction look
   smoother though. Bytes_per_plane would be 16000 for a 320x200
   screen 64001 for a 640x400 virtual screen. Why it has one extra
   byte per plane more than you would think it would be, since
   640 x 400 = 64000, I have no idea. Perhaps it is an anomilie
   caused by translating the pic. ??? Experiment w/ it. If anyone
   figures this out please let me know. */

extern void scroll_sprite       (int sourceX, int sourceY,
                                 int destX, int destY,
                                 int w, int h, char huge *buf,
                                 int buf_wid, int bytes_per_plane);
/* Similar to scroll_screen above, still supports buffersizes larger
   than one screen. This routine treats black as a special color though,
   and can be used to scroll text on top of a background. (If the text
   has been created in bitmap form like in draw_sprite above. */



/* Digital Sound Routines that will play SoundBlaster files on the
   PC speaker. */

extern void init_speaker_port   (void);
extern void IRQ0_install        (void);
/* These two functions must be called before playing background sound */

extern long *play_sound_IRQ0    (char huge *buf, unsigned long bufflen,
                                 int rate );
/* Plays 8 bit digitized sound located in buf, as a background
   task. Returns a pointer to the number of bytes it has yet
   to play. Before calling the first time, setup with a call to
   init_speaker_port(), and IRQ0_install(). (In that order). Then,
   tempLen = play_sound_IRQ0(...); will return immediately to
   your program but sound will be playing in the background.
   Graphics can be performed while the sound is playing, and
   can be coordinated with the sound by polling the tempLen
   pointer. For example: 64k of sound buffer played back at
   10kHz samples per second, will last about 3 seconds.
   That means we could be doing animation on the screen,
   while the first sound buffer is playing. Let's say it takes
   us 2.5 seconds to do our graphics, and we want to coordinate
   the next set of animated graphics with another sound. We
   can just go into a tight polling loop checking the tempLen
   variable. When tempLen reaches zero, we make the switch to the
   second sound buffer with a call to play_sound_IRQ0(...) again.
   Immediately after that we can start our next graphic.
   Perfect coordination. Unfortunately, this technique cannot
   be used to double buffer directly from HardDisk. Since,
   the sound interrupt is using the same (and only) channel that
   Dos uses for disk I/O, all disk access must be suspended while
   the sound is playing. However, graphics can be animated while
   the sound is playing, and if you have EMS memory available,
   it can also be paged into main memory while the sound is playing.
   Double buffering from EMS or Ram Disk is theoreticly possible.
   You would just have to preload the EMS during times when sound
   is not playing. I'm sure if you think about it a while, you
   can find other interesting applications.


extern void restore_ports       (void);
extern void IRQ0_remove         (void);
/* These two functions must be called to clean up after you are
   through playing sound. */
extern void play                (char huge *buf, unsigned long bufflen,
                                 int rate, int delay );
/* This function plays sound by the software delay loop method,
   instead of using the interrupt. It hogs the processor completely
   and different delay values must be used on different speed
   machines; But, it does eliminate sample whine, and provides
   the best possible digital sound on the PC speaker. */