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
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:
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.
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
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.