Canvas vs DOM Element game and collision - javascript

So I am trying to make a little game both for practice and fun (first time I have tried) never had anything to do with it before..
You can see what I've tried so far at: http://myfirstgame.e-ddl.com/ been working on it for like 6-8 hours or so. So far and realized I would better ask before going on.
The way I have it now, I have a main loop that runs every 20 milliseconds or so. Ihis loop calls 2 functions:
Handle keystrokes (which iterates through the obstacles array and check if the player's future position collide any obstacle object and change the players' properties to the future position values).
It goes through the "need update" array and change the element's CSS details to reflect the changes made.
I have several questions:
Is the above a good idea to handle collision? if not what would be a better way (I mean at around 800-1500 obstacle objects on map the game slows down).
To calculate distance, I use distance between 2 points equation. If I only have 1 point, angle and distance. How can I find the 2nd point's (x, y)?
What would be better, canvas or DOM ? (not important question as I already have it done with DOM).

Thanks for everyone.
I've found the solution to what i were looking for.
about the collision the way i was doing it was entirely wrong i will list the correct way farther down.
about the distance - the solution i came up with is checking the distance from player's current position to object if player's step is bigger then distance, deduct step from distance and walk that distance.
as for canvas vs dom - seems both has their crons and pros.
Now for the collision
the correct way of doing it is to create a pixel map array. so if your canvas or container node is width:800 by height:500 you'll have a 2d array that represent those pixes
and then when i check for position i simply check if player's current position + steps toward future position has an object.
so like :
if(array[300][500]){
return false;
}
That's what i found out.
If anyone have a better solution then that let me know.

Related

JavaScript - Drawing objects off the screen and other game optimizations

In my game a large map exists, and I am wondering if not drawing shapes (average 250+ at a time) when the player cant see them would make any difference in the game's performance.
Also, every frame I am checking the distance of the player to about 500+ other position vectors (used for enemies, food, bullet interactions), which takes a lot of square rooting. If I make a raw estimate just using the X and Y components combined, would that significantly boost game performance?
The only way to answer these questions is to try it and see what happens. You have to weigh the cost of calculating whether something is on the screen against the cost of drawing it. Again, you're going to have to measure both and decide for yourself.
As for measuring distance, you could try using the distance squared to avoid the square root.
Or you could try storing your objects in a data structure like a quadtree, which allow you to you only check the distance of nearby objects. Or putting it simpler: do you really need all 500 vectors active all of the time? Why not store them and only activate them when you need them?
But again, the only way to answer your question is to try it. We can't tell you whether this will vastly improve performance in your game. Only you can answer that, by trying things out. Good luck.

Should I use ctx.translate for an endless game-map?

Well, just imagine you keep going up but your player stays put in the middle, and as you go up the map generates itself randomly.
With the help of:
ctx.translate(0, 1);
the map moves towards you as you move up.
now, I have a few methods in mind and of them is ctx.translate, but I have a few questions:
1) in the long run, what I fear is that it will keep the memory of the previous drawings once they go out of the canvas borders and eventually the ctx x/y system will go to numbers as high as millions.
2)I need something which is CPU friendly. I am just not sure what ctx.translate does under the hood exactly, does it behave in the likes of ctx.clearRect and then redraws everything?
3) anything better to achieve the same thing will be lovely, I already know about the old clearRect(which is heavy) and redraw method, just looking for other options.
EDIT: the player may change his X coordinate in some position too.

Merge two svg path elements programmatically

I am rendering a map out of SVG paths (using jVectormap).
There are cases where one region has to be merged with the neighboring region.
Unfortunately both regions don't touch each other and I have to interpolate to fill the space in between.
jVectormap uses very simple SVG paths with M to set the the absolute startpoint and l to connect relative points.
Does any of the SVG libraries cover such an operation?
I haven't tried this, but you may get around it by running the converter at jVectormap with the following parameters:
--buffer_distance=0
--where="ISO='region_1' OR ISO='region_2'"
Where region_1 and region_2 are the two regions that you need to merge.
Solving the problem this way also means that the generated SVG paths are true to the original coordinates, whereas a following fix may lead to some (probably minor) inconsistencies.
This might not be the kind of answer you're looking for, but using Raphael.js you could loop over the entire length of the path of one region getPointAtLength(), comparing it with all points of the second region. If the coordinates are closer than n pixels from any coordinates on the second region and the previous coordinates weren't, than that could be regarded a "glue" point. You would then jump to the second regio and start looping over it, if the next point is still closer than n points, than go in the opposite direction, if still closer change direction and go farther along the path till finding a point that's farther away from the original region than n pixels. Continue looping in that direction till once again finding a new "glue" point, where once again you will switch to the original region in the manner described and all points which weren't covered in this final loop could be discarded (or you could simply create a new shape based on the points you came across whilst looping over the length of the original region.
True enough, it's not the easiest script to make, but it should be quite do-able I believe, especially when you can use a function like getPointAtLength to find the points between the defined svg points (though you need to only 'record' the defined points, and that's sort of the hard path as Raphael.js doesn't excitedly have any functions which would help with this, still even that shouldn't be too hard to match up by hand (in code of course)).

Get Second Point By First And Distance

I'm building an online game, and using node and whatnot, anyway i'm not too keen on constant streams and streams of data just for animations, i've set up a way for it to animate client side and so on... but i found a problem, all i was doing was setting the new coordinates and telling all the clients to animate their character to that point, but if you refreshed the page, the player would be there instantly.
I have got a distance,speed of movement,time of movement,start and destination... i know where they started moving, i know where their destination is, i know when they started moving and at what speed, and in a linear fashion.
What i need to work out, is where the player is (whilst animating) at that specific time when other players join the game.
Try http://en.wikipedia.org/wiki/Kinematics
Or http://en.wikipedia.org/wiki/Speed
the distance travelled can be calculated by rearranging the definition to d=v*t
The simplest approach would be to tween the position. That involves creating a series of intermediate steps along the path between the current position and the updated one. This works best if you know the frequency of updates. You can choose these points linearly or use an easing function to smooth it out.
If you really are doing a physical simulation though, it'll probably look more natural if you take the physical model into consideration. I'd try the simple case first before seeing whether you need to go into more mathematically complex territory.

Find valid nodes in a grid based on a X range

I'm having a problem with finding N positions in a grid based on a central point and a max range.
I have this grid, each coordinate in the grid can be either closed or open, I'm tying to, using an open coordinate, find all the open coordinates around the first that are valid and the walk range between then is equal or lower than the max walk range.
At first I tried a solution using A*, where I would select every coordinate in range, check if they were valid, if they were I would call A* from them to the center position and count the number of steps, if they were higher than my max range I would just remove the coordinate from my list. Of course, this is really is slow for ranges higher than 3, or grids with more than just a few coordinates.
Then I tried recursively searching for the coordinates, starting with the central one, expanding and recursively checking for the coordinates validness. That solution proved to be the most effective, except that in my code, each function call was rechecking coordinates that were already checked and returning repeated values. I thought I could just share the 'checked' list between the functions calls, but that just broke my code, since a call was checking a coordinate and closing it even if it still had child nodes but were technically not in range of their center (but were in range of the first center) it would close them and give some weird results.
Finally, my question is, how do I do that? Is my approach wrong? Is there a better way of doing it?
Thanks.
I've implemented something similar once. The simple recursive solution you proposed worked fine for small walk ranges, but execution time spun out of control for larger values ...
I improved this by implementing a variant of Dijkstra's algorithm, which keeps a list of visited nodes as you said. But instead of running a full path search for every coordinate in reach like you did with A*, do the first N iterations of the algorithm if N is your walk range (the gif on Wikipedia might help you understand what I mean). Your list of visited nodes will then be the reachable tiles you're looking for.
http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

Categories

Resources