Tag Info

New answers tagged

0

The sprite sheet that you are using is what is known as a "sprite atlas". I am not sure that Crafty supports them. The current solution is to make even separation between all sprites so that they are in a grid. See: https://groups.google.com/forum/#!topic/craftyjs/eN9KTAxieSI


1

A few things. First, your sprite is 49 pixels in width, not 52. Second, let the sprite size determine the width and height of your player. You don't have to declare it. //.attr({ x: 15, y: ch - 123, w: 52, h: 123 }) .attr({ x: 15, y: ch - 123 }) Third, your animation is smearing. I think it is because you use Crafty.background("#XXX") in Canvas mode. ...


1

Your best bet is to not generate tiles but generate and manage chunks which contain tiles. If you think about chunks as a fundamental part of the design then the issue may go away. I faced a similar issue in 3d with building my voxel engine. You likely want to do something like ... class Map { public Size Size { get { ... } } public ...


1

First off, you should only be applying forces to rigid bodies inside the FixedUpdate method. You'll get more consistent results. If you want objects to move in the direction another object is facing, you need to use transform.forward, not Vector3.forward. Alternatively you can multiply Vector3.forward by the quaternion of the rotation you want to use, like ...


1

There are a few problems here. First, SpriteAnimation has changed. You now need to define an animation reel. //this.animate("run", 1, 1, 4); this.reel("run", 1000, 1, 1, 4); Second, names in javascript and Crafty are case sensitive. //this.bind("enterframe", function () { this.bind("EnterFrame", function () { Third, I fixed a few small problems with ...


5

From a performance standpoint, having data in memory is orders of magnitudes faster than having it in a database. There are two reasons to put data into a database instead of storing it in memory: You have more data than fits into memory You want to make sure no data is lost in case of a (intentional or unintentional) server shutdown As you already said, ...


0

For situations like this where I want an endless map with possibly negative coordinates, I use a hash table instead of an array. In JS, the easiest thing (maybe not the cleanest) is to use an Object: function Map() { var contents = {}; function index(x, y) { return x + "," + y; } function set_map(x, y, value) { ...


0

Most important thing i see about your issue is to keep a good separation of concerns. When you wonder about 'negative array indexes', you have an issue because you mix the concern of knowing where the player is, and the concern of how you build/store your world data ('map'). Have a camera object, that will define what is the center of the current view ...


0

You can build a graph data structure to handle the changes between chunks. Depending on exactly how you want the chunk boundaries to work, you may or may not need to render more than one chunk at a time. Many games have chunk boundary hallways that are Z or other sight-line blocking shapes. These are so that the game can fresh load the next chunk before you ...


2

I doubt the string concatenation is the culprit here, but you could always use the transform CSS property, which is supported in almost every recent browser. Since most CSS transforms also use px values (for example: translate), you should use raw matrix coordinates. So to offset an element by say x: 10px, y: 20px you would use: transform: matrix(1, 0, 0, ...


0

You get those errors because those types (SpriteText.Anchor_Pos and SpriteText.Alignment_Type) don't exist. The correct types are TextAnchor and TextAlignment. static function AlignTxt(obj : GameObject, txtAnchor : TextAnchor, txtAlign : TextAlignment) { obj.GetComponent(SpriteText).anchor = TextAnchor.txtAnchor; ...


1

You need to handle your map in chunks/tiles of fixed size.. and only keep the chunks in the immediate vicinity of your player actually on hand at any moment (out to whatever view distance you feel is reasonable) As the player crosses a chunk boundary, you add new chunks in the direction of movement, remove them behind the player, and keep going. If you are ...


0

The acceleration measures how fast you move the device, not the current position (rotation/tilt). For moving something based in the tilt of the device you need to use the rotation with the device orientation event. For the x axis you would use the gamma data if the device is standing up, and beta if it's in panoramic mode. Then treat it like it was a ...


1

The question appears to be about how to go about selecting the correct tiles after generating a map, so that is what I'll answer. What you are talking about is called "autotiling" or "auto tiling" (depending on who you ask). Here's a simple-ish method for handling that: Given a single tile, we can find it's neighbors. Each tile then has a 4 bit state for ...


0

A common technique is to construct your maps from premade sections of n*n tiles which can fit together in different ways ("super-tiles" if you would like to call them that way). My favorite example for this is the good old X-COM: UFO Defense. They become very visible on the overview map, especially in the "farmland" biomes: When you want your map to be ...


0

For random tile generation, using a cellular automata algorithm is a good approach. http://www.roguebasin.com/index.php?title=Cellular_Automata_Method_for_Generating_Random_Cave-Like_Levels This is a good tutorial on the basic idea. Essentially you have some some random (or noise) function that generates initial tiles. Then the process gradually groups ...


1

Remember that acceleration is a change in velocity. You will want to use the acceleration samples to accumulate in the velocity variable. IE, instead of velocity = acceleration * time try velocity = velocity + acceleration * time


-1

Old hardware had more limits how many uniforms can be allocated. DX10 hardware removed this limit with constant buffers.


0

Iso-tiled maps needs "Z-axis" work, where you must draw from the upper left, moving to the bottom right, as you already know, you must overwrite already existing tiles. Your code right now is a basic work for common 2D tilesets. if (this.orientation == 'isometric') { // Isometric maps drawX = x * (cell.w / 2); drawY = y * (cell.h / 2); } This ...


1

From the screens it's kinda obvious, that your tiles are positioned wrong. So it seems your X axis needs to go from top-left to bottom-right and Y axis from top-right to bottom-left. Right now X goes from left to right and Y from top to bottom. Can you update your code to accommodate for that? Also your spacing between the tiles is too big, but first - ...


11

The "normalized direction vector" is how this task is usually approached, and how I often do it, but lately I've simply been clamping the resulting movement vector. It usually achieves the same end result and the code is a lot simpler: var moveSpeed = 6.0f; function Update() { var movement = Vector3.zero; movement.x = Input.GetAxis("Horizontal") * ...


28

You need to take the sum of the directions, normalize that, then multiply by the speed. I tangentially answered this as part of my response to Preventing diagonal movement Specifically: velX = 0; velY = 0; if(keyLeft) velX += -1; if(keyRight) velX += 1; if(keyUp) velY += -1; if(keyDown) velY += 1; // Normalize to prevent high speed diagonals length = ...


13

Separate your direction selection code from actual movement code. Choose Direction by checking which keys are pressed. Store it as a unit (normalized) vector. Multiply your Direction with Speed and with DeltaTime. Apply resulting transform to your object/camera.



Top 50 recent answers are included