If you want to see a complete version of the example we were doing in class, follow the "sample programs" link from the course Web page (or go directly to http://www.cs.trinity.edu/~bmassing/Classes/CS1321_2003spring/SamplePrograms/).
The code we wrote in class Wednesday is now available linked from the course "Sample programs" page.
I've also added instructions for turning in your code for homework 1 to my homework writeup (the one linked from my schedule page). Look for the section "Turning in your code". To summarize -- at least for this assignment, I just want you to e-mail me your source code.
In light of the fact that we didn't have class Monday, I'm putting off our next quiz until Friday.
I seem to remember that at least one of you was interested in doing mouse input rather than keyboard input. Keyboard input is a bit easier in that there's less work to do in converting the Java Magic Cloud's "events" into something that the Lewis Magic Cloud can understand. If you want to do mouse input, however, read on ....
The methods in MouseListener and MouseMotionListener (one or both of which you will need to implement to work with mouse input) give you positions in terms of pixels relative to the drawing frame. Genius magic-cloud implementer Dr. Lewis has provided methods that will allow you to convert this into a Location (instance of his Location class). Here's the (almost)-one-line version:
Location l = GameSetup.getMainFrame().getDisplay().getClickLocation(pX, pY);
where pX and pY are the x and y coordinates from the mouse event. For this to work you'll need to add a getMainFrame() method to your GameSetup; it should return whatever was passed in to setMainFrame().
You should be able to figure out more about what the above line of code does by looking at Dr. Lewis's documentation -- start by looking at getDisplay() in the MainFrame class.
A "P.S." about the hint in the last message (how to convert mouse-event pixel coordinates into Lewis-Magic-Cloud coordinates): In order for that line of code to work, you would need to have called setMainFrame in your main program.
I've updated the "sample programs" page with links to all of the non-trivial code we've written in class so far, including the stack, queue, and list classes we've worked on recently.
I've also added a link to the "lecture topics and assignments" page to a short review sheet for the midterm, describing the format of the exam and a list of topics.
I've probably mentioned before that the source code for the sample programs is available linked from their documentation (there should be a link to source code in each class's overall description). This source code looks fine when viewed from Netscape or Mozilla under Linux, but not when viewed from Internet Explorer under Windows (the line breaks are ignored, and the result is pretty unreadable). A workaround is to save any source files of interest and then view them with Notepad or Together. If one of you can suggest a better workaround, please do!
As mentioned in class, I've posted the description of the next homework. The design part is due the Wednesday after the break, with the code due that Friday.
I've also updated the "useful links" page to include links to Dr. Lewis's descriptions of how to use his screen editor and image editor programs.
Sent to Dr. Lewis's students and also to me, for me to forward to you.
----- Forwarded message from mlewis
Subject: Odd behaviors
For those of you who found that you added things to your screen in the screen editor, then they moved in the game, I believe I have an explanation and a simple (though not elegant) solution. The problem is that the ScreenEditor isn't calling your construct variables and as such, it isn't doing the Location.setPartialsInWhole call. It uses the default value for that (which I believe is 10). So the problem is that if your partials in whole is less than 10 the entities can "jump" whole blocks from the partial values. It also prevents the proper detection of collisions.
So the quick fix is to copy the line you use to set the partials in whole and paste it at the top of your screen constructor, then delete your screen files and rebuild them. You could potentially also put that call in some other place and not have to rebuilt, but it would waste clock cycles being called too often.
Dr. Lewis
----- End forwarded message -----
At least one of you reports problems running Java from the command line (commands "javac" and "java"), so -- some info that might be helpful to all of you:
You may have problems running these commands if you don't have /usr/local/java/bin in your search path. The default setup for accounts builds the search path using some subdirectories of your ~/Local directory. If you type "ls ~/Local" and see something like this: HTML-Documents hp9000s700 i386 powerpc sgi universal all should be well. If all you see is "HTML-Documents", the following commands should fix the problem without messing up anything else:
cd ~/Local (cd /etc/skel/Local; tar cvf - hp9000s700 i386 powerpc sgi universal) |tar xf -
I've added two projects: a "recursion" project containing the expression-evaluator program, and a "sorting and searching, revisited" project containing code for all the sorts and searches we've talked about in class and a test program.
I've also added to the "GUIs and graphics" a couple of programs that show ways of displaying images (loaded from a GIF file or generated as in the game's getImage methods) with the Java GUI classes. These might be useful if you want to include images in the panels you're writing for homework 6.
I've posted a slightly revised version of my homework 6 writeup, with a minor change and a not-so-minor change. The minor change is adding a link to Dr. Lewis's JAR file for this assignment, which is a recent addition to his writeup and which contains a bug fix affecting display of game-status panels.
The not-so-minor change is adding an alternative to the "edit properties panel" part of the assignment. For some games, such panels can be very useful to the game designer (you at this point), but if you have no interest in using the screen editor to generate the configuration for your game, there's not much point in writing code that will only be used when running the screen editor. So, you also have the option of adding something to your game (via the game status panel(s) or the pull-down "File" menu) that interacts with the user in some way other than via the Player class's key/mouse listener. As always, if you have questions about how this could be done in your game, feel free to ask!
As discussed in class, there will be a review session for the final exam Tuesday (May 6) at 4pm. As far as I can tell from the exam schedule on the registrar's Web page, exams don't start until 6:30pm Tuesday, so we should be able to use our regular classroom for the review session. If there's a conflict with someone else's plans, we'll find another place.
I'll plan to have official office hours as follows next week: On Monday, 3pm to 5pm. On Tuesday, noon to 1pm and 3pm to 4pm. The rest of the week, noon to 2pm. I will likely also be available to answer questions other times as well (generally, all afternoons except Wednesday), but that's not as definite as the official office hours. As always, feel free to call or send me e-mail to find out if/when I'm available outside official office hours or to just drop by.
A couple of last-minute hints and tips:
There is an updated JAR file linked from Dr. Lewis's Assignment 8 at http://WWW.CS.Trinity.Edu/~mlewis/CSCI1321-S03/assn8.html. You should get a copy of this if you're having either of the following problems: (1) You have scrolling turned on, and the player appears to be drawn somewhere to the right of where it's supposed to be. (2) You have north, east, and/or west game-status panels and the game window's initial size doesn't preserve the aspect ratio of your blocks and entities (e.g., they should be square but instead are taller than they are wide). If you're not having either of these problems, you can stick with the old JAR file.
Remember that some of your grade for homework 8 will be based on your documentation. What you should be aiming for is something that explains to a reader (1) what your game is, and (2) how all of your classes fit into the overall plan. What I will grade is the output of "generate HTML documentation", so it would be a good idea to view it with a Web browser (which you can do from Together by checking the appropriate box when you generate it) and make sure it looks more or less like you want it to.