I'm making a game which basically is to move a truck with furniture to the destination. I'm using Phaser with P2 engine.
I'm now facing problem with putting the furniture inside the truck. I've tried:
1. Making the truck parent and furniture child(Using addChild()). However, after enabling gravity the furniture just fell without any collision.
2. Setting a rectangle bound, but it collides with the truck.
3. Using PhysicsEditor to hollow out the truck sprite, but it doesn't seem to let me do that.
Now I'm down with one last method which is separate the roof and let the truck become two sprites, but I'm hoping for a better way to do this.
There is another post with the same problem but no answer(Phaser P2 Physics Hollow sprite) so I think I'd try asking again.
Thank you!
Try to make the truck with 2 sprites one for the "backrground" and one for the "edges" when you move the truck you move both sprites at the same time.
Then you make your colision between the furnitures and the edges of the truck.
I did something like that a while ago with the ARCADE engine and it worked fine.
My friend and I found a bypass without any coding. We cut a 1px hole in the truck and used PhysicsEditor to "hollow" out the truck. Since it's only 1px we think not many people will notice it. Still, it is only a temporary solution.
Below is a graph for demonstration:
Related
So I've started development on a rouge-like platformer. It would be difficult to explain exactly what it's like, but that doesn't matter. What does matter is how many sprites I need.
I have 4 classes and 4 races. (As of now, may add more later) Thief, Warrior, Wizard, and Archer. They all have different suits. As for race; Human, Elven, Reptillian, and Dwarven. Since the player can choose their race and class, do I need to make a sprite of every movement option for every combination of these? That would equal up to 16 different sprites. But since I'm adding movement, jumping, attacking, etc... Ugh I'm getting a headache just thinking about it, Help please?
you can do this with skeletal animation sprites.
You need to have a body sprite for each class and each race, but you can have a bone, and split the bone from bodies. Then you animate the bone, and allocate the proper body to it.
means that you design a run animation for bone, then when you need to play animation for any class and race, just apply the bone to specific sprites.
see this.
You will have to do a lot of drawing anyway, but what you can do is separate the classes and the races from the different movements. For exemple, draw a body without any outfit and any race specific attribut (assuming the dwarf and the elven have the same body size... ). Draw this body in all the positions you want. Then draw sprites with the only the heads of every characters, and then the outfits without anything int them.
Then, for each character, in the draw event, draw the standard body, then the character specific head, then the outfit.
The trick is to draw your body animations in such a way that the outfit and the head stay approximately the same during the movements, and the body does all the moving.
But in the end, all depends on the style you want. I would recommend my solution if you do some pixel art. Otherwise, if your characters are very detailed, you may want to use the skeletal animations as Ali Bahrami suggested.
i recommend creating a basic sprite for each race and then copying it and just adding the appropriate clothing / armour for each class.
I have a player and a coin. The coin moves towards the player at 400 per pixel, when it collides with the player the player is thrown back. How can I make the player stand still as if nothing had occurred? I tried setting immovable property to player but no result.
Sounds like you want game.physics.arcade.overlap instead of collide. collide will try and separate your sprites; overlap will just let you know that they touched. If you don't do anything in your overlap callback then the sprites will pass right through each other.
I use overlap a lot more than I use collide.
I'm writing a game in wich the user is having a spaceship and need to "kill" some enemeis that wiil try to kill him back.
I have a "Texture 2d" for the user's spaceship picture,a bullet picture and an enemy picture.
I would like to know,after the user has shoot the bullet to the enemy,how can I check that the bullet has hurts the enemy?
In other words - what function checks that one picture is "covering" (even partial) another one?
Thnx!
:-)
Please have a look into the topic "2D Collision Detection". As you are using XNA the following site should give you a good start:
http://www.progware.org/Blog/post/XNA-2D-Basic-Collision-Detection.aspx
Basically you need to detect when two non-transparent pixels are overlapping, but to prevent unnecessary calculations, you first check if the bounding box for your ship and the enemy ships is even overlapping (since the pixels won't overlap if the bounding boxes don't).
Riemers.net has a good tutorial. Here's a good sample project on per-pixel collision detection from the app hub.
I'm unaware of any pre-existing API functions that do this, but implementing it yourself will be a good exercise.
You should know the x/y coordinates of each of your picture's origins. You should also know the dimensions of each picture.
You can calculate the bounding box of a picture, and whether there exist any points in common.
I'm wondering about how the NES displays its graphical muscle. I've researched stuff online and read through it, but I'm wondering about one last thing: Nametables.
Basically, from what I've read, each 8x8 block in a NES nametable points to a location in the pattern table, which holds graphic memory. In addition, the nametable also has an attribute table which sets a certain color palette for each 16x16 block. They're linked up together like this:
(assuming 16 8x8 blocks)
Nametable, with A B C D = pointers to sprite data:
ABBB
CDCC
DDDD
DDDD
Attribute table, with 1 2 3 = pointers to color palette data, with < referencing value to the left, ^ above, and ' to the left and above:
1<2<
^'^'
3<3<
^'^'
So, in the example above, the blocks would be colored as so
1A 1B 2B 2B
1C 1D 2C 2C
3D 3D 3D 3D
3D 3D 3D 3D
Now, if I have this on a fixed screen - it works great! Because the NES resolution is 256x240 pixels. Now, how do these tables get adjusted for scrolling?
Because Nametable 0 can scroll into Nametable 1, and if you keep scrolling Nametable 0 will wrap around again. That I get. But what I don't get is how to scroll the attribute table wraps around as well. From what I've read online, the 16x16 blocks it assigns attributes for will cause color distortions on the edge tiles of the screen (as seen when you scroll left to right and vice-versa in SMB3).
The concern I have is that I understand how to scroll the nametables, but how do you scroll the attribute table? For intsance, if I have a green block on the left side of the screen, moving the screen to right should in theory cause the tiles to the right to be green as well until they move more into frame, to which they'll revert to their normal colors.
~~~~EDIT:
I do want to point out that I know about the scanlines, X and Y. This thought just ran through my mind.
Let's say I'm at scanline Y of 10. That means I'm reading 10 values into my nametables, horizontally. That would mean my first column is off of the screen, as it only has pixel width of 8. However, the color attribute stays, since it has width of 16.
Assuming the color attribute for the entire column is green, would I be correct in assuming that to the user, the first 6 pixels on the left of the screen would be colored green, and the rightmost 10 on the screen should be green as well?
So, would I be correct in my assumption that according to the screen, the left?
This site I'm sure you are already very, very familiar with. I will preface this by saying I never got to program for the NES, but I am very experienced with all the Gameboy hardware that was ever released and the NES shares many, ahh quirks with the GB/DMG. I going to bet that you either need to do one of a few things:
Don't scroll the attribute table. Make sure that your levels all have similiar color blocks along the direction you are moving. I'd guess that many first generation games did this.
Go ahead and allow limited attribute scrolling - just make sure that the areas where the changes are occuring are either partially color shared or sparce enough that the change isn't going to be noticable.
Get out your old skool atari 2600 timer and time a write to register $2006 in the end of HBlank update to get the color swap you need done, wait a few tics, then revert during the HBlank return period so that the left edge of the next line isn't affected. I have a feeling this is the solution used most often, but without a really good emulator and patience, it will be a pain in the butt. It will also eat a bit into your overall CPU usage as you have to wait around in interrupts on multiple scan lines to get your effect done.
I wish I had a more concrete answer for you, but this hopefully helps a bit. Thanks goodness the GB/DMG had a slightly more advanced scrolling system. :)
Both Super Mario Bros. 3 and Kirby's Adventure display coloring artifacts on the edge of the screen when you scroll. I believe both games set the bit that blanks the left 8 pixels of the screen, so 0-8 pixels will be affected on any one frame.
If I remember correctly, Kirby's Adventure always tries to put the color-glitched columns on the side of the screen that is scrolling off to make it less noticeable. I don't think these artifacts are preventable without switching to vertical mirroring, which introduces difficulties of its own.
Disclaimer: it's been like five years since I wrote any NES code.
Each nametable has its own attribute table, so there should be no graphical artifacts when scrolling from one nametable to another. The type of color glitching you are referring to is really only an issue if your game scrolls both vertically and horizontally. You only have two nametables, so scrolling both ways requires you to cannibalize the visible screen. There are various solutions to this problem, a great summary of which can be found in this nesdev post:
http://nesdev.parodius.com/bbs/viewtopic.php?p=58509#58509
This site may be of some help.
http://www.games4nintendo.com/nes/faq.php#4
(Search for "What's up with $2005/2006?" and begin reading around that area.)
It basically looks like its impossible to get it pixel perfect, however those are going to be the bits you're probably going to need to look into.
Wish I could be more help.
Each nametable has its own attribute table. If you limit your game world to just two screens, you'll only need to write the nametables and attribute tables once. The hard part comes when you try to make worlds larger than two screens. Super Mario Bros. 1 did this by scrolling to the right, wrapping around as necessary, and rendering the level one column of blocks at a time (16 pixels) just before that column came into view. I don't know how one would code this efficiently (keep in mind you only have a millisecond of vblank time).
I'm moving a character (ellipsoid) around in my physics engine. The movement must be constrained by the static geometry, but should slide on the edges, so it won't be stuck.
My current approach is to move it a little and then push it back out of the geometry. It seems to work, but I think it's mostly because of luck. I fear there must be some corner cases where this method will go haywire. For example a sharp corner where two walls keeps pushing the character into each other.
How would a "state of the art" game engine solve this?
Consider using a 3rd party physics library such as Chipmunk-physics or Box2D. When it comes to game physics, anything beyond the most basic stuff can be quite complex, and there's no need to reinvent the wheel.
Usually the problem you mention is solved by determining the amount of overlap, contact points and surface normals (e.g., by using separating-axis theorem). Then impulses are calculated and applied, which change object velocities, so that in the next iteration the objects are moved apart in a physically realistic way.
I have not developed a state of the art game engine, but I once wrote a racing game where collision was simply handled by reversing the simulation time and calculate where the edge was crossed. Then the car was allowed to bounce back into the game field. The penalty was that the controls was disabled until the car stopped.
So my suggestion is that you run your physics engine to calculate exactly where the edge is hit (it might need some non-linear equation solving approach), then you change your velocity vector to either bounce off or follow the edge.
In the case of protecting against corner cases, one could always keep a history of the last valid position within the game and state of the physics engine. If the game gets stuck, the simulation can be restarted from that point but with a different condition (say by adding some randomization to the internal parameters).