Icon  Name              Last modified      Size  Description
[<] Parent Directory - [>] 1995-10-23 02:41 49K sprite editor for DOS Xlib

This is a program I wrote in March, 1994. It's a sprite editor for a DOS-based graphics library. My first C project ever, I think. Not very useful anymore, but it's still cute. Unfortunately, I lost the source long ago...... (not that was very good code... just would have been an interesting bit of my personal geek history).

Also, you'll notice that I call myself "Matt Miller". I went through a phase of that. When I was really little, I used to insist on "Matthew", and got angry when people called me "Matt", but when I got to kindergarten, that turned out to be futile, so for many years, I gave up. Now that I'm a Grown Up (TM), I've decided, not withstanding, that I want to be called by my full name. But, y'know, whatever.


Sorry about that got a bit distracted. Anyway, following is the original mdraw documentation. I just read it over, and decided that I'm a nicer person now than I used to be. Also I think it's pretty funny that I thought 200K was an outrageous size for the executable.

                      A neat little sprite editor for Xlib
                                by Matt Miller


   MDraw is a sprite editor designed to create sprites for use in games.
   It is really a paint program, not a draw program, but MPaint just
       doesn't roll off the tongue in quite the same way.
   If there is already something else out there named MDraw, sorry.
   MDraw was created for my use. It does what I need it to do.
   If you are lucky, you may find it useful as well.
   It only runs in mode X at 320x240. I like square pixels.
   It can save in PBM and CBM formats. PBM is probably useful no matter
       what mode X library you are using. Compiled bitmaps are probably
       only useful if you are using Xlib. They are realllly fast.
   It can load PBMs, but not CBMs. Sorry.
   It can't deal with anything bigger than 64x64. What kind of sprite is
       bigger than that anyway?


   MDraw is copyright (c) 1994 Matt Miller. But, you are free to use it 
   and distribute it at no cost.

   Send me e-mail. My address is at the end of this document.


   I put a lot of work into this. Probably more than I should have. If you
   would like to have the source code, e-mail me and ask for it. I'll give
   it to you in trade for any cool original source you have. [1]


   There won't be any.


   Hopefully, it's mostly obvious. Some things do require a little 

Main Draw Window: Okay, this shouldn't require -much- explaining. Here's
   where you do the actual drawing. The important thing is that squares
   with little grey dots are clear, not black. (They are palette color 0).
   Oh, and the little blue tick marks around the edges mark off every five
   pixels. A sort of no-frills ruler.

Actual Size Window: This little thing is what the sprite will actually look
   like. The not-obvious thing is that by clicking here you can move the 
   sprite. (Try it.)

Radiator: Sorry, had this blank space..... It doesn't do anything.

Pencil: This selects the pencil tool. Left click in the Main Draw Window
   to draw one pixel, right click to erase.

Paintcan: This selects the floodfill tool. Pretty standard. Like with the
   pencil, left click fills with the current color and right click fill-
Circle: This is not God's Gift to Circles. Sorry. It only draws circles,
   none of them fancy ovals here, no sir. Click on the top-left corner
   of the circle, drag to the bottom right. I was too lazy to write my
   own circle function, so I just used xlib's, which is pretty limited.

Horizontal Flip, Vertical Flip, Rotate: Yep.

Undo: What a cute icon, huh?

Info: Basically tells you to read this.

Current Color: (We're back to the left bottom side of the screen here.)
   This shows what color you're drawing with right now. If you click on
   it, it will make sure the current InstaColor is equal to the Current
   Color. That will make sense later.

------------IMPORTANT NOTE ON COLORS!!!!!!!!--------------------------------

The palette is arranged this way:

0     :  Black
1-15  :  System colors. (Whatever you want them to be.)
16-231:  Generated by this formula (in Matt's Wonderful PseudoCode):

         Red=0 to 5
            Green=0 to 5
               Blue=0 to 5
                      color[index]=Red*36 + Green*6 + Blue
               Loop Blue
            Loop Green
         Loop Red

         The values 0-5 above correspond to 0,19,30,41,52, and 63, 
         respectively. This gives a pretty smooth palette.
232-239: Multi-cultural flesh tones. Blended smoothly from (R=63,G=44,B=32)
         to (R=32,G=20,B=11). Lack of browns is the main flaw in the above
240-255: User colors. (I use this for colors that get rotated, for special

Now, you are asking: What is the logic behind this scheme? 
 1st: It's really easy to find exactly the color you want, once you get the
      hang of RGB color mixing, which isn't that tough.
 2nd: You can easily blend between -any- colors. Most palette schemes are
      great for shades of primary colors, but what if you want to go from
      dark blue to yellow? This method makes it easy.

The main flaw is that there aren't very many good flesh tones. So the colors
232-239 make up for that....

Okay, back to your regularly scheduled documentation.

Color Mixer: This is the primary way to select colors. Increase and decrease
   red, green, and blue values. Really simple.

InstaColors: These are the six colored buttons in the top row. They provide
   a sort of working-palette-box. Open tubes of paint, so to speak. If you
   click on one, the Current Color is changed to whatever that color is set
   to. If you then change the color with the mixer, the selected InstaColor
   is changed. This may sound confusing but in actual use it's really

QuickColors: This are the bottom three rows of colored buttons. The top
   row is a nice rainbow, the second is greys, and the third (and actually
   part of the second) is the flesh tones. Clicking on these changes the
   Current Color, but does not change the current InstaColor. (To then set 
   the Instacolor, click on the Current Color Window, or adjust the Mixer
   up and back down.) Note that this is the ONLY way to get the flesh tones.
   And look, if your skin doesn't match any of the available colors, I'm 
   sorry, I'm not trying to exclude you. Simply send me the RGB values
   for your skin, and I'll make a personalized version 'specially for you.

New: Creates a new sprite. You can select a size from 16x16 to 64x64. Note
   that this isn't necessarily the final size of the sprite--you select that
   when you save. This is just the maximum size.

Load: Loads a PBM. Sorry, you have to know what the name of the file is--
   no neat directory listing. Just type in the name, without an extension.
   .PBM will be added.

Save: Saves a PBM. Click on the sprite resize window to adjust the size.
   Widths must be multiples of four, which is not a shortcoming since you
   WANT them to be multiples of four for maximum speed. Type in the
   filename, just like when you load a file. If the file already exists,
   you will be asked if you want to overwrite it. 
   If you have a 64x64 sprite, there is an additional selector. You can
   chose to save as one 64x64 bitmap, or as 16 16x16 bitmaps. This is
   really nice for background tiles. The little files will have the name 
   you type in for the filename with the position of each tile added to 
   the end. (So BLAH.PBM turns into BLAH00.PBM, BLAH01.PBM, all the way
   up through BLAH33.PBM.) I use this feature a lot. You can ignore it if
   you want. Note that it's a good idea to save the"big picture" as well,
   since there's no way to re-assemble the parts.

To CBM: Saves as a compiled bitmap. Exactly the same as Save in every other
   way. Warning: you can't load CBMs, so if you ever want to reload your
   sprite, better save it as a PBM as well.

Exit: Back to the wonderful world of DOS.

Starfield: Had to put something in the corner. (If it annoys you, click on
   it and it'll stop.)

I think that's all.


   The cool mouse cursors are done with the incredibly inefficient but 
   solidly bulletproof method of drawing everything on both a hidden
   and a visible screen page and updating the mouse cursor background
   from the hidden one. Not a good idea for a game, but hey, it works
   fine when things aren't time-critical.

   In keeping with this philosophy of inefficiency, I used compiled
   bitmaps for all the graphics. Which is really silly, because except
   for the mouse cursors, they're only drawn once.

   All the graphics are linked into the EXE, via 2Obj. Really convienient.

   This is my first real C program. I just started learning C two weeks
   ago. Before that, I was an Expert QuickBASIC/PowerBASIC programmer. <g>
   I was under the silly delusion that C is in someway really difficult to


   Because of all the linked graphics and stuff, the .EXE for this program
   is over 200K. Eep. So I LZEXE'd it, which compresses it to about 48K.
   Not so odd, since I expected good compression because of the above-
   mentioned inefficient practices, but here's the weird thing: LZEXE, 
   which is free, did a really good job. PKLite, the $150 thing, can only
   compress it to about 70K. (Same thing with plain PKZip, BTW). What's
   going on here? Why does LZEXE to such a better job? [3]


   Look, deal with it, okay?


e-mail: [4]

BBS:     Matt Miller on Surreal BBS at (219) 262-9371

dumb-mail:  Matt Miller
            Goshen College
            Goshen, Indiana  46526


1. Offer no longer stands, since I lost the source code and all. Unless it's in a drawer or closet somewhere at my parents' house.

2. What a jerk I must have been. And so few years ago, relatively speaking. How embarrassing.

3. Back then, I was surprised that free software could outdo expensive, proprietary software. I've long gotten over that.

4. This is out of date, of course. I've got a new address.