This is my first post to java-gaming.org, announcing the creation of a new Pac-Man clone, called PacDasher.

PacDasher requires J2SE 1.4 -- a large part of my reason for creating the game was to experiment with the latest 2D API and garbage collection features. The game allows custom mazes to be written in XML. Sample mazes, faithful to the original Midway versions, are included.

Bug reports to code@oranda.com. I am an experienced Java developer but this is my first arcade game, so comments and criticisms would be welcomed.

In developing the game I learnt a number of lessons. They will be old news for most people on this board (which I often used to research issues) but I'd like to share my experience as I think many other first-time Java game creators will go through the same things and maybe this summary will save them some time:

1. Review double buffering and understand the new BufferStrategy class.

2. Garbage collection is your biggest enemy as it interrupts the animation. Create a minimum of objects in the main iteration loop (instead reuse objects with pools, etc.) Measure the memory put on the heap per frame (for PacDasher <2K per frame). Java API calls can create a lot of garbage too. Choose a low-pause garbage collector on the java command-line. Call System.gc() at natural pauses in the game.

3. Also important for a constant frame rate is to eliminate Hotspot's opportunistic compilation. Use -Xcomp or -Xint.

4. Whereas most OO designs will concentrate on reusability, arcade game designs should concentrate on performance to compensate for Java's relative slowness.

5. Design data structures based on expected usage. What is the most common question that processing will put to your UI model? Also, for decent frame rates(PacDasher has 50 fps) only use Collections if you really need their methods. Prefer arrays.

6. It would be nice to use layers to separate what changes from what doesn't. This is well supported in the MIDP 2.0 Game API. Unfortunately in J2SE there are a lot of technical difficulties. Images take too much time to combine. Alternatively, JLayeredFrame, as with other Swing components, is heavy in terms of memory and there seems to be no way to really efficiently clear a Graphics (foreground) context (help?). Note that transparent colors are slow too.

That's all. By the way, while testing I found my video card is too old to take advantage of the new hardware acceleration features in Java, so things like BufferStrategy would just be extra overhead from my perspective and I ended up not using them.

- Very cleanly coded! Good job!- Well engineered- Seems true to the original

Not so good points:

- Not active rendered. BufferStrategy is designed for use in a hard loop, not constant calls to "repaint()". Those repaint calls are costing you in FPS as the AWT thread will call "paint()" whenever it feels like it. Assuming the 1.4.2 VM, you should be able to get ~500 fps. - The keys don't work for me. I checked the code and it looks like I should be able to use the arrow keys to control pac-man. Unfortunately, pac-man doesn't respond!- Your run script is missing "-cp pacdasher.jar". Better yet would be to make pacdasher.jar executable.

BTW, layering is easy once you break out of the AWT/Swing world. I'm sure I'll get flamed for *another* link, but you should check out the GAGE2D Parallax scrolling stuff. Triple-parallax scrolling or better all managed automatically in a simple bit of code.

EDIT: Didn't see the part about no longer using buffer strategy. I had to download 7.5 since the 8.5 zip file is corruptted. Personally, I think not using BufferStrategy is a mistake. You should be able to get excellent performance even out of older video cards. My best guess as to why it may be giving poor performance is due to the "repaint()" calls.

I can't get PacDasher to work. I added all the jars to my classpath using the Windows enviroment variables changer, but it still doesn't work. When I try to run it, it says "Exception Main not found" or something like that. Then, when i try the "Build" batch file i get a whole list of compile errors. Any suggestions (I would love to have PacMan on my computer!!!!)

Ok, now PacDasher works and as your docs say the animation is smooth. But the controls are far from smooth. The game takes three seconds to detect my arrowkey input. During these three seconds PacMan goes in a straight direction, gets stuck at a wall, and starts chewing at it. After these three seconds PacDasher detects my key input for 2 seconds and then PacMan does his thing with the wall again for 3 seconds. Also during these three seconds, I noticed that the computer kind of "freezes". The Caps Lock doesn't respond and when (in Windows XP) the mouse is over the X button in the PacDasher window, the X button doesn't detect the mouse layover.

To make a long speech short, the controls are really sluggish. This game makes me feel that I suck at PacMan (before now I was really good ).

There are several reports of the keys being sluggish. I can't promise this is fixed in the latest version, as I have not reproduced the problem on my local machine. So this is currently the most frustrating thing.

Benny, System.gc() only suggests that the garbage collector run. Though in my experience it generally runs right away.

With JDk 1.4.x it is not recommended to call System.gc() anymore. This can actually hurt performance. At one of the JavaOne performance sessions, they said that the System.gc() can 'force' a full garbage collection cycle, when it may not be necessary. Given the new short-lived area (can't think of the correct name atm.. too tired!) garbage collection is not such the pain it was, though you should still keep created objects to a minimum

There are only 10 types of people, those who understand binary and those who don't!

Given the new short-lived area (can't think of the correct name atm.. too tired!)

The "nursery" of the "generational garbage collector". The idea is that short lived objects go into the nursery, then when all those objects are dead, the entire memory heap gets dumped. Rather efficient actually.

BTW, it's no wonder you're having keyboard issues. First, you explicitly enabled the keyboard event mask (that's a no-no), then you put the following code on your Canvases:

You've got a 50/50 chance that the keys will ever go to the frame considering that frames are non-keyboard focusable. Which of course, brings me to another point. Your entire code structure would be much simpler if you got rid of the AWT components and used only direct rendering on the frame. Not only would you be guaranteed that the frame would get the events, you would also be able to remove the tremendous number of hacks and cruft that you have just to support multiple canvases. I'd send you to look at GAGE to get a good idea of how properly to do it, but I'm afraid my server is down right now.

That being said, this release is much easier to wade through. I haven't tried compiling it yet, but the ANT script is a good sign. Keep up the good work.

Changes since my last post include bug fixes, J2SE 1.5, java.util logging, Web Start (a requested feature), and more mazes. To see a sample maze, try

run spiral.xml

You can make your own mazes. The XML format is fairly self-explanatory I think: let me know if it is not.

If you encounter a bug, especially anything to do with key input or jerkiness, please send me the pacdasher.log (in the same directory as the run script) and let me know what video card you are using. I can be reached at code@NOSPAMBoTSoranda.com (without the 'NOSPAMBoTS'). Thank you to all who have commented and made suggestions in the past.

swpalmer: Sorry about the Mac thing. The features in J2SE 1.5 were too attractive for me to resist.

deepFlame: That's interesting about the CPU. PacDasher has frame rate control so it grabs all the sleep() it can get. On my 1.4MHz Wintel system, it takes 30% CPU. I know it performs much worse on Linux. On the IDE question, I am using the latest NetBeans (3.6). It doesn't support 1.5 either but I manage.

Dunno if it supposed to be this slow, but it takes me 14 seconds to cross the long path at the bottom of level1. And it takes a 100% of the cpu time, so if it's supposed to sleep in the free time there must be something wrong . WinXP, Athlon 2.0Ghz, Gf4, Java1.5b1.

I think I've fixed the worst of it. CPU usage is now less than a quarter of what it was. PacDasher 0.96 uses full-screen exclusive mode to ensure that the page flipping abilities of most video cards will work. Also, there is extra double buffering for the complex maze.

It should take less than 5 seconds to cross the long path at the bottom of level1.

...I hope you will have a better experience. If you are using the full version from sourceforge.net, and it is still slow, please send me your pacdasher.log as there is a lot of good debugging info in there.

Try the latest version (also at sourceforge.net) and let me know if there is anything I should fix before 1.0. Has anybody tried it on Linux yet?

I would try it, except you aren't allowing any standard VM's (webstart is setup to only allowed the as-yet-unreleased 1.5.x JVM) which kind of limits your playerbase .

I've got another machine with 1.5.x beta installed for compatibility tests (and because of compiler bugs in 1.4.x!) but only use it for compiling really so might have to setup lots of extra stuff to get a windowing system etc on there .

Oh, I see. Nice. Apparently, I haven't been getting notifications when posts got added to that thread. Looks like I need to do some replying.

Quote

However, there are really huge reasons why it's exceptionally dangerous for people with businesses etc to bet the farm on such things.

To each their own I suppose. The majority of users that contact me about Retroweaver are using it for business purposes. They don't seem to think they're "betting the farm", but they sure are happy about the productivity gains they get.

Web Start for 1.4 gives you a scarier certificate message than 1.5. Also, if the keys don't work at first, check that there isn't a dialog blocking things in the background. Lastly, sound is not supported for the 1.4 version.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org