Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Code Snippets / Radioactive Decay demo, v5.8+ Pro

Author
Message
RaceGT
19
Years of Service
User Offline
Joined: 15th Aug 2005
Location:
Posted: 4th Nov 2005 18:47
Radioactive decay demo:

Ok, I thought that might get your attention but now that you're here, what this is is actually much more than some kind of graphical effect. It's the result of my first work with Sparky's DLL, and it's the kind of thing I've always wanted to make. I'll leave it up to you to check it out, but there is some explaining to do beforehand:

1.) There is some supplied media because that's the demonstration of the program. You could supply your own, just make sure it's inside-out (faces facing inward). I'm sure you'd know how to change the code to change which object gets loaded; it's right at the start of the program. There are a few shapes to try, but start with the default of using "shape3.x" the way the program's written.

2.) You can press the 1,2, and 3 keys for different camera views. 1=front (default/start), 2=side, and 3=top. It doesn't really matter which view you use, but they do give you quick frame of reference when you want to know which way you're looking. If you have a mouse wheel, roll it to move the camera forward. There is no back because DB's Move Camera doesn't use negative values and I could never figure that out. If you can do 'move forward'(+), then why not 'move backward'(-)? Anyway...left and right arrows move camera left and right, and up and down keys, camera up+down. The only thing missing is pulling the camera back, but between all the controls you should be able to get the camera positioned where you want. Sometimes you have to use Camera Forward in small steps to get to exactly the point you want to look from...

3.) When you throw a ball, its speed comes from how far away the (1st) bounce point is. So, if you're very close and you let loose a ball, it will start out slower. Using the 1,2,3 keys moves the camera farther out to start with, so if you choose one of these views and shoot a ball, it will start out with a higher speed and head towards its target. It's made this way just to give a variable way to send the spheres moving at different volocities without having to do some kind of input to make that change. It's just about camera distance which makes (made) it easy to test different velocties.



Now, the whole problem all along with this program has been that it would miss bounces, and seeing that disappointed me very much. It might make a few successful bounces, but then I'd always see a ball fly off into space, and my disappointment grew. But then I found an error in my logic and it was in the adding of the object's velocity at the time of collision detection. There was an error in which variables I was using, but then I figured that out. Now it's working the best I've ever seen it, so I wanted to see if there was any feedback on it...

Try starting out at the very first default camera location at the start of the program, and fire a couple of balls. Cool. Fire a few more. Awesome. Get it up 50 or 60 balls. 99 is the max but I wouldn't try it. It's kinda cool to watch it at this point. It's what I've dreamed of making for a long time. The weird shape is to 'really test it out'.

Ok, now quit and restart the program. Maybe fire a few slow balls, but then use the 1 key to get to that far front camera view. Now fire a couple or few balls. See, they're going quite a bit faster. Here comes the test: do they stay inside. Get like 40 or 50 fast balls flying around in there. I was like "Hey look, it's working....", then a single ball goes flying off into space. If you watch it for a while, it looks like radioactive decay


Well, the purpose should be pretty obvious: What comments does anyone have about this? Please bear in mind that since I changed the manual collision detecting area, probably about 30-40% of the code inside the FOR-NEXT loop to check each object is probably useless now. Like I don't think I need to be using Sparky's once for each object once per pass through the loop any more. Plus I'm sure there's other stuff inside there that's no longer needed, so all that could likely be removed. And you can safely ignore all the mumbo-jumbo data's displayed on the screen. I was using them during the initial testing and I'm not even sure they're right any more . It's not cleaned up yet, just working...sorta. It does however show alot about the techniques of manual collision detecting, at least that's what I learned from it. And as great as I think Sparky's DLL is (I couldn't have done this without it), it shows the need for a (built-in) collision detection system that can handle things like this. As good as I thought I've done here, it's still prone to errors (apparently?), which is why I think DB could really help out its users by helping us out in this area...




http://www.geocities.com/crmnlelmnt/

Attachments

Login to view attachments

Login to post a reply

Server time is: 2024-11-23 11:10:01
Your offset time is: 2024-11-23 11:10:01