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.

Dark GDK / 3d flight simulator problems with shooting

Author
Message
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 25th Jul 2008 21:49
I'm confused on the code I need for the plane to shoot in my 3d flight simulator. Right now the plane shoots a simple sphere when you click the left mouse button but you have to hold it down for it to keep going and when you let go the ball goes right back to the planes coordinates. How would I be able to have the ball keep going continuously even after I release the mouse button and make a new ball when I click the mouse button again to repeat the process. Please help! Code would really help!
-Thanks
Dark Dragon
17
Years of Service
User Offline
Joined: 22nd Jun 2007
Location: In the ring, Kickin\' *donkeybutt*.
Posted: 25th Jul 2008 22:43
Any chance thats you, James? You said you were gonna join the forums as "Shadow wolf"....This is Stanas! Hi!

But anyway, i'm guessing you are positioning the sphere every loop?
Make a switch that if it has been fired that it no longer needs to be at the planes coords. that way it should keep going even after you have relesed the mouse....


oh and join my PivoT Forum at....http://pivo.proboards104.com
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 25th Jul 2008 23:09
No I am not James but thanks for helping. I will try it out.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 26th Jul 2008 17:27
SW - The thing you need to do is separate user input to fire a bullet from the bullet
"animation" code.

In other words - You should not make the bullet update if the mouse or whatever is pressed. You should (start at least) by making an array of bullets... All Idle - (Invisible - location not matter)

You should make a routine that loops through all the bullets, and advances them accordingly in whatever direction they are facing - and make the flight of these bullets act correct. when bullet flight over or collision happens, hide the bullet, and flag it as idle again. If it hit something - you would trigger the explosion/sounds etc. module... I say module - I mean another little mini program like the bullet flight stuff.

Now - you'll need code to fire a bullet - but DO NOT write this code based on user input. Make a function that can find an "idle" bullet (not flying, invisible) and position it, orient it, make visible. Now the routine I mention above will automatically advance the bullet each loop along with others that are still flying.

NOW make the user input part - call the "firebullet" routine. Now this way - the bullets have a life of there own - and the only connection (user to bullet) is the command to fire a new bullet.

Does this help you with the concept a bit? I personally find that explainations like these are easier for me to understand - then I can write the code. Usually looking at someone's code is not always as enlighting without some explaination of the theory - unless of course its a fairly small snippet.

what I've described is not going to be necessarily small, and it needs to be modular.... You have definite little "pieces that work together to make a bullet module if I may call it that.

1: Initialize an array that enough information per element to help you track the bullet's "lifetime"

2: routine to examine array, find an idle bullet, and position, orient, show in first "frame" of its flight. If no idle bulets - either don't shoot or expand array dynamically to accomidate.

3: routine in the main loop that updates any and all bullets flying in the array, updating position, checks for collisions and lifetime of bullet path. If Collision or "bullet went to far" - rehide - flag as idle so its ready to go next time its chaosen as the buller de second

4: routine to clean up all bullets and any memory allocated by the array for a nice clean up.

good Luck
--Jason


-----ADVANCED NOTES-----
(ADVANCED: A fancy version of this array idea is to start with an empty array, and as bullets are needed, you make the array bigger as needed on demand. Then you recycle the bullets the same way... in other words, when the bullet stops flying you hide it but don't try to remove it from array - instead flag as idle or something. Some people complete adjust array to number of bullets - freeing ram and reallocating as necessary... I don't like this method - it fragments memory more etc)

Charles Thompson
16
Years of Service
User Offline
Joined: 30th Jul 2008
Location:
Posted: 30th Jul 2008 20:00
Instead of his array method I'd recommend using a Bullet Class and creating a new bullet object every time the fire button is pressed, whenever the bullet goes too far or hits something simply destroy the object and in the destruction method have it figure out if it's near something and do damage and go through an explosion animation of the bullet perhaps. Either way, this avoids memory fragmentation and it's what classes were designed for practically.

Charles Thompson
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st Jul 2008 01:08 Edited at: 31st Jul 2008 01:23
@Charlses - Although I agree a class solution - albeit individual ones (need an array anyways to process them) or one call to encapsulate the bullet code is a better solution - I didn't think that Shadow Wolf was ready to develop such a solution on his own based on his question... though I could be wrong.

however I didn't jump back in to defend but to point out that your last sentance is one I would strongly disagree with - however I am not saying your solution would not work - and these days - memory fragmentation is something many do not understand and the main reason is people are further and further removed from the lower level things with software and frankly PC's getting faster all the time and more memory being available - usually makes these concerns go from being major concerns to minor ones.

The problem I have with:
Quote: "Either way, this avoids memory fragmentation and it's what classes were designed for practically."
is simply not true. Let's break it down. Let's get the tail end of this comment right out of the way first.

Quote: "...it's what classes were designed for practically"
If you mean to be created an destroyed... well yes. The mechanics of a class - are that the code block(s) are static and construction is actually a matter of memory being allocated whose size is dictated by the class structure - meaning the variables and such required to support the class are allocated per instantiation. Upon deletion - this N-Size block of memory is removed.

Now...
Quote: "Either way, this avoids memory fragmentation"
is simply wrong. A Class has no bearing on memory fragmentation whatsoever. The "artifact" that is useful is that if you instantiate ten instances of a class - destroy 5, and allocate five more - that those "fixed memblocks" (if not snatched up or fragmented (from smaller or different mem requests) will LIKELY be used again - but this is not guaranteed. Memory allocation is on a first come first served nature - and "releasing" memory always leaves "holes" in your contiguous heap of ram.

There are admittedly various memory managers and methods - however most of them work very much the same to my knowledge. Regardless, a class allocating memory is no different then me allocating a random ly sized chunk of memory. The memory manager and the application (and classes within) only have one relation - "Give me X sized block" and "I'm done with (ptr) "this block"... Thats all - nothing more nothing less.

the method I described above - does potentially keep more memory allocated than necessary - however - unlike your suggestion which incurs memory allocation overhead each bullet fired - and each bullet finished - every time - my method - whether an array in ONE CLASS or an array of "Bullet classes" is actually going to get faster as the game plays on because the overhead of allocating memory for the bullet and maybe even the gfx object is done once. After that its recycled. the idea is that if in the heat of battle "Shadow Wolf" ends up with 100 bullets all in the air at once - then those bullets will be recycled and no more bullets will be allocated until he tops that.

Regardless of the solution - an array will be needed.
Regardless of the coding style - classes will fragment memory.
[edit] Classes that are instatiated and deleted alot will fragment memory... anything that allocates memory and frees it will.[/edit]

Regardless of his decision - classes were designed to organize code - not dictate the life of the memory managers.

(Your turn )
--Jason

Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 31st Jul 2008 01:24
You cannot assume that your app will have it's own little block of memory that's completely linear and manageable. It's just not practical. When we're talking about a DX app with a large engine in effect, it will almost assuredly be fragmented throughout ram. You can't see it as it's own bit of memory.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st Jul 2008 01:30
TRue - however allocating blocks - and not freeing them - certain does contribute to a non fragmented paradigm.

Also - there is nothing wrong with allocating and freeing memory - that's not my point. My point is that Charles claiming his way would not fragment memory is incorrect. Also - he implied an array would not be needed if you use a class. An array (in one form or another) would need to exist - otherwise where are the pointers for the "alive bullets" stored? Are they not stored? Can a class delete itself?

Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 31st Jul 2008 01:37
I simply meant you have to realize it will not be linear. I didn't mean that you shouldn't allocate memory.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Charles Thompson
16
Years of Service
User Offline
Joined: 30th Jul 2008
Location:
Posted: 31st Jul 2008 11:00
I could take the the time to go into details but just allow me to say that I didn't mean it completely avoids it. Replace avoid with reduce. While you're code certainly does have the potential of eventually being faster I just find it an awkward solution.

You might be right about him not being ready for it though.

On a side note, you took my comment a lot more seriously than I did.

As for a class deleting itself well it can't delete the class but it can delete an instance of a class thus freeing up some memory. But, I mean really the only way to avoid memory fragmentation is to break out some machine code and start assigning items in continuous blocks then after you get done do a little tap dance around it.

One last thought by what classes were designed for I was referring to initiating multiple bullet objects. They're designed to handle things that are similar but act a bit differently. I.E. All the bullets are same but where they're heading is a bit different.

One last side note: You put a lot more time into it than I did. Sorry to the OP if I caused any confusion. Next time I'll try to take a bit more care so Jason won't write up a twelve page retort destroying one sentence.

Charles Thompson
sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 31st Jul 2008 13:31
Just to add a little more information to the discussion.

Even a simple Flight Sim with shooting...... EG a WW2 flight sim will require as a minimum handling for 1024 bullets in flight as a minimum, and in general a hell of a load more than that.

Take a P51D with 6 machine guns and have it shooting a small bust of a few seconds.

Well over 100 bullets in the air from that alone.

Have something like 10 P51s defending 20 B17s and have them attacked by 10 FW190Ds.

Probably 2,000 bullet table is the minimum one would require.

I would not want to do that with C++ and classes.

Now build a simple WW2 flight sim that will handle up to 256 aircraft at the one time and see what happens to the bullet count then.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 31st Jul 2008 16:50
@Mahoney -
Quote: "I simply meant you have to realize it will not be linear. I didn't mean that you shouldn't allocate memory."


Understood - I agree - and I knew what you meant DX and other lib's we link to when executed from within our application - plus other applications in general - all share the heap typically. Some systems allow per process "heap reserves" which would be contiguous at start... but generally speaking - Memory fragmentation just doesn't have the negative imapct it used to however I still believe taking it into account while writing your software is not a waste of time if you are making an application that is conceptually going to run for hours on end and has alot of memory allocation and releasing - as is with a complex game - classes - dx etc all going on.


@Charles Thompson -
Quote: "I could take the the time to go into details"
that's what I was doing is all...

Quote: "but just allow me to say that I didn't mean it completely avoids it. Replace avoid with reduce."
Ok. BTW - My message wasn't meant to destroy your statement as it was to steer the reader(s) mainly Shadow Wolf who is fairly new still - toward a more accurate understanding of all this menutae because seemingly little details can impact how someone designs their code/systems/games/apps etc.. and I try to be diligent about making people who are learning this stuff get steered in the right direction - if nothing more then to send them on their merry way googling the answers for themselves.

Quote: "While you're code certainly does have the potential of eventually being faster I just find it an awkward solution."
I can appreciate that. I consider it a "resources on demand" kind of solution with regards to processing the same "stuff" more than once being redundant. Now in a game - squeezing performance is a contant concern. Now, in a business application - this solution would be considered absurd for MOST things. I can see a use for this sort of logic though in some scenarios - but definately not the norm.

Quote: "You might be right about him not being ready for it though."
LOL - Won't know how he's making out either until he responds. No harm there being new to this - I admire the fact that so many people are diving in and getting their teeth cut. It's not easy - its DEFINATELY work... and it takes ALOT of TIME! So HAng in there people! (I struggle too)

Quote: "On a side note, you took my comment a lot more seriously than I did."
Not intentionally to be a pain in the rump - more to not let that comment be thought of as gospel by others - I personally wasn't effected in any way - either way - but I didn't want people thinking a "class" (in it of itself) prevents memory fragmentation - nor an alternative for problem that screams ARRAY loudly no mater how you pull it off - and Array is the only way that works - and Array of classes I think is very adequate - or at least an array of "struct" managed by some code to keep things organized.

Quote: "As for a class deleting itself well it can't delete the class but it can delete an instance of a class thus freeing up some memory."
Agreed.

Quote: "the only way to avoid memory fragmentation is to break out some machine code and start assigning items in continuous blocks then after you get done do a little tap dance around it"
Or allocate on demand and KEEP allocated for the duration - OR - Allocate a contigous chunk of ram - and manage it yourself like you said. This falls into the realms of writing your own memory manager though so you can get your class instantiations to use the
"available memory" you're controlliing versus getting it from the general heap.

Quote: "One last thought by what classes were designed for I was referring to initiating multiple bullet objects. They're designed to handle things that are similar but act a bit differently. I.E. All the bullets are same but where they're heading is a bit different"
I'll buy that with this summary: Class - One set of Code for an object type - used by multiple instances of that object type. Yuppers.

Quote: "One last side note: You put a lot more time into it than I did."
No Question LOL

Quote: "Sorry to the OP if I caused any confusion. "
Don't be - this sparked a good read for those who happen to be googling about such things.

Quote: "Next time I'll try to take a bit more care so Jason won't write up a twelve page retort destroying one sentence."
NOOOO - Don't do that! This was great! Are you kidding - the fact that you tossed out another approach and we discussed it - our thoughts - reasons - that's COOL to me... Please DO post your opinions - EVERYONE SHOULD! If I don't reply and share my thoughts - how can I ever be taught anything! I mean - what if I thought XYZ and you knew better and showed me the light? I'd be greatful.

In this case - I didn't really shed light for you - but I BET we BOTH did to other forum visitors! Its all good. Besides - 12 page posts don't kill trees Chainsaws do LOL

@Sydbod - Thank you for those numbers and your thoughts - I found them very informative seriously - thats a lot of bullets.

One trick I think sone games do is they make the sounds of 20 bullets while actually only shooting a few - maybe even visually having one bullet look like 3,6 etc.. so cut down on those numbers. Me personally, I like the "simulate each bullet" approach even if its more resources. Allows better gameplay in my opinion.

--Jason

Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 31st Jul 2008 19:59
Quote: "Memory fragmentation just doesn't have the negative imapct it used to"


Even though it doesn't, it still fascinates me (low level stuff). I'd love the challenge of squeezing speed out of something weak. Like, the GBA or NES. (Which I might look into. )

Quote: "if nothing more then to send them on their merry way googling the answers for themselves"


That's usually what everyone resorts to eventually.

Quote: "Next time I'll try to take a bit more care so Jason won't write up a twelve page retort destroying one sentence."


Lol. If he's anything like me, he enjoys every second of his essay-length replies.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 31st Jul 2008 20:10
Hi guys and thanks for responding. You are right about me being new to Dark GDK and I am definitely not advanced at programming (I'm probably between beginner and intermediate). The methods you described seemed kind of complicated for just creating and moving an array of bullets each time the mouse is clicked however I am a lot less experienced than you guys so I could be wrong. Would I be able to just load 1 bullet object and set the id to a variable say "bulletcount" which would be set initially to 1000. Then could I increment "bulletcount" each time through the loop creating bullets 1001, 1002, 1003, etc.... If this method works (tell me if it won't) how would I be able to move all the bullets that I created because the dbMoveObject command only moves a single bullet.
-Thanks
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 31st Jul 2008 20:19
Reading through Jason's explanation, I'd say it's a little in depth.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 1st Aug 2008 19:12 Edited at: 1st Aug 2008 19:20
I got my method to work however I have one problem. Every time I load bullets in the loop after my "bulletcount" reaches 10010 the camera does this weird thing where the program pauses for a second and the camera goes to the coordinates 0,0,0 and slowly goes back to behind the plane. I know the problem is the dbLoadObject command because if I preload the bullets outside the loop it works fine. However I need to load the bullets inside the loop once "bulletcount" reaches a certain number so that I can restart "bulletcount" from 10000 again so I don't need to preload an infinite number of bullets. Any ideas on how I can load the bullets inside the loop without the camera doing that weird thing?




void Laser( void )
{
dbLoadObject("media\\laserbullet.3ds",10000);
dbLoadObject("media\\laserbullet.3ds",10001);
dbLoadObject("media\\laserbullet.3ds",10002);
dbLoadObject("media\\laserbullet.3ds",10003);
dbLoadObject("media\\laserbullet.3ds",10004);
dbLoadObject("media\\laserbullet.3ds",10005);
dbLoadObject("media\\laserbullet.3ds",10006);
dbLoadObject("media\\laserbullet.3ds",10007);
dbLoadObject("media\\laserbullet.3ds",10008);
dbLoadObject("media\\laserbullet.3ds",10009);
dbLoadObject("media\\laserbullet.3ds",10010);

}
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 1st Aug 2008 19:14
dbAutoCamOff ( )

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 1st Aug 2008 19:38
Genius! Thanks a lot! I didn't even know that command existed.

However, the game still pauses for a second every time it loads new bullets. Is that normal? Is there any way to fix that?
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 1st Aug 2008 20:40
I don't use 3D, so I may be wrong, but can't you load the bullet object once, then create instances of it?

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Aug 2008 22:01 Edited at: 1st Aug 2008 22:03
AHHHHH

EASY FIX.... At least in theory....

This:


YUCKY POO!

Load the Laser one time, and I wouldn't even use "that" main one. (You could.. I just wouldn't because I'd want the objects being processed in my loop of "like things" (bullets) to be the same kinds of things (Bullets)... in this instance I MEAN "INSTANCES"!!!

You can load the laser object one time and then make instances as necessary. Also - you don't want to stack loadcommands or instance commands in this manner you posted. It's more managable to do a loop....



See if that helps. I figure you're wasting resources loading a separate bullet "object" from file - and frankly - MOST load from disk operations during game loop cause a lag - the minimum impact I found so far is making a util to load your object and save it as a DBO. Then in your game use DBO. DBO load ALOT faster then x,3ds, whatever.

This should help ALOT! And BTW - GOOD JOB SO FAR! The fact that you're starting to get a working bullet engine/system whatever - is really cool and shows alot of improvement on your part! AWESOME!

--Jason
[edited code type in my little snip]

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Aug 2008 22:04
Mahoney
16
Years of Service
User Offline
Joined: 14th Apr 2008
Location: The Interwebs
Posted: 1st Aug 2008 22:58 Edited at: 1st Aug 2008 22:58
It's alright.

Besides, you did a better/more detailed job of it.

Windows Vista Home Premium Intel Pentium Dual-Core 1.6 Ghz 1GB DDR2 RAM GeForce 8600GT Twin Turbo
Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 2nd Aug 2008 02:03
Thanks a lot guys. My bullet system now works pretty well!

However, the bullets come out of the center of the plane at "plane" xyz. I want the bullets to come out of the plane a little bit farther on the z-axis and a little bit down on the y-axis. I tried doing the following:

dbPositionObject(bullet,px,py-5,pz+5);

px, py, and, pz are plane position x, plane position y, plane position z respectively.

The result of this was that if you moved the plane when shooting the bullet starting position moved from side to side.

My question: Is their any way to offset objects so this does not happen?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 2nd Aug 2008 14:09
Yeah. You have the right idea... but you need to change you're thinking a little. Offset? Yes. By just adding +5 to x,y, or Z? No. Why? The orientation is fixed the way you are doing it.

FIRST - place bullet at the "airplane" x,y,z. Then Orient Bullet to Airplane's orientation.

Then "Move bullet" accordingly - perhaps forward, then up... You might even need to rotate (use pitch/roll/turn - not offsets)

That's HOW you do it the easiest way. Now - a math guru might do the osset idea based on the rotation and position of airplane that would accomplish same "relative offset" thing my suggestion would do - but - I won't even pretend to know how that is done.

Another thing I did whichj might be to complex but worked for my in IronInfantry (The DBPRo version before I migrated to DarkGDK) http://code.google.com/p/ironinfantrydbpro/ is make this thing I called the TOY which was a "3d Cursor I could turn on. I had all my 3d objects in an array... their object IDS and what they were called (tank... heli etc) I could turn on "toy" mode and flip through the "names" (keypresses explain how to in the docs included in the above links download - exe included) and
as I flipped though - the "toy" cursor would appear at whatever 3d object was "current". Then I had on the screen "how far toy moved" and each time I I "reset" toy or flipped to a new object these values were set to Zero and I could see them on screen.

As I moved the "toy" (I had keys set up to move toy on each axis and rotate each axis) I would get those offsets you were trying to use... so while I moved the toy forward (and or stoppped) - I could see in numbers how far I moved the toy from where it started (Center of airplane lets say say). I could turn it a bit - move up etc - until I had it lined up with the gun. Then I would write down on pen+paper the distance I moved the toy on each axis I moved it on - also any rotation.

then with these numbers I'd have code that used em - like this:
(Pseudo code BTW)

position bullet, tankx, tanky, tankz
move bullet,SomeFwdDistance
turnleft bullet, TankTurretAngle
moveup bullet, SomeUpDistance
moveleft bullet, distanceleft (line up to actual gun barrel)
pitch bullet up, angle_of_gun_barrel

...FIRE...

--Jason

Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 4th Aug 2008 19:11
Thanks a lot Jason.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 5th Aug 2008 01:13
Any time

(BTW - my pseudo code above forgot the "Rotate bullet to orientation of airplane" Should be the first line (or as the second line) LOL - You're welcome!

I hope we get to see this project your're working on!

--Jason

Shadow Wolf
16
Years of Service
User Offline
Joined: 6th Jul 2008
Location:
Posted: 5th Aug 2008 03:39
I'll try to get a demo up on the forums as soon as possible but that may not be for a while seeing as how I have a lot more work to do on the game.
-thanks again

Login to post a reply

Server time is: 2024-09-30 03:29:25
Your offset time is: 2024-09-30 03:29:25