Art based levels using Texture To Vertices

Topics: Developer Forum
Apr 26, 2011 at 10:42 PM

So I used the samples AdvanceDemo1 to play with this idea here of having art based levels using just the Texture to Vertices body but making it static. This "worked" sorta.  To make an interesting level Id need a huge long texture..alas largest texture size is 2048x2048 which on my wide screen is like a screen

and a half in either direction.  So back once again I am at the drawing board.  I tried using the terrainMS but I might run into the same problem as the coordinate systems are the same and not sure how to get the art on the level.  Someone in a previous forum post tried to help posting links to Textures, vertices, texture mapping in XNA but it was difficult to apply those small tutorials to get a full scrolling colliding level working.  I guess im asking now that I know my one path upt he wrong tree was fruitless wondering if there are more concise examples on how to get TerrainMS to produce art based levels?  (and by art based I mean not tile based)

 

Thanks,

Shane

 

 

Apr 27, 2011 at 2:42 PM
Edited Apr 27, 2011 at 2:45 PM

Shane,

 Its good to see you're still trying.  I would like to help point you in the right direction, but don't fully understand what you want to create.   I don't really understand what you mean by art-based.   If you are trying to create a level from an image and then also use that image as the texture by drawing it on to the screen (on top of your physics), I wouldn't recommend that.  I recall saying before that it can be done, but isn't a good idea.  It just isn't practical, and you'll fill up your video memory with those large textures.  It's too limiting.

 

It sounds like you've looked at them but the advanced demo's provide code where they texture the physics objects and it may show you how you could approach the task.

 

The drawing and physics are two different systems and you really should try to separate them in your mind.  

You have a texture you want to use to create your level (the 'level texture').   You will use each pixel to indicate the size and placement of your physics fixtures. This means that a pixel on your level texture doesn't equal a pixel on the screen when you draw.  You may want to ask yourself if creating a level from a texture is necessary and perhaps you could instead use an alternate approach..such as loading from a text or xml file.  Because a texture is just data that is easier to visualize...but a text file can provide the same data and may be easier to organize fixture sizes, shapes, and types.

 

Assuming you have fixtures created from your level data (the level texture), you'll have to save them somewhere.   When saving them you may wish to organize them in a way so that you know what they are supposed to be in your world.  Are they grass sections, platforms, metal boxes?    You could use the pixel color in your level texture to indicate this...or you could specify more directly in enumerations or integers if you are using a text/xml file.

 

So assuming when you created your fixtures you saved what type they were... above I mentioned grass, platforms and metal as examples.  You can iterate through your fixtures and reference that type value... you can use it to draw the appropriate texture to the screen. Use the fixture's position, dimension, and rotation to draw it in the correct shape and angle.  You need to scale the fixture's values you use to world space (Research this on the forum if you don't understand...very important!) so they are visible.  Generally physics space is small and your world space will be larger. 

 

Overall there are many ways to do this... my above mentioned approach is only one way. That's the beauty and horror of programming games.

 

 

Apr 27, 2011 at 2:59 PM
Edited Apr 27, 2011 at 3:00 PM

What I meant by art based was something like a Worms Armageddon level where the levels are continuous etc...

I think I was getting hung up on ridiculous details in my mind.  The point that might of just triggered a light bulb is the part where you said store the fixtures as a text file with a description of their look.  This makes sense to me sort of.  If I have a fixture with say a curve or two in it..and it is supposed to be textured with green grass... then I know when I draw the representation of that fixture in the game I use green grass texture to give it the look I want.  So basically at its base I can define several textures grass rock etc, and give many different fixtures one of those types of textures for when it draws itself.  This way I have a nicely textured and colorized level.  I am thinking this as a Worms style game (what I cannot get sorted out in my mind is a fixture thats textured a finite piece...and many such pieces are put together to form a continuous level with hills and valleys etc..) but instead of a limited play area one that scrolls to the right or whatever the main character goes.  (cause camera is locked to them).

 

Lol so yes still trying at this and being super unsuccessful.  I did see those other links to texturing those polygons etc...just wasn't sure how to apply it to this stuff.  Unless level data is like polygons built up like those demos had it, then marked what texture file is used.  But with that going on sounds much less 2d and more like a 3d game.  But I would love to figure this out, just need a lightbulb or two to go off.

 

Apr 27, 2011 at 5:37 PM

Here's a secret, in modern day directx (and xna) 2d is actually really 3d without the z component.  You are really drawing your sprites and polygons in a 3d world, but just looking at it head on with your camera.   So ya, when you render a polygon to the world, it may require a vector3, but the z value will just always be 0.

 

When you make fixtures you don't want them to be too huge. I don't know what exactly constitutes 'huge', but I recall it being a dimension of 10x10 in physics space.   You will have to define multiple fixtures for your larger pieces of terrain..and than position them next to each other so that when one piece ends the other starts. If you texture correctly you won't see a seam, except if you use different textures for each fixture of course.

 

If you're going to go the text file route it sounds like you'll be starting over on how you get the level data.  If you are going to make non-rectangle fixtures as mentioned above, you most likely won't be able to use spritebatch.draw (if that was your plan).  You'll have to probably define your vertices and then render them as polygons...as mentioned in your other thread.

Just start small, try defining your fixture vertices as constant values in code.  Work on making a simple rectangle fixture and rendering the texture on top of it using vertex buffers.

If you can get that, extend it to render a more complex fixture shape and also adjust your texture coordinates to match.

After that do multiple fixtures and find was to generate your fixtures and vertex buffer(s) procedurally so that when you move on to reading those values form a file, you can just plug in those things.

I wouldn't work on reading a level file until I know I have the upper system complete, because at that point you'll know exactly what it takes to render your level.

Apr 27, 2011 at 5:44 PM

thanks this gives me something to go on.  Generating a fixture proceduerally looks like job one.  Next would be texturing that fixture.   I knew 2d now adays was 3d with no Z component, but up until this here most the libs etc I used worked just like 2d (heres a sprite draw it at pixel x,y), i knew in the background its just texture mapping a quad and letting it rip...how that always did it was beyond what I learned but now looks like I will have to do it.

 

This might be a stupid question, but if I forgo the SpriteBatch.draw and I will have to render mystuff instead as texutre mapped polygons (defining texture coordinates really boggle my mind) then can I still do all this from a public override void Draw() method in xna?

 

Apr 28, 2011 at 1:40 PM

You'll want to create your fixtures, vertex buffers, (and the vertices that go in those buffers) in an initialization function and save that data.  Then yes, in your Draw method you should be able to render your polygons by calling one of the appropriate DrawPrimitive commands from  the Graphics Device.  Those polygon tutorials I linked you to earlier should provide basic examples of rendering polygons and texturing them.