So basically what I'm trying to do is generate a circle completely out of square tiles in Unity and I am trying to think about the best way mathematically to generate it.
In the end, I want it to look something like:
https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcTHh7I_BURo5qMI73YLZVG6PO4WeFtbT--QL_9qOJovpNaWemar
In this image, the tiles are more rectangular and not all sides are equal, but it gets the point across.
Does anyone know of any mathematical formulas or anything that could be helpful in doing this? I don't necessarily need straight answers (unless you have them :D), but anything to help me along would be appreciated!
Thanks!
Take the starting point (center) and start drawing your first square in the starting direction. Now turn the direction with the Golden ratio: 1.618...
Keep turning this much for every consecutive square you are drawing, every time increasing the distance from the center a little bit.
Apparently sunflowers also grow following this pattern according to this video!
I'm working on a game made in XNA,C# and I want to enable xml based animations.
XML will look like this
<Animation>
<AnimatedObject>
<Filename>Spaceship_Jet_01</Filename>
<Flipped>false</Flipped>
<StartPosition_X>300</StartPosition_X>
<StartPosition_Y>500</StartPosition_Y>
<GOTOPosition_X>650</GOTOPosition_X>
<GOTOPosition_Y>500</GOTOPosition_Y>
<Time>10000</Time>
</AnimatedObject>
</Animation>
This will move an object to the side, like this
http://imm.io/odc7 (sorry the X coordinate is wrong)
I noticed there will be problems, when the players display resolution is different from mine because I enter pixel precise information about where the object comes from and where it has to go.
I thought about a grid so I can tell the programm to move the object from (30,27) to (22,27) e.g.. Is this a good solution? The grid has to be independent from the resolution but the number of tiles has to be constant and I have to draw the object to the screen. That means I have to find the right pixle position of the tile at position (22,27) and then "move" the object to that tile.
Is there a better way to do that? How can I solve this with XNA?
If you use a 2D camera you won't have any problem... because calculating the new view to adapt it to the new resolution is not difficult.... and you have not to change anything of your loads methods nor logic...
You can do, but I don`t like
Work with positions in [0..1] range, is difficult to measure.
Fix the position with the new resolution factor when you load the xml... is ugly...
Pos *= NewResolutionSize/DefaultResolutionSize;
I am making an RPG game using an isometric tile engine that I found here:
http://xnaresources.com/default.asp?page=TUTORIALS
However after completing the tutorial I found myself wanting to do some things with the camera that I am not sure how to do.
Firstly I would like to zoom the camera in more so that it is displaying a 1 to 1 pixel ratio.
Secondly, would it be possible to make this game 2.5d in the way that when the camera moves, the sprite trees and things alike, move properly. By this I mean that the bottom of the sprite is planted while the top moves against the background, making a very 3d like experience. This effect can best be seen in games like diablo 2.
Here is the source code off their website:
http://www.xnaresources.com/downloads/tileengineseries9.zip
Any help would be great, Thanks
Games like Diablo or Sims 1, 2, SimCity 1-3, X-Com 1,2 etc. were actually just 2D games. The 2.5D effect requires that tiles further away are exactly the same size as tiles nearby. Your rotation around these games are restricted to 90 degrees.
How they draw is basically painters algorithm. Drawing what is furthest away first and overdrawing things that are nearer. Diablo is actually pretty simple, it didn't introduce layers or height differences as far as I remember. Just a flat map. So you draw the floor tiles first (in this case back to front isn't too necessary since they are all on the same elevation.) Then drawing back to front the walls, characters effects etc.
Everything in these games were rendered to bitmaps and rendered as bitmaps. Even though their source may have been a 3D textured model.
If you want to add perspective or free rotation then you need everything to be a 3D model. Your rendering will be simpler because depth or render order isn't as critical as you would use z-buffering to solve your issues. The only main issue is to properly render transparent bits in the right order or else you may end up with some odd results. However even if your rendering is simpler, your animation or in memory storage is a bit more difficult. You need to animate 3D models instead of just having an array of bitmaps to do the animation. Selection of items on the screen requires a little more work since position and size of the elements are no longer consistent or easily predictable.
So it depends on which features you want that will dictate which sort of solution you can use. Either way has it's plusses and minuses.
As everyone knows, satellites around the earth don't go in a perfect circle. They are more an elliptical orbit.
I'm trying to represent this using OpenGL to draw an orbit around the earth. Currently, I draw a dashed-line composed of 360 markers which makes a series of dashes around the globe in a nice perfect circle.
If I have the Orbital inclination, Perigee and Apogee what would be the way to calculate this circle? I'm trying to find a formula or white paper or something to get me in the right direction....
What this is crazy, of course they are perfect orbits. No but seriously sounds more like a need Physics formua. Try..
http://scienceworld.wolfram.com/physics/Orbit.html
or
http://physics.info/orbital-mechanics-1/
Don't have really any experience here, but if you plan to actually track satellites you will want to use the Keplerian elements ( http://en.wikipedia.org/wiki/Orbital_elements#Keplerian_elements , http://en.wikipedia.org/wiki/Orbital_elements#Orbit_prediction) which get published for satellites. Note that real satellites have perturbation in their orbits so the Keplerian elements for a satellite are regularly updated. If you just need something that "looks" like satellite orbits then the idealized ellipses form the other answer will be fine.
I am trying to write a custom Minecraft Classic multiplayer client in XNA 4.0, but I am completely stumped when it comes to actually drawing the world in the game. Each block is a cube in 3D space, and it is possible for it to have different textures on each side. I have been reading around the Internet, and found out that for a cube to have a different texture on each side, each face needs its own set of vertices. That makes a total of 24 vertices for each cube, and if you have a world that consists of 64*64*64 cubes (or possibly even more!), that makes a lot of vertices.
In my original code, I split up the texture map I had into separate textures, and applied these before drawing each side of every cube. I was told that this is a very expensive approach, and that I should keep the textures in the same file, and simply use the UV coordinates to map certain subtextures onto the cube. This didn't do much for performance though, since the sheer amount of vertices is simply too much. I was also told to collect the vertices in a VertexBuffer and draw them all at once, but this didn't help much either, and occasionally causes an exception when the number of vertices exceeds the maximum size of the buffer. Any attempt I've tried to make cubes share vertices has also failed, resulting in massive slowdown and glitchy cubes.
I have no idea what to do with this. I am pretty good at programming in general, but any kind of 3D programming or game development completely escapes me.
Here is the method I use to draw the cubes. I have two global lists List<VertexPositionTexture> and List<int>, one for vertices and one for indices. When drawing, I iterate through all of the cubes in the world and do RenderShape on the ones that aren't empty (like Air). The shape class that I have is pasted below. The commented code in the AddVertices method is the attempt to make cubes share vertices. When all of the cubes' vertices have been added to the list, the data is pasted into a VertexBuffer and IndexBuffer, and DrawIndexedPrimitives is called.
To be honest, I am probably doing it completely wrong, but I really have no idea how to do it, and there are no tutorials that actually describe how to draw lots of objects, only extremely simple ones. I had to figure out how to redo the BasicShape to have several textures myself.
The shape:
http://pastebin.com/zNUFPygP
You can get a copy of the code I wrote with a few other devs called TechCraft:
http://techcraft.codeplex.com
Its free and open source. It should show you how to create an engine similar to Minecrafts.
There are a lot of things you can do to speed this up:
What you want to do is bake a region of cubes into a vertex buffer. What I mean by this is to take all of the cubes in a small area, and put them all into one vertex buffer. Only update this buffer when a cube changes.
In a world like minecraft's, LOTS of faces are occluding each other. The biggest thing you can do is to hide faces that are shared between two cubes. Imagine two cubes sitting right next to each other, you don't really need to draw the face in between, since it can never be seen anyway. In our engine, this resulted in 20 times less vertices.
_ _ _ _
|_|_| == |_ _|
As for your textures, it is a good idea, like you said, to use a texture atlas. This greatly reduces your draw calls.
Good luck! And if you feel like cheating, look at Infiniminer. Infiniminer is the game minecraft was based off. It's written in XNA and is open-source!
You need to think about reducing the size of the problem. How can you produce the same image by doing less work?
If your cubes are spaced at regular intervals and are all the same size, you may not need to store the vertices at all - your shader may be able to calculate the vertex positions as it runs. If they are different sizes and not spaced at regular intervals, then you may still be able to use some for onf instancing (where you supply the position and size of a cube to a shader and it works out where to render the vertices to make a cube appear at that location)
If your cubes obscure anything behnd them, then you only need to draw the front-most cubes - anything behind them is just not visible. A natural approach for this would be to use an octree data structure, which divides 3D space into voxels (cubes). Using an octree you could quickly deternine which cubes are visible, and just draw those cubes - so rather than drawing 64x64x64 cubes, you may find you nly have to draw a few hundred per frame. You will also find that as the camera moves, the set of visible cubes will not change much, so you may be able to use this "temporal coherence" to update your data structures to minimise the work that needs to be done to decide which cubes are visible.
I don't think Minecraft draws all the cubes, all the time. Most of them are interior, and you need to draw only those on the surface. So basically, you need an efficient voxel renderer.
I recently wrote an engine to do this in XNA, the technique you want to look into is called hardware instancing and allows you to pass one model into the shader with a stream of world positions to "instance" that model hundreds (even thousands of times) all over your game world.
I built my engine on top of this example, replacing the instanced model with my own.
http://xbox.create.msdn.com/en-US/education/catalog/sample/mesh_instancing
Once you make it into a re-usable class, it and its accompanying shaders become very useful for rendering thousands of pretty much anything you want (bushes, trees, cubes, swarms of birds, etc).
Once you have a base model (could be one face of the block), its mesh will have an associated texture that you can then replace with whatever you want to allow you to dynamically change block texturing for each side and differing types of blocks.