• entries
743
1924
• views
584204

# No screenshots

127 views

Finally got the polygon map editor to the point where I can go back to working on the game.

Have thought of a problem though - I wanted to have a parallax scrolling backdrop like in my 2D platformers. Now, the way I did this in Orc and Udo was to rendering a big quad with a repeating texture before blitting the map, offset by a scaled version of the world co-ordinates, but resetting the offset once it passed the relevant threshold.

Because this project rotates the entire world in the view, to create the same effect is going to require rendering a quad large enough to work at any rotation as well.

Haven't quite got all this figured out in my head yet, so going to leave it for now.

(EDIT - Got parallax scrolling working and yes, I did have to draw a very big quad)

First plan is to create a class to handle the map elements. I need to sort the map elements by texture, then have a system a bit like ID3DXMesh, whereby it stores the extents of each section so I can add each subset into one vertex buffer in one go and only render it once I need to change the texture.

I figure that sorting by texture is a pretty trivial startup operation that is better done in game rather than in the editor.

Really quite tired. Can't see me getting much of this done tonight. Day off tomorrow though so should make some reasonable progress then.

[EDIT] Couldn't be arsed with setting up subset information - don't really need to anyway. Just passing the graphics object and the vector of textures into the MapList Render method, then doing:

void MapList::Render(GraphicsDevice &Graphics,safe_vector &Tex){    if(Bv.size()==0) return;    int I=0;    int T=Bv[0].Texture;    while(I        {        VertexBuffer V;        while(I.Texture==T)            {            Bv.AddToVertexBuffer(V); ++I;            }			        Graphics.SetTexture(Tex[T]);        Graphics.RenderTriangleList(V);		        if(I.Texture;        }}

safe_vector<> is just a wrapper around std::vector that throws my game's own Exception class on subscript out of range.

All the error reporting is now being done via exceptions, which is a lot better.

I thought the other day that I had found a really nice idea by making the Engine class's constructor acquire the Direct3D device, and its destructor release it, so my WinMain looked a bit like:

try{    Engine E;    while(MessageLoop)        {        E.Update();        }}catch(Exception &E){    ShowError();}

or whatever, but the problem was that I need to somehow access the Engine instance inside the WndProc, or rather the functions the WndProc calls, in order to tell the Engine instance about keypresses and so on.

Only three solutions I could find were to (1) have a global pointer to the Engine (global in main.cpp that is), that is assigned when the Engine is created and set to NULL when the engine is released, (2) use the above pointer and new and delete the Engine and deal with it through a pointer throughout main.cpp or (3) to encode a pointer to the Engine instance to the window with SetWindowLong(WL_USERDATA).

All three seemed (to me) far more messy than just having a "global" (as in, static in main.cpp only) instance of the Engine and manual Acquire() and Release() methods.

I'd be interested to hear if anyone else has come up against this, and any better design solutions they have come up with.

[EDIT AGAIN]

Given my recent state of mind, I thought I should post a screenshot to prove that I am actually doing something and not just rambling.

The above shows a map designed in the polygon map editor and displayed, at an arbitrary position and rotation, in the actual game. If you squint really hard, you can just about see the stardrop backdrop, which is a 512x512 texture that wraps around in all directions, no matter how far you scroll.

All the triangles that share the same texture are rendered in one call to DrawPrimitiveUP(). Next step is probably to convert the VertexBuffer class to actually use a proper vertex buffer.

Question - if I am regenerating all the vertex info every frame, is there any advantage to using a real vertex buffer rather than using a std::vector and DrawPrimitiveUP()?

To those of you still reading - thank you.

[EDIT] Here's the screenshot with a bit more visible backdrop texture, since you really can't see the stars in the one above once it's shrunk to 800x600:

Now I need to go away for a while. Pleased to have got the two-layer scrolling working though, since I was quite worried about that.

Hey.

With regards to the DrawPrimitiveUP stuff: unless you're changing the vertex info every frame, I would suggest using a vertex buffer. Depending on the usage settings you give it, typically a vertex buffer just sits in video memory and you can say: "draw triangles starting from this index" and it'll just be able to do it. Whereas, with DrawPrimitiveUP you have to say: "copy these triangles from RAM to video-memory and then draw them". Definitely slower. If your geometry is very dynamic, you might as well be using a dynamic vertex buffer or DrawPrimitiveUP as the data has to be copied to video-RAM anyway.

Looking good, EC. I'm eager to see what direction the game itself goes in -- did you already tell us what type of game it will be?

Quote:
 Original post by LachlanL Hey. With regards to the DrawPrimitiveUP stuff: unless you're changing the vertex info every frame, I would suggest using a vertex buffer. Depending on the usage settings you give it, typically a vertex buffer just sits in video memory and you can say: "draw triangles starting from this index" and it'll just be able to do it. Whereas, with DrawPrimitiveUP you have to say: "copy these triangles from RAM to video-memory and then draw them". Definitely slower. If your geometry is very dynamic, you might as well be using a dynamic vertex buffer or DrawPrimitiveUP as the data has to be copied to video-RAM anyway.

That's what I figured. I guess I could put the map geometry in a proper vertex buffer and transform and rotate it using matrices, but I haven't really figured that bit out yet.

I guess it isn't too difficult with the help of d3dx, so perhaps have a try at that later.

Quote:
 Original post by HopeDagger Looking good, EC. I'm eager to see what direction the game itself goes in -- did you already tell us what type of game it will be?

Not 100% sure yet, but I'm thinking about a sort of cross between a spaceship shoot-em-up and a game of pool. Got proper physics working in terms of stuff bouncing off each other (all thanks to Oliii's tutorials), so whatever the end result, it will probably be based around that in some way.

## Create an account

Register a new account