I am trying to make a simple arcade shooter like Galaga in TIBasic. I have successfully created some code that lets you move your character (an "X") horizontally across the screen while shooting a bullet that clears everything along the vertical path it takes. However, I'm having a problem with the "rocks" that are supposed to fall from the screen and disappear when hit. When I shoot the rock, it is cleared by the bullet, but then continues going down the screen until it hits the bottom of the screen. Here's the code for the rocks:
//outside the game loop:
1->R
//inside game loop:
If not(R=8)
Then
R+1->R
If R>1
Then
Output(E-1, 1, " " //removes last rock
End
Output(R, 1, "R" //replaces last rock with one below it (traveling towards the ground)
End
This code obviously doesn't stop the "R" from continuing to go down the screen when it is cleared (by the way, I just use Output(...," ") on wherever the bullet was to clear away anything the bullet hits). So, how would I check if the rock was cleared away on the last iteration of the game loop? Is there a way to check if something (the "R") is at a certain place on the screen in order to check if it was cleared away by a bullet on the last iteration? Or is there a better way? Thanks for the help!
It appears that the code you have doesn't test if the bullet is in the same place as the rock. To have this collision, you'd need to compare the "R" y-value of the rock with the y-value of your bullet you displayed, and compare the x-value of the rock (however you store that) with the x-value of the bullet. If both are equal to each other, then they have collided, and you can "delete" the rock by setting it to whatever value signifies it doesn't exist anymore. Assuming R is the y-value of the rock, S is the x-value of the rock, Y is the y-value of the bullet, and X is the x-value of the bullet, In the code to move the rock, I'd put this somewhere:
:If R=Y and S=X
:DelVar R
//You could also delete the bullet here because it's "stopped" by the rock
This code will test if the two are collided and set R to 0 (meaning it doesn't exist). If you wanted, you could also add a text-version of an explosion to give it some more flair. Good luck with your project, and I hoped this helped!
When making a game in Ti-Basic, there are 2 options for which "screen" to put it on: The text screen of the calculator, using functions like Disp and Output, and the graph screen, using Text, as well as the drawing functions, stored pictures, and pxl and pt functions. I'm not sure about how to check the text out put screen for the presence of an object on the screen, but the graph function has the Pxl-Test function:
:Pxl-Test(y,x)
Someone else may have know how to check for something on the text screen, but I suggest switching to the graph screen to make use of this function.
If you are going to switch to using the graph output here are some things to note:
The text function is
:Text(row,col,output)
Row and col are switched from the Output function
Rows and cols are measured in pixels on the screen, as opposed to the space it takes to type a letter
Most letters are 3 pixels wide, spaces are 1 pixel wide, so it will take multiple spaces to clear out an unwanted character
You may need to disable the graph axis (FORMAT menu), the y-functions (VARS menu, then right to Y-VARS), and the stat-plots (STAT PLOT menu) in the begging of the program then restore them at the end.
One last not on using the Pxl-Test function is that it tests a group of pixels, while a letter. For now let's pretend you only use Rs and an X in your program (I don't know if you do or don't), so you should test a spot on that character that is relatively unique to that character.
Good luck!
Related
I'm making a Create-a-Character.One of the features is being able to adjust a facial feature’s placement.E.g. can move the nose up or down
(Through arrow buttons, example: 1 click on up button, move nose up by a little bit.)
But obviously I don't want the eyes or nose or lips floating outside the face or a nose ending up on a forehead that would be strange lol.
So how do I code so that the user can only move a movieclip a set amount of times in the chosen direction?
If you use just arrow buttons to move objects, it is very easy. Once a button is clicked, check object's position and move it if needed. Basic example:
// if arrow up clicked
if (nose.y > 100)
{nose.y -= 2}
// if down arrow clicked
if (nose.y < 140)
{nose.y += 2}
It's same for x axis and obviously, numbers 100 and 140 can be anything you want. It means, move objects just between these points.
User 987 answer is correct, however if your button moves the object at a faster pace say +-5, setting +-2 to the offset might not put it back in the boundary. It will correct itself by +-2 every frame there after, not accounting for if the user continues to hold down the button to try and exceed the boundary further. The nose will continue to glide further away.
The better way to implement this is to immediately set the nose back to the edge of the boundary.
if (nose.y > 140) {
nose.y = 140;
}
I have gone through a couple of YOLO tutorials but I am finding it some what hard to figure if the Anchor boxes for each cell the image is to be divided into is predetermined. In one of the guides I went through, The image was divided into 13x13 cells and it stated each cell predicts 5 anchor boxes(bigger than it, ok here's my first problem because it also says it would first detect what object is present in the small cell before the prediction of the boxes).
How can the small cell predict anchor boxes for an object bigger than it. Also it's said that each cell classifies before predicting its anchor boxes how can the small cell classify the right object in it without querying neighbouring cells if only a small part of the object falls within the cell
E.g. say one of the 13 cells contains only the white pocket part of a man wearing a T-shirt how can that cell classify correctly that a man is present without being linked to its neighbouring cells? with a normal CNN when trying to localize a single object I know the bounding box prediction relates to the whole image so at least I can say the network has an idea of what's going on everywhere on the image before deciding where the box should be.
PS: What I currently think of how the YOLO works is basically each cell is assigned predetermined anchor boxes with a classifier at each end before the boxes with the highest scores for each class is then selected but I am sure it doesn't add up somewhere.
UPDATE: Made a mistake with this question, it should have been about how regular bounding boxes were decided rather than anchor/prior boxes. So I am marking #craq's answer as correct because that's how anchor boxes are decided according to the YOLO v2 paper
I think there are two questions here. Firstly, the one in the title, asking where the anchors come from. Secondly, how anchors are assigned to objects. I'll try to answer both.
Anchors are determined by a k-means procedure, looking at all the bounding boxes in your dataset. If you're looking at vehicles, the ones you see from the side will have an aspect ratio of about 2:1 (width = 2*height). The ones viewed from in front will be roughly square, 1:1. If your dataset includes people, the aspect ratio might be 1:3. Foreground objects will be large, background objects will be small. The k-means routine will figure out a selection of anchors that represent your dataset. k=5 for yolov3, but there are different numbers of anchors for each YOLO version.
It's useful to have anchors that represent your dataset, because YOLO learns how to make small adjustments to the anchor boxes in order to create an accurate bounding box for your object. YOLO can learn small adjustments better/easier than large ones.
The assignment problem is trickier. As I understand it, part of the training process is for YOLO to learn which anchors to use for which object. So the "assignment" isn't deterministic like it might be for the Hungarian algorithm. Because of this, in general, multiple anchors will detect each object, and you need to do non-max-suppression afterwards in order to pick the "best" one (i.e. highest confidence).
There are a couple of points that I needed to understand before I came to grips with anchors:
Anchors can be any size, so they can extend beyond the boundaries of
the 13x13 grid cells. They have to be, in order to detect large
objects.
Anchors only enter in the final layers of YOLO. YOLO's neural network makes 13x13x5=845 predictions (assuming a 13x13 grid and 5 anchors). The predictions are interpreted as offsets to anchors from which to calculate a bounding box. (The predictions also include a confidence/objectness score and a class label.)
YOLO's loss function compares each object in the ground truth with one anchor. It picks the anchor (before any offsets) with highest IoU compared to the ground truth. Then the predictions are added as offsets to the anchor. All other anchors are designated as background.
If anchors which have been assigned to objects have high IoU, their loss is small. Anchors which have not been assigned to objects should predict background by setting confidence close to zero. The final loss function is a combination from all anchors. Since YOLO tries to minimise its overall loss function, the anchor closest to ground truth gets trained to recognise the object, and the other anchors get trained to ignore it.
The following pages helped my understanding of YOLO's anchors:
https://medium.com/#vivek.yadav/part-1-generating-anchor-boxes-for-yolo-like-network-for-vehicle-detection-using-kitti-dataset-b2fe033e5807
https://github.com/pjreddie/darknet/issues/568
I think that your statement about the number of predictions of the network could be misleading. Assuming a 13 x 13 grid and 5 anchor boxes the output of the network has, as I understand it, the following shape: 13 x 13 x 5 x (2+2+nbOfClasses)
13 x 13: the grid
x 5: the anchors
x (2+2+nbOfClasses): (x, y)-coordinates of the center of the bounding box (in the coordinate system of each cell), (h, w)-deviation of the bounding box (deviation to the prior anchor boxes) and a softmax activated class vector indicating a probability for each class.
If you want to have more information about the determination of the anchor priors you can take a look at the original paper in the arxiv: https://arxiv.org/pdf/1612.08242.pdf.
i wanted to make a turn based system like final fantasy tactics. I already created the map, which is 5x5 tiles grid and the characters which is each character places in the end of the tiles. I have 2 teams, which are named Red and Yellow.
------Red-------:
First character is at 0,0. Second character is at 0,1. Third character is at0.2, fourth character is at0.3, and the last one is at0.4`.
-----Yellow------:
First character is at 5.0. Second character is at 5.1. Third character is at 5.2, fourth character is at 5.3, and the last one is at 5.4.
I wanted Red team are moving first and make a decision (whether it is attack or wait), and after 5 characters of the Red team is already made a decision, the Yellow team is the one that make a decision (Yellow team is an AI)
But, i don't know how to move my characters into the next grid (e.g: from 0,0 to 0,1) by clicking the left mouse button and also how do i display a grid (when select a move selection) that shows how many tiles that the character able to move.
Anyone know about this? or how should i know more about this? is there any recommendations books or webs?
You have your basic data structures set up, but now you need to get some higher level code to manipulate that data.
First of all, I think you should work on selecting locations on the grid with the mouse. Once you can click and get that grid coordinate saved to a variable, you need to set up a function to move your characters. After the first click (on a character), you need to check the valid moves, and for each valid move, you need to render an image on the grid square (or highlight the square's texture).
Secondly, you need a function which iterates through all the characters in each team, according to who moves next. When you have gone through Red.length (red is an array consisting of each player), then you switch to counting through Yellow.length, and running the AI for each character. If you are trying to make a two player game, you instead ask for user input a second time for the yellow team.
I recommend that you learn about how to display your grid and set up a simple way to highlight squares on the grid. After that, you need to convert mouse coordinates into grid coordinates. Your teams should each be an array of characters. I'm not familiar with actionscript, but in the languages I know, they would look like this:
team[6] = {Character1, Character2, Character3... }
Character1.position = {x, y}
running a turn would be something like this:
while battle == not finished {
for (i = 0; i < red.length; i++) {
getInput();
move(red[i], newX, newY); //red[i].position = {newX, newY}
}
for (i = 0; i < yellow.length; i++) {
runAI();
move(yellow[i], newX, newY);
}
}
The hardest part will be the mouse selection and drawing the grid/characters. Graphics are always a nuisance. The data itself just takes a bit of thinking. Your question in particular seems to be about game programming. My advice is to make the grid, then figure out how to display the grid. Then get mouse input. Finally, worry about moving the characters and highlighting squares.
I have a car object, and I want it to gradually rotate to the direction where the user clicked.
Every frame I did math to calculate the new direction it needs, and it's stored at car.direction. The actual direction is of course in car.rotation.
Now I want to update the rotation every frame until it's equal to the direction. However I tried everything and can't figure out how to do that.
By the way, I'm using FireFly, that is a gameengine built on top of Starling Framework, But I don't think it's relevant.
I would go with Marty's suggestion, use the smallestAngle function to determine which direction you should be rotating. Basically you can move some percentage of the smallestAngle during every frame update until the percentage of that smallestAngle is below some threshold (and have it "snap" the rest of the way).
Something like
//each time this is called it will get 1/4 closer, but never get to 0, hence the need for a threshold avoid paradoxes
//http://en.wikipedia.org/wiki/Zeno's_paradoxes#Dichotomy_paradox
var angleToMove:Number = smallestAngle()/4; //the divide by 4 here means get 1/4 of the angle gap closer each time this function is called, I assume this is on a timer or frame handler, making the 4 greater will make it follow more slowly, making it lower will make it follow more quickly, never reduce to or below 0 unless you want wonkiness
if(angleToMove<someRadianThreshold)
angleToMove = smallestAngle();
//use angleToMove to adjust the current heading/rotation
I'm drawing rectangles at random positions on the stage, and I don't want them to overlap.
So for each rectangle, I need to find a blank area to place it.
I've thought about trying a random position, verify if it is free with
private function containsRect(r:Rectangle):Boolean {
var free:Boolean = true;
for (var i:int = 0; i < numChildren; i++)
free &&= getChildAt(i).getBounds(this).containsRect(r);
return free;
}
and in case it returns false, to try with another random position.
The problem is that if there is no free space, I'll be stuck trying random positions forever.
There is an elegant solution to this?
Let S be the area of the stage. Let A be the area of the smallest rectangle we want to draw. Let N = S/A
One possible deterministic approach:
When you draw a rectangle on an empty stage, this divides the stage into at most 4 regions that can fit your next rectangle. When you draw your next rectangle, one or two regions are split into at most 4 sub-regions (each) that can fit a rectangle, etc. You will never create more than N regions, where S is the area of your stage, and A is the area of your smallest rectangle. Keep a list of regions (unsorted is fine), each represented by its four corner points, and each labeled with its area, and use weighted-by-area reservoir sampling with a reservoir size of 1 to select a region with probability proportional to its area in at most one pass through the list. Then place a rectangle at a random location in that region. (Select a random point from bottom left portion of the region that allows you to draw a rectangle with that point as its bottom left corner without hitting the top or right wall.)
If you are not starting from a blank stage then just build your list of available regions in O(N) (by re-drawing all the existing rectangles on a blank stage in any order, for example) before searching for your first point to draw a new rectangle.
Note: You can change your reservoir size to k to select the next k rectangles all in one step.
Note 2: You could alternatively store available regions in a tree with each edge weight equaling the sum of areas of the regions in the sub-tree over the area of the stage. Then to select a region in O(logN) we recursively select the root with probability area of root region / S, or each subtree with probability edge weight / S. Updating weights when re-balancing the tree will be annoying, though.
Runtime: O(N)
Space: O(N)
One possible randomized approach:
Select a point at random on the stage. If you can draw one or more rectangles that contain the point (not just one that has the point as its bottom left corner), then return a randomly positioned rectangle that contains the point. It is possible to position the rectangle without bias with some subtleties, but I will leave this to you.
At worst there is one space exactly big enough for our rectangle and the rest of the stage is filled. So this approach succeeds with probability > 1/N, or fails with probability < 1-1/N. Repeat N times. We now fail with probability < (1-1/N)^N < 1/e. By fail we mean that there is a space for our rectangle, but we did not find it. By succeed we mean we found a space if one existed. To achieve a reasonable probability of success we repeat either Nlog(N) times for 1/N probability of failure, or N² times for 1/e^N probability of failure.
Summary: Try random points until we find a space, stopping after NlogN (or N²) tries, in which case we can be confident that no space exists.
Runtime: O(NlogN) for high probability of success, O(N²) for very high probability of success
Space: O(1)
You can simplify things with a transformation. If you're looking for a valid place to put your LxH rectangle, you can instead grow all of the previous rectangles L units to the right, and H units down, and then search for a single point that doesn't intersect any of those. This point will be the lower-right corner of a valid place to put your new rectangle.
Next apply a scan-line sweep algorithm to find areas not covered by any rectangle. If you want a uniform distribution, you should choose a random y-coordinate (assuming you sweep down) weighted by free area distribution. Then choose a random x-coordinate uniformly from the open segments in the scan line you've selected.
I'm not sure how elegant this would be, but you could set up a maximum number of attempts. Maybe 100?
Sure you might still have some space available, but you could trigger the "finish" event anyway. It would be like when tween libraries snap an object to the destination point just because it's "close enough".
HTH
One possible check you could make to determine if there was enough space, would be to check how much area the current set of rectangels are taking up. If the amount of area left over is less than the area of the new rectangle then you can immediately give up and bail out. I don't know what information you have available to you, or whether the rectangles are being laid down in a regular pattern but if so you may be able to vary the check to see if there is obviously not enough space available.
This may not be the most appropriate method for you, but it was the first thing that popped into my head!
Assuming you define the dimensions of the rectangle before trying to draw it, I think something like this might work:
Establish a grid of possible centre points across the stage for the candidate rectangle. So for a 6x4 rectangle your first point would be at (3, 2), then (3 + 6 * x, 2 + 4 * y). If you can draw a rectangle between the four adjacent points then a possible space exists.
for (x = 0, x < stage.size / rect.width - 1, x++)
for (y = 0, y < stage.size / rect.height - 1, y++)
if can_draw_rectangle_at([x,y], [x+rect.width, y+rect.height])
return true;
This doesn't tell you where you can draw it (although it should be possible to build a list of the possible drawing areas), just that you can.
I think that the only efficient way to do this with what you have is to maintain a 2D boolean array of open locations. Have the array of sufficient size such that the drawing positions still appear random.
When you draw a new rectangle, zero out the corresponding rectangular piece of the array. Then checking for a free area is constant^H^H^H^H^H^H^H time. Oops, that means a lookup is O(nm) time, where n is the length, m is the width. There must be a range based solution, argh.
Edit2: Apparently the answer is here but in my opinion this might be a bit much to implement on Actionscript, especially if you are not keen on the geometry.
Here's the algorithm I'd use
Put down N number of random points, where N is the number of rectangles you want
iteratively increase the dimensions of rectangles created at each point N until they touch another rectangle.
You can constrain the way that the initial points are put down if you want to have a minimum allowable rectangle size.
If you want all the space covered with rectangles, you can then incrementally add random points to the remaining "free" space until there is no area left uncovered.