• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Buckeye

Points drawn with DrawPrimitive shaped by aspect ratio of view window

5 posts in this topic

When points are drawn via the device pipline [DrawPrimitive(D3DPT_POINTLIST, ...)] in a swapchain, the shape of the point takes a shape (rectangular vs square) according to the aspect ratio of the swapchain view window. Other shapes drawn via the pipleline (mesh->DrawSubset) and via a shader (effect) appear correctly. The points exhibit that behavior whether drawn in pixels or world units.

 

In the image below, all three views are separate swapchain child windows of the main window. Note the sphere (ID3DXMesh) is not distorted (nor are other objects). The points, as can be seen, seem to appear with the aspect ratio of the view window. Shown here, the points are being drawn in world units.

 

point_display.png

 

Also shown in wireframe fillmode, the appearance is the same in solidfill.

 

As I'm (unsuccessfully) trying to figure out mesh picking in swapchain views, it appears that the points, when being rendered, are affected by the aspect ratio of the window associated with the swapchain, whereas other objects are not.

 

If it's important: I've tried it with hardware and software vertex processing, and with swapeffect = discard and  = copy.

 

Anyone have an explanation? Is this a bug perhaps?

 

0

Share this post


Link to post
Share on other sites

In D3D, the viewport coordinates range is -1...1, regardless of the render target dimensions.

 

"Normal objects" usually compensate for this by scaling their perspective transform to match the aspect ratio.

0

Share this post


Link to post
Share on other sites

I'm not sure what you're saying with regard to points rendering. Could you clarify, please? Or are you saying that points are not "normal" objects?

 

Also, you say "objects" compensate for the aspect ratio. Do you just mean the aspect ratio is set by the current projection transform set for the pipeline, shaders, etc.? That's done, of course. For each swapchain, the projection matrix is setup with an aspect ratio of the render window client and is used by the pipeline and shaders. Although not shown in the image I posted, the same phenomenon occurs when the view matrix is also the same.

Edited by Buckeye
0

Share this post


Link to post
Share on other sites
Actually, the D3D 9 viewport is in pixel-space (well, x and y at least). Normalized device coordinates are in [-1..1] (and [0..1] for z). But yes, aspect ratio is handled with the projection.
 
Point sprites ? I hear they have sometimes driver issues. Though you already checked software vertex processing, also try the reference device.
 
I'm concerned about that wireframe rendering though. Shouldn't the lines be continuous ? It really looks like you (still) have a rendertarget/window size mismatch (which then causes the squash of the points, too) ? I recommend doing (again) what Tispe recommended earlier, i.e. checking all relevant size information: client area, swapchain size, viewport, projection aspect ratio, Present parameters (if you're still using custom rectangles). Best dump it as text in every window and watch it live.
 
Or post your rendering code, maybe I see something.
1

Share this post


Link to post
Share on other sites

@unbird - once again, you pointed out something that pointed to the resolution of the problem - the difference between the wireframe renderings. Turns out the problem was a combination of the viewport settings, projection matrix and the rectangles used by swapchain->Present all having to be set correctly (which I did not).

The app now displays correctly. For each window/swapchain pair:

1. get and set the swapchain backbuffer as the rendertarget

2. set the viewport to the window client size (cRect)

3. set the perspective projection matrix with the aspect of the window client size (use cRect)

4. set the view matrix as desired

(Render stuff with the device)

5. swapChain->Present(&cRect, NULL, handleChildWnd, NULL, 0); // cRect is same client rect used for setting the viewport

6. release the backbuffer

The problem arose simply because I did not match the viewport rectangle and the source rectangle in the Present call.

By the way, the swapchain backbuffer sizes (rendertargets) are always the size of the main window client, from which the device was made. So only if there is one child window the size of the main window client will the backbuffer size be the same as the child window size. I reset the device when the main window is resized with the normal sequence: OnLostDevice(), device->Reset, OnResetDevice. That's to ensure that the buffer size is always large enough for a single child window to render. It's kind of a pain because the swapchains are apparently created in D3DPOOL and all have to be released and recreated.

Now that it's all working, for my purposes, I'm not quite sure what the real benefit of multiple swapchains may be, unless they share a common buffer (?). That would be a memory advantage, I suppose. As you mentioned elsewhere, unbird, it may be possible to use a single swapchain for several windows.


 

1

Share this post


Link to post
Share on other sites

Update - I eliminated the swapchains altogether. For each visible child window, my DrawScene routine sets the viewport size to the size of the child's client rect. The projection is set with the aspect ratio of the child window. After gd3ddevice->EndScene():

 

gd3ddevice->Present( &cRect, &cRect, hChildWnd, 0);

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0