Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Beta: Crystals  (Read 7787 times)
0 Members and 1 Guest are viewing this topic.
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #30 - Posted 2003-04-29 00:12:12 »

Quote
On this version, my personal best is 49,746


70,629. I think it was level 22. Maybe it was higher.  Grin

Java Game Console Project
Last Journal Entry: 12/17/04
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #31 - Posted 2003-04-29 05:33:24 »

Quote
The flash is implemented as an extra layer that is normally just empty (i.e. lets the layers below show through), but then flashes itself when necessary. Easy to code, easy to maintain.

Smart, but as it seems to turns out, not very fast in execution.
Isn't the background (with the stars) also a layer that's drawn anyway which you can just draw in other colors instead of black to get the flash effect?

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #32 - Posted 2003-04-29 11:28:27 »

Quote

Smart, but as it seems to turns out, not very fast in execution.
Isn't the background (with the stars) also a layer that's drawn anyway which you can just draw in other colors instead of black to get the flash effect?


1. I think the execution-speed problem is merely because my Swing painting is highly un-optimized. It works fine on my test 1ghz laptop, so as long as it's smooth enough for testing not to be unpleasant Smiley I'm not yet ready to start optimizing.

2. Sneak peak of what I'm going to do with the layers:

http://grexengine.com/sections/people/adam/crystals-full-v1.299999.jar

(note: please don't bother telling me about the ConcurrentModificationException - I know; this is not a "real" release, it's just the latest working build...Ditto don't get too concerned about the fact that all the mines now attack you - it's just for testing the movement! Smiley)

EDIT: FYI, there are 3 or 4 backgrounds in that build, and each level randomly selects a background; you might have to play through as many as ten levels to see all the backgrounds. Not too exciting, but once the background-selection is working perfectly, I can worry about adding more interesting ones Smiley

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline mill

Junior Duke




popcorn freak


« Reply #33 - Posted 2003-04-29 11:37:53 »

haha it's great fun! i know my dad is gonna love this.

with "moving bombs" i thought that they would jiggle a little, but this is also cool.

it's another game now. it would be cool if you had two modes: one with following bombs and one with jiggling bombs. just suggestions.

how about letting the starfield follow the mouse? think it'd be a cool effect.

keep us posted!

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #34 - Posted 2003-04-29 12:53:05 »

Nice  Smiley
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.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #35 - Posted 2003-04-29 14:17:14 »

Quote
Nice  Smiley
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.


Yeah, at the moment I'm only using 40% CPU to handle everything on a 1ghz PC, so I should have a lot of room to e.g. increase the frame rate (but I have no idea until I start delving what the causes of jerkiness will actually be...)

Out of interest, is the lack of smoothness a constant thing (i.e. could it be just that the frame rate is too low?) or is it occasional jerks? I've just checked, and the starfields are currently all aiming to run at a measly 25fps!

The background "completely stopping sometimes when you move the mouse" is quite scary; I fear it could be a VM-specific issue.

malloc will be first against the wall when the revolution comes...
Offline zparticle

Senior Duke




Thick As A Brick


« Reply #36 - Posted 2003-04-29 14:36:46 »

It really looks like a logic/event handling issue. It stops completely for me anytime the mouse is being moved. BTW there is a really easy way to cheat. Move the mouse outside the window and then back into the window at a point close to a gem, then you don't have to move through the mines. This also allows you to get at mines buried in a blob of mines. Hold the mouse out side of the window and jerk it onto the window very quickly. The cross never "goes through" the pixels between the edge of the window and where the mouse ended up when you stop moving it.

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #37 - Posted 2003-04-29 14:48:38 »

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?  Grin

Java Game Console Project
Last Journal Entry: 12/17/04
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #38 - Posted 2003-04-29 14:59:25 »

Quote
It really looks like a logic/event handling issue. It stops completely for me anytime the mouse is being moved.


The thing is, it NEVER stops for me, and the logic means it never should. And I don't think I'm the only person who doesn't have that particular problem?

Quote

BTW there is a really easy way to cheat. Move the mouse outside the window and then back into the window at a point close to a gem, then you don't have to move through the mines. This also allows you to get at mines buried in a blob of mines. Hold the mouse out side of the window and jerk it onto the window very quickly. The cross never "goes through" the pixels between the edge of the window and where the mouse ended up when you stop moving it.


Going "outside the window" is actually intentional - otherwise the game would quickly get totally impossible on harder levels.

However, the "jerk the mouse in quickly" bit was something that didn't occur to me (doh!). As mentioned in an earlier post, the current link between mouse and player's cross is only temporary - there will be a variety of different versions (some enabled by powerups/powerdowns, others enabled by specific levels).

However, I would like to keep the current behaviour (note: I AM intending to remove the mill/jbarnes cheat; sorry, guys Smiley) - except that your "jerking the mouse" is something I'd like to do without.

Hmm. Guess I'll have to start doing proper swept-volume collision detection; this is not going to be as easy as you might imagine: it will probably mean writing a new collision-detection routine from scratch Sad. Alternatively, maybe I can get away with a "maximum step-size" which is the largest amount the player can "jump" by - so that even on a long jump, of distance say 300 pixels, I only have to do (300/max-step-size) * numObjects collision checks... that might be OK (a the moment I do one: for the end point Smiley - hence your cheat!).

malloc will be first against the wall when the revolution comes...
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #39 - Posted 2003-04-29 16:44:53 »

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? Wink) 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.

Java Game Console Project
Last Journal Entry: 12/17/04
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline mill

Junior Duke




popcorn freak


« Reply #40 - Posted 2003-04-29 17:25:10 »

ahem, my cheat Smiley

about controlling the cursor you can also use the Robot class, or even better use fullscreen Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #41 - Posted 2003-04-29 17:56:50 »

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? Wink) 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.



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! Smiley

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #42 - Posted 2003-04-29 17:58:45 »

Quote
ahem, my cheat Smiley

about controlling the cursor you can also use the Robot class, or even better use fullscreen Smiley


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?

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #43 - Posted 2003-04-29 18:06:54 »

Quote
I've seen Robot mentioned on the forums before - but it's not a part of the standard libraries


Yes it is.

java.awt.Robot

Offline mill

Junior Duke




popcorn freak


« Reply #44 - Posted 2003-04-29 18:10:14 »

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

Offline mill

Junior Duke




popcorn freak


« Reply #45 - Posted 2003-04-29 18:12:09 »

another thing.. have you really profiled your code or are you just guessing? i hardly think it's your collision detection that's slow..

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #46 - Posted 2003-04-29 18:28:07 »

Quote


Yes it is.

java.awt.Robot


Doh! I was looking at the 1.2 docs. @since 1.3. Thanks Smiley.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #47 - Posted 2003-04-29 18:54:15 »

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..


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...

malloc will be first against the wall when the revolution comes...
Offline mill

Junior Duke




popcorn freak


« Reply #48 - Posted 2003-04-29 18:59:03 »

conclusion: don't worry about the order stuff then Smiley

but do if it becomes a problem Smiley

"don't design for tomorrow, design for today"
- read in some XP book, probably Extreme Programming Installed

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #49 - Posted 2003-04-29 19:41:31 »

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*.

Java Game Console Project
Last Journal Entry: 12/17/04
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #50 - Posted 2003-04-29 20:55:08 »

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?  Grin


PS: please could you give this a try on another test-build I've just uploaded? <chuckles evilly> 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... Wink

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.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #51 - Posted 2003-04-29 21:05:06 »

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*.


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 Smiley (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 Smiley).

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. Sad. I really do appreciate everyone's advice and thoughts, and I hope to work in all the good gameplay ideas, sooner or later Smiley. But time is very sparse right now, so I'm having to cherry-pick Sad.

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #52 - Posted 2003-04-29 23:54:19 »

Quote
my fourth day in a row of 16-hours-of-work-a-day


Only 16? Luxury!!!!

Grin

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #53 - Posted 2003-04-30 01:43:43 »

Quote
PS: please could you give this a try on another test-build I've just uploaded? <chuckles evilly> I don't think you'll find it quiteso easy this time...


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 ).


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. Smiley

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. Wink 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.


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. Smiley I use Breshenham for both drawing and collision detection in WarGames, my 4K entry.


Java Game Console Project
Last Journal Entry: 12/17/04
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #54 - Posted 2003-04-30 09:50:43 »

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.


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! Smiley

malloc will be first against the wall when the revolution comes...
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #55 - Posted 2003-04-30 12:04:26 »

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!


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).

Java Game Console Project
Last Journal Entry: 12/17/04
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #56 - Posted 2003-05-01 00:52:39 »

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

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #57 - Posted 2003-05-03 12:00:54 »

Quote

It works, but I would prefer a fast fade too.

Really? In my duke rogers game I do fillRect every frame to clear the screen as well as another 200 fillRects to draw the stars and I well over 80fps on my p2/266 laptop. fillRect should be fast enough I think.


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?.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2003-05-07 17:14:57 »

Quote
Nice  Smiley
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.


I've got my java profiler up and running again, so if you could do a profiling run:

1  
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? Smiley If this is OK, email the hprof to ham.crystals @ grexengine.com

Thanks...

malloc will be first against the wall when the revolution comes...
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (41 views)
2014-10-17 03:59:02

Norakomi (33 views)
2014-10-16 15:22:06

Norakomi (26 views)
2014-10-16 15:20:20

lcass (30 views)
2014-10-15 16:18:58

TehJavaDev (59 views)
2014-10-14 00:39:48

TehJavaDev (60 views)
2014-10-14 00:35:47

TehJavaDev (50 views)
2014-10-14 00:32:37

BurntPizza (66 views)
2014-10-11 23:24:42

BurntPizza (38 views)
2014-10-11 23:10:45

BurntPizza (80 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!