Oogst

Members
  • Content count

    142
  • Joined

  • Last visited

Community Reputation

481 Neutral

About Oogst

  • Rank
    Member

Personal Information

  1. The only DX9 GPU profiler I know is PIX and I don't think PIX can be used to effectively capture detailed performance data for a longer capture. I can get all the detail for a single frame but I don't have a clear reproduction case so it's very unpredictable when the framedrops will happen.     We don't do any of that kind of streaming of textures or meshes at all.   What I can imagine might be happening is that the driver is moving textures between system RAM and GPU memory. However, the videocard drivers report 1024mb dedicated video memory and the game uses less than half of that, so swapping between system RAM and video RAM only makes sense if something else in Windows is grabbing a lot of that memory. Is there any way to monitor this kind of behaviour?   By the way, the textures are loaded during the loading screen, not during gameplay, like this: D3DXCreateTextureFromFileInMemoryEx(device, fileBuffer, imageSize, D3DX_DEFAULT_NONPOW2, D3DX_DEFAULT_NONPOW2, 1, 0, D3DFMT_UNKNOWN, D3DPOOL_MANAGED, D3DX_FILTER_LINEAR, D3DX_FILTER_NONE, 0, NULL, NULL, &resultTexture);   Just tried this and I do see occasional framedrops when I do this, but very rare and not in the kind of pattern I see during normal gameplay.
  2. Just checked, I was already doing D3DPRESENT_INTERVAL_ONE.
  3. I'm experiencing odd framedrops in our live DirectX9 game and have difficulty figuring out why they happen. If I play a match then occasionally for a few seconds roughly one in every 10 frames is dropped (not with a regular pattern though). I've logged frame timings and the framedrops turn out to be caused by the swap call (which also waits for VSync if enabled):   direct3DDevice9->Present(NULL, NULL, NULL, NULL);   Nothing else on the CPU side is taking long enough to cause the framedrops. In other words: I am somehow giving the videocard too much work to do to finish within the 16ms needed for 60fps.   The odd thing is: the frames around it are all rendered faster and I am not aware of anything special being rendered during the framedrops. I've tried doing a PIX capture but nothing special seems to happen in those frames.   It gets even stranger: if I turn off VSync I run at around 200fps. I see the same pattern of framedrops, but the drops are from taking 5ms for normal frames and 6ms during those longer frames. So I get a pattern of frame durations in ms like this: 5ms-5-5-5-5-5-6-5-5-5-5-6-5-5-5-5-5-5-5-5-5-6-5 etc. This is far below the duration needed to achieve 60fps with VSync enabled, so it makes no sense to me that with VSync on I am still seeing framedrops.   One thing I've noticed is that this happens more if I move quickly. Could it be that using a texture that hasn't been used for 10 seconds is slow in DirectX9? Seems odd since I never heard of this kind of behaviour.   Note that I am running these test on a Geforce GTX 560 Ti on 1920*1080 on Windows 7.   I'm out of ideas on what to try next. How can I find the cause for this?
  4. That's a lot of tiles... Of course not every object needs to render on every tile, but this would still explode the number of rendercalls. I can see how this can work, but I think I'd need to rebuild half the engine to use this efficiently (including switching to DirectX11).
  5. Performance is not so bad that I need to try drastic solutions like that one right now, but it is an interesting thought. What kind of order of magnitude are we talking about for how many tiles one would need for a 1920x1080 screen? Order of 10x6 tiles? You mentioned it varies per hardware, but right now I don't even know whether we are talking about 2x2 tiles or 100x100 tiles.   (The game is Awesomenauts by the way, and it is in DirectX9 and OpenGL.)
  6. That explodes the number of rendercalls, unless the GPU ROP caches are quite big. Is this actually a good idea when rendering 500 objects per frame?
  7. What is "screen space tiling"? If I Google for this I get hits for tile based renderers but as far as I know that is a type of graphics hardware, so I suppose you mean something else?
  8. Okay, I'll just happily use scissors then. Thanks! :)     From how I understand it the viewport might sometimes fill outside its bounds, for example when doing a wireframe render with a thick wire, because viewports operate on the vertex level. Viewports don't just fill all pixels of the object outside the viewport bounds: that only happens in those rare edge cases like that wireframe edge.
  9. I would like to make certain objects only render at certain parts of the screen. Basically exactly what the scissorRect can do. However, the exact same thing can also be achieved by setting the viewport to a smaller region and compensating the matrices for the offset. Does this give better performance? If I understand the documentation correctly the scissorTest is done per fragment while the viewport is done per vertex. This suggests that using the viewport instead of the scissorRect would potentially save significant amounts of fillrate. Is this true or am I misunderstanding this? ScissorRect is a lot easier to implement so I only want to use the viewport for this if I am actually gaining something that way.   (Note that this is for our 2D game, in which fillrate is currently the main performance bottleneck. The fragment shaders are extremely simple, so basically most performance goes into large amounts of overdraw of partially transparent objects.)
  10. Are there any downsides to doing "fullscreen window"? I know the concept but have never looked into the details. Why would a game still offer real fullscreen of it already offers fullscreen window?
  11. Ah, yes, this is indeed not a separate graphics card, it is an Intel integrated graphics thingamajig. I call all GPUs "cards", but that is not correct of course. It is indeed an Iris, so not one of the older models. It runs the game with good performance, it just has this one issue.   Regardless of whether this is a driver issue or not, I do need to do something about it, since our users blame us instead of Intel...
  12. Our game Awesomenauts often crashes after alt+tab on Intel videocards. If I run the game in OpenGL in fullscreen and alt+tab out of the game and then back into it, then it has a chance of about 50% to crash.   I have a memdump of this crash. The error is "Access violation reading location 0x00000018." It happens deep in the driver in ig75icd32.dll inside a call to glClear(GL_COLOR_BUFFER_BIT). The last call before that is glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0).   The crashes do not happen when I run similar code in DirectX (Awesomenauts supports both OpenGL and DirectX). The crashes also do not happen on the Nvidia videocard I tested with. The Intel videocard I tested with is relatively new (from last year).   I thought that maybe the crashes are caused by losing the context (although I have no idea how that could possibly happen), so I tried calling wglMakeCurrent at the beginning of every frame, but that did not make a difference.   Am I doing something wrong here, or is this an Intel driver bug? Even if it is a driver bug: what can I do on my side to fix it?   Thanks in advance! :)
  13. Yes, our artists use Photoshop for drawing things. They then put them in levels in our own in-game level editor. Animations are done in After Effects for frame-to-frame stuff and our in-game animation tool for simpler things. (I am myself a programmer at Ronimo, by the way.)
  14. I have written a blogpost about how our artists reuse 2D assets that have been drawn for daylight in a nighttime level, in our new game Swords & Soldiers II. These assets have their lighting drawn in, but it turns out that with some simple tricks they can be used for a night setting and still look good, without redrawing the lighting in Photoshop and without taking up additional texture space. I have put the most interesting images below, there is more and some additional explanation and videos at the complete blogpost here:   Using 2D daylight assets to create a night level   I hope you find this interesting!               More images, videos and info at the complete blogpost.
  15. Technically I guess you areright this isn't DoF, but the post effect shader used is exactly DoF. This is not simply a blend between a blurred and a non-blurred image (the fastest and most common form of DoF): my implementation takes into account the depth of the pixels around and thus makes sure sharp objects not bleed over a blurred background. What I have made is DoF with simply a modified depth buffer. Whether it is still called DoF then, I don't know.