ahem, my cheat 
about controlling the cursor you can also use the Robot class, or even better use fullscreen
[quote]Well, my cheat is pretty easy to fix. Just make āmouseDraggedā call āmouseMovedā. The jerking motion however, would need you to move the cross along a line from the last point of the mouse to the current point of the mouse. (Time to go study Breshenhamās (sp?) algo, eh? ;)) You can make the āout of boundsā trick work correctly by listening for MouseEntered and MouseExiting. Sadly, jumps from outside the window will have to start from the first point received bv MouseMoved.
[/quote]
Yeah, thanks - Iāve no difficulty in disabling that cheat.
As for the rest, I think you misunderstand the problem: when I have a large number of collidable-objects on screen, say N objects, I am currently doing O( N ) calculations per player-movement. With a correct swept-area, I could STILL do only O( N ) calcs - this is probably the main reason that that class of collision algorithm is so widely used. However, my collision-detection can only accept Rectangular shapes as the input for one of the objects which āmay have collidedā. Therefore, Iād need to do my O( N ) calculations once for every discrete position between start-point and end-point. With M pixels per step, my algo suddenly jumps from O( N ) to O( N * M ), which is NOT good. That increase could be enough to cause the performance to grind to a halt. That is my concern.
What you describe is precisely what I said: a āswept-volumeā collision detection algo, so called because you are sweeping a volume (or in this case, an area) across the screen, to create a bigger volume.
I cannot see how you could use Bresenhamās here - that algo is for painting a line on a pixel-based screen; it has no other uses, AFAICS. I think what you mean is just simple two-dimensional interpolation.
Thereās also no reason why jumps from outside the window would be difficult to handle - Iād just use the velocity-vector of the mouse movement, and backtrack to find the start-point. However, I suspect that MouseMotionListener probably supplies the āfirst intersection with the JComponentā anyway. I may be wrong, but it would pretty foolish NOT to work that way. However, Sunās JDK docs are classic: even for 1.4, they say āInvoked when the mouse enters a component.ā. Thatās it; no more explanation than that!. I hope I never meet the lazy sonofabitch who wrote these crap bits of the JDK docsā¦Iāve already (successfully) reported several bugs on the docs over the years - including one where they completely forget to include a jdoc for several methods - no explanation of parameters, or anything!
[quote]ahem, my cheat
about controlling the cursor you can also use the Robot class, or even better use fullscreen
[/quote]
Iāve seen Robot mentioned on the forums before - but itās not a part of the standard libraries, and I recall people wondering about where it came from. Do you know?
[quote]Iāve seen Robot mentioned on the forums before - but itās not a part of the standard libraries
[/quote]
Yes it is.
java.awt.Robot
Bresenham is used to iterate along a line. at every pixel if you like, you can do whatever you want. you can, as you suggested, draw a pixel and hence draw a line. you can also do something else, like check for collisions.
java.awt.Robot btw
another thingā¦ have you really profiled your code or are you just guessing? i hardly think itās your collision detection thatās slowā¦
Doh! I was looking at the 1.2 docs. @since 1.3. Thanks :).
[quote]another thingā¦ have you really profiled your code or are you just guessing? i hardly think itās your collision detection thatās slowā¦
[/quote]
I didnāt say it was slow at the moment; O( N ) is actually pretty fast. But do it 200 times as often, and it could become a problem. At the moment, itās only being called about 4 times per second - 800 times per second is something to be more careful about.
Anyway, thanks to everyone for the thoughts and ideas. Iām hoping to upload the next version soonā¦
conclusion: donāt worry about the order stuff then
but do if it becomes a problem
ādonāt design for tomorrow, design for todayā
- read in some XP book, probably Extreme Programming Installed
BlahBlahBlahBlahBlahBlahBlah,
My experience is that the collision detection costs are the least of your worries. When I was testing the collision library I use in GAGE, I found that the cost was so small it was almost immeasurable. Considering that it was a ācheck the whole world against the whole worldā implementation, Iād think your game wouldnāt do much worse. The real cost still seems to be painting. Every ounce of painting speed you can get will help immensly.
[quote]Thereās an even easier way to ācheatā. Click and drag the mouse and the cross wonāt move until you let go of the button. Thus you can transport your cross anywhere you like. How do you think I got 70,000 on my first try? ;D
[/quote]
PS: please could you give this a try on another test-build Iāve just uploaded? I donāt think youāll find it quiteso easy this timeā¦
(same address as the last test-build: etc etc /crystals-full-v1.299999.jar)
ā¦not that I added this to spoil your cheat, but Iām experimenting with different mine-formations, and suddenly realised this one was going to be a problem for youā¦ 
This will be the last build from this version (1.2x). For each version, the latest āstable test buildā will always be [first 2 sig figs of current version, with 5 nines on the end]. E.g. 1.3 will have 1.399999, as will 1.31, 1.32, etc.
[quote]BlahBlahBlahBlahBlahBlahBlah,
My experience is that the collision detection costs are the least of your worries. When I was testing the collision library I use in GAGE, I found that the cost was so small it was almost immeasurable. Considering that it was a ācheck the whole world against the whole worldā implementation, Iād think your game wouldnāt do much worse. The real cost still seems to be painting. Every ounce of painting speed you can get will help immensly.
[/quote]
Yeah, Iāve had several harsh experiences of the ponderous nature of java painting; years ago my mandelbrot applet used to calculate new fractals 3 times faster than it could paint them, with several of the old 1.2.x VMs; I knew the problem, but attempts to use DirectColorModel kept failing for stupid sucky reasons. I expect your collision detection routine is clever and good, unlike mine (the fact that you had a whole library, where I have 4 lines of code, suggests to me that yours was a whole world of good better :)).
PS. Sorry to all if my posts have been a bit unclear, cranky or etc. Iām not getting time off my day-job to do this (some big important stuff going on there), so Iāve just done my fourth day in a row of 16-hours-of-work-a-day. :(. I really do appreciate everyoneās advice and thoughts, and I hope to work in all the good gameplay ideas, sooner or later :). But time is very sparse right now, so Iām having to cherry-pick :(.
[quote]my fourth day in a row of 16-hours-of-work-a-day
[/quote]
Only 16? Luxury!!!
;D
[quote] PS: please could you give this a try on another test-build Iāve just uploaded? I donāt think youāll find it quiteso easy this timeā¦
[/quote]
Youāre right, it is much harder. The ācheatā still works, but the moving bombs tend to negate the effect. BTW, it would be nice if there was some form of crystal āclinkingā sound when you touch the crystals.
There seems to be quite a few performance problems tho. It was resonably fast the first time, but rather slow after that. Even when it was fast, the stars would ājumpā as the ticking sound restarted. There was also popping in the audio between plays of the ticks.
[quote] I expect your collision detection routine is clever and good, unlike mine (the fact that you had a whole library, where I have 4 lines of code, suggests to me that yours was a whole world of good better ).
[/quote]
Clever? Perhaps in coding style, but not much else. If you used my lib, it would make a check of the cross against every bomb and crystal on the screen for each frame. I was originally planning to improve collision detection with sorted lists, but it ended up being unnecessary as the collision code was probably the fastest process of all.
For a good comparison, take your 800 and multiply it by a reasonable number of cycles per operation. Letās say 50. That works out to about 40,000 cycles for each check. Now, letās assume a 733 MHz processor. Why? Cause thatās what I have. 733,000,000 divided by 60 (frames per second) is 12,216,666 cycles. As you can see, our 60,000 cycles pale to what we have available. In fact, the processor isnāt actually doing anything for about 90% of the time of the game.
The moral of the story is that logic is cheap and drawing is expensive. Use logic liberally.
[quote] I cannot see how you could use Bresenhamās here - that algo is for painting a line on a pixel-based screen; it has no other uses, AFAICS. I think what you mean is just simple two-dimensional interpolation.
[/quote]
You just said it yourself. Itās 2D interpolation. You can use the path created to either put pixels in that path, or move an object along it. I use Breshenham for both drawing and collision detection in WarGames, my 4K entry.
Yeah, I agree on the sound issues; if you look back far enough through this post, somewhere I think I explained that I added the sounds at the last minute. Since my microphone is broken, I had to make do with free onesā¦the popping noise on the clockticks is because itās a bad sample.
I really wanted a noise for the crystals - and I experimented with various different ones - but in the end it always seemed to make the game worse. Mostly, I suspect, because of how mangled it sounds when you play the same clip several times in succession in java, all mangled over the top of each other; you often get two or more crystals in quick succession, so this happens often. If the new sound APIās add the ability to detect if a sound is already playing (which Iām sure they do), Iāll try again - once Iāve found/generated a decent sound sample!
[quote]If the new sound APIās add the ability to detect if a sound is already playing (which Iām sure they do), Iāll try again - once Iāve found/generated a decent sound sample!
[/quote]
They do. All you need is a special sound listener. Watch out for the cost of rewinding a clip when itās playing. Java seems to bleed out the rest of the clip before restarting it. This generally results in blocking which will slow down your game.
Alternatively, you could use GAGESound or OpenAL. Personally, I think OpenAL is an overkill and would reduce your portability. (Althought this is true of any library.) GAGESound however, would need a slight change to notify something when a sound is done playing. Since I built it as mostly an effects engine, I havenāt yet decided how I should handle events (since they tend to slow things down).
My last post to this threadā¦Iāve uploaded 1.3, and started a new thread for it. Hopefully tomorrow I can complete the changes I was making tonight before I got pulled away. (c.f. other topic for details).
EDIT: link to other thread: http://www.JavaGaming.org/cgi-bin/JGOForums/YaBB.cgi?board=Announcements;action=display;num=1051741647
Iāve made a funky multi-layer background using transparency, and discovered that I max a 1Ghz CPU with ~ 50,000 partially transparent fillRectās per second.
This is pretty crap. I find it hard to believe thatās hardware-accelerated alpha (this was on a gf2). I suppose I now have to start using special Imageās, and give up on Swingās automatic imaging and buffering (i.e just using paintComponent() etc) - although I thought it was supposed to be hardware accelerated?.
[quote]Nice
On my 1GHz desktop itās not yet very smooth, but Iām sure thatāll come in time. Also sometimes the background completely stops moving when I move the cross. Probably related.
[/quote]
Iāve got my java profiler up and running again, so if you could do a profiling run:
java -jar -Xrunhprof:cpu=samples,thread=y,depth=10,cutoff=0,format=a crystals-full.jar
(change the jar filename if necessary) and play long enough for it to happen once or twice, then email me the java.hprof.txt file, I can compare it with some runs of mine and see if thereās a CPU hog in there somewhere that I donāt get problems with.
Warning: the game will probably be pretty unpleasant with the profiler running. And could you zip the output file before sending? If this is OK, email the hprof to ham.crystals @ grexengine.com
Thanksā¦