Guide to sources LCARS 24 is compiled with DJGPP and Allegro plus libraries for jpeg and gif. The jpeg and gif libraries are in the lib folder with this source package. Newer versions of Allegro have a compatibility problem with this version of the gif library. However, since there are numerous conflicts with the newer versions of Allegro and newer versions of DJGPP, one of which causes trouble with sound (there are fixes for most of the other problems), release versions of LCARS 24 are compiled with versions of DJGPP and Allegro that predate these troubles. This must be done on a DOS-only machine, not a Windows environment. These are the zips for the version of DJGPP used here. gcc303b txi42b djdev203 bnu2112b mak379b gdb521b These are not the versions shown at the current DJGPP Web site, but some are available here: GARR Network's Napoli FTP-archive http://cdn.mirror.garr.it/mirrors/djgpp/deleted/v2gnu/ Also Goodie Domain Service: http://gd.tuwien.ac.at/pc/dos/djgpp/deleted/v2gnu/?fisel=gG In addition: DJGPP v. 2.03: (note the wildcard) gcc for DJGPP v. 3.0.3: gcc README v. 3.0.3: GNU binutils v. 2.11.2: The version of Allegro to use is 4.0.2, just to be on the safe side. The DJGPP part of Allegro hasn't changed for the better in quite some time. Allegro 4.0.2: This older version of Allegro builds and works smoothly with the above-mentioned DJGPP setup. The maintainer of Allegro has also said, however, that Allegro should not be compiled for DJGPP on a Windows machine unless in Pure DOS mode, that it can introduce bugs. If you use the latest versions of DJGPP and Allegro, for whatever purpose, there are problems compiling Allegro. One is that the following line is missing from the file graphics.c in the subfolder allegro\source: extern void blit_end(void); The above line should be added above the following line in that file: /* lock_bitmap: If you do that and just ignore all the warnings as Allegro is compiling, there is a reasonable chance that it will complile and can be installed and used. If compiled under Windows XP, malfunctions will crop up later. Use a DOS environment, not a Windows DOS box. With the setup I recommend above, the situation is totally different. It compiles and installs smoothly with no complaints, and some programs will be a fraction of the size they would be with the newer versions and work better. In fact, sound output with the newer setups is unacceptable, and the maintainers of Allegro offer no solution. Either way, do it in a DOS enviroment if you are using DJGPP. The makefile MAKEFILE.GCC is for compiling LCARS 24 with DJGPP, with no instructions included for other platforms. The DOS batch file MK.BAT just issues the command for that, which you could type in directly if you prefer: make -f makefile.gcc I normally just type MK and let the batch file execute the above. If you compile LCARS 24, you can run your compiled version (LCARS24.EXE) in your local folder if you have LCARS 24 version 3.1 or higher installed on the machine. This is required, since there are many support files in that package, mainly fonts and images. Startup doesn't get very far if there are any font files missing; you get an error message supported by the two bulletproof (built-in) fonts Mars28 and Luna. LCARS 24 properly compiled will run from the local folder, as long as LCARS 24 is properly installed and runs on the machine. For a ThinkPad with 800 x 600 screen, type 800 to run the batch file 800.bat, which starts LCARS 24 with the argument 800, or type LCARS 24 800. This is because such machines have strange (cheap!) graphics cards that don't have the 1024 x 768 mode. Other platforms I haven't gotten into MinGW (for Windows), Linux, or other UNIX yet. This might compile as a native Windows version with MinGW (with whatever changes to the makefile that requires). For Linux, etc. the file GETKEY.C would have to be rewritten to take key input from the Allegro keyboard functions or NCurses. The file I/O, as well as the gif and jpeg libraries (and perhaps the calls to their functions), and the directory references would have to be changed. The LCARS 24 DOS box might be inappropriate for a Linux/UNIX version and could be disconnected or redone for UNIX commands. Without getting into these versions myself, I don't know yet what other calls need to be changed. I have made all the time and date functions in conformity with Linux style. For setting the time or date, I think the user has to be logged in as root on any kind of UNIX system, and I haven't added functions to check for that and post a notice where necessary. The source files A general listing of what is where is given below. Each file has an explanation at the top. Perhaps the easiest way to see how to make or adapt a program so that the LCARS 24 core takes care of the graphics is to back up then tinker with the file BMI.C, which sets up the most common type of LCARS screen and uses fonts of several sizes. The names of the LCARS colors are shown at the top of that file for your reference. You can try a few simple modifications, compile it with the same makefile, then run LCARS 24 in your local folder and launch the BMI program to see your changes. LCARS 24 is rather strange in a few ways other that the LCARS motif. For one thing, LCARS 24 and all its apps (not counting the background MIDI and MP3 players), have a total executable size on disk of less than that of one little Allegro program in the EXAMPLES folder of any of the newer versions of Allegro, at least, and all the LCARS apps start up instantly, even faster than those little examples could if on a RAM disk, which is normally as fast as possible. You can see from the makefile that they are all prelinked. Further examination reveals that apps don't have mains but mode names instead. They are not only linked but avoid the high overhead of DJGPP, Allegro, and the LCARS 24 core. The main pays that high cover charge, and the rest get in free, paying for only what they actually consume, which is very little, since the core does most of the work, and there is code sharing even among apps. Also, an LCARS app doesn't burn up time setting the graphics mode. It's already set, and program launching is really nothing more than a normal screen change. Also, having more than one iteration of the same app open at one time is not supported. That's the Mac/Windows thing, but it's not an LCARS thing, at least not on a single computer. Files 24 may look like it's open in two places on the screen (tantamount to having two Explorer windows open side by side), but it's not. It always opens with the folder tree open twice side by side to facilitate moving, copying, etc. With Windows, it's common to open two Explorer/floppy/recycle windows and adjust their sizes and positions so you can drag and drop between them. Files 24, opens with that already done for you, but it's not the same program open twice on the screen at once. Even with all that, it's not possible to have that much functionality in one chunk that loads so quickly and has such a small footprint on disk, right? Well, it's compressed with UPX (the Linux kernel is usually set up the same way, needing to decompress at startup). Okay, it's just one cheap trick after another, but the bottom line is that, regardless how much smoke-and-mirror methodology is required, LCARS programs are supposed to start instantly, regardless of what people are used to with mainstream software. Touch a key, and the screen changes before the key is fully pressed. So it's subversive, in a sense, giving the user a false sense of hope that mainstream software can eventually do the same. It could, with CPU and hard-disk access speed increased a thousandfold--or if priority were placed on quick response by any means necessary. Hello? Spam comes up instantly, doesn't it? So what about making things the user actually wants as efficient as spam, regardless of what programming methodology that requires. For example, if it really were impossible for a Web browser to start up in less than 30 seconds after a user clicked on a desktop icon, yet users demanded instant display with no excuses, then each slow-starting program could come with a PNG of its opening screen, which could be blitted up by the program launcher in the blink of an eye. It's a cheap trick, but just an example to illustrate that there are other ways of doing things if trimming the fat out of bloatware is too much to ask. Game programmers have to go to extremes to make some functions smooth enough to be acceptable. Watch the stake in Ferengi Blackjack increase or decrease as you increase or decrease the size of your bet--especially when there are cards lying on top of it. It may look like magic, but any good game programmer could make that happen. What about regular application software? Does it answer to a lower standard? Even without future improvements in computers, operating systems and programming tools in this area, LCARS 24 will continue on the path of instant response, using other tricks, if that's that it takes. Starting with version 3.1, LCARS 24 supports SFML (Starfleet Markup Language) to renders a wide variety of LCARS screens. This is similar to yet quite different from HTML, and already offers some user interaction, yet is fast and smooth. External DOS apps When the user launches an external DOS app, things are different. There can be none of this instant-on business. But LCARS 24 is still different in this regard. First, it generates an LCARS title screen for whatever DOS app you have installed, then it creates a batch file and exits. The title screen remains displayed until the DOS program loads, starts up, and takes over responsibility for screen displays. When that program exits, the next thing executed by the batch file is "LCARS 24 restart in progress" (directly to Standby mode without the startup intro). So in effect, LCARS 24 releases all but a few bytes of memory when launching a DOS program, just in case it's needed. Some DOS programs need that and wouldn't be able to run on some machines otherwise. Launching a memory-hog game or DOS-based Web browser as a child process would fail if the machine had only 32 megabytes of RAM. With this precaution taken as a kindness to the user, the downside is that LCARS 24 doesn't bounce back as quickly as it would if it remained loaded (launching the DOS program as a child process). But showing off has to take a back seat to making sure something works. In future versions, there may be special consideration for external LCARS programs, to allow them to start and later close without delay. Touch-screen and mouse support? The first comment people make is about touch-screen support. But I suspect what they really want is mouse support, since touch input is implemented through a mouse driver, and few people have touch-enabled displays anyway. But mouse input is just not appropriate for LCARS, even though you see it on Star Trek Web sites. In that regard, on any Web pages I make, the only click targets are text, never LCARS buttons or bracket sections. Also, LCARS 24 is mainly intended for laptops, and normally you don't poke the screen of a laptop. Touch is more for a wall-mounted flat screen for use as a light switch, control panel for a microwave oven or washing machine, doorbell, etc. or perhaps a TV remote control built into the arm of an easy chair or coffee table, or even for control panels on the next-generation space shuttle-- whatever, in short, units that don't move when touched. When it's real and relevant, I have no problem with touch-screen input. Finally, to the die-hards who still want touch but really intend to use a mouse for that function, I make the point that before adding touch support I would have to buy at least one touch-screen display and test the code to make sure that no functions are accidentally invoked without user intent because of mouse movement, considering a case in which a user by force of habit moves the mouse and clicks, even though no mouse cursor is displayed. The program would have to be tested an verified not to misinterpret that as touch-screen input. Sure, I could do that just to be able to say that LCARS 24 supports touch, but hardly anyone would really buy a touch-screen panel, etc. for this. Proper coding? Nah! The priority is program performance. It started out for personal use, not open source or a school project. The code itself is undergoing constant clean-up, and I won't make any claims about coding elegance. Its use of arrays adds to the hotrod performance, but is generally frowned upon. Structs, linked lists, and other niceties are few and far between. It's mostly just mass quantities of simple code. But at least it's neat and legible and makes some sense at a glance. What is where Some of the following might not mean much unless you've tried out the various functions and apps of LCARS 24. The scalable font that displays the time is called Mars28. It can be used in size 2 up to sizes too big to fit a single character on the screen, in units of 28 pixels in height, always in an LCARS color on a black background. A memory bitmap (solid black) is created in the size of output, the Mars28 string is drawn to the bitmap, then the bitmap is blitted to the screen. The change is visually smooth, as you can see with the clock numerals, and the program need not erase the previous display. Most of the other fonts support buffered output, as well, to allow use of LCARS fonts instead of TrueType with HTML output. The 14-point font used for labeling is called Luna. Others are pretty much named according to size. Calls to an old font called Scorpio appear in the code, but they are now implemented by a newer font of the same size. Core Some defines and globals: lcars24.h Antialiased fonts: mars24.c, headline.c, parts.c Plain bitmapped fonts: mapfonts.c, winfont.c Graphic objects: cropcirc.c, brack1.c, elbows.c, parts.c Graphics mode: grset.c LCARS colors: lccolor.c Keyboard: getkey.c Screenshots: scrnshot.c Error messages: errmsg.c File loading, saving: textio.c Buffered copying: copyfile.c Doc display: lcreader.c, help.c Roman numerals: roman.c Stardate: stardate.c Voice and beeps: playwav.c Gif animation: gifview.c Standby mode (clock & calendar, math & DOS service, program launching, library, settings, all alarm modes and Glow mode, Image Scroll, and Image Zoom): main.c, standby.c, pickboth.c, File manager: files24a.c, files24b.c System info: sysinfo.c HTML & SFML support: htmload.c, htmproc.c, htmview.c, sfmview.c MIDI & MP3 support: binaries with the LCARS 24 package (code not included here) JPEG: jpeg.h (libary also supplied) GIF: gif.h (libary also supplied [plus alternate for versions of Allegro where there is conflict]) Math formula parser & solver: matheng.c Apps Chess: chess24.c, rand.c, hash.c, book.c, eval.c, moves.c, search.c, utils.c Card games: cards.c, borg.c, blackjak.c Text editors: filemenu.c, text24.c, phone.c, progedit.c World map: mapdata.c, mapfonts.c, worldmap.c World time: timezone.c BMI (a medical app): bmi.c Unit conversion: convert.c Crossword: crosswrd.c Tic-tac-toe: warbird.c, wb3.c, wb5.c View360: view360.c Planet sim: planets.c Gates: gates.c Starfleet: starship.c Periodic table: periodic.c HTML: htmload.c, htmproc.c, htmview.c SFML: sfmview.c Program editor: progedit.c (Many others. Briefing is a Powepoint clone in LCARS style.) A comprehensive screenshot gallery can be viewed at lcars24.com. Bill Morris lcarsuser@yahoo.com Comments? Bug reports? Feature requests? There are places for those on the LCARS 24 project page at SourceForge. There are public forums, and anyone may report a bug or make a feature request. June 24, 2010