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:
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.
Subject: cs1321, sort of -- running Java from the command line
cd ~/Local
(cd /etc/skel/Local; tar cvf - hp9000s700 i386 powerpc sgi universal) |tar xf -
Subject: cs1321 -- updates to "sample programs" page
Subject: cs1321 -- updated homework 6 writeup
Subject: cs1321 -- review session, office hours, etc.
Subject: cs1321 -- last-minute hints and tips