BerryBots forums

It is currently Sat Jun 24, 2017 1:56 am

All times are UTC




Post new topic Reply to topic  [ 3 posts ] 
Author Message
PostPosted: Wed Apr 06, 2016 5:56 pm 
Offline

Joined: Wed Apr 06, 2016 5:16 pm
Posts: 3
I've been debugging my bot's firing routines for a few days now, and I am fairly sure the given enemy ship's x and y coordinates are wrong ... it appears the given x and y are the coordinates of the ship *before* it moved in the current tick / cycle. When I draw a debug circle at these coordinates for a moving ship, it is always "lagging", or behind it. If I correct the x and y using the ship's current heading and speed, then it matches the ship's position as displayed on the screen ... and, my firing routine is much more accurate.

I haven't checked the position of player ships ... they could also be affected.

Edit: I just checked player bot position, and it appears to be off the same as enemy bots.

2nd Edit: it appears that bots fire from these "off" positions ... unless the drawing of laser fire happens the turn after firing. I assume the collision detection logic is based on the on screen position. Is this correct?


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 2:24 am 
Offline
Site Admin
User avatar

Joined: Sat Nov 17, 2012 5:03 am
Posts: 88
I don't think there's a bug in ship positions, but that the graphics being off by 1 tick is a side-effect of the order that things are processed. I definitely agree it's confusing you can't just draw where your ship is and have them in sync. Each tick, these things happen in order:

* All ships have their run() functions called - it's as if they are all running simultaneously. (You don't get updated info about an enemy ship because its code ran first, for instance.) Lasers and torpedos are placed on the stage originating from a ship's current position.
* Physics are processed - ships move and check for collisions with walls and each other (and speeds/headings are updated), lasers move and then check for collisions, torpedos move and then check for collisions (and also affect speed/heading if they hit a ship).
* The stage has its run() function called.
* Everything gets drawn to the screen.

It's kind of important to me that the stage gets final say before things are drawn to the screen - the stage can move and destroy ships and update scores and lots of other stuff, which is really the final state I want a player to see. But I do have an item on my to-do list to add a debug option to draw graphics before physics processing occurs, which I think would be exactly what you need. Thoughts?


Top
 Profile  
 
PostPosted: Thu Apr 07, 2016 5:23 pm 
Offline

Joined: Wed Apr 06, 2016 5:16 pm
Posts: 3
The order of events makes sense, now that I think about it a bit more ... I guess I was thinking to render first was expected/logical. But then, as you say, the stage would not get to alter before rendering ... how about:

1) Stage run
2) Render
3) Ships run
4) Physics

This would always render ships where they are ... I am not aware of any negative side effects of this rotated order. If this doesn't work, I can work with the way it is currently ... just needed to be clear what was happening. The specs online do state how execution flow is supposed to work ... it didn't "click" till now. Probably just my fuzzy brain not connecting the dots quick enough to understand the consequences/effects clearly. :-/


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group