The Teen Programmers' Journal Retrospective Hologram cover collector's edition! Issue #1 -------- This one came out right at the beginning of the first major change ever to occur in TPU. David Kitchin had let his Ultranet account expire and a bunch of us set up a new site. TPU Newsletter -------------- 12/31/97 Wanna design a better ASCII heading for the newsletter? E-mail it to psion@tpu.org. Contents -------- What's New in TPU CGI Update News from sauronMAX IRC update Source Archive Update Interest and Learning groups Editorials Java - a cool language or just a very bad case of Javaholism? Accepting exceptions Technocracy Instructional Articles A Concise Bot Writer's Guide to the IRC Protocol Particle Engines Reviews Bem's Top Freeware List Project Updates The Entropy Calorimeter TPU3D Update Wanted/Seeking Artists/Programmers Desperately Needed Help Wanted TI-86 users needed! --- What's New in TPU [Special Update] www.tpu.org is finally here! The TPU web page is now http://www.tpu.org/, though all recent addresses will still work. The US mirror is http://www.us.tpu.org/. CGI Update Submitted by Psion HTML version: http://www.tpu.org/~psion/cgi.html All of the TPU Interactive Information Center CGI scripts are at last working in their new server home! We encourage you to make use of these communication tools as much as possible. Here's a quick review of the various services and any news about them. Mail any comments to chilip@ptd.net Main IIC Log-On: http://www.tpu.org/iic.html All scripts are accessible from this page. WebBoard -------- The first TPU CGI script ever, this really symbolizes the whole purpose of the IIC. This script is similar to old BBS message forums, USENET news, and other topical discussion boards. Various forums exist which you post to in full HTML. Records for each user are kept allowing the script to tell you which forums have messages that you haven't read yet. I am looking for suggestions for any new forums that people want to see and for forum ops to be given certain administrative duties in specific forums, such as editing that forum's look. Member Directory ---------------- The all-purpose TPU membership database utilities area. Features include the member e-mail address list and the profile directory. Each member has a profile telling various information about him/her, such as programming languages known, current/finished projects, etc. We ask all members to fill out their profiles. You can browse through all members' profiles or search for profiles containing specific text in the various fields. If all members fill out their information here, project recruiters will be able to easily draw on a base of hundreds of potential candidates by searching the database for necessary qualifications. With everyone's participation we can have a very nice system going here. NOTE TO ICQ USERS: Please fill in the ICQ UIN field of your profile to be included in the master TPU Member UIN list. Please don't put any additional comments in the field, just the number. If you don't have ICQ, then please leave this field blank, no "N/A"'s or "What is this?"'s. Resource Directory ------------------ This is a categorized Yahoo!-type search engine for links submitted by TPU members. Categories include member home pages, software, projects, and programming resources. Great for advertising your home page or software company. Add a link to your current/finished projects and then see what your fellow members have created. The more people add links, the more people will visit the Directory, and the more publicity submitters' sites will get, so add all relevant links that you can. Voting Booth ------------ This script is quite self-explanatory. The current poll is on the issue of whether of not we should change the name of the organization to reflect the fact that many members will no longer be "teens" soon. Drop by and make your voice heard. That's all for now. -- Adam Chlipala chilip@ptd.net ICQ UIN: 489166 News from sauronMAX Submitted by Pontus Nilsson Teen Programmers Unite - Homepage, Hello my name in Pontus Nilsson more known as sauronMAX in IRC. I am the news administrator and the second WWW administrator. If you don´t know who the administrators you can go to: http://www.tpu.org/admins.html I am currently working on a new homepage design. If you want to look how far I have come with the design then go to: http://www.tpu.org/new_page If you want to contribute with a homepage design then please mail me. (email at the bottom of my message). If you have a project or a interest group but haven´t got any WWW space then you could get some at TPU´s server. Talk to Sune Kirkeby (meIIon) about this. That´s about all from me. Contact me ICQ UIN: 5537002 Email: pontusni@wineasy.se Homepage: www.users.wineasy.se/pontusni IRC update Submitted by xekul HTML version: http://www.tpu.org/~xekul/newsletter.html Hello If you feel like talking in real time to some of us TPUers, IRC is the way to do it. So how do you get on IRC, you ask? A program known as an IRC client is needed. For UNIX, I recommend ircII-EPIC (http://www.frenzy.com/~bhauber/epic); for Windows, mIRC is the most popular client (http://www.mirc.co.uk) After you download, compile and install the client, run it and type these two commands: /server irc.chat.org /join #tpu The irc.chat.org is the name of the server you want to connect to. I also know of these servers (in North America): irc.passport.ca irc.magic.ca irc.videotron.ab.ca irc.ais.net irc.emory.edu irc.frontiernet.net irc.ionet.net Just make sure you connect to an EFNet server and not LinuxNet or Undernet or Dalnet or something. The /join #tpu takes you into the channel #tpu. Once you are in the channel, you can `say' stuff just by typing it in and pressing . If you need any assistance at this point, you may ask in the channel. http://www.tpu.org/irc/tpu.html has more information on the TPU chats; http://www.irchelp.org has more information on IRC in general. Please note the ops policy: do not ask for ops because you will not get them. Only trusted individuals such as administrators (don't take this as a personal insult if you aren't one) are able to obtain op status from the bot. A commonly asked question is how to get the bot (cleverly named Daneel) to say something when you enter the channel. Simply introduce yourself to the bot with the command `/msg daneel yo' (don't include the quotes) and then set your info line with the command `/msg daneel info '' I hope I didn't insult anyone's intelligence in the above e-mail. Thank you for your time. -- xekul the IRC admin Source Archive Update Submitted by rebmalim The archive has grown significantly since the last newsletter. Thanks to all of you who have donated code! Some more variety would be nice, though; if any of you have code in languages other than C/C++, please donate it... Also, the archive has moved to a new location: http://www.tpu.org/source/ is the new site. This may be faster than the old page for some of you. Interest and Learning groups Submitted by kAin Learning groups and Interest groups. A interest group is for people that have a common interest (like pascal programming for example). They can ask each other questions and work together on projects. To sign up for a interest group email the contact person in the group and subscribe to the mailing list. A interest group will get a dedicated mailing list each, to help the members communicate. Current interest groups: The DJGPP User Group: http://ajani.home.ml.org/djgpptpu/ Watcom C/C++ interest group: http://www.angelfire.com/wa/WatcomC Pascal Interest Group: http://tcp.home.ml.org/pascal/ Visual Basic interest group: http://www.icrdl.net/claudeg/tpu_vb/ QuickBasic Interest Group: http://www.iobbs.com/~rm/quickbasic/ Computer Art Interest Group: http://www.ambercomputer.com/art_tpu/ Music interest group: http://www.xoom.com/Armpit/ Learning groups are lightweight interest groups, they are primarly a mailing list that people can ask questions to. Please visit the IG homepage at http://www.tpu.org/ig/index.html for more information and information on how to create interest groups and learning groups. [Late breaking news: All IG mailing lists can now be reached via [oldmailinglistname]@tpu.org] Henrik Abelsson Editorials Java - a cool language or just a very bad case of Javaholism? Submitted by Dmitri HTML version: http://www.tpu.org/~dmitri/java.html Java - a cool language or just a very bad case of Javaholism? In this article, I am going to examine Java's so called "features" and attempt to examine Java's popularity. So, let us begin with a detailed examination of this language's "features": 1. Java is slooooooow! I do not think that there is any question in anyone's mind that nearly all applications/applets written in Java are slow as hell. One can't even compare the speed of an average C++ program (even with all Microsoft's MFCs, ActiveXs, and other stuff that slow the programs down tremendously) with an average Java program. 2. Java is interpreted! That, of course, is a major reason for it being so slow, but there is another problem with it being interpreted, and not compiled. The resulted Java bytecode is decompiled with ease by a number of Java's decompilers. I've even read somewhere that Java even saves comments in it's bytecode (I haven't seen anything that would prove this, though, but I wouldn't be surprised if that were the case). Most Java decompilers, however, give incredibly accurate source code and make Java one of the most unsecure languages, in terms of programmers keeping their source code a secret. 3. Java is way too much Object Oriented! I am not going to argue the usefulness (or uselessness) of OOP in this short article, but I am going to say this: I agree that OOP can be very useful sometimes, but as a programmer I would prefer to make the decision when to use it and when not to. Java, on the other hand, forces me to use it whether I like or not! 4. Java is platform independent! Yeah, right - dream on! Try "compiling" a program with Microsoft Visual J++ (which has probably "compiled" at least 50% of programs written in Java now) and run it on UNIX platform. Of course, one can argue that Java was meant to be platform independent and it's Microsoft's fault that it's not, but SO WHAT? Who cares whose fault it is? The fact remains that Java's probably most popular "compiler' doesn't produce platform independent code! 5. Java does not have pointers and other useful features from C++! Again, you can argue all you want about that preventing security problems and crashes, but that is exactly the same as saying that car accidents are a cause of a big percentage of deaths in the world, so let's not use cars! Again, I think that a programmer should be the one to decide what parts of the language he (or she) wants to use and which parts not to use in a program. 6. Java has a terrible GUI interface! There is not much to be said about this - if you think that Java's GUI looks great compared to native Windows and X-Windows GUI, then there is nothing more to discuss. You obviously have a terrible case of Javaholism. And so, after all this, why is everyone so hang up on (or addicted to) Java? To tell you the truth, I do not have a slightest idea. OK, so everybody wanted to have a platform independent language (obviously it didn't turn out quite the way they wanted it to be), but there must a million of other interpreters out there that give decent platform independency (ex. Perl). Why Java? Anyone who can answer that question, please contact me immediately! So long turkey programmers, Dmitri (a.k.a. JavaSucks) Turkey programmers is a registered trademark of Dr. B.C. Day, my Computer Science professor :-) Accepting exceptions Submitted by DeHackEd HTML version: http://www.geocities.com/SiliconValley/Peaks/9235/exceptio.htm Exceptions Exceptions are something that C++ introduced as part of error handling. Though I find them to be extremely interesting, they are hard to work with. "Though they crash my compiler!" I know a lot of people in TPU code with DJGPP. Hell, I do, and it saved me around $200! It produces quality code, and if it's good enough for Quake, it's good enough for me. But who has honestly looked at the assembly output from the compiler? It's long, it's ugly, and any more than 4 exception types can be fatal to the thing. Also, I once tried compiling some code that handled exceptions. It crashed with an "Internal Compiler error 40". I turned on all warnings. It told me it did not have a prototype for (int?)getch(void?); I gave it one, and it compiled WITHOUT the error. No offense, but that sounds odd. And what's with the funky output? Could you not just have a longjump? It would be simple, painless, and internal (no user access) variables would tell the compiler what the error was and a pointer would show it the way to the thrown object. Sean "DeHackEd" Pajot Problem: The radio does not work in Official mode Solution: It's not suppose to work in OFF mode. C:\CPP>gcc throw.cc -o throw.exe -lstdcx -fhandle-exceptions This article was made with Notepad. Technocracy Submitted by plik Technocracy By: PliK Yes Teen puter' gurus, it is a sad world we live in. We are the fortunate. We have embraced a new and glorious technology unlike any other. With nearly all other forms of new technology, the older (sometimes wiser) adults have taken it upon themselves to learn about it, and then pass this knowledge down to their kids. The automobile is a prime example of this phenomenon. The automobile transformed our personal way of living; the parents would buy one, learn how to drive it, and in a few years when the sloth in them was manifest, they taught the kids to drive so they would not have to. This has been the way of technology, and in theory, it makes perfect sense. Computer technology has broken the mold, and the adults do not know how to interpret the new order. The penetration of the personal computer into our houses began in the early eighties. Sure their were other cases, but for the most part the early eighties is when the revolution began to happen. With the keen invention of computer games, kids now had a reason to use the computer(there would be no REAL reason for them to bust out the ol' spreadsheet program and track their finances now would there?). In order to even get these games running, children had to learn a little bit about the computer. The parents had to learn a little about the computer also, they had to learn in order to use their spreadsheet program. The big difference between the children and the adults here is the fact that computer games are fun, and in all truth, I have yet to see a spreadsheet with kick-ass gameplay. So the children got the impression that computers were fun, while the adults got the impression that computers are mundane. Well sure enough there would be those select few; those children who were just a little more curious, those who wanted to know more. They called them hackers, you remember don't you, MOD, LOD, all those other kewl groups. The adults consentrated on the fact that the children were going places that they should not be going, and it boggled them why the kids would even want to do so, I mean computers are boring right? The primary difference between a child and an adult is perspective, the secondary is pure, flowing, creative capacity. These children were not looking to cause harm, they were just having fun, it was after all just a game. "But dad its just a game, that's why you bought me the computer anyways, so I would sit for hours and play games, and then you would not feel any sort of obligation to spend quality time with me right dad?" ,a sad commentary on the way adults use technology. Anyhow, these so called hackers grew up and created some of the most exciting advances in hardware and software(I would rattle them off, but I am afraid I don't remember, they are all off in a book somewhere). "What is this guy getting at?", you are saying to yourself right now, well, here is my point. I am fed up with the complete ignorance of computer systems displayed by my high school. They just installed a brand new p-200 network with like 25 computers(yes yes I know, network quake during class, yada yada yada), and the teachers know nothing about the system. Even my AP Comp. Sci. 2 teacher doesn't under stand them, she is stuck in the punch card days, and is so sloth ridden that she won't catch up with technology. They do not understand us. We are not your average bunch of gurus, like car gurus, or football gurus! I am trying to say that what we do with a computer is so artistic in form and structure, we are the paragon of man over machine, and it is in our reign that we create beauty. I guess the real inspiration for this little article comes from the fact that last year, while I was bored at lunch time, I went into the computer lab, all the other dumb-ass kids were in their looking up all the porn sites on the web, the others were playing solitaire(yet another sad commentary). But I transcended, I just wanted to program, I knew the only thing the puters' probably had was qbasic, but I figured it was a good waste of a lunch. The only problem was the cheap windows security system(full armor, ya know it?) that I had to break through inorder to snatch a dos prompt. I was not going to hurt anything(though I had the power); my intentions were purely saint-like. But it all came crashing down when the ignorant computer teacher checked up on the lab and did not see the obnoxious glow of some windows background outlining my screen, she figured something was up. I was dragged down to the principles office and despite my explanation THEY DID NOT UNDERSTAND, BECAUSE THEY HAD NOT TAKEN THE TIME TO EDUCATE THEMSELVES, DESPITE THE FACT THAT THIS WAS A SCHOOL. I was permanately kicked off of the computers and received a five day suspension. I write simply for the masses to think, so with that I leave you a final word of wisdom...think. Instructional Articles A Concise Bot Writer's Guide to the IRC Protocol Submitted by Psion HTML version: http://www.tpu.org/~psion/irc.html If you ever get the urge to write an IRC bot as I and many others have, the first thing that you need to do is to create a basic IRC client. To save you the trouble of deciphering the RFC1459 IRC protocol, I have prepared this quick overview of how to get your bot up and running. This document assumes that you are already familiar with using an IRC client and that you understand the basics of IRCing. To start with the basics, the IRC protocol involves your IRC client connecting via TCP/IP with a server, usually on port 6667. If you want to try out any of the topics discussed here, then you can telnet to your favorite IRC server on port 6667 (probably with local echo) and type commands to the server manually. You can also use the /raw command in mIRC to send text directly to the server. Some other clients use a /quote command instead. All messages exchanged between you and the server will consist of a list of words (or arguments) separated by spaces. The last argument may contain spaces. It is prefaced by a colon (:). Each message is terminated with a carriage return/line feed, AKA '\n' in C, AKA ASCII characters 13 and 10. If at any time you want a definitive IRC reference, try the RFC protocol, found at: http://www.irchelp.org/irchelp/rfc1459.html Server Messages --------------- All messages that you receive from the server will be in one of two forms. The first one is for information messages or errors from the server. These follow the format: : : For example, :irc.concentric.net 372 Markov :Welcome to Concentric Internet Services. 372 is the code for MOTD lines. The other type of message relays a command iniated by another user. They follow the form: :!@ For example, :Bobo_!chilip@cs4-04.all.ptd.net PRIVMSG #tpu :Do you all like goats as much as I do? Commands -------- A comment sent to the server simply follows the form: Session Walkthrough ------------------- The following is an example of a sample IRC session. The < and >'s are NOT part of the exchange, a < at the start of a line indicates a message from the server, a > a command sent by the client. At the start of this log, the client has just connected to irc.ais.net:6667. >USER billyboy castle.microsoft.com irc.ais.net :William Gates >NICK BillyBoy The USER and NICK commands are used to log on to the server and set/change your nickname, respectively. Their syntaxes are: USER : NICK <:irc.ais.net 375 BillyBoy Message of the Day <:irc.ais.net 372 BillyBoy Don't break anything or we'll come kill you. ... <:irc.ais.net 376 BillyBoy End of Message of the Day Following logging on, the server sends a series of informational messages meant to be displayed in your client. A bot does not need to do anything with them. >PRIVMSG LinusT :Tonight I come for you! This is a private message directed at a specific user. General syntax is: PRIVMSG : <:LinusT!linus@linux.org PRIVMSG BillyBoy :Just try Buddy! Here is a reply. Notice how the command is shown to you just as LinusT's client would have sent it. You will probably want to join some channels eventually. >JOIN #win95 <:irc.ais.net 375 BillyBoy Bad channel key >JOIN #win95 :Mo' money! <:BillyBoy!billyboy@castle.microsoft.com JOIN #win95 In the example above, the channel is locked to require a certain key to enter. The syntax for the join command is: JOIN [:] <:irc.ais.net 353 BillyBoy #win95 :ILuvBill GoatLove 4yearold maxSux <:irc.ais.net 353 BillyBoy #win95 :Slowisgud BillyBoy After joining a channel, the server will send you a list of the people in the channel in the form of a series of NamReply messages. Each message contains a space-separated list of nicknames. <:GoatLove!goat@animals.com PRIVMSG #win95 :Bill!!!! My idol!!! <:4yearold!bahbah@wahwah.org PRIVMSG #win95 :ACTION kisses BillyBoy's feet!! >PRIVMSG #win95 :Thank you! Thank you! Any new souls for sale? >:ElitG!lusr@hackrz.org JOIN #win95 >:ElitG!lusr@hackrz.org PRIVMSG #win95 :Yo wassup all!! >:ElitG!lusr@hackrz.org PART #win95 The above series illustrates the use of PRIVMSG to send to channels instead of individual users. Line 2 shows an action, AKA a message of ASCII character 1 followed by the word ACTION and a space, the action text, and a terminating character 1. The last 3 lines show the messages shown when a user enters or exits the channel. <:MacFanClub!mfc@apple.com PRIVMSG BillyBoy :If you don't get off the server right away you're toast! >PRIVMSG MacFanClub :OK, OK, don't hurt me!!!!!!!!! >QUIT :Off to buy McDonalds or something And, finally, when you decide to sign off, the above shows how it is done. That sums up all of the commands that you need to create a basic IRC bot. Again, refer to http://www.irchelp.org/irchelp/rfc1459.html for a more detailed reference on all aspects of the IRC protocol. You can also e-mail me at chilip@ptd.net with any further questions. Particle Engines Submitted by ProMagnoN HTML version: http://home.global.co.za/~lawson/part_tut.htm A PARTICLE SYSTEM TUTOR ----------------------- by ProMagnoN (lawson@global.co.za) ABOUT THIS DOCUMENT ------------------- There is no "pseudo-code" in this doc. There IS, however, nice proper C code that should compile. Isn't that nice. DISCLAIMER ---------- If this code or document causes in any way anything bad or good for anyone or anything, it's not my fault. I can't be held liable. I do, however want to hear about it if it DOES work nicely. It's nice to know that people are actually using something that took me a long time to make WHAT YOU NEED ------------- You will need the file that contains all the pictures, texts and also a html version of this document. The file is downloadable at the URL of my page: http://home.global.co.za/~lawson/particle.zip I assume, at the point of writing this document, that you have some knowlege of how pointers work in C (or what ever other language you program in.) I will explain linked lists and they work with pointers. You must also be able to get into whatever video mode you want to use for the system. Getting in and out of video modes would take a lot of explaining, especially for vesa, and I suspect that there are many other tutorials out there that explain that. If you're at a loss, go get ALLEGRO, a really nifty library for DJGPP that does, well, everything. Sounds, Graphics, Music, Etc. A brain is also essential. They are $10 at K-Mart, although somewhat used :) WHAT IS A PARTICLE SYSTEM? -------------------------- It's a system that uses hundereds (or even thousands or more) of particles (points) to generate a nice looking effect, be it an explosion, blood splatter, teleport effect, engine static, damage effects, or just a demo effect while something else is calculating elsewhere. Particles are nice and fast, you see. Each particle is usualy a pixel on the screen, but not always. Some examples may be found inside programs like GoreWarz (my own game) and Quake (by IDSoftware, and IMO the best 3d game ever). Yes. Particles can be used in 3d as well, and have several times. HOW DO WE SET UP A PARTICLE SYSTEM ---------------------------------- First you need to define a structure that can hold the points (in pascal it would be called a record, not a structure). Particles have a position and a velocity. If you have a nice vector library or something, or want to use fixed-point numbers, feel free. I will keep it simple. ------------------------------------------------------ typedef struct PARTICLE { float x_pos; // horizontal position float y_pos; // vertical position float x_vel; // horizontal velocity float y_vel; // vertical velocity char color; int life; // how long the particle will last for } PARTICLE; ------------------------------------------------------ WHY LINKED-LISTS? ----------------- Imagine having an engine that has any number of particles at a time, like maybe it's a bit quiet, nobody is shooting or dying or anything, so there might be very few particles actually in action, say 10. Then someone fires a rocket, off goes the particle-generated smoke trail, it hits the wall, off goes the particle explosion, and now we have 12,000 particles in action. The number varies a LOT. So when speed counts in a game (IT DOES!) you can't afford just to have an array of 30,000 particles and check each one no matter whether it's being used or not. That approach is just too slow. So we use linked-lists... The example I am about to give is to show you the WRONG way to do a particle system! ------------------------------------------------------ typedef struct PARTICLE { float x_pos; float y_pos; float x_vel; float y_vel; char color; int life; } PARTICLE; PARTICLE particles[50000]; ------------------------------------------------------ The above is the WRONG way to do it! HOW DOES A LINKED-LIST WORK? ---------------------------- A linked list works by each element instead of being in an array, having rather a pointer to the next, and the previous element. (That, BTW, is a DOUBLE linked list. A SINGLE linked list would only have a pointer to the next). Here is an example: ---------------------------------------------- typedef struct PARTICLE { float x_pos; float y_pos; float x_vel; float y_vel; char color; int life; struct PARTICLE *next_item; struct PARTICLE *prev_item; } PARTICLE; PARTICLE *first_particle = NULL; PARTICLE *last_particle = NULL; ---------------------------------------------- The start of the list is marked by having prev_item point to null. The end of the list is marked by having next_item point to null. Notice the pointers to another structure of the same type inside the PARTICLE structure. Also notice the absence of an array, instead there is a pointer to the first and the last item in the list. I find it easier to think of a linked-list in terms of a chain, the elements of the list forming the links in the chain. Examine to see a nice graphical example of linked-lists. ADDING ITEMS TO THE LIST ------------------------ Now we write a routine to add a new particle into the list: The routine must allocate memory for it, check if the memory was, in fact, allocated, and also place it in the list. Then it must return a pointer to the particle it just created: It will be called insert_particle and you will use it like this: PARTICLE *a_particle; ... a_particle = insert_particle(); ---------------------------------------------- PARTICLE *insert_particle(void) { PARTICLE *temp = NULL; // we need a temporary particle, NULL to be safe. temp = malloc(sizeof(PARTICLE)); // we allocate memory for the new particle if (!temp) exit(0); // we have run out of memory if temp is NULL. Exit. memset(temp,(char) 0,sizeof(PARTICLE)); // I set it all to 0, to be safe. // Since the particle is going to always be put at the end of the list, // we set it's next_item to NULL. temp->next_item = NULL; // If first_particle is NULL, then the one we are inserting is the first // as well as the last in the list, as it's the only one in the list. // If first_particle is NOT NULL, then there are other particles already // in the list, and we link the last_particle's next_item to temp, and // we link temp's prev_item to the last particle, then we make temp the // last particle. if (first_particle==NULL) { first_particle=last_particle=temp; temp->prev_item = NULL; // the first item on the list doesn't // have a previous item. } else { last_particle->next_item = temp; // we tell whatever the last item is // that it must point toward the new // temp as it's next item. temp->prev_item = last_particle; // we tell temp that it's previous // item is the last one. This is // because it's a double linked list. last_particle = temp; // now we move the last_particle // pointer to temp, because by // putting it after the last element // in the list, it becomes the last // element. } // now that it's in the list, we return a pointer to it, so the rest of the // program can use it, eg, set up values, position, etc. return temp; } ------------------------------------------------------------ For more grahical info, look at . It shows the steps infvolved in inserting an item into the list. REMOVING ITEMS FROM THE LIST ---------------------------- You remove an item from the list by setting the item before it's NEXT field to its own NEXT field. Then you set the item after it's PREV field to its own PREV field. Then you free() it. The steps involved are drawn up in The only problem arises when the one to be removed is either the only one in the list or is the last one or is the first one, because in all those cases, there is either no previous or no next item, or there is neither. So we have to do a special check for those cases. If its the first AND the last item, then we know that it's the only item, and we just set first and last to NULL, and free it. It will be used like this: delete_particle(this_one); // this_one is a PARTICLE *this_one; ----------------------------------------------------------------------------- void delete_particle(PARTICLE *target) { if (target==NULL) return; // check to see if it actually needs deletion // is it the only particle in the list? if ((target==first_particle)&&(target==last_particle)) { //simply null them. first_particle=last_particle=NULL; } else if (target==first_particle) // is it the first one? { first_particle = first_particle->next_item; // move the first_particle off. first_particle->prev_item = NULL; // unlink the prev_item. } else if (target==last_particle) { last_particle = last_particle->prev_item; // move it back one; last_particle->next_item = NULL; // unlink it. } else // since it's none of the others, it is somewhere in the middle. { target->next_item->prev_item = target->prev_item; target->prev_item->next_item = target->next_item; // do the switcheroo :) } free(target); } -------------------------------------------------------------------------- CLEAN UP -------- Of course, you will want a routine to clear the entire list, on program exit. ------------------------------------------------------------------------- void clear_list(void) { PARTICLE *current_particle = first_particle; PARTICLE *temp_particle; while (current_particle!=NULL) // while it's not gone thru the list { temp_particle = current_particle->next_item; // use a temp variable free(current_particle); // delete it current_particle = temp_particle; // restore from temp } first_particle=last_particle=NULL; } ----------------------------------------------------------------------------- ANIMATION --------- Animation is simply made by adding the velocities onto the position each frame. Also, decrease the "life" every update and then if it's 0, delete the particle. ---------------------------------------------------------------------- void update_particles(void) { PARTICLE *current_particle = first_particle; PARTICLE *temp; while (current_particle!=NULL) { temp = current_particle->next_item; // add the velocity to the position: current_particle->x_pos+=current_particle->x_vel; current_particle->y_pos+=current_particle->y_vel; // decrease life current_particle->life--; // check for no life left if (current_particle->life<=0) { // kill it delete_particle(current_particle); } // jump to next. Using a temp variable in case current was deleted. current_particle = temp; } } ---------------------------------------------------------------------- DISPLAY ------- You also need to have some routine that plots them on a screen. This section assumes that you know have a WORKING putpixel() routine. If you don't have one, get one, or get ALLEGRO with DJGPP! ---------------------------------------------------------------------- void draw_particles() { // we don't need a TEMP variable because we aren't changing anything. PARTICLE *current_particle = first_particle; while (current_particle!=NULL) { // draw it. Note that you need to make a putpixel routine for this to // work. Either make your own, or use a library like ALLEGRO or something. putpixel(current_particle->x_pos, current_particle->y_pos, current_particle->color); current_particle=current_particle->next_item; // go to next one. } } ---------------------------------------------------------------------- NOW LETS MAKE SOME EFFECTS! --------------------------- First, a nice explosion effect. An explosion with particles is done by creating several particles, setting their position to the same place, but setting their velocities in all different directions. I assume you know how to set up a random number generator, or use C's built in one, just in case, here is a little routine to return a floating point random number between 0 and 1. There's also a defined thing that returns a number between -1 and 1: ----------------------------------------------------------------------- float rnum(void) { float temp; temp = random(); temp /= MAXINT; return temp; } #define negative_rnum() (rnum()*2)-1 void init_explosion(void) { PARTICLE *temp; int a; for (a=0;a<100;a++) // make 100 particles in the explosion, you can // change it if you want, for more particles { temp = insert_particle(); temp->x_pos = 100; // set it to a position on the screen. temp->y_pos = 100; // in this case (100,100), but it can be anything. temp->x_vel = negative_rnum(); // between -1 and 1. multiply to speed // up. the effect. temp->y_vel = negative_rnum()*4; // here I have multiplied the y_vel by 4. // this makes a kinda vertical explosion, // because the particles will move faster // vertically than horizontally. temp->color = 15; // WHITE, but you could use any color here. temp->life = (int)(rnum()*30); // the effect lasts for UP TO 30 frames. } } void mainloop() { init_explosion(); while (!kbhit()) { update_particles(); draw_particles(); } clear_list(); } ----------------------------------------------------------------------- See? That's all there is to particle effects. Go out and play with them now. IDEAS AND EXTENTIONS -------------------- The above system is meant for this tutorial... you would probably want some other stuff as well in the system you use for a game. Here are some ideas that are often used: Instead of a "color" variable, have a "begin_color" and "end_color" and fade between the 2, using "start_life" as the reference. Add z_pos and z_vel to it. Add gravity: Just add a constant, (say, 0.01) to the y_vel when you update the particles. y_vel+=0.01; // gravity Add collision detection or transparency. Don't limit particles to pixels. You could (in your draw_particles() routine) draw lines between the particles, every one (except the last) has a line from it's position to it's next_item's position. Mix effects. If you had a init_explosion() and an init_teleport_dots() routine, they could easily be mixed because it uses linked lists. Just call them one after each other: init_explosion() init_teleport_dots() would work just fine. You might want to make your code more re-usable, eg: ---------------------------------------------------------------- // void init_explosion(void) would be changed to: void init_explosion(float x_pos,float y_pos, float num_particles,float speed,int max_duration,char color) { PARTICLE *temp; int a; for (a=0;ax_pos = x_pos; temp->y_pos = y_pos; temp->x_vel = negative_rnum()*speed; temp->y_vel = negative_rnum()*speed; temp->color = color; temp->life = (int) (rnum()*max_duration); } } ---------------------------------------------------------------- You can also add properties to a particle like it's type. For this I use a set of flags in one SHORT: typedef struct PARTICLE { ... short flags; ... } PARTICLE; and have #defines for the type: #define FADES 1 #define SNOWFLAKE 2 #define BOUNCY 4 #define GRAVITY 8 #define FRICTION 16 #define EXPLODES 32 and then inside the update_particles() or draw_particles() routine I have the appropriate if statement: void update_particles(void) { ... if (current_particle->flags&FRICTION) { current_particle->x_vel *= 0.9; current_particle->y_vel *= 0.9; } if (current_particle->flags&GRAVITY) { current_particle->y_vel += 0.01; } ... if (current_particle->life<=0) { if (current_particle->flags&EXPLODES) init_explosion(current_particle->x_pos,current_particle->y_pos, 1000,4,30,current_particle->color); ... } ... } notice that using flags means you can have multiple things on a particle: current_particle->flags = BOUNCY|GRAVITY|FADES; DON'T get into loops, eg, don't allow your init_explosion routine to create particles which will explode! It will cause an overflow really quickly! Possibilities are endless!!!! Go out there and explore them. ------------------------------------------------------ That's it. Game over, man. It's over. ----------------------------------------------------- Contact me at lawson@global.co.za or at http://home.global.co.za/~lawson/ but not after March 1998, 'cause I'm moving to the USA! Ask me questions if you want. ------------------------------------------------------------------------ Reviews Bem's Top Freeware List Submitted by DuskCat HTML version: http://members.xoom.com/DuskCat/top_freeware.html Bem's Top Freeware List To submit items to the list, send the URL to baj@usa.net, with the subject "Top Freeware Submissions". If you don't like any of my picks, send mail to the above address, and tell me why. I may end up agreeing with you. Win95 Dipstick This neat program allows you to drag multiple download links into its window to find out which one will download the quickest. This program is very beneficial for frequent downloaders. -> http://www.klever.net/kin/dipstick.html Notepad+ Better notepad for Windows 95. Close to no limit on the size of files, multiple windows, changeable fonts, and much more. A must! -> ftp://ftp.zdnet.com/pccomp/0697/npplus.zip Power Toys Windows 95 shell enhancements by Microsoft. Lots of useful utilites, many of which should have been included in Windows 95 in the first place. -> http://www.microsoft.com/windows95/info/powertoys.htm Web Ferret A utility that searches multiple search engines and discards duplicate results. If you want to find something on the web, this tool can't be beat. -> http://www.ferretsoft.com/netferret/webferret.htm Win 3.1 Need Submissions - Send URL to baj@usa.net, with the subject "Top Freeware Submissions". DOS DJGPP A 32-bit port of GCC to DOS. A very good C/C++ compiler, one of the best at optimizing code. If you can't afford Watcom, this has to be the best for DOS development. -> http://www.delorie.com/djgpp/ Cubic Player A music file player for DOS. It plays almost every concievable format, including mpx. The best music player I've come across. -> http://www.ThePentagon.com/cubic/ OS/2 Need Submissions - Send URL to baj@usa.net, with the subject "Top Freeware Submissions". Linux Need Submissions - Send URL to baj@usa.net, with the subject "Top Freeware Submissions". Project Updates The Entropy Calorimeter Submitted by witwerg HTML version: http://cypress.idir.net/~witwerg/calorimeter The Entropy Calorimeter ------------------------------------------------------------- Entropy - Linux the Right Way =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= In This Issue.... Well to keep TPU members informed about the Entropy Project I've decided to send out a project update with every TPU newsletter. For now I'm calling it the Calorimeter. Why? Well Entropy reminds me very much of Chemistry. In Chemistry, entropy is the heat used or produced by a reaction usually forming a solid byproduct. Calorimeters are very high tech devices used to measure heat produced and used by a reaction (aka Styrofoam coffee cup :). So now fairly regularly TPU has their own Calorimeter for the Entropy project to measure our Entropy and formed byproduct! For all of those unfamiliar with Entropy Linux... Entropy Linux is a distribution of the free 32-bit operating system called Linux. Linux is a Unix clone. Entropy Linux will make Linux easier to pick up from newbies, and for those interested easier to learn. With extensive documentation, integrated programs, and in many cases easy-to-use utilities. Generally in this issue I will cover. The entropy Webpage. The established deadlines. Area Updates. Linux Installation program Area Update Addition Information and Request The same ole The available area now and their jobs The current list of developers The Entropy Webpage ------------------------------------------------------------- Well for all those waiting for the webpage, progress is being made. I've checked it out, and right now there doesn't seem to be anything on it, but I'm sure the people working on the webpage are coming along. If you want to check out what's along you can look a http://www.tpu.org/entropy/ or http://sune2.virtua.dk/entropy/ Deadlines ------------------------------------------------------------- In a attempt to push things forward in developing Entropy. An idea has been submit to set a deadline for something to show for the project. I encourage area heads to email me what they think we can get done by the end of February. Once the goals have been set, I will post the results in the next Calorimeter Area Updates ------------------------------------------------------------ Because of the holidays I have very little here from the area heads, reporting our progress. Anyway. I do know that the installation program has been planned. I plan to have a plugin API done by February or march. The webpage is begin put together. I'm sure next time, I'll be able to give the area head enough time to type a little dittie, and the holidays should interfear. UPDATE FROM THE INSTALLATION SUB-AREA! ----------------------------------------------------- They need people to help with the installation. There is hole bunch of stuff kain wants to do, like a GUI fdisk, hardware auto-detection, and more. If you can help with get Linux initially up and running through a installation program contact him directly with the information for Hendrik or talk to me and I'll forward you. Additional Information and Requests ------------------------------------------------------------------------ Same ol' I your interested in helping out contact me a witwerg@idir.net as I'll talk to you and see about getting you to work. Job Areas Descriptions ========================================================================= Installation ------------------------------------------------------------------------- Develops the utilities and methods to install the base part of Linux onto the harddisk so the harddisk can be boots, and package installation begin. This include stuff like partitioning, initial configuration, swap disk initialization, etc. Configuration ------------------------------------------------------------------------ Develops the utilities and methods to install and maintain Entropy program packs(sort of like Slackware disk sets however a bit more specific). This includes installing, removing, and upgrading programs, as wells as configuring them, Linux, and the Linux startup. Packages ------------------------------------------------------------------------- Helps create a list of programs and program packs, and this collects and packages them for use by Entropy Linux. Webpage ------------------------------------------------------------------------- Create, and maintain the Entropy webpage with all our latest software. Bug-lists, help, developer information, program packs, developer voting, and anything else we need to have on the web for developers or the general public Documentation -------------------------------------------------------------------------- Create and maintain all Entropy Linux Documentation Graphics -------------------------------------------------------------------------- Make Linux look pretty will various graphics for X and our webpage. Command Shell ------------------------------------------------------------------------- Project to write a command shell for Linux with modules to decrease it's size yet allow for support of the syntax of several differ net command shells, and other built in utilities. Boot Loader ------------------------------------------------------------------------ Create an easy to configure boot loader. With support for several operating systems. Developers ------------------------------------------------------------------------- Henrik Abelsson . . . . . . . . . . . Jakob Roland Andersen - - - - - - - - Gabe Cain . . . . . . . . . . . . . . "C. Gugler" - - - - - - - - - - - - - Ramon van Handel . . . . . . . . . . Seth Horne - - - - - - - - - - - - - Bem Ajani Jones-Bay . . . . . . . . . Jon Klippenstien - - - - - - - - - - Mike Leonhard . . . . . . . . . . . . Mark Robinson - - - - - - - - - - - - Tsu-Man . . . . . . . . . . . . . . . Mjumbe Ukweli - - - - - - - - - - - - Nick Walker (Xioth, MIA) . . . . . . witwerg - - - - - - - - - - - - - - - Rob Wohleb . . . . . . . . . . . . . xekul - - - - - - - - - - - - - - - - _ _ \ \ From The Desk Of Witwerg The Sage / \_\ | --------------------------------------- | //o_/ | With his spell book: Foilicult | \ \_/ & Linux 2.0.x \ \_ Intelligence and Wisdom are key! TPU3D Update Submitted by Chetan TPU3d Update:-(by Chetan Taralekar, email:- chetan@earthling.net) I am currently involved in the TPUGFX project and am the sole coder in TPU3d. So here's an update for Tpu3d, which is a subset of TPUGFX. Notice that this is *NOT* an update on TPUGFX/TPU2d, coz i dont know till what they have accomplished. I suggest you contact Chicken(samko@geocities.com) or Del(myers@cedar.alberni.net) for more info bout tpu2d. *** Features of TPU3d *** 1..All integer-based world. 2..Is flexible in rendering methods; i.e. you can add your own perspective transformations and other add-ons easily. 3..Based on the modular and generic configuration as TPU2d. (Different files for device dependent startup, same files for generic code, support for various methods etc.) 4..Current support for triangles, quadrilaterals and pentagons(regular and irregular) only So far it can only scale bitmaps according to the distance and can wireframe tri, quad and pentagonal surfaces. Polygon support can easily be added, but it will complicate things in texture mapping which has not been implemented right now. Wireframing works properly, with shading and lightsourcing implemented correctly. I am currently working on polygon fillers with proper shading for the facets. Tpu3d has now finished a working wireframe modeller and a points scaler(ala DOOM enemies). So starfields and 3d equation graphs work well. Support for dynamic objects is also been coded. *** Future implementations *** 1..Depth Sorting(Experimenting on ways other than distance sorts) 2..Texture Mapping(Perspective correct) 3..Splines and Curves support 4..Implement a Modeler and a curves to multifacet transformer *** Further Info *** Info on Tpu2d can be obtained by going to the TPUGFX page(Contact Chicken, I forgot the address :) Latest info on TPU3d can be obtained by emailing me. As I am the only coder in TPU3d and with my exams coming up, I think I could use a bit of help, although I could easily code the basics myself. Contact me if you think you can help in any of the above future implements or give any ideas on anything. I'd appreciate that. Also, it would *really* help if anyone knowing OpenGL or the likes could help, since that would make this lib truly portable and future oriented. Ok, Thx all. Bye. Chetan Web page:- http://www.geocities.com/SiliconValley/Bay/1187 email:- chetan@earthling.net A line from shakespear.c:- (2B | !2B)? that_is_the_question():isnt_it(); ******************************EOF******************************************* ******* Wanted/Seeking Artists/Programmers Desperately Needed Submitted by Jeremy Penner HTML version: http://armpit.home.ml.org/ad.htm Artists/Programmers Desperately Needed Pure Substance Software is looking for artists and people who code using DJGPP. You must be dedicated and do work instead of procrastinating and making up excuses, like school. (We know people like that well, and there's no room for them here.) We request you send us a sampling of some of your work (ie. a program or a picture you made). E-mail pzp655@freenet.mb.ca with your program/picture or see http://puresubstance.home.ml.org for more information on our company. -- Jeremy Penner Help Wanted Submitted by John Wood HTML version: http://www.ambercomputer.com/documents/help.html We are currently looking for people to join our project. We are making a top-down view capture the flag game. We are creating the game in Visual Basic 5 Pro and are using DirectX5(DirectDraw, DirectSound, and DirectPlay). We need: At least two(2) 2d artists - Artists that are experienced with drawing 2d animated top-down sprites. At least two(2) 3d cutscene artists - Artists that are experienced with making 3d cutscenes. At least two(2) SFX creators - Those who can record and create sound effects At least two(2) musicians - Those who can make up original music that can set a mood for the game We hope that you take this opportunity seriously and join. We really think that this project could really be a success and even earn some $$$$. E-mail the project leader at johnwood@prodigy.net or visit the project web page for details at http://www.ambercomputer.com/capture/ TI-86 users needed! Submitted by Psion Do you have a TI-86 calculator? Can you run DOS programs? Do you know C? Then please e-mail me at chilip@ptd.net to become a beta tester for my TI-86 C compiler! Teen Programmers' Journal #2 ---------------------------- 1/17/98 Teen Programmers Unite - http://www.tpu.org/ (Best viewed in a monotype font, such as courier) Contents -------- Editorials The Geek Column (Humour) Javaholism - A Reply 7 Habits of Highly Effective Programmers Geurilla's Prophesy Why Microsoft doesn't scare me (and why it scares you) Instructional Articles Linked blocks in particle systems Neural Networks Wanted/Seeking TPU Quake Clan --- Editorials The Geek Column (Humour) Submitted by PowerTux HTML version: http://www.renc.igs.net/~jameshelferty/geeks.html Back, in spite of popular demand, is the geek column! Alrrrrright, let's get right down to it. This time around, I'm going to explain to you the difference between a geek and a nerd. I think it's high time you people out there found out the difference. This way, you won't be feeling our wrath each time you mislabel us. (Yes, you with the hat. That WAS us who invalidated your credit card..) Let's start with nerds. Nerds are people who don't have a life besides computers. They spend all of their time learning how to use programs, and when they've finally mastered them, yay! They're ready to pat themselves on the backs for a job well done. Geeks, on the other hand, are.. well.. they're pretty much the same thing, actually. Except that geeks can write these programs too. No, I don't mean in Visual Basic, or something as easy as HTML. (which most nerds take pride in being able to write in) I'm talking assembler. A geek is a programmer. And all 'real' programmers type in their code using edlin. About now, I suppose you're asking 'So why don't they like being called nerds?' Well, it's pretty simple. Ever since Revenge of the Nerds came out, people have been thinking nerds wear glasses, have sinus problems, wear pocket protectors... please! People, that's just not the way we are! We don't ALL wear glasses. Not ALL of us have sinus problems. And we're smart enough to know that the ink in pens has enough surface tension not to leak out, as long as we don't move at a speed greater than (9.8)/(ink constant)(volume of ink).. So people, please try to remember. We're geeks. Not nerds. Got that? Geeeeeeks.. not nerds. Okay! So now, what am I? ...*sigh*... why do I even try... ----- Javaholism - A Reply Submitted by Pri$m HTML version: http://home.pix.za/gk/prism/pages/scrawl/jholism.htm Javaholism - a reply Pri$m ~~~~~~~~~~~~~~~~~~~~ ~~~~~ In the first issue of the Teen Programmers Unite Journal, a coder called Dmitri wrote an article in which he attempted to evaluate Java as a programming language, and ended up highlighting it's 'faults' as he perceived them. In the true spirit of freedom of debate, I offer this as a reply to his article, in which I will tackle each of his 'points of weakness' one by one, in defence of Java. 1) _Java is slow!_ Java IS slow. It's generally significantly slower than anything written in any incarnation of C++, agreed. However, since Java is primarily designed for the creation of Applets, with good coding and a good design, you can quite easily overcome this. Take a look at Pri$m's Domain, and the Pri$m's Logo applet I use as a signature on all of my pages. It models a simple 8 sided polygon in realtime. Reasonably effective, and pretty fast. In short, while Java is slow, it's speed does not present as significant a problem as Dmitri seems to think. While it does make it unwieldy for writing full-scale applications, it does not make much of a barrier when writing applets. Therefore it's speed does not seem as much a problem when balanced against it's other attributes. 2) _Java is interpreted, and thus can be de-compiled_ True. But then again, when writing applets, well, you're not exactly hiding state secrets in them, are you? :) (I for one publish all the source code to my completed applets for download) 3) _"Java is way to much Object Oriented!"_ Well ... I suppose you do have the right to make the choice. The choice is quite simply, use Java and use OOP, or don't write applets. :) OOP is not only a really great paradigm, but Java being purely OOP is merely Sun keeping up with the latest movements in programming languages. All of the newly designed languages are at least hybrid OOP languages. (Ada 95, Dylan, Eiffel, etc) The fact is that virtually everyone now wants OOP in their languages. Secondly, it makes Java's extensive built in libraries, which I'll get to in a moment, particularly easy to use because they're all in 'packages' ... which basically makes it dead easy to find what you're looking for. 4) _Java is not platform independent_ This bit is definitely the weakest point in Dmitri's case. Microsoft Visual J++ is ENTIRELY platform dependent. But then, I wouldn't recommend trying to run anything written with an MS product on anything else than an MS OS. Aside from that, Visual J++ is NOT the most popular Java compiler. I believe at the moment Symantec Visual Cafe is. Either way, every OTHER tool on the market, and that includes Kawa, which I use, enables you to write platform independent code that'll run ANYWHERE. (Borland's JBuilder would be a great example, if it were less buggy) (As proof of this, I've seen my Logo applet run on a Linux Redhat XWindows system flawlessly, and significantly faster than under Windows '95) The fact is that it seems that Microsoft doesn't seem to want people to be able to write platform independent apps easily. An argument against Java is that, well, 90% odd of the planet uses Windows, why do we need anything else? The fact is that 90% odd the of the planet uses Windows because all other competition, irrelevant of their strengths and weaknesses, was squeezed out for lack of software support. Java eventually gaining prominence would mean that people could choose Linux, SunSPARC, VMS or even (gasp) Macs based on which one suited their demands more, and STILL have a decent amount of software support for it. 5) _Java lacks some of C++'s more powerful features_ That it does, but this is not as bad as Dmitri depicts. EVERY object variable in Java is a pointer. (Actually, closer to a reference) You just can't manipulate them directly. As for the benefits of enhanced security, the potential of what some guy on the other side of the world could do if he could mess with your machine whenever you enter his webpage is scary. That security is vital, especially to those in the commercial and end user areas of computing. Aside from that, Java provides a pre-built, totally cross-platform set of libraries that, as they grow, are targetted at catering for EVERYTHING. Java has a set of color model and color filter classes that I for one have never before seen in a compiler's standard library. I've also heard that Java 1.2 should have a 2D graphics library built in. Things like that can make life so much easier. :) If you've ever tried to port a Linux sockets app to Windows 95, or the Mac, you'll know how valuable these common libraries can be not only practically, but also in terms of learning how to write code without tying yourself to a specific platform. 6) _Java cannot produce attractive GUIs_ Agreed. This, as far as I am concered, is it's gravest problem. Java does not provide for a means to fully control the placement of components in things like dialog boxes, but the inherent logic behind that is that Java has to provide a way to create an interface that will be consistent across all target platforms. Java therefore provides Layout Managers, which allow only a limited degree of flexibility, but provide platform independent design. And once again, if you're writing applets in Java, if you do happen to use things like buttons and checkboxes, you'll appreciate that anyone should be able to see them as they were designed. For applications, this remains one of Java's serious limitations, although some IDEs work around it. (JBuilder, for instance, has an XYLayout manager which means you can put your controls wherever you want) What I'm basically trying to say is that Java, despite it's shortcomings, is actually a wonderfully elegant little language. It deserves to be looked at and tried out by absolutely everyone - and hopefully sometime in the future will gain more credibility as a language to develop standalone applications in. For the moment, however, it's main advantage lies in that it remains the only real choice for writing applets, and it that task, it is extremely well thought out and designed, and, therefore, a pleasure to use. - Pri$m. - http://home.pix.za/gk/prism | prism@pixie.co.za | UIN: 670945 ----- 7 Habits of Highly Effective Programmers Submitted by kbot HTML version: http://users.pdnt.com/~consalus/habits.html 7 Habits of Highly Effective Programmers 1. Take breaks for violent games before and after frustrating tasks such as debugging. Even God took a day off. Mindless killing helps you concentrate. 2. Set a goal for what you hope to accomplish, and do it no matter what the cost. If you are having problems, lock youself in the room with cold pizza and jolt, close irc, and work till it is done. 3. Instead of remaking the same functions for every program, make functions where all needed data is passed to the function so that you can use it in future programs. 4. Plan out what you are doing beforehand. Make all major design and technically discisions before jumping in and coding, or you will run into problems. 5. If you run into a problem you cannot solve, print the code out and bring it to bed with you. Read it before you go to sleep and when you wake up. 6. Comment your code. It doesnt hurt, but it sure can help. 7. Indent and format, and do it consistantly. It makes your code easier to read and easier to understand. ----- Geurilla's Prophesy Submitted by Geurilla HTML version: http://www.magicnet.net/~jacobw/zine/Proph.html Geurilla's Prophesy The world is a changing place. Duh. The computer industry is moving at a break-neck pace. Gee, I haven't heard that a million times. Java will revolutionize the industry. What was that? A resounding "no"? Ok, the introduction of one new language probably won't totally change the way we live, but the idea is a very provocative one. Think about this: A program written and compiled once runs equally well anywhere, on any machine, under any circumstances. Everyone's operating system is the same (well, to be a perfect world, it would be fully customizable, right?). Processing power, for most applications, isn't really an issue. Internet connections are muli- megabit. Download time doesn't exist. There is no such thing as a platform. That's the future. Today: we have many great architectures- RISC, 8088 and family, IA-64, and let's throw in the Motorola PowerPC family to mix it up. But the problem is this, each family has a different instruction set. Each arcitecture has its ups and downs and is different, and, therefore, the software is different. GUI's have become very similar. MacOS, OS/2, and Win32 are very similar. Application development is moving to platform independence. It's not a new idea. People have ported programs written in C for years and years. Interfaces have become predominatly standard. Someday, we won't be worrying if we should develope for a 16 or 32 bit environment. We won't care if the user is running a Voodoo or Mystique graphics card. The reality of this evolution won't be seen by our generation, but it is realistic. Just an opinion. Don't flame me. Jacobw@magicnet.net ----- Why Microsoft doesn't scare me (and why it scares you) Submitted by Geurilla HTML version: http://www.magicnet.net/~jacobw/zine/Scare.html Why Microsoft Doesn't Scare Me (And Why it Scares You) I often see on IRC or message boards people putting down Microsoft and its "unfair dominance over the computer industry". People like to complain about how slow Windows 95/3.x/NT is. They trash VJ++ for its non-compliance with Sun's SDK Specifications. They hate Visual Basic because it's slow or it's stupid or for fools. They can't stand Internet Explorer. Why? Because it's cool. It's some kind of anarchy. It's not mainstream. Microsoft makes good products. Competetive products. That's why they have the dominance that they do. Windows 95 is easy to use. It has a user friendly interface. It is relatively powerful. Visual Basic is easy to use. It's versatile. It can do anything any other language can do, even if it's achieved with nothing more than a dll. VJ++ is... well, you got me there. But the point is this: Microsoft won the OS war. Someone had to. Now everyone is developing for Microsoft's Operating Systems. The future of the industry is in Microsoft's Operating Systems. Deal with it. I recently read an article in in Visual Basic Programmers Journal dealing with this topic. It's available on-line at http://www.windx.com. I highly recommend it. Very interesting thoughts. Geurilla's pet peeves (things people trash): The Windows architecture is great. It's multi-tasking and 32-bit. It supports dynamic linking. These are things that were virtually imposible with DOS. DOS is dying. The Object Oriented Programming Model is great. Don't trash it just because you don't understand it or it confuses you. There is nothing wrong Internet Explorer. It has the same basic features as Netscape Navigator. One is not better than the other, in my opinion. And besides, isn't the imortant thing the fact that it has pictures? Just an opinion. Don't flame me. jacobw@magicnet.net ----- Instructional Articles Linked blocks in particle systems Submitted by Daniel Burrows HTML version: http://www1.scasd.k12.pa.us/students/dnb11/3D/more_particles.html Linked blocks in particle systems The previous TPU Newsletter had an excellent article on particle systems. This is a short suggestion for further improvement in the technique which was described in it. Overview In the previous TPU Newsletter there was an article describing how particle systems work. If you missed it, the basic idea is to store lots and lots of particles in memory, move them around each frame, and then write them to the screen. These are the major steps and the major difficulties in performing particle animation; I use an alternative method of storage which I think is more efficient than the linked-list described in the article (in fact, it's an outgrowth of a linked-list.) All code examples in this article are in C++ (sorry Pascal programmers :( )--if you absolutely have to have them in a different language, mail me and ask me for them--hopefully, you'll be able to piece together what I'm saying. Concept The simplest method of storing particles is a struct--for example: struct particle { float pos_x; float pos_y; float vel_x; float vel_y; char color; char time; } This method actually works quite well for programs with only a single set of particles that are all created or destroyed simultaneously. For example: particle particle_list[3000]; int num_particles; These definitions allow you to do a simple explosion effect. However, in a more complex program with particles being arbitrarily created and destroyed, this doesn't cut it. You would either have to cycle through all 3000 (or more!) particles and test each one or else keep the array contiguous by shifting particles whenever you created or deleted some. In addition, you've allocated space for 3000 particles. What if you only use 100? Clearly, there has to be a better way to do this, and the first answer that leaps to mind is a linked list. Note: While I am going to give a quick run-through of what a linked list is, I won't go into an in-depth explanation of linked lists here. This article has a very good description of what a linked list is. The basic idea of a linked list is to create a chain of items in which each item contains information about where to find its neighbors. In this case, each item (or "node") will contain a pointer to the next item in the list, or NULL if there is no next item (i.e. it is the last item in the list) All you have to do is modify the particle structure to contain a pointer: struct particle { *particle next; int pos_x; int pos_y; char color; char time; float vel_x; float vel_y; } typedef particle_list=*particle; (Note: Yes, I could do this with objects and member functions and it would probably look "nicer"--but I'm trying to describe particles, not discuss the pros and cons of object-oriented programming or describe how it works.. ;) ) Now, after constructing the appropriate routines (add_particle,delete_particle, etc), your list will be ready to work. I could have used a doubly-linked list (i.e. one that contains a pointer to the previous element as well). Which type you use depends on whether you really NEED that extra memory space that you can save by only using one pointer and on whether you're deleting lots of items from the list--deletion is much more effecient with a doubly-linked list. Problems with the linked list format Linked lists are very neat ways to store data, very memory-efficient, and fairly easy to understand. What's the problem with them, then? * Memory: Although they are efficient in that they don't waste memory on extra items, they tend to be bad for storing very small bits of data--in extreme cases, the space used for the next and prev pointers can exceed that used by the rest of the structure! This is not nearly that bad, but if we allocate 3000 particles, enough extra space will be allocated to store at least 500 more without the pointers. * Speed: This is the biggie, though. Here's a "typical" loop for iterating through the list: particle curr=list; while(curr) { put_pixel(curr->pos_x,curr->pos_x,curr->color); curr=curr->next; } The pointer load and test has to be executed once for every single particle. Even if put_pixel is not an inline routine, this is pretty bad. If it is, the pointer load will consume a lot of time. Worse yet, consider what would happen if we changed this to assembly language (if you don't know assembly language, skip this--it's not critical) : PUSH DS LES DI,DoubleBuffer ; Note: this code assumes we're using 32-bit pointers--for other ; pointer sizes some modification is needed. It also assumes that ; a 320x200 double buffer is being used. The purpose isn't to be ; a working model but to illustrate the problem with this method LDS SI,list loop: > MOV AX,DS ; Start by checking for a NULL pointer > TEST AX,AX > JNZ NotNull > TEST SI,SI > JZ Done NotNull: MOV BX,[SI+4] ; BX=curr->pos_x MOV AX,[SI+6] ; AX=curr->pos_y SHL AX,6 ADD BX,AX SHL AX,2 ADD BX,AX MOV AL,[SI+7] ; AL=curr->color MOV ES:[DI],AL > LDS SI,[SI] JMP loop Done: POP DS RET I've marked the offending parts of the code. Not only are they approximately a third of the instructions in the loop, they are some of the slowest instructions--especially the branches. The computer can't cache the upcoming pixels with any consistency since they're off somewhere else. This is the primary problem with this code. It would be so much easier to quickly draw (and update!) all those pixels if they were in an array--instead of the awful pointer loads and tests, we could do a simple count-down loop with DEC CX/JNZ and shift the current pointer with ADD SI,SizeOf(particle). It was thoughts like these that gave me the idea for what I dubbed the linked block system (although I'm sure someone somewhere has a real name for it ;) ) Linked blocks Often, particles come in bunches. Confetti is all thrown at once, blood spurts in spurts, snow particles can stay allocated and be recycled into the sky when they melt. If I were going to write a program to do a single one of these which never had to deal with other particles, I would store them in a gigantic array and loop through it. Since the particles are mostly created and destroyed at the same time and are controlled by the same movement algorithm, there's no reason to separate them from each other. One solution to the efficiency concerns of linked lists is to make the observation that there is no law saying what the nodes of a linked list are. In other words, we can create linked lists of arrays. Each node will be a continuous block of memory which begins with a pointer to the next node (or NULL if there is no next node) and the number of particles in the block. When drawing or updating particles, we can perform the pointer-load to get the next block, then use a tight, fast loop to perform the actual operation. This can speed the program up considerably and (to my mind) makes more sense. It also means that if particles need to be added, the block can be expanded to accomadate them--or even that extra space can be allocated and the particle count can be set lower than the actual size of the block, then incremented as particles are inserted. Particle destruction is still a problem (as with regular arrays), and I wouldn't suggest using this for a system that destroys large numbers of particles on a regular basis without first checking to see if some "trick"--for example, recycling particles by moving them back to an origin or breaking your list into smaller blocks--can be employed. However, even if you have to skip over "holes" in the array, this is still sometimes faster than a linked list. You have to be a little more careful with your memory allocation than you do in a "normal" linked list, but it's not too bad. You can create a "dummy" structure: struct particle_header { particle_header *next; int num_particles; } This structure can then be used for memory management (another int field can be added if you want mismatches between the allocated size of a block and the amount that's processed.) --------------------------------------------------------------------------- daniel@shadow.astro.psu.edu ----- Neural Networks Submitted by socrates HTML version: http://www.ilstu.edu/~rahmed/neural.htm What Are Artificial Neural Networks By Rehan Ahmed (AKA, Socrates_) Who this article is for: 1) Those whom have never heard of artificial neural networks or 2) Those whom have heard of them but know very little about them Simple Guide to Neural Networks Are computers smarter than humans? Of course not, humans make computers! Sure, computers are able to do incredibly fast calculations and solve problems that would take the human brain much, much more time and more prone to error. However, small babies are able to recognize people in a variety of environments, use complex grammar, understand gestures and speech. Until now, computers have had little success reproducing the natural skills of humans-- though now, neural networks, are having slightly more success in emulating these skills. So, what are neural networks? Well, a neural network is a computational structure inspired by the study of biological neural processing (Rao 1). Uhhh..Whatever…stated simply, a neural network wants to work how our magnificent brain works. There are numerous types of neural networks but almost all of them are composed of layers - the input layer, hidden layers, and the output layer. These layers act independently from the others. When the computation in the layer is completed the value from it is passed on to the next layer. The processing elements of the network (which are done in the hidden layers, usually) are similar to the neurons in the human brain and are called cells or artificial neurons (which we will just call neurons). All of these neurons are interconnected through synapses or connections. Now if the input in the neutrons exceed the threshold function it is said to fire (1). If it does not it is said to not have fired (0). This is a basic, very basic introduction to neural networks (I'm actually laughing at how simple it is) But, nonetheless, one, by reading this article, should be able to hold some sort of intelligent conversation regarding neural networks. There are many more aspects of neural networks -weights -training -feedback -supervised or unsupervised learning -noise -memory (short term or long term memory) What Can be Done with Neural Nets There are many applications that lend themselves wonderfully to neural networks. Many problems in life are solved without algorithms, meaning, that orthodox computer programming will not work. However, using neural networks it is possible through training to be able to recognize and solve the problem. Some situations -Face recognition -Financial forecasting (eww…) -Voice recognition -Handwriting recognition -Virus detectors -Compression utilities and many more A Contrast between Neural Networks and Artificial Intelligence and how this relates to the Game Programmer There is a difference in a approach between neural networks and AI and one should not get them confused. Neural networks are designed bottom-up: producing simply networks which replicate intelligence - recognition, association, classification, learning - using nature as their template Taken from a site which I can't find anymore but excellent tutorial on NN's This contrasts sharply with the AI approach. Artificial intelligence is geared toward a specific problem. If problem is to navigate a robot about a room and move palettes, the AI approach would attempt to recognize various visual signals generate an internal model of the room from these, determined how the robot should move to achieve its end, and then perform the determined actions. The neural network approach would attempt to build networks which can recognize palettes, avoid bumping into objects, move towards a target, and pick things up. From what I have seen and from what I have coded in my games most people use a rule-based system as basic AI. For example, if enemy moves within this area shoot him (or something much more complex) However, I am planning, once I become more seasoned in Neural nets to have the opponent actually think. He will actually learn. I have heard games in the past that say the opponent learns but I questioned whether they use neural networks or not. However, I am sure many of the next-generation games or ones that have just hit the market implement some sort of neural networks to enhance the experience. Well, I'm really, really tired now and I think I'm going to stop but I hope this article sparked some interest in you, the reader, toward the fascinating world of neural networks. I have just begun but if you have any comments or I have confused you please email me at rahmed@ilstu.edu. So Long! Sources that I used C++ Neural Networks and Fuzzy Logic by Rao and Rao, 2nd Edition Nnintro at osiris.sund.ac.uk (doesn't seem to be there anymore =( Be sure to visit my C tutorial at www.ice.net/~socrates/c.html ----- Wanted/Seeking TPU Quake Clan Submitted by Nitsuj HTML version: nitsuj.home.ml.org/CLANJOIN.html TPU now has a Quake Clan called Clan TPU. To join, e-mail Nitsuj @ Greco_roman@hotmail.com There are Currently 3 members. They are : Nitsuj, Xekul, and TechmageWe are accepting both shareware and registered users. Hopefully there will be enough of us soon to enter a tournament. The clan homepage is currently at Nitsuj.home.ml.org/CLANTPU.html Catch you all in a few -Nitsuj ----- Teen Programmers Unite - http://www.tpu.org/ Teen Programmers' Journal #3 ---------------------------- 1/31/98 http://www.tpu.org/ Contents -------- What's New in TPU TPUCON - A Quick Summary IIC CGI Update Editorials DOS Is Dead--But We Don't Have To Like It TPU Purity Test (1st Revision) Instructional Articles Particle Systems: A further discussion --- What's New in TPU TPUCON - A Quick Summary Submitted by rnd HTML version: http://www.us.tpu.org/rnd/tpucon.html Well, Devon (irc Ender) pointed out that maybe someone should write an article on TPUCON, and a few people on irc lately have mentioned it, so here goes.. TPUCON - a quick summary by rnd TPU: Teen Programmers Unite CON: Convention, in the computer world usually a large gathering of hacker types in real life opposed to electronic gatherings on irc. Hey all, rnd here with a quick explanation of the original TPUCON idea for those who haven't heard about it yet. Back in mid-June, 1997, some of the #tpu regulars (Twitch, xekul, parsite, kain and crackwiz (hey, haven't seen him around for a while come to think of it..)) basically came up with this cool idea that we could have our own big get together of all tpu members who could make it and be able to meet face to face. What would we do? Hang out, teach each other computer stuff, have fun, maybe have a big quake game if we can get the computers, probably start lots of fights about oses and countries and editors and other such topics, probably terrorize the local city area (we *are* teens..), and most likely other things we just spontaneously decide to do :) When would we have a TPUCON? Originally it was hoped we could pull off a con in Summer '97, but this never worked out, for lots of reasons, including that a lot of people went on holiday during the summer, and the fact that most of the TPU membership was idle at the time. A few people are starting to talk about possibly having a TPUCON in Summer '98, but there isn't much support for it currently. One major problem is that even though after the restructuring during Fall '97 most of our members are inactive. Please people, fire up that dusty old irc client and come to #tpu on efnet! Even if you don't give a damn about a con, come on irc, it's not strictly programming, it's usually teen gossip with lots of computer discussion thrown in! As for a quick note to where TPUCON would be held, this was up for debate when the con was discussed earlier. The three choices we narrowed it down to were Toronto, Chicago or Cleveland, which is very convenient for easterners, but pretty annoying for us out west here :) It was decided the con would be held in North America somewhere because that's where most TPU members are from. A possibility would be to hold a con for Europeans in Europe somewhere at the same time as TPUCON-North America and have an irc link at least, and possibly a video link. Unfortunately, we would need some sort of sponsorship to hold a con such as this. TPU is of course mostly teens, and the average teen barely has enough money to go see a movie on Friday night. I dunno where we'd find a company willing to sponsor a hundred or so (hopefully) teens to hang out and terrorize elderly people walking down the street. (rnd! your immature side is showing! *slap* ah, much better.) So anyway, that's the basic story on TPUCON. So far nothing has materialized yet, but if you think it's cool, come on irc (efnet, channel #tpu) sometime and discuss it, or post to the webboard (I personally haven't read these for a long time, sorry :) or something.. If enough people want it, we might actually be able to get something done! The original TPUCON page is located here: http://www.citynet.net/personal/parasite/tpucon/ -rnd (linux user, C coder, composer, etc.etc.) email: rnd@cosmos.ml.org irc: rnd@efnet (channel #tpu - be there! :) p.s. If there's any music-composer types reading this, check out the TPU Music Interest Group at http://members.xoom.com/Armpit/ ----- IIC CGI Update Submitted by Psion The latest addition to the TPU IIC is here: The Project Directory. Members rate themselves in a multitude of skills and maintain listings of open positions in their programming projects and what skills are required to fill them. The script instantly matches you up with the projects you can join/people who can fill your positions. Give it a try. Log on to the IIC at: http://www.tpu.org/iic.html and follow the Project Directory link. Contact me with any comments and suggestions. Also: Coming soon, dynamic IP address resolution free for all TPU members! Each member will be entitled to one *.dyn.tpu.org hostname, configurable through a CGI script. You will be able to update what address it points to through through a web interface or custom client. ----- Editorials DOS Is Dead--But We Don't Have To Like It Submitted by Jeremy Penner HTML version: http://armpit.home.ml.org/dosdead.htm This is a rebuttal to Geurilla's "Why Microsoft Doesn't Scare Me" article that appeared in TPJ#2. I'm afraid that I have to agree with the fact that DOS is dying with the mainstream computer users. It's very simple marketing--you make something that the biggest number of people can use. But I draw the line at saying that Windows is a good OS. A good OS doesn't crash on you every day. A good OS doesn't make you re-install it 4 times in a year. Both these things happen to me with Win95. Having to delete and re-install Windows is one of the biggest pains in the ass a computer has ever put me through. I was lucky--I have the disks to re-install it. Some guy who bought his computer with Windows pre-installed would find himself SOL with a $2000 paperweight. Windows architecture great? Don't kid yourself. Is it truly the sign of a great OS if one misbehaving application can take down your entire system? Don't forget the various internet nukes: WinNuke, Teardrop, Land, Bonk...try telling me these security holes make up a superior OS that deserves to lead the market. As for your specific pet peeves, there *is* something wrong with Internet Explorer. The Javascript implementation is completely screwed up, for one thing. I tried to create a little script; it ran perfectly under Netscape, and made Internet Explorer die a horrible, horrible death. As far as I can tell, it's because I used a variable that was bigger than 128. Oh, and don't forget IE's numerous security holes! ActiveX allows some hacker to mess around with your files. There are several ways of making IE arbitrarily download and run viruses and the like. (See http://l0pht.com/advisories.html if you don't believe me.) Has Bill Gates won? Yes. Is it right? NO. I'm sure there are a few people for whom Windows runs perfectly on. I'm sure you're one of them. For the vast majority of people, however, Microsoft is the cause of all their computer problems--and they're making billions doing it. ----- TPU Purity Test (1st Revision) Submitted by rnd HTML version: http://www.us.tpu.org/rnd/puretpu.html TPU Purity Test 1st Release January 16th 1998 *** WARNING *** This file may contain subtle or not-so-subtle references to various possibly illlegal acts which might contain one or more of the following: goats, genitalia, linux, pornography, ACE, microsoft and massive violence. If you are over the age of 18 or have any resemblance of maturity, please go no further. No animals were harmed in the creation of this test except for a few odd goats here and there. Much thanks to those who contributed questions: PowerTux, xekul, mellon, ACE, Tsu-Man, kbot, Daedalus, Jester, Yoda, and anyone else who I've forgotten to mention. One note: If you're never on #tpu on irc, you probably won't understand much of this as it reflects the `#tpu culture' that has sorta sprung up.. -rnd, 1st tpu purity test compiler :P Answer the questions, and count up the number of "Yes"'s you had. If you have between 0 and 29 you are probably one of the following: a Newbie #tpuer, a Hanson Freak, a Skyinet Loser, a Red Lamer or an Amoeba or something. :) The rest are as follows: 30 - 39 Average #tpuer 40 - 49 Long Time Regular #tpuer 50 - 59 Slightly Perved #tpuer 60 - 69 Goat[FORNICATE]er/Bill Gates Here's a few of our scores: rnd - 43 Yoda - 41 xekul - 41 As you can see we've been around for a long time and vividly remember the AxeMan in Summer 97 :) So anyway, good luck, and remember, this isn't serious or anything, we were reading a pyrotechnics purity test one day decided to make our own. So remember, it's for fun, eh? Questions: 01. Have you ever fondled a goat before? 02. Do you like to see goats on fire? 03. Do you PH34R THE FLAMING GOAT? 04. ...Do you know why? :) 05. Do you know why this test is obsessed with goats? 06. Are you aroused by surprise.jpg? 07. Are you a #tpu regular? 08. Have you ever defenestrated something? 09. Have you ever insulted xekul? 10. Have you ever done a gay little dance? 11. Can you name the founder of TPU? 12. Do you participate in OS wars? 13. ...Language wars? 14. ...Compiler wars? 15. ...Editor wars? 16. ...Canadian political party wars? 17. ...Country wars? 18. Do you enjoy harassing on #windows, #anime, #warheads and #theworld? 19. Do you pariticpate in Right 0n! floods? 20. Do you remember the Skyinet days? 21. Are you Discordian? 22. Do you know what `Whoop Your Rumpty' means? 23. Do you insist on using pathetic, yet vaguly funny text fitlers while on irc? 24. Do you understand s/foo/bar? 25. Do you own a copy of surprise.jpg? 26. Have you ever caught ACE trying impersonate someone else in #tpu? 27. Have you ever been to #cindy? 28. ...was it as impersonating a female? 29. Have you ever tried to impersonate someone in #tpu? 30. Did you know that Bill Gates was killed by goat rights fanatics? 31. Have you ever tried to draw a flaming goat? 32. Have you ever tried enflaming a realy goat? 33. Have you ever installed Linux? 34. ...on a 386? 35. ...on a 286 or lower? 36. Do you remember the AxeMan? 37. Have you ever experienced the effects of "rm -rf /var"? 38. Have you ever been teardropped while joining #teensex to find out what the big commotion was about? 39. Have you reinstalled Linux more than 5 times? 40. Do you laugh when someone says `Aaggghh! I shouldn't have eaten my pet dog Fang's corpse!'? 41. Are you becoming homophobic? 42. Are you afraid of natural sunlight? 43. ...And you are _not_ a vampire, or other demonic creature? 44. Do you smile more often on IRC than IRL? 45. Do you ever get uncontrollable urges to launch a manmade object into orbit? 46. ...did you join the TPUSAT project? 47. Have you read the Legend Of The Red Lamer? 48. Do you know the first TPU homepage URL? 49. Have you ever broken a tooth, lost vision, or suffered similar facial damage while attempting the xekul-patented evil one-eye? >o] 50. Have you read the entire BOFH series? 51. ...Have you re-enacted any of them? 52. ...Are the police still looking for the bodies? 53. Ever tried to program an improved ICQ? 54. Have you ever tried hacking sune2.virtua.dk? 55. ...successfully? 56. Ever started a project and never finished it? 57. Has Linus Torvalds been made aware of your undying devotion? 58. ...has he signed a restraining order? 59. Has your nickname ever started with the letter x? 60. ...does it still? 61. Are you on Bill Gates' Fan Club's most wanted list? 62. Do you own a virtual pet? 63. ...is it a goat? 64. Do you know about ACE being a part of Hanson? 65. Have farmers in your city lately begun locking their goats in at night? 66. Have you ever spent two hours trying to locate goat-related easter eggs in MS products? 67. Have you ever weakened your authority in the livestock/owner relationship? 68. Have you ever really wanted to kick Bill Gates where his genitals should be? 69. Have you ever visisted the `Pretty Goats Webring'? ----- Instructional Articles Particle Systems: A further discussion Submitted by Dav HTML version: http://corryong.albury.net.au/~smcall/cycle/response.htm Particle systems: Alternative approaches In the last two issues of TPJ, two different approaches to creating particle systems have been discussed. I would like to further discuss the merits of either approach, and suggest some additional ideas to improve efficiency. The first method was linked lists, discussed in TPJ#1. As pointed out by the article in TPJ#2, linked lists can be very inefficient both in speed and size. The alternative presented there introduced the concept of using a linked list of arrays, with each array containing a variable number of elements. The problems usually assosciated with arrays, on the other hand, are that removing an item is inefficient. To maintain the order of the elements when a particular element is removed, each higher element must be moved downwards one position. For a large array this can take an inordinately large amount of time. An alternative approach is to simply mark unused elements as such, and skip them during the loop processing, but this leads to two other problems: firstly, time is wasted checking to see whether particles are active and secondly (and most importantly) it complicates the process of adding particles to the list - an empty slot must be found. The key in the above paragraph is 'To maintain the order'. In particle systems, it is generally unnecessary to maintain the order of the processing of the particles: each particle moves independently of all others. So, in an array of particles from which a single particle needs to be deleted, all that needs to be done is the following: - copy the last particle data over the data of the particle to be deleted, ie. "particle[to_delete] = particle[last_particle_index]" where 'last_particle_index' is generally equal to 'number_of_particles - 1'. - Reduce the number of registered particles by 1. This may or may not also involve changing the size of the memory block in which the particle array is stored. Note that is also feasible, using the above method, to store all particle data in a single array. However, this has the following disadvantages: - If a fixed array size is used, a limit is placed on the permissible number of particles. - If a resizeable array is used, the entire array may need to be moved in memory. This is extremely inefficient. I suggest that, if there is a theoretical limit to the number of particles in the system at once, the first point above is not really a problem, especially if the limit is relatively low. Some further efficiency notes: - If using resizeable array(s), or linked lists of arrays, the array should be created with particles in order from high life time to low life time. If this is done, then particles to be deleted will generally be at the high end of the array, so that deleting them simply involves reducing the particle count. - Never increase the size of an array. The resulting memory move can be very time consuming, especially for arrays which are already large. If a particle needs to be added but the arrays are all 'full', simply create a new array. - Operations which work on groups of particles are more efficient than going throught the particles individually. For example, for particles which expire after a time limit, all can be deleted at once so long as they are grouped together. Take an explosion as an example; it consists of various particles of different life spans. If the particles are ordered in order of life span, highest to lowest, then particles will expire in groups, and they can be removed from the system simply by decreasing the particle count by the appropriate amount. Happy coding, Dav (DavMac@iname.com) -- TPU: http://www.tpu.org/ If you wish to submit an article for a future newsletter, visit http://www.tpu.org/news.html. The deadline for issue #4 is Friday, February 13. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #4 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 2/13/98 Contents -------- What's New in TPU Future Possibilities TPUCon Project Revival Editorials Me's Two Bits The "Usefulness" of Java Instructional Articles Writing Win16 Screen Savers --- What's New in TPU Future Possibilities Submitted by Psion * Member software CD? Here's an idea that I've been toying with for a while. It involves members contributing demo/shareware/freeware programs that they have written to be printed on a run of CD-ROMs. Universal installation programs for the major platforms like you find on most large shareware collection CDs would be included. This would provide members with easy publicity for their software, perhaps even advertising software they hope to sell commercially. Popular freeware programming tools (included with the permission of the authors) such as DJGPP could also be included. I know that many a newbie C programmer would appreciate having a CD with an easy interface for installing DJGPP with customizable settings for which components and libraries to install. The Entropy Linux files could also perhaps be on the CD. Something like this would obviously require money. One possibility would be that each contributing member could contribute the cost of 2 CD's, to pay for the CD that he would receive and also for one more to be distributed for free, or perhaps for a minimal cost. This is not definite or refined at all, just ideas. Feel free to discuss it on IRC, the WebBoard, or the news server. * Programming book? This is another idea in the same veign as the first. We could possibly assemble a book on many different aspects of programming. Unlike commercial slow-moving books on narrow topics, this could contain chapters on just about all programming topics. Articles from the TPJ and new material could all be included. It could feature tutorials in all major languages oriented toward people with enough experience to be able to learn fairly quickly. There could be reference sections on many different topics, links to programming sites, lists and reviews of products, etc. Information that we feel is essential to a well-rounded knowledge of "net programming culture" or whatever you want to call it could be in it. All in all, I think it could be pretty damned cool to have an all-purpose programming learning/reference book written collaboratively, and this could actually be a revenue producing project, allowing for possibilitues of TPU hosting web pages and even servers for members. * Endorsement of Interplay's "Learn BASIC"? Interplay has contacted us about the possibility of endorsing a beginners' programming edutainment product called "Learn to Program BASIC: Jr. High Edition." The general consensus seems to be that we will agree to this. A Teen Programmers Unite logo could actually be on a commercial product. 8) This is an excellent opportunity to let beginning programmers know about this organization as a possible resource. Details are still being discussed and the final arrangement will probably be announced in the next TPJ issue. - "Learn BASIC" : http://www.interplay.com/basic/ ----- TPUCon Project Revival Submitted by pForce HTML version: http://www.ocslink.com/~pforce/tpucon.html Due to a recent revival of interest in the original TPUCon project, I thought that it would be a good idea to write a little about it. If you can remember way back in the last TPU Journal, rnd wrote up a short summary of the basic idea behind TPUCon. If you've forgotten, TPUCon's goal is to hold a gathering of the members of TPU to meet in real life, and to gain a perspective on the group which can't quite be grasped over the vastness of the internet. While the idea sounds good in theory, in practice it will be much more difficult to achieve than it might first seem. We first will encounter the problem of finding a convenient location for the majority of people who are willing to come. Since the majority of TPU's membership lives in North America, it will be held there, most likely somewhere in the United States. Another problem that we will encounter is funding for the project. Although we have no definite plans or timetables, the project will be quite costly to pull off from any perspective. There are several ways which this money could be raised. This ranges from the members evenly paying their share (although this is least preferable as we would like as many people to come as possible, regardless of financial status.), to finding sponsors from the corporate world, to holding various fund raisers which would be determined within the group. I hope that I have managed to convey the sense that this project will require as many minds as are willing to help us if it is to achieve the kind of success we are hoping for. Not only would TPUCon be a fine way to meet the people of TPU, but it would be good for publicity of the group and possibly to get additional corporate sponsors for any other events TPU would like to hold. Since the original group of TPUCon seems to have lost the steam it once held, I think that it is important to restructure the project group to get fresh new ideas in on it, which might get the job done. Of course, everyone in TPU is welcome to join in. If no one else would like to step forward, I have the time that would be needed to coordinate a project of such a size, although most likely a committee would work to our advantage to more evenly distribute the task. Remember, we are Teen Programmers Unite. Lets try it. Paul Force -- pforce on IRC paul@forcecorp.com ICQ UIN: 1149697 Please send me any comments that you have, I will try to get back to each of you personally! ----- Editorials Me's Two Bits Submitted by Me HTML version: http://www.scn.org/~bitman/twobits.htm Me's Two Bits A few weeks ago I went into the voting booth and found out that some people (about 34 percent the last time I checked) wanted to change TPU's name. I promptly voted "No" because of the fact that I was against the idea. Most people want to change the na me to something that would alow us to stay in the group when we grow up and become adults. I don't think that that was the intent of TPU in the first place. I have always seen TPU as a place where teenage programmers, like myself, could get together and e xchange ideas and work together on projects. When you outgrow TPU, you can, as someone suggested, join the NAP. Another option would be to set up an organization for former TPU members (FTPU) so that they (we) can continue to unite their (our) efforts. This has been another exciting eppesode of Me's Two Bits. Please tune in next week for Me's oppinion on why pencils don't come with bigger erasers. If you disagree with Me of Hearth, please, by all means, do one of these two things: Email your counterp oint to Me at bi504@scn.org, or write an article in next week's edition of TPJ rebuking my position. If you happen to agree with Me, please send Me a message telling Me how much you admire Me's ability to state the obvio us. ----- The "Usefulness" of Java Submitted by coldAXEin HTML version: http://www.geocities.com/SiliconValley/Lakes/4384/Java.htm The Usefulness of Java Neil J. Adcox [coldAXEin] "The usefulness of Java"” has been gravely overstated in the past few years as the Java hype continues to bellow through the software development community. Everyone gets caught up in the so called "features" of Java ( cross-platform portability etc. ) that people forget to analyze what they actually mean. After closely examining some of the information in recent articles I will attempt to write my own synopsis of "The usefulness of Java" [ Insert English teachers applause for successfully using an oxymoron ] The fact that Java is NOT platform independent is probably why the language is destined to go the way of languages such as ADA and LISP. I wrote an applet for the express purpose of "testing" it on other platforms and found that out of the 4 platforms it was tried on it only worked for two of them; the target platform Win 95/NT and UNIX. Let’s face it, Windows and Mac successfully capture 98% of market share and UNIX is dying ( Aren’t I making enemies? ) That’s another article, another day. Java is actually "write once, test, debug, and special-case everywhere." MSDN’s Dr. GUI has written a succession of articles on Java’s "write once, run everywhere" philosophy (or the lack thereof). You can read these articles at http://premium.microsoft.com/msdn/library/periodic/periodic/msdnn/dr_gui/gui36.htm. You will probably need to obtain a [free] membership to MSDN (Microsoft Developer’s Network). So.... if Java is not truly portable, where does that leave us [and the language]? The other features of Java are either insignificant or add to it’s useLESSness. Because of Java’s built in security features, Java is limited in what services it can offer. Sure, a spinning sphere looks great on a web page but what does that offer the software world. Real developers don’t need such fruitless animation and if they did there’s always Gif89’s. I have yet to see a Java application that is truly useful. I’ve seen menu’s [on Prism’s page] and other uses but none are substantial applications. Java applets barely even enhance a user’s experience on a web page. Add these facts and throw in Java’s inability to offer an interface and you get a language that does nothing but glare at you on a shelf. Perhaps the most annoying "feature" of Java applets is the [ life ] time it takes to download them. Ever waited for a Java applet to load? Must of us would probably yell a resounding "NO"; we all pressed the back button too quickly. Perhaps the last object [ all puns intended ] standing in Java’s path is ActiveX. Although Java was already on it’s way down, COM/OLE/ActiveX are blowing "taps" on their bronzed trumpets. Applications written in ActiveX format are portable [ at least as much as Java ] , reusable, can be Object Oriented, and can be written in ANY language with THAT language’s features [even Java’s ( hehe :o) )]. You like messing with pointers? Use C/C++. Like the GUI enhancements of Visual Basic? Use VB. Want seamless integration, portability, drop-in program components, power? Use ActiveX. Sure, Java might revolutionize the industry, when the market falls out the bottom and software companies find their stock plummeting. Once Java becomes truly useful, come knocking on my door. If my intuition is correct, however, you’ll be standing out in the cold [ AXEin ...:o) ] for a long time. Give me HTML/VBScript/(especially)ActiveX and I’ll run circles around anything written in Java..... ----- Instructional Articles Writing Win16 Screen Savers Submitted by xekul HTML version: http://www.tpu.org/~xekul/ssprog.html Win16 Screen Saver Programming ------------------------------ Since someone asked for a screen saver programming tutorial, I decided to include the little article I wrote and included in TPUSaver. Please note that this is an old article, from my old, horrid Windows days; I've since then `moved on' >o]. Also note that since this is years old, it's for Win16; I'm not bothering to write a Win32 version since I don't program in Windows anymore. And please don't e-mail me about this; I probably know less than you do >o]. With that cleared up, here's the article. The Article ----------- Windows screen savers can be written in almost any Windows programming language such as Visual Basic or Delphi. A screen saver is just a Windows executable renamed from .exe to .scr. The name of the screen saver must be "SCRNSAVE:TPUSaver" or whatever the name of your screen saver is. This is so Windows can recognise your program as a screen saver. When Windows calls the screen saver, it runs "tpusaver.scr /s" and when it wants to run the settings or configuration, it runs "tpusaver.scr /c". Windows calls the screen saver whenever the time specified elapses, even if the screen saver is already running. To avoid this, you can use the API call SystemParametersInfo to tell Windows that the screen saver is running. You also have to change it back when your screen saver terminates (when the user moves the mouse, clicks a mouse button or presses a key on the keyboard). You also have to make sure that the screen saver window is maximized with no title bar. The cursor should also be turned off with the Showcursor API call. The screen saver window should be made so it's always the topmost window with the API call SetWindowPos. Declarations ------------ Here are the declarations mentioned above (this is for Visual Basic 3.0): Declare Function ShowCursor Lib "User" (ByVal bShow As Integer) As Integer Declare Sub SetWindowPos Lib "User" (ByVal hWnd, ByVal After, ByVal X, ByVal Y, ByVal cx, ByVal cy, ByVal Flags) Declare Function SystemParametersInfo Lib "User" (ByVal uAction As Integer, ByVal uparam As Integer, lpvParam As Any, ByVal fuWinIni As Integer) As Integer How to use them --------------- Then you call them like this (Visual Basic 3.0): To hide the cursor: Do a = ShowCursor(False) Until a < 0 To show the cursor: Do a = Showcursor(True) Until a >= 0 To keep a window on top ("frmTPUSaver" is your screen saver window): SetWindowPos frmTPUSaver.hWnd, -1, 0, 0, 0, 0, 3 To tell Windows the screen saver is running: a = SystemParametersInfo(17, 0, ByVal 0&, 0) To tell Windows the screen saver stopped: a = SystemParametersInfo(17, 1, ByVal 0&, 0) ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, February 27. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #5 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 2/28/98 Contents -------- Editorials The "Real Usefulness of Java" Microsoft Doesn't Scare Me - It Is Just Evil Reply to "Usefulness of Java" Features ChickeN toughts Assembly programs on hand-held calculators? --- Editorials The "Real Usefulness of Java" Submitted by lapse HTML version: http://www.undergrad.math.uwaterloo.ca/~gstalusa/realjava.html The "Real Usefulness" of Java George Talusan, gstalusa@uwaterloo.ca http://www.undergrad.math.uwaterloo.ca/~gstalusa This letter is in response (re: retaliation) to the editorial submitted by Neil J. Adcox in issue four of Teen Programmers' Journal. Mr. Adcox's remarks vaguely parallel those of frustrated Java programmers around the world. I agree that inconsistency between platforms is Java's greatest weakness. I, and most likely many others, including Mr. Adcox, have spent countless hours, if not days, debugging Java code simply because it works as advertised in Sun's appletviewer but fails when viewed under one of the more popular web browsers like Microsoft Internet Explorer or Netscape Communicator. An example I've been wrestling with is the behavioural differences in the GregorianCalendar class methods between MSIE and appletviewer. Though Mr. Adcox points out the web-related deficiencies of Java, he fails to focus on the other great benefits and potential benefits for the services Java offers. To directly quote Mr. Adcox, "...The other features of Java are either insignificant or add to it's uselessness..." it seems obvious that he feels that database connectivity, network layer abstraction and the multitude of inherent functionality Sun has given us is completely useless. Perhaps it's simply gibberish to the layman programmer only interested in making "spinning spheres" and "fruitless animations" but in the real world is where Java begins to flex its muscle. At the enterprise-level, Java allows teams of programmers (or in the rare case, a lone programmer) to develop n-tiered applications that can function on a small Intranet or a wide area network spanning several nations. The distinction between applications and applets, two words Mr. Adcox seemed to use interchangeably, broadens the deployment area and scope at which a software house can target their Java-based products. Another laughable point made in Mr. Adcox's article is Java's security implementation. He claimed this limits the usefulness of Java applets. I tend to disagree. Would you want a rogue applet to make unauthorized network connections, read privileged files on your hard disk? I didn't think so. This point is moot under a UNIX-based file system since a rogue applet would be able to effect files belonging to its user and not the data of another. Point the finger at the security of Windows 95 where every user essentially has root access. Mind you, a Java application has the ability to perform file I/O and make network connections. An applet is simply an application with restrictions imposed on these rights. Ever hear of a trusted applet? Better yet, MSIE and Navigator provide facilities for disabling Java security. Try that if you want an applet to act like an application. The last point I'd like to make is the so-called portability of ActiveX. Last I read Microsoft has made a commitment to porting ActiveX to other platforms but for now it's just a pipe dream and vapour-ware. Until that day, ActiveX is only available on Windows platforms (maybe Macintosh with MSIE?). The portability of Java is not a pipe dream. It's fact. Despite the minor behavioural discrepancies between platforms, Java is ahead in the portability race. There are a lot of problems I'd like to address from Mr. Adcox's article, but I don't have the time or the patience to do so. I'll just list them with a vague comment: Java not being object oriented Do I even have to touch this one? GUI enhancements Java implements GUI objects common to all platforms. If you want to limit your user-base to Windows, by all means use Visual Basic. Drop-in components JavaBeans? JFC? Fundamental object-oriented programming? Seamless integration Again, do I have to touch this one? Integration is a design issue. A properly designed application, Java or not, can be seamlessly integrated with a suite of any other applications. Java's inability to offer an interface Ever hear of the AWT, the Abstract Windowing Toolkit? I didn't think so. Try looking at the JDK and the countless source code available on the Internet. Death of UNIX No, I don't think so. If you got this far, I'd like to thank you for reading my rebuttal in its entirety. Before I end this, I'd like to point out that this is simply my opinion and what [I seem to think] I know of the software industry. I have a professional background in PowerBuilder development with Sybase SQL Anywhere and Microsoft SQL Server back-end databases. I've designed, implemented and deployed two applications and have aided in the design and implementation of several others. I learned Java in my spare time, so I don't claim myself to be an authority on the subject. On a final note, "Everyone gets caught up in the so called "features" of Java (cross-platform portability etc.) that people forget to analyze what they actually mean", Mr. Adcox needs to practice what he preaches and reanalyze what he really means. ----- Microsoft Doesn't Scare Me - It Is Just Evil Submitted by NoB HTML version: http://www.goldrush.com/~wohleb/tpj/micro.html Microsoft Doesn't Scare Me, It Is Just Evil by NoB (super_nob@hotmail.com) In response to... Why Microsoft Doesn't Scare Me (And Why it Scares You) http://www.magicnet.net/~jacobw/zine/Scare.html Does Microsoft scare me? No. Not now, the idea that I might be up against their team of programmers in the future does though. I find them to be lacking in the area of morals. True that in this day in age the capitalistic idea of profit above morals does prevail, i find them to be lacking more than other corporations. Everyone knows of the current court battles being fought. The biggest thing that upsets me is their constant development of software that is proprietary and thus giving us, the programmers, problems. I believe the Win95 registry is a perfect example. From my point of view, it looks as if they are out to get the common programmer. Can they make it anymore difficult to program these days? I mean come on, do they always have to take there own route and thus make us conform? I believe their tampering with the JAVA set, JAVASCRIPT set and the creation of ACTIVEX are perfect examples. The author of "Why Microsoft Doesn't Scare Me (And Why it Scares You)" said that Win95 is a great OS. Where has he been? It crashes every two hours! Ok ok, so the GUI can be nice. Ever have porblems with PnP? I know I have. Is it just me or do they put out their software before they even beta test it. One more thing, Netscape is better than MSIE. MSIE does initially load faster, but it is slower at loading web pages and it crashes more. Netscape also makes it much easier for programmers to make plugins. This is just my opinion! ----- Reply to "Usefulness of Java" Submitted by François-Denis Gonthier HTML version: http://www.icrdl.net/claudeg/rjava1c.html Reply to 'The usefulness to Java' Here is what I think about coldAXEin's article concerning the usefulness of Java that was published in the last TPU Journal. I'll comment every part of the text that needs to be commented. I'm not an experienced Java programmer, I just think some details of that article were wrong (some were right though). "The fact that Java is NOT platform independent is probably why the language is destined to go the way of languages such as ADA and LISP." LISP is still widely used in some specific domains of computer science. It's a very powerful language when used on artificial language experiments. Ada looks like an good language to me, not used as LISP is. But Ada is a quite new language compared to LISP which is one of the oldest programming languages. Java is totally new. The arrival of Java on the computer market created much enthusiasm. Now that people discover the weaknesses of the Java language, articles like the one I'm replying to are being written more and more. I think people overestimated Java. Java should have stayed an experimental language because today's computer and OSes are not ready to welcome it. The goal of Java wasn't to enable programming of big cross-platform applications but to enhance portability over the multiple computers, visible or not, that we use in everyday life. For example, the use of a universal language-interpreting chip would enable people in the future to 'reprogram' a vacuum cleaner (in a far, far future) without any special equipment. "I wrote an applet for the express purpose of "testing" it on other platforms and found that out of the 4 platforms it was tried on it only worked for two of them; the target platform Win 95/NT and UNIX." What compiler did you use ? If you used MSVJ++, there's no surprise that you have portability problems. J++ has a very nice interface but the code it produces is subject to be platform dependent (and that platform is Windows 95... ugh !!!). Big companies like *cough*cough*Microsoft*cough* are using Java to promote their own OS. As an example, in my C:\WINDOWS\OCCACHE directory, where are stored IE objects that are downloaded from Internet, I have a file called Java Win32 Class... com.ms.win32. That's totally against the Java principle which make Java applets using those classes totally non-portable. "Let’s face it, Windows and Mac successfully capture 98% of market share and UNIX is dying ( Aren’t I making enemies? )" Mac is dying... UNIX as we knew it is dying also. But that doesn't mean the OS market will stay like that forever. "That’s another article, another day. Java is actually "write once, test, debug, and special-case everywhere." MSDN’s Dr. GUI has written a succession of articles on Java’s "write once, run everywhere" philosophy (or the lack thereof). You can read these articles at http://premium.microsoft.com/msdn/library/periodic/periodic/msdnn/dr_gui/gui36.htm. You will probably need to obtain a [free] membership to MSDN (Microsoft developer’s Network). So.... if Java is not truly portable, where does that leave us [and the language]?" Exactly what I meant before... you reading articles at the wrong place. MS isn't an example. And after all... who cares about Dr GUI ! "The other features of Java are either insignificant or add to it’s useLESSness. Because of Java’s built in security features, Java is limited in what services it can offer. Sure, a spinning sphere looks great on a web page but what does that offer the software world. Real developers don’t need such fruitless animation and if they did there’s always Gif89’s." I've seen games on web pages and artificial intelligence experiments all made in Java. I don't remember waiting long hours to load them and they were nicely optimised for speed. Try to do that in DHTML. "I have yet to see a Java application that is truly useful. I’ve seen menu’s [on Prism’s page] and other uses but none are substantial applications. Java applets barely even enhance a user’s experience on a web page." You should search more. I admit some Java apps on web pages are quite useless but some well programmed applets make Java apps look very good (I don't have any examples near but I'm sure I could find some if I wanted). I'll give you one point. Applets aren't the things that show the full potential of Java, especially since today's Internet lines are mostly modems. "Add these facts and throw in Java’s inability to offer an interface and you get a language that does nothing but glare at you on ashelf." JDK 1.2 will include great Java GUI classes called JFC (Java Foundation Classes). With those classes, Java apps will look any other application from good GUI. "Perhaps the most annoying "feature" of Java applets is the [ life ] time it takes to download them. Ever waited for a Java applet to load? Must of us would probably yell a resounding "NO"; we all pressed the back button too quickly." YES ! What kind of modem do you have ? Java takes a while to download, but not 'forever'. I think the word is too strong there. "Perhaps the last object [ all puns intended ] standing in Java’s path is ActiveX. Although Java was already on it’s way down, COM/OLE/ActiveX are blowing "taps" on their bronzed trumpets. Applications written in ActiveX format are portable [ at least as much as Java ] , reusable, can be Object Oriented, and can be written in ANY language with THAT language’s features [even Java’s ( hehe :o) )]. You like messing with pointers? Use C/C++. Like the GUI enhancements of Visual Basic? Use VB. Want seamless integration, portability, drop-in program components,power? Use ActiveX." Some points here: 1: Java never causes IE to crash in normal browsing. Many ActiveX controls crashed my browser, even the very popular Shockwave. 2: Maybe ActiveX components are faster to download and can be installed on the HD. On the other side, ActiveX controls takes 'forever' just to start. Java doesn't. 3: Since ActiveX components are downloaded on the client computer, they are a big security threats. Bug were discovered with IE3.0 ActiveX and that is probably not the only existent bug. 4: Java applets are a lot more used than ActiveX controls. Even CNET's ActiveX.com no longer uses their ActiveX menu. Java applets are easier to program and install because you don't need to manipulate heavy OCXs. 5: ActiveX is portable ? Does it run on UNIX ? DEC ? Solaris ? "Sure, Java might revolutionize the industry, when the market falls out the bottom and software companies find their stock plummeting. Once Java becomes truly useful, come knocking on my door. If my intuition is correct, however, you’ll be standing out in the cold [ AXEin ...:o) ]for a long time. Give me HTML/VBScript/(especially)ActiveX and I’ll run circles around anything written in Java....." You future house has more of a chance of being filled with Java chips than to be filled with computers that runs ActiveX components. Realise that Java isn't meant to be just a web programming language like it is today. For now, let's close this discussion about Java. Teen Programmer Journal isn't the right place to hold such war. If you want to continue, come to #TPU and I'm sure you'll find somebody to fight you ;) [Maus] claudeg@icrdl.net http://www.icrdl.net/claudeg <-- And yes !!! there is a Java applet hidden somewhere there ;) ----- Features ChickeN toughts Submitted by ChickeN HTML version: http://www.geocities.com/SiliconValley/Way/3047/tpj5.htm ChickeN's toughts I'm just in a workaholic mood, so here's my letter, I just needed to write to u guys. ---- Project status update - TPUGFX ---- The TPU graphics libraries Khm, started as a cool thing, it died. The reason: unprofessionality, from both me and the team. I started to plan it, wrote some specifications and folks joined the project. I wanted to finish the design and start coding, but gave too much freedom to the team. They just started coding. My idea was to make TPU2D first, then TPU3D upon it. Everything in the same design style, open to developers who use it. We didn't even figured the TPU2D - set-up out as there already were TPU3D demos (3d texturing, bumpmapping, etc) out there. That's not the way things should be done, especially if you are working in a team. If you think it's cool and want to prove me that I'm wrong, no problem. http://members.xoom.com/samko/ I'm giving away the project leadership if someone wants it, what is not likely to happen.... ---- ---- ---- ---- ---- ---- ---- ---- ---- Project status update - SamOS ---- Samo's OS I learned something. SamOS will be handled quite different and we _will not_ start coding right off. First the design, then the specifications and then coding. We're at this point trying to get some serious people to help out and we are starting to write down the rough design and specifications. Current members all are from TPU, but I don't think we can call the whole thing a 'plain' TPU project as it is developed under pixel group, a company of Samo Korosec, me that is. We are also trying to use the pixel group's newsgroup for our discussions and pixel group will distribute SamOS when it's done. Currently there are 6 developers who seem to be into SamOS for sure and some optional, who will be kicked out if not working without a reason. It's me, Samo Korosec, Bernhard Messerer (who made same expariances with projects as me thus wants SamOS first have specified and designed b4 coding), Simon Kittle, Jeremy Ford, Rene Willemink and Luca. Thomas Harte (BritBloke) and Warren Smith also showed some interest in cooperating - they are on the "maybe" list. We currently are accepting all kind of people into our group that could be of help. See the SamOS page for details. ---- ---- ---- ---- ---- ---- ---- ---- ---- editorial - TPU growing up ---- the issue of adult TPU members IMO TPU members that grow up to adults can still stay in TPU. Not as members in a normal way, but as senior members, who just are helping out and maybe do some admin work, unless others can take that over. Or we (the soon to be adult ones) found a orgaization (!=NAP), which also has TPU as a part of it. It has to be free, though. This way, we could publish TPU works, books (psion), linux distros (xekul), etc. and still act as a community of programers, not neccasairy a part of TPU, rather a partner. ---- ---- ---- ---- ---- ---- ---- ---- ---- editorial - software designing ---- how to make software, ...and sell it! I will not talk about languages or techniques, as i think that most of you may even be better coders than I am. It's the approach I'm trying to use and which seems quite ok to me. Here's what you have to do: 1. Plan exactly what you want to do 2. Choose a good design for your project 3. Make it look proffesional 4. (most important!) Take a artist into your group With that 4 point checked, you just need the will to pull it trough and you will. Now, why am I writing this? Because I think u don't plan things or that u don't choose a good design? no. The biggest problem in TPU is the lack of artists. Not just pixel painters, but people who know what looks good and what not. You can make a good program, but if you try to sell it on a ugly homepage, it just wont work. SamOS for example, was just a joke, first. I made a page designed with my own GUI, and promoted a kewl design for a OS there. Since start of november 1997 till now, the page got more that 600 (!) hits, with even proffesional OS groups asking me to design a GUI for them. And, as u may know, the project is up'n'running now. I even redesigned the page :o). ---- ---- ---- ---- ---- ---- ---- ---- ---- ad - pixel group ---- some info about pixel group pixel group was founded in order to provide a software developing platform, that is somewhat more serious than the #tpu chats. It is a website designing and software development "company", trying to work on a higher level (don't get me wrong, just more serious) than the teenaged groups all over the net. Feel free to give us money :o) ---- ---- ---- ---- ---- ---- ---- ---- Additional links: pixel group: http://pixel-group.hypermart.net/ SamOS : http://home.onestop.net/chicken/ Samo's home: http://samo.home.ml.org/ ----- Assembly programs on hand-held calculators? Submitted by Psion I am writing this to inform all of you of a wonderful opportunity in "hand held computing" that surprisingly few people are aware of. I am referring to the TI-8x series of graphing calculators created by Texas Instruments. They use your old favorite, the Z80 chip. That's right, the same one that's in GameBoys. If you're unfortunate enough to never have even seen a graphing calculator, the screens are nice and big allowing for some pretty nice graphics. OK, so it's a calculator, what's the big deal? This fact that so few seem aware of is that you can write programs for them. "Haha," you say, "I knew that. My friends and I write little TI-BASIC programs on our calculators all the time." Well, I'm not referring to TI-BASIC programs. You can actually write assembly programs on your computer, compile them, and send them to your TI-82, -83, -85, or -86 to run. These aren't limited to little 1+1 programs, as you may have been able to guess by the fact that you can use assembly. You can do reasonable quality greyscale, 8 shades on the 86. You can write 2-player games using the calc-to-calc link cable. I am working on a DOS C compiler that compiles for TI-8x calculators at the moment. You can check on the progress at http://www.tpu.org/~psion/tcc/. I may post a working version there soon, for now I am just having people test it on IRC. If you would like to help me test it, please e-mail me at psion@tpu.org Useful TI-8x sites: http://www.ticalc.org/ http://www.ti.com/ ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, March 13. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #6 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 3/14/98 Contents -------- What's New in TPU TPUMIG Composition Competition Update New Interest Group Editorial Policy Change Instructional Articles Linked Lists in C --- What's New in TPU TPUMIG Composition Competition Update Submitted by Jeremy Penner HTML version: http://puresubstance.home.ml.org/vote.htm 1st TPUMIG Composition Competition -- Official Update ----------------------------------------------------- As of Thursday, March 12, 1998, the voting booths have been open for the 1st official TPUMIG Composition Competition. Any member of TPU may come and vote on the best piece of music. Come and listen to the songs and get your vote in soon! The voting booths close on March 19th! The URL for the competition is http://members.xoom.com/~Armpit/contest.htm (be warned, this could take a LOT of downloading time, depending on how many entries we get, and what format they choose to write in. But it's sure to be worth it!) --Jeremy Penner TPUMIG Admin ----- New Interest Group Submitted by RoM HTML version: http://www.iobbs.com/~rm/tpu/hardware.html A New TPU Interest Group (Presently unrecognized by TPU for construction reasons) Rob Morrow There's a new interest group in town, the Nova Hardware TPU Interest Group. Somewhat against the grain of Teen Programmers Unite, this group has to do with people who enjoy the soldering, schematic-reading aspect of hardware (excluding the messageboard where people can sell hardware). Members can start and join projects, add their own tidbits of information, or ask questions on the messageboard. The address is http://www.iobbs.com/~rm/nova/. Click on the Hardware TPU Interest Group link in the sidebar. Email Rob Morrow at rm@atlas.iobbs.com if you wish to join. Also, if you wish to add helpful information on how to run the site or what to add to the site, please email (rm@atlas.iobbs.com) Rob Morrow. Current main messageboard posts: From RoM: Unknown purpose of component. Says delay line on it. Current market messageboard posts: From #17: GUS Pro for sale. $100. 512K RAM. - RoM Rob Morrow ----- Editorial Policy Change Submitted by Psion The past couple of TPJ issues have been swamped with "reply editorials," IE people responding to previous editorials from past issues on hot topics such as Java and Microsoft. These views would really have been better expressed on IRC or on the WebBoard/news server. So from here on, no reply editorials will be accepted. In general, only editorials which discuss a completely original topic will be included. ----- Instructional Articles Linked Lists in C Submitted by Jeremy Penner HTML version: http://puresubstance.home.ml.org/ll.htm LINKED LISTS IN C -- by Jeremy Penner Well, after an ad, an editorial, and an update, I decided I might as well write something that might actually be useful to someone! Although many C programmers already know how to use linked lists, I got a request to write this (several, actually, I think I was supposed to include this in TPJ3 ^_^) on IRC from kbot. If anyone else finds this useful in any way, bonus. This tutorial requires a basic knowledge of C, structures, and pointers. I will start off by explaining what linked lists are. They work something like an array. (just to give you something to relate them to) It's a bunch of list entries linked together by pointers to the next/previous one. The previous link is often not included, but can be quite useful. How do you link something along? Simple: with a pointer to the next entry. For example: char foo[10]; char index; char *foonext[10]; for(index=0;index<10;index++) { foonext[index]=&foo[index+1]; } "Hold on," you're probably saying. "This code will crash!" Well, guess what--it will! That's why we either have to loop them or end with a NULL. For, say, frames in an animation, looping may be just the thing. In case you're really thick-skulled and you NEED a working example, fine. Here's a loop: char foo[10]; char index; char *foonext[10]; for(index=0;index<9;index++) { foonext[index]=&foo[index+1]; } foonext[9]=&foo[0]; There. Now the code will work (although it will be quite useless as foo is already an array =]) How do you get the links into the entries? As you can see, just using an array of pointers is really ugly and messy. That's why you use a structure. Here's an example: typedef struct FOO { int bar; struct FOO *next; struct FOO *prev; } FOO; Ahh, this is getting better all the time! "Hey," you may be saying, "How do I know where this list begins?" This is where global variables come in. Consider the above FOO declaration and add in below it: FOO *first_foo_in_list; See? Problem solved. Now, you may well be saying to yourself now, "What advantages does a linked list have over an array or something?" Well, quit talking to yourself ^_^ No, it does have several great advantages, as well as some disadvantages. The advantages are that it is really easy to add in entries in the middle of the list and have them all move over. Something like: void InsertFoo(FOO *bar, FOO *beforebar) { bar->next=beforebar->next; beforebar->next->prev=bar; bar->prev=beforebar; beforebar->next=bar; } Note that this should really check to see if beforebar->next is NULL. This piece of cryptic code is supposed to add bar in the list after beforebar. Everything in the list has now moved over to fit bar in! Sweet, huh? Removing an entry from a list is also as easy. void RemoveFoo(FOO *bar) { bar->prev->next=bar->next; bar->next->prev=bar->prev; } Again, checking for NULL really should be done. As you can see, inserting and removing entries is fast and easy--much faster than would have been done on an array. The only disadvantage to linked lists that I can think of is that you can't access it by number, you have to traverse all the links to find it. So really, what you use depends on your application. I hope you've learned something. If you have any questions, feel free to direct them to me at pzp655@freenet.mb.ca. Unless, of course, it's something like "WhAt bE A POiNtER?!???!?!!?!!! Y00 b3 l33t h@X0R!!!!!!!!!!! PH34R!!!!!!!!!!!!!" in which case please direct your queries to /dev/null. Thank you. ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, March 27. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #7 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 3/28/98 Contents -------- What's New in TPU TPU Name Change? Vote for your choice Instructional Articles 3D graphics Object Encapsulation of Windows Custom Controls (in API) Wanted Ads Artists Wanted for C&C game --- What's New in TPU TPU Name Change? Vote for your choice Submitted by Psion Once again some members are discontented with the name "Teen Programmers Unite," so another IIC poll has been set up. Please log in to the IIC at http://www.tpu.org/iic.html and click on the Voting Booth link. The current choices are: * Teen Programmers Unite * Teen Programmers' Union * Teen Programmers United And there is a blank to submit other suggestions. Something fitting the TPU acronym would be good as tpu.org is already registered. ----- Instructional Articles 3D graphics Submitted by Shaun HTML version: http://www.inconnect.com/~kruger/tpu/3dgfx1.html 3/2/1998 Well I was encouraged by people on #tpu to write so here I am. I am writing on the way I think that a graphics engine should be written. This is not a planned document so I will be mentioning things as I think of them. I will be refering to x, y, and z. x = horizontal from left to right y = vertical from bottom to top z = straight ahead(giving depth) Basic rendering: When rendering the first thing that you must do is rotate the 3D points. I believe that you should first rotate around the y axis (yaw) this will give you your heading. Second you should rotate about the x axis (pitch) this will point you up or down. Last you rotate about the z axis (bank) this will roll you from side to side. I have done alot of thought about how this is done and yes this order does make a difference. After you have done your 3D rotations make sure you kept track of all of your polygons. for each polygon you render you need to average the z value of two or more points of the polygon. Another thing that will make building a graphics engine easier is limit your self to triangles. If you think about it everything gets down to triangles. another reason for this is I used to design aircraft for MS Flight Simulator, sometimes I would try to make complex poly's that would bend all over the place and they would never render right. If you limit yourself to triangles you work with one plane at a time, seeing as a plane is defined with 3 points not more. this will make it so all of your polygons look perfect. Another addition is to sort your polygons based on if they are pointed twards you. In order to understand what I mean you must first realize what it means to "point a polygon twards you". This requiers you to have a front face (visible) of your polygon and a back face (not rendered) of your polygon. When texturemaping your polygons you must determine if a polygon is facing twards or away from you. If it is faceing you render it with texture. If it isn't skip it and go to the next. There is someting special about naming points in a counter clockwise way when facing a polygon. I don't know how this is important, although it is covered in PC Games Programmers Encyclopedia. if you do this you can greatly decreace the number of triangles that you must render. Special Changes for open-air graphics engines: When rendering a world like a flight simulator you must first render the ground of the world. this will literally lay the foundation for the rest. next you must depth sort all polygons for buildings and other objects. After you have depth sorted the other objects you render everything from back to front. This is commonly refered to as the painters algorithm. Object types: There are no preset object types, this must be done in the design of your graphics engine. If I were making a Flight Simulator type graphics engine I'd start of by defineing the world and how it will look and be drawn. Next I'd define static objects like buildings. Last I'd make dynamic objects like aircraft. Each of these would be handeled diferently before the render. First I'd transform the 3d models for all the aircraft. This includes placment and rotation of 3D points. The next step is to place the buildings. The buildings should be predefined objects and need just be placed and rotated to fit the location. Remember you can do this a run-time or scenery compile-time. The latter will be more cost efective of processor time. Now for the fun part you have to transform every single point in existance. All those buildings you transformed, all the aircraft you moved they all have to move again. This is where the world is rotated to give the proper view. The world moves because in a 3D world your camera view is the center of the universe. At this point you are done with all the 3D rotations. just remember not to destroy your original 3d structures. If you destroy your original 3d structures you'd have to read them up from a file between every frame. Cameras and real-time video screens as textures: Today I finally figured out how to make a TV screen work. In a 3D game of course I realized that all a TV screen is just a texture. What you need to do is define a camera view to take a picture of another area for you. This will require support for multiple camera views. You first render the scene that this camera is looking at. When you render it you should save it to a bitmap in memory. Then you must use that bitmap as the texture that is placed on the TV screen polygon. The only problem with this is you are rendering two scenes in one. now you can speed this up by making the secondary camera view only 64x64 instead of 320x480. Remember the higher the resolution the slower your render process is. Writeing to video memory: I believe that when writing to video memory it is best to write to a bitmap then when the screen is done being drawn then copy the bitmap directly to the video memory. This can help keep flicker out or even eliminate it all together. Multiple Monitors: I know that it is possible to have multiple Monitors on one machine. It has been implemented in Windows 98 (still in beta). You in theory can render to two video cards if you can diferentiate between the two cards when writing to video memory. There are some problems that you may run into: First, keeping track of what get's rendered to where. Meaning what view goes to which monitor. Second, is your machine fast enough to suport two views? Will your frame rate go below 10?(very rough) Third, do you have the money for two monitors and two (perferably congruent) video cards. Creation of objects: When I talk about creation of objects I don't mean C routines. I am talking about 3D models. I have come up with a set of structures that will be helpful when defining 3D objects. The base will be done with an object structure type. This will be expanded if animated models are developed. (remember a structure is called as a type, these will have to be called in reverse order) struct object{ triangle static[100]; limb dynamic[100]; } obj This requires... struct triangle{ vertex points[4]; // this defines the array 0-3 points I'll // only use 1-3 for the points on the // triangle } tri This requires... struct vertex{ // This is for each vertex float x; float y; float z; //Untranslated float u; float v; float w; //Translated } vert In your code you would read these and set them using this type of system. object car; car.static[i].point[i].x = (predetermined value); (or) object car[5]; car[i].static[i].point[i].x = (predetermined value); You can set 'i' to any number within the aray. You may also call an aray of the object structure. The only problem that you may face is for each structure you have to allocate 1,200 Floating point numbers just for the static point definitions. When texturing is added then the texture will be put into the triangle structure. The texture path will be stored seperate from the texture filename so you can define the texture path seperatly and then just add the texture name when making the object. This will keep your root clean and you can put it into a \texture subdirectory of the program's root directory. 3D rotations: Today I figured out the equations for 3D rotations. I only have one problem with them, they are in matrix form. Here are the variable definitions and the equations... r = rotation angle a = cos(r); b = (-sin(r)); c = sin(r); d = cos(r); In code I would make it like this: a = cos(r); b = (-sin(r)); c = b*(-1); d = a; x = u y = v z = w And now for the matrices. Y rotation +- -+ +- -+ +- -+ | a b | | x | = | u | u = ax + bz | c d | | z | | w | w = cx + dz +- -+ +- -+ +- -+ X rotation +- -+ +- -+ +- -+ | a b | | w | = | w | w = aw + by | c d | | y | | v | v = cw + dy +- -+ +- -+ +- -+ Z rotation +- -+ +- -+ +- -+ | a b | | u | = | u | u = au + bv | c d | | v | | v | v = cu + dv +- -+ +- -+ +- -+ While chatting in #tpu I was dicouraged from asking a teacher for help. I only got this far because of asking for help with matracies. If you see any problems in my math tell me. Writing the engine: In TPU journal 7 I will show give an address to go to for downloading the graphics engine. All of the things that I have written here will be used in my source eventually. After I get the 3D rotations and triangle rendering I will add texture mapping. I hope that this has all been useful information to those of you interested in making a graphics engine. Shaun kruger Kruge on #tpu ----- Object Encapsulation of Windows Custom Controls (in API) Submitted by spectrum HTML version: http://www.eburg.com/~baxters/ Class Encapsulation of Windows Custom Controls. This tutorial describes a method of encapsulatingehind a class interface a window b using the Windows API. Learn how to make the window callback integrate into the object model. The sample application features a reusable enhanced push button class. http://www.eburg.com/~baxters/ ----- Wanted Ads Artists Wanted for C&C game Submitted by Gareth Owen HTML version: http://www.gmaitken.demon.co.uk/wanted/wanted.html Help Wanted: Artist for C&C Type game ------------------------------------- We are after an artist capable of doing art for a C&C type game, this will include drawing units and landscape. You need to be pretty dedicated, we may even ask you for a picture on a daily basis, but that is unlikely. The game is called 'Operation: Rowner Strike' and a lot of the coding has been done. Also wanted, but not required, Musicians and Sound Artists. E-Mail me for more information: gaz@athene.co.uk ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, April 10. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #8 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 4/25/98 Contents -------- What's New in TPU Updates to Nova Hardware TPU Interest Group The TPJ and Programmers' Omnibus book Wanted Ads RPG Game Team Seeks Artist --- What's New in TPU Updates to Nova Hardware TPU Interest Group Submitted by RoM HTML version: http://www.iobbs.com/~rm/tpu/hardware1.html Updates to Nova Hardware TPU Interest Group (Presently unrecognized by TPU for construction reasons) Rob Morrow For those who still haven't checked out this interest group yet, the address is http://www.iobbs.com/~rm/nova/ Click on the Hardware TPU Interest Group link in the sidebar. Email Rob Morrow at rm@atlas.iobbs.com if you wish to join. Also, if you wish to add helpful information on how to run the site or what to add to the site, please email Rob Morrow. I've done some updates to the page. We have a General Library of Information now, and it has Pinouts of simms (and soon to come, just about any pinout you could possibly want), Rob's Notes of Pain and Suffering (and don't forget stupidity), and definitions of basic components such as capacitors and resistors. Current projects: Hand-held CPU. Sounds really kewl; if we can get this off the ground (and it's well on its way), this could be a major money-maker. Check out the projects page for more information. Current main messageboard posts: From RoM: Unknown purpose of component. Says delay line on it. Current market messageboard posts: From #17: GUS Pro for sale. $100. 512K RAM. - RoM Rob Morrow ----- The TPJ and Programmers' Omnibus book Submitted by Psion As you can see, particpation in the TPJ is not exactly at an all-time high. I have therefore decided to switch it to a monthly schedule as opposed to bi-weekly. Many people have promised to write articles, or even a whole series of articles, and not produced anything. This is not an accusation, I am merely pointing out a fact. A quality article can be written in under half an hour. I'll leave it up to you, the potential contributor, to decide if the TPJ can continue to be informative on programming issues or will simply serve to announce TPU news and wanted ads. Though it may seem foolhardy taking the current status of the TPJ into account, I would like to reopen the idea of a collaborative programming book written by TPU members. You may have read about this already in a previous issue. The basic premise is as follows: Members write tutorials/references/etc. on as wide a variety of issues as possible. The goal is to cover all major aspects of programming of interest to our generation. Some parts would receive more emphasis, and others would have brief articles just to keep the reader informed. My ideas for potential parts of the topic tree: * Concise tutorials (like those found on the web, only hopefully with less grammatical errors :]) for all major programming languages * Explanations of how to do graphics, sound, etc. both manually and using one or two popular libraries * Complete listings on functions in language standard libraries and in popular add-ons * Explanations of all major internet protocols * Complete opcode listings for all major chips * Tutorials on concepts like neural nets, binary search trees, etc. And there are many, many more possiblities. It would also be nice if we could include a CD with an easy, common interface to install free development tools such as DJGPP and lcc-win32. Members could also have the option of including demos of their programs on the CD. At best, a major company might publish the book. At worst, we could make it available online. Overall, I think this could be a very worthwhile project. I would definitely want to buy a book with the features described above. To make this work, we would need to have people sign up to do specific jobs. I think it is too early to start with the heavy duty planning. For now, I invite everyone to share their ideas on this subject in the WebBoard Forum "Programmers' Omnibus." To get in, log on at: http://iic.tpu.org/cgi-bin/iic/msgboard.cgi ----- Wanted Ads RPG Game Team Seeks Artist Submitted by Jester99 HTML version: http://pw2.netcom.com/~kimballa/misc/ad.html Help wanted! Hello, this is Aaron Kimball, programmer of a new RPG currently named "Haligwarre." An artist (or two!) is needed to draw all the artwork for the game. It's a Windows95 game, and tile-based. If you are interested and want more information, contact me at Jester@Bitsmart.com -- Jester ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, May 29. --------------------------------------- /----------\ /----------\ /----\ | | | /------\ | | | \---\ /---/ | \______/ | | | | | | /----/ /--\ | | | | | | | |_| | \__/ \_____/ \_________/ Teen Programmers' Journal --------------------------------------- Best viewed in a monotype font Issue #9 TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html 5/29/98 Contents -------- What's New in TPU Programmer's Omnibus IRC Meeting Other Stuff Instructional Articles Tutorial on creating the base for a DirectX fullscreen game --- What's New in TPU Programmer's Omnibus IRC Meeting Submitted by Psion I think it is about time to start the preliminary planning for the Programmer's Omnibus book. The best way to start is by having a general IRC meeting for all potential authors. A general outline of the book's contents will be collaboratively created and some assignments will be given. These will be available along with a log of the meeting on the TPU web site. *** The meeting will be in IRC EFNet channel #tpu on Saturday, June 20, starting at 2 PM EST Here is the general description of the project from a previous TPJ issue. --- ... I would like to reopen the idea of a collaborative programming book written by TPU members. You may have read about this already in a previous issue. The basic premise is as follows: Members write tutorials/references/etc. on as wide a variety of issues as possible. The goal is to cover all major aspects of programming of interest to our generation. Some parts would receive more emphasis, and others would have brief articles just to keep the reader informed. My ideas for potential parts of the topic tree: * Concise tutorials (like those found on the web, only hopefully with less grammatical errors :]) for all major programming languages * Explanations of how to do graphics, sound, etc. both manually and using one or two popular libraries * Complete listings on functions in language standard libraries and in popular add-ons * Explanations of all major internet protocols * Complete opcode listings for all major chips * Tutorials on concepts like neural nets, binary search trees, etc. And there are many, many more possiblities. It would also be nice if we could include a CD with an easy, common interface to install free development tools such as DJGPP and lcc-win32. Members could also have the option of including demos of their programs on the CD. At best, a major company might publish the book. At worst, we could make it available online. Overall, I think this could be a very worthwhile project. I would definitely want to buy a book with the features described above. To make this work, we would need to have people sign up to do specific jobs. I think it is too early to start with the heavy duty planning. For now, I invite everyone to share their ideas on this subject in the WebBoard Forum "Programmers' Omnibus." To get in, log on at: http://www.tpu.org/ -Also....- Many people have commented that the TPU web site lacks content. The Resource Directory, a link database and search engine to which members can add links, has been available as a part of the IIC for quite some time. We can build up a quite impressive collection of links to the best programming resources on the web, as well as links to member home pages and software in separate categories, if everyone submits a few links. It's quite self-explanatory. Just go to the category you want to add to and click the "Add URL" link. The Resource Directory is located at: http://www.tpu.org/res/ There aren't many categories right now, please suggest any new categories to psion@tpu.org. ----- Instructional Articles Tutorial on creating the base for a DirectX fullscreen game Submitted by Tetrabyte HTML version: http://www.fortunecity.com/skyscraper/coding/98/TutDXFulScr.html Tutorial on creating the base for a DirectX fullscreen game written by Brian Bintz ( bintz@ix.netcom.com ) Table of Contents: I. Creating a window II. Adding DirectDraw support III. Adding DirectInput support IV. Threads and Synchronizing V. Timers and TimerEvents; creating an OnIdle function VI. Loading BMP files and stripping into individual parts VII. Drawing Isometric Map VIII.Storing Map Data IX. whatever else I think of or is suggested Part I: Creating a Window For simple window needed by a DirectX app I have always found it easier to use Win32 api. I imagine MFC could also be used, but then you would have to link with the MFC lib all the time and would have the overhead of the extra features MFC gives you, which are really never used or needed. You can look on Dejanews if you want to read more into the debate of using MFC with DirectX. Steps to create a window using API 1. fill in WNDCLASS structure 2. register the window 3. create the window 4. show it 5. update it The WNDCLASS looks like this: typedef struct _WNDCLASS { // wc UINT style; WNDPROC lpfnWndProc; int cbClsExtra; int cbWndExtra; HANDLE hInstance; HICON hIcon; HCURSOR hCursor; HBRUSH hbrBackground; LPCTSTR lpszMenuName; LPCTSTR lpszClassName; } WNDCLASS; look in the help files for more specifics on it. Basically, style should be CS_HREDRAW and CS_VREDRAW so that DirectX knows to redraw the screen. lpfnWndProc should be a ptr to your defined WindowProc. You should cast your function to a WNDPROC to be safe. Everything else should be fairly obvious, if you have problems email me. NOTE on WNDPROC: WndProc is a pain to use in a class. It has to be defined as static so that a this* is not passed to it, since its supposed to be a C function. Unlike TimerEvents which allow a user to pass a custom variable as an added argument. TimerEvents will be discussed later. This extra argument can be used as a ptr to the functions owning class. Many different ways of getting around WndProc's problems have been discussed on Dejanews and your welcome to look there for more info. One way is to have a global ptr to the class, which your WndProc can use to access public variables. Private var access is another matter though and much more of a hassle, though. It should be defined something like the following: static long WINAPI WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam ) To Register Window: simply call RegisterClass( &your_wndclass ); To Create Window: call CreateWindowEx( ); you should capture the returned HWND and save it because DirectX needs it to initialize the DirectDraw Object. I perfer to keep the window creation as simple as possible, so I create a popup the size of the screen. I get the screen size using GetSystemMetrics( ); lookup these functions for more info Showing and Updating Window: very easy simply call ShowWindow(hwnd, nCmdShow); UpdateWindow(hwnd); Thats all there is to it and it is easy to build a class around this from which your individual programs can inherit from. If you need help on this email me, but you shouldn't need any. Next up... Adding DirectDraw support ------------------------------------------------------------------------ This document is copyright (c) 1998 by Brian Bintz (tetrabyte) All rights reserved. Windows IG is a subdivision of TPU ----- --------------------------------- TPU: http://www.tpu.org/ TPJ: http://www.tpu.org/news.html If you wish to submit an article please visit the above URL and follow the exact instructions there. The deadline for the next issue is Friday, June 26.