Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


tonemgub

Member Since 21 Oct 2011
Offline Last Active Today, 04:52 AM

#5227097 Very strange behavior at DrawPredicated with Intel GPU

Posted by tonemgub on Today, 03:56 AM

The WARP driver is a software driver, not a hardware one. Are you sure that the Intel System Analyzer tool can monitor software drivers?

 

According to this blog post, occlusion culling should be supported since D3D_FEATURE_LEVEL_9_2: http://blogs.msdn.com/b/chuckw/archive/2012/06/20/direct3d-feature-levels.aspx .

Your Intel 3000 card should support feature 10.1: http://www.cpu-world.com/info/Intel/Features_of_integrated_Intel_HD_graphics_units.html .

 

 

 


maybe my GPU doesn't support ID3D10Predicate?

ID3D10Predicate is not a feature of the graphics card. It is just a software interface used by the application to receive feedback from hardware queries. The associated feature used in this demo is the occlusion query, which should already be supported on your card.

 

Although, according to some google results for "intel hd 3000 hardware queries" or "intel hd 3000 occlusion queries", it doesn't support it: http://forum.unity3d.com/threads/ios-dev-intel-hd-3000-graphics-sufficient.101428/ . (tl;dr: the answerer on that forum corrects himself in a later post, saying he mistook Intel X3000 for HD3000. The HD3000 does support occlusion culling).

 

I also found this article about software culling, if you are interested: https://software.intel.com/en-us/blogs/2013/03/22/software-occlusion-culling-update

 

The only way you're gonna know why the demo doesn't work on your system is by debugging it. Unless someone else already knows about this problem and can pitch in...




#5226037 Why would a mesh appear to be stretched out?

Posted by tonemgub on 28 April 2015 - 04:34 AM


I think it's the camera because when I move around the sides of the mesh appears to stretch out.

If it appears to stretch horizontally the more it gets close to the left or right edges of the screen, this is normal. It happens because the horizontal fov of the camera is greater than the vertical fov. The horizontal fov is usually derived from the vertical fov and the aspect ratio. If you had a perfectly square monitor, with a perfectly square resolution, the fov's would be the same and this wouldn't be noticeable.

 

Also, if you're only moving left and right or forward and back relative to the mesh object (instead of rotating the camera) while keeping the object in view, then the farther vertices of the mesh will be affected more by the fov than the closer ones (because objects in the distance are supposed to appear smaller, so vertices in the distance are "shrunk" more than closer ones). This would also cause the effect you're describing.




#5225785 Why Does Everyone Tell Newbies To Make Games?

Posted by tonemgub on 27 April 2015 - 02:23 AM


No, I'm just saying that it's hard if you have no knowledge of a framework, and if there are no good tutorials tongue.png

 

Games are a good start to learn programming, because it's the end result that matters, not the code, especially for children. Simply making something move on the screen or changing colors is a really good start. Once they know that, they can start putting their imagination to work.

 

My first attempt at a game was in DOS - I tried to make a game like Galaxian, but in 80x25 text mode. I made the player ship out of box characters with an arrow character on top, and I got as far as making it shoot bullets. I never implemented any enemies. The important thing I got from this is not the knowledge of how the screen was a grid of characters or how those box characters could be used to make rough objects, but the enthusiasm for coding games. Every time I managed to implement something new, I remember I used to show my mom and my little sister, so I could get the praise I deserved. smile.png It's that enthusiasm that kept me going then, and it's also what still drives me now. I didn't know, nor could care less that there were others doing more advanced stuff then. That was my achievement, and I was proud of it (still am smile.png )!

 

Pong is probably a good start for those who lack imagination, because it gives them a straight-forward goal, without requiring too much explanation. Just like me, they do not have to implement a fully working game either - just doing something towards a goal is a good enough start.




#5222198 DXGI Alt+Enter behaves inconsistently

Posted by tonemgub on 09 April 2015 - 04:38 AM


MSDN's guidelines don't work for me...

 

I don't remember on what MSDN page I saw this exactly (IIRC, it had some example code too), but MSDN seems to imply that the Alt+Enter handler works on the assumption that you always constrain your window's client size to one of the resolutions supported by the adapter, by handling WM_WINDOWPOSCHANGING (or WM_SIZING). If you've noticed, most video games that let you switch between windowed and fullscreen also do this. This is also what IDXGIOutput::FindClosestMatchingMode is intended to be used for.

 

Unfortunately this also means that if you want to have arbitrary window sizes in windowed mode and no performance loss in fullscreen (as the warning says), you have to disable the default Alt+Enter handler and implement your own, where you specify the sizes and resolutions you want during switching and resizing.

 

But if you ask me, this is just the work of a lazy programmer at Microsoft, who went so far as to implement the Alt+enter handler but could not be bothered to also implement the related WM_WINDOWPOSCHANGING handling, and instead they added that warning. smile.png




#5222035 DXGI Alt+Enter behaves inconsistently

Posted by tonemgub on 08 April 2015 - 05:17 AM

This was discussed before. To avoid that warning, before you call ResizeBuffers, the client size of the window attached to the D3D device must match the size of the fullscreen resolution.

 

The warning happens because ResizeTarget will not change the window size in fullscreen mode (or IIRC ResizeTarget does set the window size correctly, but then SetFullscreenState also resizes the entire window to fill the screen, so the client area will not match the fullscreen size), but ResizeBuffers will still use the window's client size if you pass 0 for the Width and Height parameters.

 

For manual switching, if you add another call to ResizeTarget right after SetFullscreenState (but leave the other call in there as well), you shouldn't get the warning anymore.

 

But for the default Alt+Enter handler, you can't do this, so I think you must instead pass the proper width and height to ResizeBuffers, instead of 0.

 

Also, make sure that when you re-create the depth-stencil buffer, you use the width and height of the backbuffer ( GetBuffer(0) ), not the width and height of the window client (or the values from WM_SIZE's lParam). If you don't, you will get another warning.




#5222015 Reason for D3D_DRIVER_TYPE_UNKNOWN when using non null adapter?

Posted by tonemgub on 08 April 2015 - 01:29 AM

My guess is that when you use a specific adapter, it uses the  D3D_DRIVER_TYPE of the adapter, which is D3D_DRIVER_TYPE_HARDWARE for an adapter obtained from EnumAdapters and D3D_DRIVER_TYPE_SOFTWARE for an adapter created by CreateSoftwareAdapter.




#5220162 Perspective projection thoughts

Posted by tonemgub on 30 March 2015 - 05:27 AM


In the terrain renderer I'm going to use the altitude to calculate a visible range and use that in the perspective matrix to scale the depth buffer.

When displaying objects I'm going to have a fixed visible range.

Has anyone tried this before?

 

Who hasn't. You've just described what a perspective matrix does, basically. smile.png (except for the altitude part)

 

Joking aside, yes I do remember reading articles where it was mentioned that you can use multiple perspective matrices based on distance from camera. to get around precision problems caused by the depth buffer compression when using high depth values. You basically just keep your frustum's aspect ratio and angles constant, but move the front and back planes forward, so that you get more precision at higher depth, and render your distant geometry. Then you move the planes back to the front, and render your close objects. This was/is used to get around Z-fighting in the distant geometry. I don't know of any side-effects.




#5219553 Direct3D 12 documentation is now public

Posted by tonemgub on 27 March 2015 - 03:34 AM

They probably won't "roundhouse kick" it, because it's still needed for backwards compatibility with older versions of D3D (including the lower Feature Levels in D3D12).

 

Debug/Release has nothing to do with this. They both support the Debug layer. The reference driver is probably also what they send to hardware manufacturers as example of driver implementations... The WARP driver is simply an implementation of the reference driver optimized to use SIMD/SSE, and I think it's used with Store apps when there is no hardware acceleration available.

 

Probably.

 

In fact, MSDN has this to say:

 

Because WARP uses the same software interface to Direct3D as the reference rasterizer does, any Direct3D 10 or 10.1 application that can support running with the reference rasterizer can be tested by using WARP. To use WARP, rename D3d10warp.dll to D3d10ref.dll and place it in the same folder as the sample or application. Next, when you switch to ref, you will see WARP rendering.

 

But the only good reason they can't drop the reference rasterizer is probably ( smile.png ) because officially Microsoft only requires that SSE is supported by the CPU for 64-bit versions of Windows. The 32-bit Widnows can still be installed on machines without SSE (or even MMX?), and there the WARP driver cannot be used.

 

Of course, we can all just take a look at (and test) D3D12CreateDevice to see what it supports.




#5219244 Direct3D 12 documentation is now public

Posted by tonemgub on 26 March 2015 - 01:45 AM

Thank you!

 

EDIT, so this post is not completely useless: Let's see who draws the first triangle on D3D12. :)




#5218830 preventing system crash or power outage from wiping savegame: best methods

Posted by tonemgub on 24 March 2015 - 11:05 AM


the power could still go out during an unbuffered write...

 

If this is your concern, then you obviously need a way to check that your save files are not corrupted. A simple checksum would probably do. However, if this does happen, your backups aren't safe either, so there's no point in doing backups. Either you have a corrupt save and discard it, or you have a good one and use it.

 

Unbuffered output is useful if you want to display a "saving" indicator/progress bar, to let the user know when their game was properly saved directly to disk, so they don't Alt+F4 your game (or turn off their computers) during the save.

However, this is only useful if you save all your data in one shot (perhaps from a separate thread). If you do multiple writes&reads from the save files, for data used during gameplay, then you're better off using cached writes&reads to avoid disk trashing or slowing down your game while it's waiting for I/O.

 

 

 


looks like the thing to do is:
1. write to a new file each time.
2. unbuffered write MIGHT save your arse, and it might not.
3. when the game starts, assume the power went out last time, and any savegame type files you try to load might be corrupted.
4. due to assumption 3, all savegame type files should have some sort of crc check on loading.
5. if crc checks fail, perform automatic recovery (if possible).
6. how you want to futz around with filenames, copying, deleting, renaming, etc is up to you (.sav, .bak, save1.dat, save2.dat, etc).

 

Yes, except the last step. Like I said before, backups aren't helping, so you're just making your job harder impelmenting them either way. You should just save the game directly under the desired file name, and avoid any extra file operations. The more file operations you do, the more chances are that something will get corrupted in case of power loss.

 

EDIT: Sorry about the double-post. Not sure what happened there. smile.png




#5216803 ShaderResourceView sRGB format having no effect on sampler reads

Posted by tonemgub on 16 March 2015 - 02:48 AM


applying just the filter didn't change things, but applying both the format and filter did

Not a SharpDX user either, but it's obvious: the Filter specifies that the loaded image data is in SRGb format (to skip the conversion from linear), and the Format specifies the format of the DirectX texture. You obviously need both to have the same format for things to work as expected.




#5215597 x86 / x64 and the crazy conditional moves based on flags

Posted by tonemgub on 10 March 2015 - 01:21 AM

if(x != y){ cmp x,y
a = 24 movne a, 24
}

 

Are you sure you were reading about x86/x64? Because MOVNE is an ARM instruction...




#5214942 WinAPI - Raw input and mouse acceleration

Posted by tonemgub on 06 March 2015 - 07:00 AM

I read that once, but it doesn't say much about mixing the regular mouse input with raw input? In fact, I think it says you can still use the legacy mouse messages along WM_INPUT - you can tell raw input to allow legacy messages during device registration.

 

And I don't think that the Windows acceleration makes sense for anything other than just the UI elements, since (according to the article I linked to), the acceleration is relative to the screen resolution and DPI setting in Windows (not even the physical DPI), not the physical resolution of the mouse. I don't know why anyone would want to emulate this type of acceleration.




#5214920 WinAPI - Raw input and mouse acceleration

Posted by tonemgub on 06 March 2015 - 04:35 AM

The best way to do that is to just use the standard WM_MOUSE* messages when your GUI is active.

 

How would turning off acceleration help you implement your own acceleration? That makes no sense.

 

You can find the formula Windows uses for it's acceleration all over the internet. I found this: http://donewmouseaccel.blogspot.ro/2009/06/out-of-sync-and-upside-down-windows.html




#5214686 splash and menu screens

Posted by tonemgub on 05 March 2015 - 03:48 AM

The splash screen and the menu are what we call "game states". So you should look for tutorials about implementing game states. I found this after a quick search: http://lazyfoo.net/articles/article06/index.php .






PARTNERS