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 / Why asteroids speed goes haywire?

Author
Message
tneva82
16
Years of Service
User Offline
Joined: 7th May 2008
Location:
Posted: 23rd Jan 2009 09:44
Ran into strange problem. I'm trying to create bullet controller class that is responsible for keeping track of bullets, moving them etc. However when I try to create class something weird happens. Specifically asteroids all start to head more or less in same direction(here's print from debug file where I insert velocities of each asteroids):

asteroid 10 x: 0.494975 asteroid y:0.494975
asteroid 11 x: 0.492377 asteroid y:0.497559
asteroid 12 x: 0.507374 asteroid y:0.482257
asteroid 13 x: 0.479598 asteroid y:0.509888
asteroid 14 x: 0.511739 asteroid y:0.477623
asteroid 15 x: 0.487302 asteroid y:0.502530
asteroid 16 x: 0.487533 asteroid y:0.502307
asteroid 17 x: 0.511902 asteroid y:0.477447
asteroid 18 x: 0.472106 asteroid y:0.516832

As you can see they have all very similar x and y components. Also lot more decimals than I would expect. If I remove line that creates new bullet controller they vary more and there's less decimals.

Here's the constructor whose calling starts the problems. As you can see it just initialises private variable to right value.



And here's the main block of code(I removed all that don't have something to do with the asteroids). First line is the one which causes the problems(or atleast commenting it fixes problems).



Any ideas where the issue might come? Class variables are all private so they shouldn't be able to interfere. Maybe something about pointer handling?
Van B
Moderator
22
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd Jan 2009 11:36
I'm no GDK coder, but I thought I would ask this anyway.

Have you considered using SIN to generate your random velocities instead?, like SIN(RND(360)), maybe in GDK that would be more like newThrust.x=(float)dbSIN(dbRnd(360));
I find myself using this every time I need a quick and easy random vector.

You seem to be using RND(4)+1, then dividing that by 100, and randomly inverting the X and Y velocities.
I think this might be part of the problem, there is only a little scope for your velocities, basically each axis will have only 1 of 10 different speeds, whereas if you use a random SIN value each asteroid would be more unique.


Health, Ammo, and bacon and eggs!
tneva82
16
Years of Service
User Offline
Joined: 7th May 2008
Location:
Posted: 23rd Jan 2009 12:06 Edited at: 23rd Jan 2009 12:16
Quote: "Have you considered using SIN to generate your random velocities instead?, like SIN(RND(360)), maybe in GDK that would be more like newThrust.x=(float)dbSIN(dbRnd(360));
I find myself using this every time I need a quick and easy random vector."


Splurts.

Knew there had to be better way to do it

Anyway range of values isn't problem since it works just fine if I comment the bulletList creation. I remove that, it works fine every time. I put it in and no matter how many times I start it goes haywire.

Edit: Got it! Needed to change asteroid creation to:



//model is just j variable named anew to something bit more describtive.

And remove pointer and it's deletion. Also made asteroid list initial size to be 0. And it works now. Not sure why that would cause conflict but now my ship is happy blowing asteroids off(well actually turning them invisible ATM since it makes it easier from ID point of view).
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 23rd Jan 2009 14:05
It's pretty obvious where the problem is...

Create a new object on the heap.
asteroid=new ownObject(models[j], i, 2+j);

Push a pointer to that object onto a vector (ie, NOT a copy of the object, but a pointer to it).
asteroids.push_back(*asteroid);

Delete the object from the heap.
delete asteroid;


After that delete, the pointer stored in the vector will be pointing to free memory, which may be allocated when you next create a new object.

tneva82
16
Years of Service
User Offline
Joined: 7th May 2008
Location:
Posted: 23rd Jan 2009 20:58
Quote: "After that delete, the pointer stored in the vector will be pointing to free memory, which may be allocated when you next create a new object."


So why the issue comes up only when line that is far BEFORE those lines is uncommented? That one sent me looking into wrong direction for a while as problem a) appeared when certain line was there far before those lines and b) was consistently on then while without it consistently worked perfectly.

Go figure
Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 25th Jan 2009 04:33
When vectors exceed their limits, they allocate a whole new array and delete the old one. This means their internal address changes, a LOT.

So, remove the line where you delete the new asteroid pointer. It's unnecessary, and is probably causing the problem. Remember, a pointer is just an integer, it points to a spot in memory, it's not an actual object or anything. You're basically passing around the asteroid's address, but then you kick the asteroid out of the house, so there's no one living there.

Login to post a reply

Server time is: 2024-11-18 09:58:07
Your offset time is: 2024-11-18 09:58:07