DOS Games: A time not forgotten

To most people, the word "DOS" means nothing (or two, if they're Hispanic)...but to those of us who were using IBM/PC compatible computers (that phrase takes me back) around 20 years ago, it means awesome computer games that are on an entirely different level than the video games of today. Before I go too far, let me clarify: DOS refers to a kind of text-based operating system. It stands for Disk Operating System. There were many different variations of DOS made by many different companies, most notably MS-DOS by Microsoft. The DOS era was a great time in history...I'm talking about a time when 640x480 resolution graphics were considered top of the line...a time when game music was hardware synthesized (AdLib, SoundBlaster, Gravis Ultrasound!)...a time when mouse functionality was an 'extra' feature.

To a person unfamiliar with this world, this may sound dull and irrefutably boring. I implore every one of you to bear with me, for the world of DOS is like no other; there's a reason why Jim Hall wanted to make a free replacement for MS-DOS when Microsoft announced its planned demise, there's a reason why so much work has gone into DOS emulators like Dosemu and DosBOX (years after its demise) and more importantly, a reason why there's a myriad of 'classic' game download sites.

I don't think we can begin to examine any DOS games before we take a look at the game that (in my opinion) made DOS games so popular: id Software's DOOM.

DOOM is basically the first-person shooter (FPS) that started it all. Wolfenstein 3D was really the one that started it all, but DOOM's improvements over Wolfenstein 3D made it extremely popular. DOOM brought things like lighting differences, non-perpendicular walls and room height differences. That doesn't sound like much, but it's really the difference between a forest and an office of cubicles. It also brought weapon swaying while moving, adding to the "realism" of the game. The differences in technology are outlined here.

DOOM had it all. It had so many different levels and episodes, the ability to load custom graphics and levels, lots of different weapons. You could spend days playing this game. For 1993, it was BAD ASS. It definitely raised the bar for computer games forever.

Three years later, Duke Nukem 3D came out. In essence, it was almost just like DOOM, but introduced some very appealing and popular features: more manly and sexual game content (strippers, Duke's famous phrases he says throughout the game, steroids) and more usable items like a jet pack and cooler weapons, like the "freezethrower." It was basically DOOM, except with aliens, more items and more attitude.

In DOOM, the player's character never says a word; it is an emotionless being. However, Duke is a sort of bad boy role-model, overly macho and unafraid of anything. And of course, he dons a cool pair of sunglasses. It also left a lasting impact on games as we know it.

Next we have a few games that never gained mainstream popularity, but are more than worth mentioning for their content and gameplay. I'd spend countless Summer nights playing these games...they defined a time in my life as well as the DOS gaming genre.

Tyrian was the arcade style scrolling shooter to have on your PC. Its Adlib music, rich and colorful graphics, and gameplay that changes every time makes it one of my personal favorites that I still play to this day.

One of the really cool things about this game is the ability to buy/upgrade just about everything on your ship, heck, you can even buy different ships. You got to pick from a handful of weapons, shields, generators and accessories, some of which wouldn't show up unless you took the right path in the game. That's the other cool thing, the ability to choose which planet to go to next. Most of the time, you have no choice, but sometimes you'd be able to pick which asteroid or planet to go to next. Not to mention there are secret levels all over the place. Some secret levels even have secret levels.

MegaRace isn't much of a game, but the music by Stéphane Picq is unforgettable and for the time, the graphics were awesome. If the cars had more features and there were more levels, it would've been a lot more popular. That and all of the video sequences featuring Lance Boyle are really annoying.

As I said though, there's not much to the game...you chase other cars and destroy them by either firing at them or ramming them until they explode. That aside though, let's just say that the music really brought your sound card to life. The music featured in this game is like no other.

Last but not least comes Cyberdogs and its sequel, C-Dogs. Both were written by Ronny Wester. I don't know much about the guy, but he wrote these two really cool games and released them as freeware, which is awesome. This was rare because most games of the time you either had to play as shareware
(more commonly known as a demo), meaning you could only play a level or two before having to buy the game, or you just had to straight up buy the game.

Cyberdogs isn't as good as the sequel, but it was different and cooler in the sense that you got points for killing things, collecting items and blowing up things in order to buy new weapons and armor. My favorite is the PowerGun, it shoots relatively fast and only took one shot to kill/blow up most things. Gameplay was intense in the later levels though, the more advanced enemies moved so fast you literally had about half a second to react or they'd just kill you. C-Dogs featured a level editor and some more advanced weapons, like grenades, molotovs, etc. It also introduced a multiplayer game mode. The biggest improvement is the player's ability to do a dash, which was really useful for dodging and fighting mobs. This game is very fast-paced on some of the more harder levels and would be INSANE if you could play it online, which brings me to the next paragraph.

Ronny Wester released the source code for these games in 2002 and two developers rewrote C-Dogs for Windows/Mac/Linux and called it C-Dogs SDL. I wish I could say something nice about this remake, but I can't. When I run C-Dogs SDL, I only get 22 fps (frames per second) tops, which makes for really slow and choppy gameplay. Running the original DOS version, I get close to 70 fps. They have plans of making it playable online, but it'd be useless unless they can make some optimizations to make it a lot faster. The remake needs a lot of work, but you can check it out here.

You just have to admire the work that went into making these old games. Nowadays, basically the only obstacles to making a game are using a 3D modeling program like gmax or Blender to make some unique characters and getting some decent music for your game. There are tons of game engines out there to choose from, like the Unreal engine and the Quake engine. There's some tweaking and customizing involved, but it's nothing like what it took for these old games. First of all, they started from scratch. Most of the graphics you see here (excluding the prerendered graphics from MegaRace) were hand-tweaked by the pixel to get the best looking graphics. They didn't have all these special programs to make nice looking textures or models/sprites. Space limitations meant that they had to have the music hardware synthesized instead of using actual recorded music, like in newer games. That meant that they had to compose the music using a tracker on a computer, sometimes having to find the right combination of waveforms to produce the certain sound desired. Most importantly, these games had to be optimized to hell in order to make up for no dedicated graphics, extremely slow processors and very little RAM to work with. A lot of old games were already written in lower level languages, but past that needed core parts of the game to be written in assembly language, which is the closest you can get to writing actual machine code. This allowed games to run smooth as glass on 33 MHz processors.

So how can you play these games? The easiest way would be to get a DOS emulator, probably the best of which is DOSBox. It allows you to play pretty much any DOS game at nearly the same speed as with the real thing. If you can get your hands on an old old computer (one with a 90 or 133 MHz Pentium processor would be perfect) that has a real sound card in it, you can download and install the latest version of MS-DOS. Or, you can try FreeDOS, a free MS-DOS replacement that comes with a lot of free tools, including a web browser (Arachne) and the infamous 4DOS. I recommend using DOSBox though, that way you can play old DOS games on just about any computer. It's a lot easier.

Once you've got access to DOS, you can check out some of the many classic game download sites, like Best Old Games and Classic DOS Games. If you're a big torrent downloader, you can find huge DOS game collections on any torrent site. This is not illegal, as all of these games are either in their redistributable shareware form, or have since been released as freeware.

How to make data links not suck

In AutoCAD 2007 or 2008, tables and data links were introduced. Tables are tables...basically spreadsheets in AutoCAD. Data links are links between tables and Excel spreadsheets, much like an external reference. They were a good idea in theory, but actually using them sucks. Both tables and data links are extremely slow, but if you get them to work right, you can use an Excel spreadsheet just like an external reference.

Pretty much everyone I've worked with thinks that data links are crap, and because of that, I've been using Spanner almost non-stop. They are crap. Tables and data links lack some major functionality and much needed customization.

Anyway, you may be used to running the TABLE command, creating a new data link and telling the new table to use that data link. This is the crappy way of using data links. Most of the time, this results in discarded formatting and very poor results that scare people away from data links entirely.

To get the most out of data links:

1. Open up the spreadsheet you want to use in Excel.


2. Select and copy the range of cells you want to use.


3. Go into AutoCAD and go to the Edit dropdown and select "Paste Special" or run the PASTESPEC command. The Paste Special dialog will appear.


4. Select the "Paste link" radio button and select AutoCAD entities from the list. Hit OK.

This creates a new data link automatically and brings in the initial Excel formatting. If you want a table to keep Excel's formatting, you need to run the DATALINK command and change that option in that data link's properties.

Here are some extra tips:

• Unlike Spanner, AutoCAD is going to draw a border for the edges of cells whether there's a border in the Excel sheet or not. If you don't want a border to show up, either merge some cells in Excel or right-click the cell in AutoCAD and click "Borders".


• AutoCAD seems to add some additional cell padding in all directions, creating loose tables. There's not really a way around this; stick to Spanner or OLEs in cramped drawings.

Why use MATLAB? Don't be a fool.

I'll get right to the point, it's beyond me as to why anyone (businesses, educational institutions, individuals) would want to use MATLAB except for very specialized purposes. GNU Octave has almost identical syntax and is FREE. Let's compare them:

MATLAB vs. GNU Octave:

MATLAB:

• Costs $1950 for an individual license, with an additional $1000 or more for every toolbox you'll need.


• Takes too friggin' long to load on Windows. It takes at least 30 seconds for it to load at OSU. What a slow piece of shit.

GNU Octave:

• Is 100% free and open source. Since it's a part of The GNU Project, it will always be free! (Open source meaning that a copy of the source code comes with the program)


• Has nearly identical syntax to that of MATLAB. The semantic differences are outlined here.


• Has a myriad of add-on packages at Octave-Forge to replace all those expensive toolboxes. Not to mention, you can write your own add-ons in C, C++, FORTRAN or the default scripting language itself.


• Allows you to use all the existing literature and support for MATLAB, but in addition, if a bug is found in the program, you can report it to the developers and get it fixed rather quickly.


• Has been in active development since 1988, so it is quite stable and mature.


• Loads in a few seconds.


• Has a handful of ways you can access the application. As mentioned in a previous post, Xoctave is a front-end for Octave that is almost identical to MATLAB's GUI. QtOctave is a little different, but has some nice tools included and has a portable version that you can put on a thumb drive. Otherwise, the default way to access it is by a DOS-like command-line interface. I prefer this method for straight up calculations, but prefer Xoctave for homework.


• Does not support object-oriented programming (yet).

Is it really worth the several thousand dollars to get a few more fancy features that you probably don't need? If nothing else, use Octave, and if it doesn't meet your needs, you can think about getting MATLAB.

spell.lsp: An AutoLISP accessible spell checker and MTEXT formatting removal tool

Download spell.lsp
License: Public Domain, zlib if you want.

SCOWL (Spell Checker Oriented Word Lists)

There have been some requests on the discussion groups for a LISP accessible spell checker (not really, a few posts from years back, I just wanted to see how slow it would be). I figured that it'd be a pretty easy task, considering there are probably some free dictionary files out there, and there are (SCOWL from Kevin's Word List Page). It was an interesting day project, but making a function to remove mtext formatting proved to be a little more challenging than I initially thought. I know, there's already the UnFormat function in StripMtext written by John Uhden and Steve Doman, but it's somewhat unreliable. At the very least, it doesn't remove \\p*; alignment codes. I made my own function that uses foreachs and vl-string-searches instead of wcmatch. I'm not 100% sure on which is more efficient, but I'm pretty sure wcmatch is pretty costly with how broad it can be. My function hinges on the fact that there are three kinds of codes, codes to be totally removed, codes that contain text to remain, and codes that need to be replaced with something else, like a newline character.

Anyway, here's a quick guide on the functions included:

;; str2lst converts a string into a list
(str2lst "a,b,cd,e,fgh" ",")
;; returns '("a" "b" "cd" "e" "fgh")

;; lst2str converts a list into a string
(lst2str '("hello" "there" "mister.") " ")
;; returns "hello there mister."

;; loadWords takes a list of dictionary files and loads all the words into a list
(loadWords '("somedictionary.txt" "anotherdictionary.txt"))
;; returns a list of words
;; files should be one word per line, lower-case

;; checkWord takes a word and a dictionary and checks if the word is in the dictionary
;; basically a wrapper for vl-position, returns nil if the word is spelled right
(checkWord "ahasdh" myDictionary)
;; returns T since "ahasdh" is not a word

;; checkText takes text, separates into words, checks them and returns a list of misspelled words
(checkText "This is a test sentence." myDictionary)
;; returns nil, as all of those words are spelled right

;; remMtextFmt removes mtext formatting
(remMtextFmt "\\P\\Lhello\\l {\\fVerdana;\\W1.7x;there}")
;; returns "\nhello there"

The command "CT" (c:ct) is an implementation of the functions I've created. It allows you to select multiple text and mtext entities and returns the misspelled words.

Anyway, feel free to use this code to add some spell checking functionality to your applications, or just to have a better mtext stripper. The nice thing about this is that you can make a custom dictionary easily to include the common words in your drawings that aren't in SCOWL. Speaking of SCOWL, I used the first four files, as shown in the .lsp file. The more higher number file you use, the more words you're including. They're sorted by how often the words are used. First four does pretty well, might be able to get away with just the first two. Using four creates a 54,000 item list. You'd think that would present a problem, but checking three paragraphs of mtext only takes a fraction of a second.

You could use ssget to grab all the text in the drawing:

(ssget "_X" '((0 . "TEXT,MTEXT")))

Anyway, happy lisping, and comments are welcome.

Accessing Microsoft Excel with Visual LISP

One of the most useful things about Visual LISP is that it lets you access applications that utilize the Component Object Model, or COM. This includes AutoCAD itself, Microsoft Office applications, and some others. Accessing Excel isn't that much of a pain, but currently there aren't any really good examples out there for those who haven't done it before, unless you want to dig through posts in the discussion groups.

In this post, I'll briefly show how to add and read values from Excel spreadsheets using Visual LISP.

Before using any vla or vlax functions (which is what we're going to use), you must call (vl-load-com) to load the COM extension. Before we actually look at the actual code, know that COM is object-based. Let's review some of the functions you'll use:

;; creates a new object to use, in our case, "Excel.Application"
(vlax-create-object "object type")

;; retrieves a property of an object
(vlax-get-property object 'property)

;; sets a property to an object
(vlax-put-property object 'property necessary parameters)

;; performs a specified action
(vlax-invoke-method object 'method parameters, if needed)

;; returns the actual value of a variant
;; a variant can be almost anything, thus the name variant
(vlax-variant-value variant)

;; destroys the specified object
(vlax-release-object object)

Right, so let's get right into it. You'll need an Excel spreadsheet to play around with. You can create a new one, but it's almost always easier to make a template for yourself and save it under another name when done.

;; load COM
(vl-load-com)

;; open Excel
(setq excel (vlax-create-object "Excel.Application")

;; get Excel's workbooks
workbooks (vlax-get-property excel 'Workbooks)

;; open an existing spreadsheet
currworkbook (vlax-invoke-method workbooks 'Open "C:\\test.xls")

;; get the active sheet in that spreadsheet
activesheet (vlax-get-property excel 'ActiveSheet)

;; get the cells in that active sheet
cells (vlax-get-property activesheet 'Cells)

row 1
column 1

somedata '("This" "is" "a" "sentence" "with"
"almost" "ten" "words" "in" "it.")
)

;; place the values from somedata into rows 1 through 10, column 1
;; rows and columns start at 1, but list positions start at 0, hence the 1-
(while (< row 11)
(vlax-put-property cells 'Item row column (nth (1- row) somedata))
(setq row (1+ row))
)

;; print the last written value
;; only using prompt with this because we know it is a string
(prompt
(vlax-variant-value
(vlax-get-property
(vlax-variant-value
(vlax-get-property cells 'Item (1- row) column)
)
'Value
)
)
)

;; save the changes
;; returns :vlax-true if successful
(vlax-invoke-method currworkbook 'Save)

;; close all other spreadsheets, if there are any
(vlax-invoke-method workbooks 'Close)

;; quit Excel
(vlax-invoke-method excel 'Quit)

;; destroy all the objects you made, in reverse order
(vlax-release-object cells)
(vlax-release-object activesheet)
(vlax-release-object currworkbook)
(vlax-release-object workbooks)
(vlax-release-object excel)

;; garbage collect in case Excel doesn't close for some reason
(gc)

That's pretty much it. Here's some other handy stuff:

;; create a new spreadsheet
(setq newworkbook (vlax-invoke-method workbooks 'Add))

;; make Excel visible
(vla-put-visible excel :vlax-true)

;; save the current spreadsheet as another file
;; may not work with Excel 2007
(vlax-invoke-method currworkbook 'SaveAs "C:\\some other file.xls"
-4143 nil nil :vlax-false :vlax-false 1 2)

As always, happy lisping.

Batch processing AutoCAD drawings without creating script files

Many people on the Autodesk Discussion Groups would have you think that the only way you can do any batch processing is to make a .lsp that creates script files. This is not true and I simply refuse to use script files. You can do so much more with AutoLISP. Here is my own personal command, "batch":

(defun c:batch (/ dir files total ct docs doc)
(defun listAllFiles (path ext /)
(apply 'append
(cons
(mapcar
(function (lambda(x) (strcat path "\\" x)))
(vl-directory-files path ext 1)
)
(mapcar
(function (lambda(x) (listAllFiles (strcat path "\\" x) ext)))
(cddr (vl-directory-files path nil -1)) ; to exclude "." and ".."
)
)
)
)
(if (and
(setq dir (getfiled "Select a directory to process..." "Start here" "" 33))
(setq dir (vl-filename-directory dir))
)
(if (setq files (listAllFiles dir "*.dwg"))
(progn
(vl-load-com)
(setq total (itoa (length files))
ct 0
docs (vla-get-documents (vlax-get-acad-object))
)
(foreach file files
(setq doc (vla-open docs file)
ct (1+ ct)
)
(prompt (strcat "\r" (itoa ct) " of " total " drawings processed."))
(command "_.delay" "1000")
(vla-close doc :vlax-false)
)
(vlax-release-object doc)
(vlax-release-object docs)
)
(prompt (strcat "\nNo files of that type found in " dir " !"))
)
(prompt "\nNo path specified!")
)
(princ)
)

The command defines a function called listAllFiles, which recursively lists all files of a certain type in a directory (and its subdirectories, obviously). This was a pain in the ass to create. Anyway, all it does is ask the user for a directory, and then uses Visual Lisp/ActiveX to open each drawing, wait for 1 second, and then close it. All you have to do is add whatever .lsp you want to use into your startup suite.

Procedure:

1. Save the above code as a .lsp file


2. Add the .lsp file you're going to use to process the drawings to the startup suite (command: APPLOAD or Tools>Load Application). This .lsp file should end with (command "qsave") to save the drawing. DO NOT have (command "close") anywhere in the file, as this will cause an access violation and crash AutoCAD, because AutoCAD sucks.


3. Restart AutoCAD and load the .lsp file from step 1. Run the "batch" command, select your directory, sit back and watch it do the work for you.

Uses: Fixing a detail library (or several).

Notes:
I used getfiled to pick the directory because not everyone has Express Tools installed. Otherwise you can use the nicer (acet-ui-pickdir). Also, I don't really think the value for the delay matters that much. It appears that when you call vla-open, it switches to that new drawing long enough for things in the startup suite to do their work, then switch back to the parent drawing. Still, it's a good idea to keep the delay in there.

Parsing .csv files with AutoLISP

You can access Microsoft Excel via COM automation ssing Visual Lisp. This is handy, but very slow. It only takes a few seconds when you're not doing that much, but if you all of the data in a large Excel file, using vlax is going to take a very long time (too long for the end user anyway). Really, the best way to handle this is to save your .xls (or .xlsx) as a comma-separated value (.csv) file and use that instead. It's also significantly simpler to do and a lot less things can go wrong. Above all, reading a .csv file is almost 200 times faster than reading the same amount of data from an .xls file using COM.

First, we need a function to actually do the parsing, in this case, convert the comma-separated string into a list.

(defun str2lst (strg delim trim / templist pos)
(if trim
(setq strg (vl-string-trim delim strg))
)
(setq templist (list))
(while (setq pos (vl-string-search delim strg))
(setq templist (cons (substr strg 1 pos) templist)
strg (substr strg (+ 2 pos))
)
)
(reverse (cons strg templist))
)

How the function works should be pretty straightforward. 'strg' is the string to parse, 'delim' is the delimiter ("," in our case), and 'trim' is a T or nil value which tells it whether or not to trim of the excess delimiters at the end, for example:

(setq myline "hats,broccoli,purple,,,,")

(str2lst myline "," T)
;; returns '("hats" "broccoli" "purple")

(str2lst myline "," nil)
;; returns '("hats" "broccoli" "purple" "" "" "" "")

That's pretty much the quote unquote hard part, the rest is in actually collecting the data:

(setq mydata (list)
myfile (open "mycsv.csv" "r") ;; open for read
)
(while (and
(setq line (read-line myfile))
(/= "" line) ;; make sure it's not blank
)
(setq mydata (cons (str2lst line "," nil) mydata))
)
(setq mydata (reverse mydata)) ;; reverse because of using cons

Now you have your data in a nice list. If you're not comfortable working with lists directly, you could make a function to access the data by row and column.

;; returns nil on invalid row and column number
(defun RowColValue (datalist row column / value)
(if (> row (length datalist))
nil
(if (> column (length (setq value (nth (1- row) datalist))))
nil
(nth (1- column) value)
)
)
)

Happy lisping.

Network-based OpenDCL deployment

Almost anyone who's programmed in AutoCAD is familiar with dialog control language, or simply DCL. It's an old crappy and complicated language for making dialog boxes accessible with AutoLISP. DCL is the way of the past...OpenDCL is the future. It was derived from a now GPL'ed third-party extension called ObjectDCL. It is now maintained by some of AutoCAD's finest; Owen Wengerd (of ManuSoft fame), for one.

OpenDCL is vastly superior to DCL in every way. With OpenDCL, you can make your own custom tool palettes with just about anything on them. OpenDCL has event handlers, drawing preview boxes, drag and drop support, block view boxes, hatch view boxes, just about everything you'd ever need. On top of that, it has a user interface designer (OpenDCL Studio) that makes all of this a breeze. Most of the work is done in OpenDCL Studio designing the UI and specifying what AutoLISP functions to call on a certain event, i.e. a mouse click, a drag and drop, a list selection change, etc. In essence, OpenDCL gives you the power of ObjectARX and MFC in AutoLISP.

Anyway, this is all off-topic. Those who don't know of OpenDCL's power should check out it's website, using anything else is a waste of time.

The only issue with OpenDCL is that it's not already integrated into AutoCAD (unlike DCL). You have to install the runtime which copies all of the ARX files and tells AutoCAD to load them upon typing "opendcl" at the command prompt in AutoCAD. Well, all of this is changed, because you can simply place the OpenDCL files in a network location and use a few lines of LISP to tell AutoCAD to load the correct file, thus eliminating the need to install the runtime on every computer. Alternatively, a .msm Windows installer merge module is also provided so that you can merge that with an existing .msi installer package, but .msi's don't always play nice. Plus, what if AutoCAD is already installed on all of your computers? That'd still be one installation too many.

Procedure:

1. Install OpenDCL Runtime or OpenDCL Studio onto any computer. These can be obtained from the OpenDCL website.


2. Copy all files in the C:\Program Files\Common Files\OpenDCL directory to a network directory of your choice.


3. Use the code below to load the proper ARX, when needed.

Code:

;; slashes must be doubled, i.e. "C:\\Somewhere\\Somewhere else"
;; path must not end with slashes
(setq OpenDCLLocation "wherever you put the OpenDCL files")

;; detect if computer is 64-bit
(if (vl-string-search "64" (getenv "PROCESSOR_ARCHITECTURE"))
(setq OpenDCLFilename (strcat "OpenDCL.x64."
(substr (vlax-product-key) (1+ (vl-string-search "1" (vlax-product-key))) 2)
".arx"))
(setq OpenDCLFilename (strcat "OpenDCL."
(substr (vlax-product-key) (1+ (vl-string-search "1" (vlax-product-key))) 2)
".arx"))
)

;; detect if ARX is already loaded
(if (not (member OpenDCLFilename (arx)))
(arxload (strcat OpenDCLLocation "\\" OpenDCLFilename))
)

That's it. If you ever need help with OpenDCL, just go to the forums. There are lots of helpful people like Owen himself and Fred Tomke. I also frequent these forums, but am not as experienced as they are.

Windows/Linux equivalents/replacements

Been messing around with Linux for quite some time now, largely due to free CFD/FEA software like Code_Saturne included in CAELinux, and of course the ever popular Ubuntu. I almost feel dirty mentioning Ubuntu, it's like the iPod of Linux distributions; the trendy-not-necessarily-the-best product. At least it's free, right? Back on topic, aircrack-ng included in BackTrack is also pretty cool...got to learn how easy it is for crackers to get into your wireless network and/or decrypt your traffic unless you're using the latest encryption (WPA2 AES 4tw).

Over the years I've been able to do more and more with free software (freeware and/or truly free software), but majority of it is freeware designed solely for Windows, only a few projects (VLC Media Player, OpenOffice, Audacity, ZSNES) are cross-platform. As a programmer, I understand the pain of writing portable code and realize that you can't accomplish everything with just standard libraries; there's always going to be something that needs platform-specific code.

Ubuntu already has a lot of the things you need out of the box: OpenOffice, Evolution (email client), Pidgin (a cross-protocol instant messaging client; not going to link to it because I don't like it all that much, although it does what I need), and of course, Firefox. I didn't write this to endorse Ubuntu though; there are already far too many sites that do that. I don't think that Ubuntu is bad, in fact it's great, it just makes some things too simple I think. Of course this is great for introducing the world of free software to non-technical people and others who simply though there wasn't anything besides Windows or OS X.

Anyway, here's a list of free programs I used on Windows and what I use on Linux (will use really, I compiled this list so that when I finally make the switch I won't be lost).

Windows - Linux

Defragmenter: Defraggler - Not needed; the Ext filesystem is more resistant to fragmentation.

Cleanup: CCleaner - Again, not needed.

Archiving/encryption: 7-zip - k7z
The LZMA algorithm is superior to zip, bzip2 and rar...it'd be a shame to leave it behind.

Music: Winamp - Audacious Media Player
Audacious Media Player is superior; I wish I could use it on Windows. It supports almost every file format without having to hunt down plugins. It plays almost every module, chiptune and video game music format right out of the box. Fantastic.

Office: Microsoft Office - OpenOffice
(Included in Ubuntu)

Solid modeling: Autodesk Inventor - BRL-CAD

CD/DVD ripping/burning: ImgBurn - Brasero
(Included in Ubuntu)

File synchronization: SyncBack - JFileSync

Batch renamer: ReNamer - Metamorphose

IP blocking: PeerGuardian - MoBlock

Torrent client: BitComet - Transmission
(Included in Ubuntu)

Workspaces: Dexpot - Built in to Ubuntu

Image editing: Photoshop or Paint.NET - GIMP
(Included in Ubuntu)

Computation: MATLAB - GNU Octave
Frontends for Octave:
Xoctave - Almost identical to the MATLAB GUI.
QtOctave - Less similar to MATLAB GUI, but has a portable version and some extra tools.

Most of these can be found in the package manager :)

Endianness in C

I ran into the problem of endianness when I was first starting out my most recent project to directly synthesize .au sound files. I thought I'd share some of the things I found out.

First off, endianness is the order that computers store octets in memory. A value of 1 on a big-endian machine would look like this as a 32-bit integer in hex: 00 00 00 01, whereas it would be flipped on a little-endian machine: 01 00 00 00. The least significant byte (LSB) is stored at the lowest address on little-endian machines. Keeping this fact in mind, it's easy to determine if a machine is little-endian or big-endian:

unsigned int unity = 1;
#define is_littleEndian() (*(unsigned char *)&unity)
// will return 1 if little endian, otherwise 0

Just making a char out of the first octet in the unsigned integer. If it's little-endian, the 01 will be in the least address, returning 1.

Now that you've determined whether the machine's endianness, let's review some ways you can convert from one to the other. Ints are simple enough:

int32_t endianSwap(int32_t a)
{
return a << 24 & 0xFF000000 | a << 8 & 0x00FF0000 |
a >> 8 & 0x0000FF00 | a >> 24 & 0x000000FF;
}

This works with both signed and unsigned integers. You may be asking yourself why I included the bitwise OR operations with the left and right shifts by 24. Well, right shifting signed integers is not implementation defined. The vacated bits may be filled with 1s or 0s. This is simply a precaution.

Converting floating point numbers is a little more involved, and you can't exactly convert to another double (you can, but it just makes more sense not to convert back). This is handy if you're writing data to a file.

uint64_t bigEndian_double(double a)
{
uint64_t b;
unsigned char *src = (unsigned char *)&a,
*dst = (unsigned char *)&b;

if (is_littleEndian())
{
dst[0] = src[7];
dst[1] = src[6];
dst[2] = src[5];
dst[3] = src[4];
dst[4] = src[3];
dst[5] = src[2];
dst[6] = src[1];
dst[7] = src[0];
}
else
b = *(uint64_t *)&a;

return b;
}

Comments are welcome.

Dealing with Images

Here's the last article I wrote at my old site (no images again).

Herein lie some techniques you can use to make the best of the sometimes arduous task of using images in your drawings, for more often than not it's unavoidable. If you're lucky, you'll get to work with a high quality image, hopefully not a JPEG. Or, you might have the original drawing, and assuming it's in good shape you can re-scan it to better suit your needs. But also more often than not, the image you'll have will be poorly scanned by someone unaware that the image will be reused in another drawing. Of course, this problem would be solved if companies/entities working on a common project would share drawings amongst each other freely, but that's almost never the case, so here we are.

Before reading further, it's important to keep the following question in mind: do I want to edit/copy then edit the image file (as opposed to using the original)? There are times when it's not permissible to edit, let alone copy, an image file, in which case you're stuck using the following commands to tweak it. Call it poor man's Raster Design, if you will. But, if you can edit or copy the original image file, it might be less complicated to use an image editing program to tailor the it to your needs. If you choose that route, be sure and save the image in a lossless image format, like a BMP, PNG or TIFF (sometimes). Chances are the original image file is from a scan or is a lossy image format like a JPEG, so you want to use one of the aforementioned lossless image formats to preserve whatever quality you can.

Tip: Install the Raster Design Object Enabler to enable AutoCAD to import additional image formats (see image below). The enabler can be downloaded here.

The ALIGN Command

The first step after inserting an image is using the ALIGN command to make it orthogonal. The ALIGN command asks you to select objects, and to choose two pairs of source and destination points. What it's really asking for is the basepoint and endpoint of an alignment vector representing the original object (the source vector), and another set of points signifying the target alignment vector. With that information, it will align the original objects to the new alignment vector relative to the source vector. In the case of the image below, the square is being aligned to the target vector (red).

The above image makes it clear what we've set out to do. Most of the time, your source vector should be a line that was almost certainly orthogonal in the original drawing. More often than not, it's a border line on the title block. It's easiest to use one of these because they're certainly going to be the longest lines available from the image, which will provide the highest level of accuracy when aligning. Once you've chosen what line you're going to use as a source vector, switch to ORTHO mode and draw a perfectly horizontal line so you'll have something to use as a target vector. It doesn't matter how long the line is, because you're only using the line for alignment, not scaling. Now you can use the ALIGN command and align the image.

If you've taken your time in selecting your source points, the image should be pretty orthogonal. Zooming in to the line you wish to use in the image helps; that way you can click the exact centers of the endpoints in question.

Or, you may not want to align your image orthogonally at all. For instance, if you're working with an aerial photo, you probably want to align the centerline of a road or a property line (in the image) with some part of a parcel or tract map (in your drawing), or something to that effect. This time the game changes, because you'll want to make sure and use the 'Scale objects based on alignment points' option in the ALIGN command. When you insert the image, it's never properly scaled. But with the ALIGN command, you can correct this. You can choose a reference common to both the aerial photo and the parcel map, such as section corners, allowing you to align and scale the aerial photo properly.

The IMAGECLIP Command

The IMAGECLIP command is used to 'clip' off the undesirables of an image. The command is straightforward; the first prompt asks if you want to either turn the boundary on (ON) or off (OFF), create a new boundary (New boundary), or delete the existing boundary (Delete). When you use the 'New boundary' option ('n' for New, or just hit ENTER as New is the default option), the command asks you if you'd like to make a rectangular or polygonal boundary. The 'polygonal' option ('p' for Polygonal) is much like the POLYLINE command, previewing the closed boundary (see image below).

As stated before, with IMAGECLIP, you can hide the undesirables of the image/scan, like the title block or certain views. For instance, you may want to isolate certain views, and you can do this by copying the image and creating different clipping boundaries for each instance of the image. That way you'll be free to move the different views around, unrestricted by the positioning of the original image. Note that clipping the image in AutoCAD does not modify the image file and that you can restore the image to its original appearance by simply deleting the existing boundary using the IMAGECLIP command.

The IMAGEFRAME Command

Along with IMAGECLIP and images in general is the IMAGEFRAME command. Because of how the command works, it should really be a system variable, but it's not. IMAGEFRAME simply asks you to choose an integer from 0-2, inclusive. IMAGEFRAME=0 turns off all image frames, so you won't see any more polygon borders around any images, making selecting any image difficult. IMAGEFRAME=1 turns on all image frames, and makes the polygon borders plot just like normal lines. IMAGEFRAME=2, the default, shows all image frames, but does not allow the polygon borders to plot. The image itself will still be plotted, but not the polygon borders. This command is still around for nothing more than user preference, as IMAGEFRAME=2 seems to be the intelligent choice for almost every situation.

The WIPEOUT Command

The WIPEOUT command can be used to block out/hide certain parts of images, among other things. A wipeout object is really a blank raster image, but it has its own object class in AutoCAD. Using wipeouts is different from using IMAGECLIP in the sense that the created wipeouts will not be a part of the image entity; wipeouts are separate entities, acting on other entities as well, not just images. Note that the draw order of the wipeouts must be kept in front of the images for them to work, since they're separate entities.

The WIPEOUT command is also straightforward and very similar to the POLYLINE command. Unlike IMAGECLIP, there is no option to create a rectangular boundary, as the command defaults to drawing a polygonal boundary. Alternatively, you can create a polyline to define the new wipeout, and use the 'Polyline' option to make a wipeout from that polyline. Note that you need to go back to the WIPEOUT command, choose the 'Frames' option, then select 'OFF', unless you want the wipeout boundaries showing on both the screen and when you plot. As with the IMAGEFRAME=0 setting, turning the frames off makes it impossible to select the wipeouts, so you must turn the frames back on in order to move them around when making any changes to the drawing. Unfortunately, there isn't a setting to still show the wipeout's boundary in the drawing, but not plot it, as with IMAGEFRAME. There's no way to get around it without turning the wipeout frames off. This is because wipeouts are blank raster images; raster images on no plot layers don't plot at all, therefore wipeouts on no plot layers don't plot at all, either.

Note: When using wipeouts with PDFs, turn the wipeout frames on and make the wipeouts color 255 to avoid blacked out areas.

MTEXT Background Masks

MTEXT entities have a very nice feature built into them: background masks. Using background masks, you can place mtext over images and other things without having the text itself bleed into them. This comes in handy when you want to overwrite a piece of text from a scanned drawing, or to make annotations on an aerial photo. As with wipeouts, the draw order of the mtext must be kept in front in order to keep the masking effect.

You can access this feature by clicking the '...' button in the 'Background Mask' field of the properties pane, as shown below.

The settings shown are usually good for any application and should be deviated from only for special cases. 'Use background color' is used to simply block out the space behind the text, only use a specific color if you desire a solid fill behind the text (which will result in a black block, unless plotting in color). On the other hand, this may be exactly what you're looking for if you're creating a map and want to draw attention to labels. Just make sure you're plotting it color.

Tip: If trying to fit a background mask in a specific space, try changing the Border offset factor or moving the grips of the MTEXT entity, as the background mask follows those grips, not the text.

The IMAGEADJUST Command

The IMAGEADJUST command can be used to change brightness, contrast, and fade, as shown in the image below. This comes in handy when you can't edit/copy then edit the image file, but need to tweak its appearance.

As you can see, it is fairly straightforward.

In closing, if you're going to be dealing with a lot of scans of older manual drawings (hand drafted), it'd be more efficient to buy Raster Design than to fool around with the previously mentioned commands. Raster Design is a very featureful add-on that provides raster to vector conversion tools, as well as many other useful tools, like despeckle. Despeckle (command: IDESPECKLE) can be your best friend for those old scans; it removes splotches and junk from the drawing, making text more legible and images more presentable. I highly recommend it if you're going to be dealing with a lot of images. You can check it out here.

The Art of Revision Note Writing

Another one from my old site.

If you're reading this, chances are you've made a revision (or thousands) and therefore have had to create revision notes. Though the idea behind creating revision notes is simple, knowing how to properly write them is a skill not easily mastered, for you face a dilemma: you, the person making the revision, may know exactly what has changed while others may only have a vague idea. Therefore, the purpose of the revision note is to convey the following information: what was changed, how those things were changed, and what brought about the changes. This may seem like a simple and straightforward task, but more times than not the space alloted for the note itself is small, which obviously poses a problem. Now, you must aim to convey the aforementioned information in the shortest fashion possible while not leaving out any of that information.

Before looking at some examples, let's look at what no revision should be without:

• The letter or number (or whatever sort of code you use) of the revision.

• The date the revision was made. If space permits, you may want to include the starting and ending dates of the revision, as opposed to just a single date.

• The name or initials of the person who made the revision. This provides a method of accountability.

• The name or initials of the person who checked the revision (and anyone else relevant to the revision, i.e. the engineer, the project manager, etc.). If you're the person making the revision, this is how you cover yourself.

• A concise description of the changes made. If adding content, describe what was added and where it was added, if possible. If removing content, describe what was removed and where it was removed from, if possible. If modifying content, describe the content before and after the revision.

• A reference to what prompted the revision, generally following the following format: "...per someone (some company or department) (some form of communication) dated mm/dd/yy." Again, accountability. If someone questions the necessity of the revision, they can follow through with the information you provide and get all the facts.

In addition, it's better to both maintain professionalism and to minimize the wording by using a sort of legalese. It's not so much the words you use (although it's better to use more 'formal' words, avoiding slang and the like), but the words that you leave out. For instance, instead of "I deleted the A and B holes as directed by an e-mail I received from the engineer on the 22nd", the following would be preferred: "Deleted holes A and B per (name of engineer) email dated 5/22/08". It is in this fashion, that is, writing in a minimalistic but concise fashion, which we must strive to achieve in order to create effective revision notes.

Here are some examples:

NO: Shortened shaft length per J. Doe e-mail.
YES: Shaft length now 5'-2", was 7'-8". Rev'd per J. Doe e-mail dated 4/1/08.

NO: Corrected tag numbers per customer request.
YES: Corrected control box tagging per J. Doe (some company) phone conversation on 3/17/08.

NO: Updated electrical configuration per engineer.
YES: Increased starter size to 1, was 0, removed pressure switch. Rev'd per J. Doe e-mail dated 5/3/08.

Understand that even though it's easier to write a short and basic revision note, it's necessary to add every pertinent detail to prevent future confusion, therefore saving time and frustration. Even with a revision control system, it's essential to write such notes as not everyone has access to the revision control system, and more importantly, not all drawings are small enough for it to be readily apparent what changes were made between revisions.

The Prophecy

This is also from my old site. It was and still is an open letter to the CAD community.

May 8th, 2008

To my fellow CAD operators, drafters, engineering technicians, designers, engineers, programmers and the like:

It's no secret that AutoCAD has become as Windows has--that is, the big kid on the block. AutoCAD has maintained this position for quite some time now apparently, the length of which is unapparent to me as I've not been on the block for too long--long enough will suffice. How this came to be should also be common knowledge: it was one of the first CAD packages out there when the market was just starting and was lucky enough to fend off the competition to secure its throne. Such is also Windows: in the beginning, there was DOS. There were many flavors of DOS. Then Microsoft, out of their fears of Apple's new GUI (graphical user interface) based OS (operating system), made their own GUI (which not surprisingly had a lot of similarities to Apple's...) to run on top of MS-DOS, called Windows. Then Microsoft convinced several computer manufacturers to ship their computers with windows preinstalled on them, thus beginning its reign. In both cases, the situations were the same--one software company became the pick of the litter by mere chance.

Since Windows' inception, a flagrant dislike was born for Microsoft. Many would like to see some great new OS come along and demolish everything that Microsoft has built up thus far, making a Babylon of software in the process. In the mid-90's, users were even more specific, wanting Bill Gates himself hanged or even worse. Those were the true blue screen days. As such, there have been many attempts to dethrone Windows, with little success. Apple has tried and is still trying to fight for the throne with its mongoloid-esque advertising campaigns, dribbling about this nonsense of 'Mac vs. PC' when nowadays it's so clearly OS X vs. Windows. Apple started building their machines with 'PC' hardware back in 2005, and now the only differences lie in the software. But that's a different story. Linux tries to show users that there are alternatives, not so much to dominate, since most Linux distros (distributions) are given away free of charge. As such, Linux doesn't have much to gain by dominating the market when there are no real profits involved.

So far, Linux is the only OS that has come close to taking over. Linux has taken a great bite out of the server market because servers don't directly deal with the proprietary software and file formats exclusive to Windows--they only have to store and serve them. This is the dilemma: most software is written solely for Windows. To counter that, macs now have the ability to install and run Windows alongside OS X. Also, the Linux community has started projects like Wine, Mono and DotGNU to allow most Windows applications to be run on Linux. For some, that seems like more work than it's worth. For others, the fact that Linux is free (most distros anyway) is enough to completely pry them from everything they've learned on Windows to start anew, that is, relearn how to use a computer altogether since Linux works differently than Windows. Of course, there are Linux distros to make that transition less painful, like Ubuntu.

Both Windows and AutoCAD thrive off of the common concept that once a user becomes tied down to specific software due to proprietary file formats or otherwise, a threshold is created that must be crossed in order to make the user switch to another software package. The threshold is crossed when the benefits (better features, easier to use, less costly, etc.) of another software package outweigh the drawbacks of switching from the current package: taking time to learn the new package, dealing with whatever file format issues that may arise (incompatibilities, dependency on third party converters), leaving the existing comfort zone with that current package, and dealing with the resultant changes from making the transition. Those resultant changes may be any of the following: switching OSes, getting new third party software packages to replace the old ones, billing changes due to change in productivity, etc. Because they know their own position in the market and that this threshold exists, they exploit it by putting less effort into software development and more into advertising...while current users are disgusted, the company can secure its throne by acquiring more users through advertising, and of course, by already being the industry standard.

As such, we arrive at the current problem that most are well aware of: 'they exploit it by putting less effort into software development and more into advertising'. With the 12 month release cycle, and its said stranglehold on the industry, Autodesk has put less and less effort into making a quality product. Instead, they focus on making the product attractive to possible customers by adding as many bells and whistles as possible. Meanwhile, they fix other problems as it suits them in order to keep the existing users somewhat quiet. Our lack of communication is their advantage. Even if we all were aware of this, what would we do? What is there to do? Most of the CAD industry hinges on the proprietary DWG format that Autodesk itself created and still maintains. To combat this, the ODA (Open Design Alliance) was created, and now provides developers with a set libraries called DWGdirect to read/write drawing files based on the OpenDWG specification, which is based off of Autodesk's original DWG specifications. This luxury comes at a price, of course. This has helped somewhat, as many other CAD software companies use these libraries to achieve compatibility, i.e. Bentley Systems Inc., IntelliCAD Technology Consortium, and Dassault Systemes S.A. (makers of SolidWorks).

But this is only a band-aid, as Autodesk truly controls the DWG format since they are the leaders of the CAD industry. In addition, with every new release of AutoCAD new objects are added and changes are made to the format itself, making things more difficult for the ODA and consequently blocking the companies that use DWGdirect from making software packages that could ever be truly compatible with AutoCAD DWGs. Autodesk offers a similar set of libraries called RealDWG that can read/write natively in the DWG format, but as with DWGdirect, this luxury comes at a price. Even though this allows other CAD software to be 'fully' compatible with Autodesk DWGs, it's no good because Autodesk still controls the format. Sure, the ODA could try to fork off from Autodesk's standard, but take a guess who's going to win that battle. (Note: even with RealDWG, applications can't be truly compatible because AutoCAD sets the standard for rendering objects, meaning that only AutoCAD can render DWGs correctly. This has been proven by XANADU Inc.'s BUDWEISER compatibility benchmark: "So far no non-Autodesk application has succeeded to read and interpret this drawing in all its tests.")

All these things considered, what can we do about it? No other software package has come close to threatening AutoCAD's position because of the aforementioned reasons. I believe the underlying reason for this is a more central one: the price, or rather the existence of a price, and the manner in which problems are fixed. I cite the OS battle as an example. The only OS that's making any progress towards fighting Windows is Linux. Why? Because people are getting fed up with the same old stuff: problems with Windows that don't get fixed until the next service pack (which means months), or even the next major release. Because Linux is open-source, problems are addressed as soon as they are found, eliminating the lengthy wait for a simple bug fix. On top of that (and more apparent to users I might add), is that people are noticing that the price of Windows is increasing with time, which makes free Linux look all the more attractive. This is the beauty of FOSS (free open-source software).

Let's take the same scenario and see how it applies to AutoCAD. AutoCAD has the same problems: owning a copy of the biggest boy on the block comes with the biggest price on the block, and users are forced to wait until the next major release for most bug fixes. The service packs don't fix much, if anything. Therefore, we must venture to solve the problem in the same manner--that is, make a FOSS replacement for AutoCAD. Such a task might take years, but imagine the benefits and admire the beauty of the idea...a CAD program created and maintained by the people who actually use CAD on a daily basis. The core features will be as we see fit, taking shape from discussions and contributions. Open-source works: if there's a disagreement on a feature, there's no need to walk away angry, both methods can be implemented and the choice between those methods would become a new setting. Of course, most of us are not programmers, and this is why it takes some initiative to begin to make something like this a reality. The features/benefits and the actual feasibility of such a project must be made clear.

From now on, the software package that will be created from such a project will now be referred to as 'the package' or 'the project'. I say 'will be' instead of 'would be' because the latter implies an if: 'if it were created, it will be' instead of 'it's going to be created, and it will be'. There's no way that users will put up with these same antics forever. First and foremost, the package will be entirely free. This is paramount to the package's success, because only by being free will it have the power to pry people from other CAD packages. Through YOUR involvement in this project, you--the people who work for companies who use CAD software--can make those who must know know that it meets your company's needs (and if it doesn't, you are empowered to help it start to meet those needs) and that it won't cost a bundle to implement. In addition, won't it be nice to have a copy of CAD at home without having to borrow a license?

This brings me to my next point/feature: 'it won't cost a bundle to implement'. Because the project will be based on community involvement and contributions, more likely than not, the support created for the package will be enormous. Transitions from existing CAD packages will be made as painless as possible because those who decide to contribute will already be the users of those same CAD packages. Paying for training will be a thing of the past!! When new features are implemented, they will be heavily documented by the contributor(s) because they themselves and other contributors need to know exactly how the new feature works and integrates with the package. Through communication, each new feature will slowly drip down from the programmers' point of view to the end users' point of view, allowing for maximum understanding of all features.

The next feature: portability. As we aim to cater to users' choice and needs through the core features, we must also aim to allow them keep that choice by choosing what OS they desire to use the package with. This is also paramount to the package's success. One ongoing complaint of AutoCAD users is that it can't be run natively on OS X or Linux, and as such users have been pleading for versions that will do so. Also, as a matter of philosophy, users shouldn't be forced to switch to another OS or stay with one they don't like just to use one piece of software. Choice, simply put, is what makes and keeps users happy. Therefore, the package will be portable, working on a variety of popular OSes. OS independence can be accomplished by writing the package in a portable, cross-platform programming language. I say it should be written in a lower-level programming language, like C or C++, to foster portability and alleviate performance concerns. OS independence also means that the package can't be tied down by utilizing proprietary software (.NET^TM, DirectX), and therefore will only use free software and libraries, like OpenGL. Also, with the same aforementioned user empowerment, if a user has a specific OS that they'd like to use it with, they are empowered to port (convert code to work on another platform) it to that OS because the source code will be 'open' (available to all), or at least request that it be ported.

Performance should be kept in mind at all times. Users have been complaining about AutoCAD's performance for many years now. The first example that comes to mind is data links. Data links take an exorbitant amount of time to create and insert as tables into drawings, while third party add-ons can do the same thing in a fraction of that time. This more than anything goes to prove how little Autodesk cares about the end users and producing a quality product. When you come right down to it though, the little slowdowns only add up to a few minutes of lost time per week. That's besides the point though, because what happens is users' productivity is affected when they must deal with those slowdowns. Frustration, impatience and the like makes for unhappy users and lower quality work. As stated before, this will be accomplished by using a lower-level programming language. In addition to that, having a wide variety of programmers in the immediate community provides a means of filtering out inefficient code, leaving only sheer brilliance.

Part of satisfying user choice is providing flexibility and customizability. The package should be as flexible and customizable as possible, providing exactly what the user needs and wants. If the user wants an extensive UI (user interface) then let the user have it. If the user wants a bare-bones UI, again, let the user have it. The UI should be exactly what the user wants: no more, no less. For example, the troublesome InfoCenter in AutoCAD can only be disabled by using a registry hack. Probably a better example would be the new ribbon. The ribbon, introduced in 2009, was not received well by most users. Users found themselves lost, having to dig and dig to find out how to get AutoCAD looking the way it used to look (dashboard, workspaces, etc.). Should a user have to go to this extent to disable a feature? No. This is exactly my point: the user should be empowered with choice from the very start, being able to choose exactly what he or she wants.

Many of you may be thinking, why should I contribute to such a project? The most important and straightforward answer is that it will directly benefit you yourself, whether you're a user or a developer. When the project reaches near maturity (stable release) and a solid package is created, it will affect the other CAD software companies, mainly Autodesk. Competition will be increased, which means that prices will equalize/drop and everyone will be forced to make products of greater quality in order to keep up, especially Autodesk. As such, there are two possible end results: the project replaces AutoCAD as the industry standard, or more likely, competition is increased enough that existing CAD packages improve drastically. With the previous statements in mind, remember that the idea is to provide ourselves with a great free tool, while increasing competition at the same time. As such, we're not going stamp out other CAD developers, but help them in a few ways. By increasing competition, work will be created for existing CAD developers as they must implement their company's version of our new features as we create them. At the same time, we will provide those same developers with models of how to implement those new features, as the source code will be open.

Besides, isn't it about time we had a fully featured free CAD package? There's well-developed free and open-source software for every software category except CAD. The only thing that comes close to qualifying is Archimedes. But, Archimedes is focused solely on architecture, and that just won't do. On top of that, it's written in Java^TM, which many critics argue produces slow applications compared to similar programming languages. We, the mathematics and engineering elite, should have been one of the first to take an initiative towards FOSS a long time ago. We've fallen far behind, and it's high time that we do some catching up.

Sincerely, Jacob Abel a.k.a. thatcadguy

Note: A Mr. Foley pointed out to me shortly after I made this article that another reason that it's essential that the package is free, as in free of charge/non-profit, is that Autodesk has in the past bought the competition. REVIT and what's now the add-on electrical package are the two best examples. REVIT used to be owned by another company and the electrical package used to be Via Circuit Design, both now absorbed by Autodesk. So you see, it's truly essential that it be non-profit and that it be created by those with that thought in mind, as to avert any would-be attempts by Autodesk to absorb it.

Increasing Your CAD Speed

Here's another one from my old site (minus the pictures).

First, a bit of theory: Increasing your speed by just working faster is not very efficient at all. To efficiently increase your CAD speed, you must first master your technique...if you're a very fast individual, but don't know simple shortcuts, you're no good to anybody. But, if you're very fast and you know the most efficient way to do something, you will be regarded as masterful. That being said, through my experience, the best way to accomplish this is to optimize the way you interface with the computer via keyboard macros, and to learn how to efficiently and effectively locate points (as in locating the point five inches from point A, as well as being 45 degrees from point B, as opposed to locating some place in a drawing). On top of those, CAD is all geometry...a person with a very good geometry background as well as mathematics in general is not going to have very much trouble getting well accustomed to CAD.

Improvement through Human-Computer Interface

There has been some debate whether using the keyboard (via macros, shortcuts, etc.) is faster than using the mouse (toolbars/menus/tool palettes). Of course, you must use both...but for every individual, it's likely from previous computer experience that they are either mainly accustomed to keyboard shortcuts (like DOS users) or mainly accustomed to clicking buttons with a mouse (users introduced in this GUI-dominant era). Personally, I think the keyboard is superior. As a gamer, I must master key combos, therefore, it's very easy for me to enter two or three key macros into the command line in AutoCAD and hit the spacebar in under a second. Granted, if you're that proficient with a mouse, you could probably match the speed of a keyboard user, but I'd say its common sense that it's easier to learn to do key combos than to acquire the finesse required to click through menus/dialogs/buttons.

So, to get you started down this key-filled road, a good place to start is editing your PGP (ProGram Parameters) file. The acad.pgp file controls the keyboard macros that AutoCAD recognizes at the command line. To achieve this, you can use the Command Alias Editor in AutoCAD, which is provided as a part of the Express tools. It is located in the menus as Express>Tools>Command Alias Editor. Alternatively, you can just type in 'aliasedit'. In the editor, you can easily edit every macro/shortcut a.k.a. 'command alias' for every function.

The key is to have the shortest command aliases possible, while still maintaining some level of description. I mean if you use the block editor quite often, what sense does it make to have to type in 'bedit' every single time, when you could just type in 'be', or whatever alias it is that you desire? BEDIT isn't too good of an example, but you get the idea. It adds up typing out all those long command names, believe me. Or, if you REALLY like memorizing keys and want to achieve maximum speed, you could make aliases with the keys around where your hand typically sits on the keyboard. Either way, keep common sense in mind when making your aliases. For example, the one letter aliases should be reserved for the commands you use more often, while the longer two or three letter aliases should be reserved for the less used commands.

For example, my right hand is most always on the mouse, and my left hand is in the normal position on the keyboard. You might have a similar setup, or will anyway. Even though I still prefer to have aliases that make sense, i.e. abbreviations, it's pretty obvious that it'd be faster to make commands associated with combinations of the leftmost keys on the keyboard if you're going to assign your left hand to accessing commands. The shorter the distance your hand has to move, the quicker you can type things in, right?

Starting with AutoCAD 2007, you can use the CUI editor to control almost all aspects of the user interface, hence 'CUI' (Customizable User Interface). The part we're interesting in is the 'Keyboard Shortcuts' section, of course. The CUI editor is in charge of a different class of keyboard shortcuts--that is, the ones that are instant (they do not require a return or a hit of the spacebar) and typically are paired with another key like CTRL or SHIFT. The CUI editor can be accessed by typing in 'cui' at the command line. Using the CUI editor, you can drag and drop commands into the 'Shortcut Keys' portion of the 'Keyboard Shortcuts' section to create new keyboard shortcuts.

The CUI editor has two lists: a list of customizable items and a list of commands. In the right column, there is another list: existing shortcut keys. Right below that are the specifics for the currently highlighted shortcut. In this pane, you can change the key combination used to activate the command and tweak the macro itself, if desired. The usefulness of the CUI editor becomes clear; it gives you complete control of almost all aspects the user interface...if only they would integrate it with normal keyboard shortcuts so everything was in the same place.

The improvements in key usage mentioned above are the most effective ways to increase your speed in interfacing with the computer. But, there are other ways...the next of which that I'll discuss is ergonomics. As with your hand and typing, the key to utilizing ergonomics is to keep in mind that the shorter distance you have to move, the faster you can be. Staying close to the previous topic, you'll first want to consider your arms/hands and what they do, and what their positions are, typically. The first step is to raise or lower your chair until your armrests are level with your desk while the chair is under load. This minimizes the rule that wrist fatigue can have over you while drafting or otherwise.

Next is positioning your monitor(s). You'll want to place them so they point directly at the center of your face and so positioned that you don't have to always have your neck turned or bent uncomfortably to gaze directly at the monitor. Also, there's one more thing to keep in mind when positioning your monitor...something that no one I know of has talked or complained about: the hassle with having to move your head far off to the side of you (compared to the monitor) to look at plans or cut-sheets, whatever it is you're working with, and then having to move it back. As with your hands, the farther you have to move back and forth, the more time it takes your brain to readjust itself to what it was you were looking at previously on the screen before you glanced over at your plans. Granted, this is another little thing like typing commands that only takes a few seconds at most, but these things add up; it's more than just the fact that it takes more time than another method, it's the fact that in general, the longer and more tedious a task is, the more it takes away from your ability to work. Back to the subject, my solution to the problem is the most straightforward one anyone could possibly think of, and that's positioning your monitor closest to the space that your paperwork usually occupies. The whole idea is that the more you can keep your monitor in your peripheral vision, the easier it is for your brain to readjust, if it even needs to.

All that being said, I've taken it to the next level with positioning my monitors, which required some unorthodox methods. My current setup which works quite well, is to place clips to the side of your monitor on the wall behind your computer (hopefully you have a wall). You'll need at least two, and to space them about the same distance apart as the width of the standard paper size you typically work with, because you're going to hang your work up on the wall. In this fashion, you need only rotate your head by a slight amount to look directly at your work, as opposed to looking down and over at something on your desk.

Or, if you really want to get creative and expensive, get a flat-screen TV or monitor and hang it on an open bit of wall directly above your desk. Your immediate work will be right below the screen, on the desk. Again, the distance is smaller, as well as letting you keep the monitor within your peripheral vision. Personally, I prefer the first method. The only flaw with the first method is that it gets rather tedious (having to get more and more clips to secure papers on the wall) if you have a lot of papers that you're focusing on, whereas the second method allows you to just arrange them on the desk in front of you.

Locating Points

This bit on locating points should be more of review than anything else, but there's a reason I'll take the time out to go through all of it. First and foremost, Osnaps are your best friend. Below is my standard setup (OSMODE=4607).

Whether you like to have your osnaps on all the time or not (F3 to toggle), it's essential to know the underlying geometry behind them to use them effectively. I'll leave that to the educational system and the internet though. Besides the more obvious reasons for using osnaps (placing something on the exact end of something else, etc.), they have other uses, mostly for moving/copying or constructing other geometry. For example, if you have something with an associated piece of text sitting next to it, and you need to copy it to other similar objects in the drawing, osnaps are a superb tool, since you can use a geometric reference to copy things around, like a midpoint, end point, center point, etc.

This may seem like child's play, and it certainly is, but bear with me. Points of reference (utilized via osnaps or otherwise) are essential for geometry based operations such as arraying, rotation, mirroring, moving, copying, trimming; you name it.

All that being said, know that you can single out any specific osnap and make it override the current osnap setup (whether you have osnaps on or not). So if you're used to not having them on anyway, no problem, you can still access them anyway. This can be accomplished by a long right-click:

...or by my favorite, three letter key combinations.

Combo	OSnap Override
end	Endpoint
mid	Midpoint
cen	Center
nod	Node
qua	Quadrant
int	Intersection
ext	Extension
ins	Insertion
per	Perpendicular
tan	Tangent
nea	Nearest
app	Apparent Intersection
par	Parallel

If you are not familiar with them (you should be), rather than my trying to explain them, it's more likely that you'll get more out of just looking at the name of the override itself, and then trying it out in AutoCAD. Use them (and any other command modifier) during any function. These are handy for geometry intensive areas; this way you can pick out whichever geometric feature you desire.

For locating points relative to others, there are other command modifiers. The simplest is direct distance entry, where you simply point your crosshairs in the direction of the next desired point, and enter the distance. This, as well as all command modifiers, can be used in conjunction with ortho and polar. This offsetting method is especially useful; you can place your crosshairs on the geometric feature of another object (thanks to our good friend, osnap) and locate a point whatever distance towards that feature.

Similarly, if you want to use this same method, but from a different point of reference, not from the previous point, use the 'from' command modifier. Type in 'from' or 'fro', and it will ask you what point you would like to use as a reference, and then allows you to use that point as such.

Also similar is relative point entry. This consists of entering the @ symbol along with numerical data to locate the next point. Like some of the other command modifiers, this is typed in place of clicking a point.

Geometry	Method	Format	Example	Explanation
2D	Relative	@x-distance,y-distance	@2,3	makes a point 2 away in the positive x-direction and 3 away in the positive y-direction from the previous point
2D	Polar	@distance	@12<45	makes a point 12 away in the 45 degree direction on the xy-plane from the previous point
3D	Relative	@x-distance,y-distance,z-distance	@4,1,7	makes a point 4 away in the positive x-direction, 1 away in the positive y-direction, and 7 away in the positive z-direction from the previous point
3D	Spherical	@distance	@3<45<30	makes a point 3 away in the 45 degree direction on the xy-plane, 30 degrees above the xy-plane, from the previous point
3D	Cylindrical	@distance	@2<35,6	makes a point 2 away in the 35 degree direction on the xy-plane, 6 away in the positive z-direction, from the previous point

Next come the scant used command modifiers, but useful nonetheless. To locate a point between two points (without making an additional line), just type in 'mtp' or 'm2p', and it asks you for the two points. Simple, straightforward. You can also locate points using parts of coordinates from other points, like the x-coordinate of one point and the y-coordinate of another point. You can achieve this by typing .x, .y, .z, .xy, .yz, or .xz. For instance, .x takes the x-coordinate of a chosen point; .yz takes the y and z coordinates of a chosen point, and so on. The point will be created once AutoCAD has all three component coordinates (x, y, z).

Now that you've been fully introduced to the other command modifiers, it's time to look at the last and most useful, osnap tracking. Osnap tracking is a method of locating points from reference points using the previous methods, but with less typing. Simply putting the crosshairs over an osnap makes it a reference point once the osnap icon appears over it, and you can use it as a reference point to go from, etc. You can even use it to locate the polar intersections from two points of reference. The best way to learn how to use osnap tracking is to use it, not to try and read up about it. So instead of my trying to explain further, do yourself a favor and get to it.

Now, keep in mind that any of these command modifiers can be used with each other as much as you please. They can be nested as far as you please. Don't get too carried away though.

Writing/Using LISP Routines

I'm sure everyone has heard of AutoLISP (LISP for short) by now. LISP is one of the more popular programming APIs in AutoCAD. To the point: if there are things you do often that are quite tedious and simple in nature, there's a very good chance you could benefit by investing some time in learning LISP. LISP is great for simplifying the things that are specific to your particular needs; the things that simply aren't satisfied by the 'broad' (I use that term lightly) tools provided by Autodesk.

LISP routines can be written for just about anything that doesn't really require major problem solving. It all depends on how much code you want to write. They can be very complex, such as the one-line automation system I created for work, or very simple, like the polyline join routine I use on a daily basis (PEDIT slows things down with all those prompts).

In addition, it's handy to be familiar with LISP, in order to check over the routines you get from other places (the internet or otherwise). I say this because for one, AutoCAD is ripe with security flaws. For instance, LISPs and routines from the other APIs can read and write registry values without any sort of consent or warning. You do the math.

Now, I'm not going to attempt to teach or explain LISP, because I don't exactly know where the best place would be to start. There are plenty of sites on the internet that explain LISP better than I ever could. Visit my links page for some of the must-know sites. The two pointers I will give are: learning by examples is far better than theory alone, and get ready to wear out your parenthesis keys.

Notes

Recently, there has been some talk about using a certain gaming controller with AutoCAD, specifically one belonging to Belkin called the Nostromo SpeedPad n52. While it has a nice setup and the ability to have 56 different macros (probably even more than that), it is not a full keyboard; therefore, it would only benefit those who don't have to type sentences very often since any advantage gained would be lost if you had to move your hand back and forth between the normal keyboard and the Nostromo often. So unless you don't need to type full sentences in notes or use other keys exclusive to a normal keyboard often, I'd advise against any such use as you'd just be better off setting up macros on a normal keyboard. That way your hand can stay in one position, minimizing the distance it has to travel on average.

Good Practices (a.k.a. CAD Theory)

This is from my old site, cadgasm.tk (now defunct).

There are certain practices and standards that all well-experienced CAD users would agree are good and favorable. When I say good, I mean that these practices generally keep overall work to a minimum and make that work much less unpleasant and tedious in the long run.

• Adhere to your company's CAD standards. Whether they're good standards or not, it's better to adhere to them than to stick to your own. If you don't, someone else has to correct your mistakes (as they should, even though you should've done it right to begin with) when they open your drawings and find out that they aren't in line with those standards. Plus, you might have an unpleasant encounter with a supervisor or manager in your future if you choose to habitually ignore company standards. If your company's CAD standards are inefficient, don't keep silent, say something about it. It shows you know what you're doing and is a good way to get ahead in the business world by trying to introduce new or better ideas.

• If you see something that you think or know will need to be changed, i.e. the appearance of a block, it's much better to change it early in the game than to have to change it when it's in ten times or more drawings some time down the road. This saves time and frustration. It can be a pain to adhere to this rule sometimes, but it's always more of a pain in the rear to fix the problem later than to fix it when it first becomes apparent to you.

• When you send drawings to anyone, make sure you send everything required. Typically, using eTransmit is a good practice because it takes everything needed and wraps it up in a .zip file for you. The drawings, the xrefs, the fonts, the .ctbs; they're all there. It's a major annoyance to receive a drawing and think you can start your work just to find out that there are several missing xrefs or images. On a related topic, if you want to send someone a drawing, but don't want them to be able to modify it, send a DWF or PDF (DWF preferred). DWFs can be inserted into drawings as external references, and thus objects show up as if they were from a normal drawing; lines can be traced, etc., whereas PDFs are mostly raster images, not vector based and offer a poor means of preserving quality. P.S. If you're going to send a PDF, please, plot as vector, don't plot the drawing out on paper and scan it.

• Properly layer out your drawings, and keep objects on ByLayer as much as possible. No one likes to get drawings that have EVERYTHING on the same layer (especially Defpoints), or certain sets of objects differentiated by just color or linetype. Entities should be layered out by type, i.e. instead of just having a ROAD layer, have a ROAD_TEXT layer for road-related text entities, a ROAD_DIM layer for road-related dimensions, and finally a ROAD layer for everything else road. Generally, the more layers, the better, with emphasis on grouping relevant objects together. There's not really a point to making a large amount of layers just to put one object on each layer. As you use CAD more and more, you'll get a better idea of how things should be layered out.

• Don't explode hatches, text, dimensions, or leaders. There's really no logical reason to explode any of these in any drawing. It just makes a child's mess out of a drawing, and on slower machines creates a very slow drafting environment when thousands of little entities have to be drawn out one by one. AutoCAD has optimizations to draw hatches, linetypes, text, etc. on your screen many times faster than if it were to attempt to draw out the thousand-of-entities equivalent.

• Take time to properly name drawings. Including a project number, the drawing number, and a short description is much better than something like "cross-section.dwg". Ideally, your company should have a naming convention to minimize the time it takes to find certain files within a project.

• Take time to properly name the layouts within those drawings. As appropriately namely drawings minimizes the time it takes to find a specific drawing within a project, appropriately naming layout tabs minimizes the time it takes to sort through all the different layouts in the drawing.

• Take time to make sure text entities are properly aligned/justified (top left, middle right, center, etc.). At first, it may seem faster to just copy around a piece of text with left justification for every note (and it is), but when you go back for the inevitable revisions, you'll very likely have to reposition the text. Or, if you have to change the scale, be it through annotative scaling or conventional methods, every single piece of improperly aligned text will have to be repositioned. It's just better to do it right the first time.

• Use Mtext instead of multiple individual pieces of text when making a note requiring more than one line. It's much more tedious and time consuming to modify a paragraph made up of several pieces of text since it usually means you have to edit every single line of text to even out the bulge or void you create when you make the change. Plus, Mtext just keeps things neater, and makes sure that long notes are properly justified the way you want them to be.

• Only override dimension text if you're dimensioning something that's part of a not-to-scale depiction. It doesn't make much sense to override the dimension text if it actually is to scale. It makes much more sense to change the dimension style to accommodate your needs, if possible.

• Submit revised plans to your checker as a complete set instead of submitting individual sheets. This way, the checker is forced to set aside time just for checking that set of plans, and is more likely to catch something than if he/she were to receive one sheet at a time. Some people have a tendency to quickly skim over single sheets and miss things, as if they were blowing it off because one sheet is unimportant to them.

• As a rule of thumb, entities that will only be used on a single layout and are not-to-scale should be placed in paperspace. Everything else, of course, will be in modelspace in order to be referenced by the different layouts and scaled properly through viewports. For example, views of a to-scale part should be in modelspace, because they're to-scale and might be used in more than one viewport. Notes and legends should most likely be in modelspace as well, since they might be referenced by several layouts. Layout-specific notes, however, should stay on their respective layouts, not in the free-for-all modelspace.

• Lastly, keep file sizes down and crap out of drawings, purge your drawings before saving. A zoom extents wouldn't hurt, either.