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

EbonySeraphim

Members
  • Content count

    35
  • Joined

  • Last visited

Community Reputation

131 Neutral

About EbonySeraphim

  • Rank
    Member
  1. Thanks for the advice!  I'm going to find free replacements for the assets used to develop the projects initially.
  2. I'm about to start applying for a programmer position at game studios, so I'll need to put together a portfolio.  As a programmer, this means actual code and ideally something showing off the running game like the binary.  I recall at hearing from some industry guys at a GDC 2012 talk that they do not want binary submissions because they can contain malicious code.  So my question is, what is it that I should submit other than my code?  Do they want the MSVC++ solution to build and run it themselves?  Do they just want the code to look at?  Should I submit a video file of the running game so they don't even have to bother building it and still see what the end product is?   Also, every project I've finished worth showing uses borrowed game assets that I'm not allowed to legally distribute/sell myself.  If I submit these projects to a game company/HR, would there be a problem sending them assets along with it with some sort of disclaimer that the art/sound/aethetic assets are not my own nor do I have the rights to them?   Thanks for the responses and/or insight.
  3. Your ability to do much in either API depends on your domain knowledge (3D graphics) and your overall programming level.  If you already know a lot about computers processing 3D graphics, and have used large and complex APIs before, then learning both APIs at the same time will probably not be a difficult task.  If you're a beginner at either, and certainly if you're just beginning both, don't try to learn both at the same time, because learning one will be enough a challenge.
  4. Either I asked a really dumb question, or one that no one knows the answer to - a response indicating either one would be appreciated =) I did further Googling and ran into a post on a Unity forum which said that Microsoft's HID interface limits the number of buttons to 32. Though it wouldn't limit joysticks that might actually use another interface (gameport?), for all intensive purposes, I'd accept that as a show stopper and a reason for hardware manufacturers and software implementers to consider it a hard limit. I'm not 100% sold on the post until I find more concrete information because it seems awfully short sighted so I'd like to see it written in some official document or find more secondary sources saying the same thing.
  5. This seems like an end-user question, but as a developer, I'm seeking a developers explanation which is why I'm posing here: I've recently gotten into flight sims and purchased a Thrustmaster Warthog. There are a lot of buttons and switches on the product that add up to 19 buttons on the joystick and 32 on the throttle (2 separate game pads in Windows). In it's native sim/game(DCS:A-10C) it works great because there's direct knowledge of the product I bought, but other sims don't have built in mappings for events such as the release of a specific button (usually switch put in the off or center position, or throttle from OFF to IDLE). This leaves me to attempt to use the Thrustmaster scripting tool which can virtualize a new device with button events generated on arbitrary input events. That is, a release of a physical button can be mapped to a press of a button in the virtual controller -- or even trigger a button hold, etc. Even though I can do this, I still need(ok...maybe want is the operative word) the original 32 buttons but TARGET claims DirectX is capped at 32 buttons, and so do the flight sim forums. This means, I have no where to map the new actions unless I force it to generate keyboard events which would get messy since the sim would have those mapped and I'd have to clobber them. Being a developer and having written more than trivial code for joysticks, I was pretty sure this was false so I checked the DirectInput documentation. I noticed that DIJOYSTATE2 supports 128 buttons, and DIJOYSTATE supports 32. I can tell the joysticks I'm working with appear to be operating under the constraints of DIJOYSTATE, but the code I've written (since 2002-ish) has always used DIJOYSTATE2 and works on older devices just fine. It seems obvious that one was meant to support more elaborate controllers and DIJOYSTATE2 has been there since DirectInput8 so why is this still considered a limitation? Unless the game/software is older than DirectX8, support for 128 buttons has been there for a long time. Maybe I'm missing something. tldr: Why does newer software still consider DirectInput joysticks to have a 32 button hard limit when DIJOYSTATE2 (part of the API) supports 128 buttons?
  6. [quote name='DieterVW' timestamp='1296494290' post='4767554'] Your shutdown messages give the best clue for the investigation. The only thing you need to worry about are external reference counts on D3D11 objects. Internal references are managed by D3D and won't cause leaks. The counts you see for internal references are for default state objects that are maintained by D3D. From the table that was printed out it shows that the only outstanding external reference you still have is for a device. It doesn't appear to me that the leaked device reference is in the code you pasted here. [/quote] Thanks a lot for that information! I thought things were the other way around with references. I may have resolved the problem last night after I added a call (or 2) to ImmediateDeviceContext::ClearState() in my shutdown sequence and got the number of live objects to lower than what I posted here when it occurs. I have to go home and test before I find out if all ExtRefs were 0 though.
  7. This is a topic I recently gained and understanding of so I'll take a whack and trying to explain it briefly and in very simple terms. Multi-pass rendering is like layering sheets of translucent paper on top of one another to compose a final image. When you lay down each sheet of paper (pass), you are adding a new component of information that wasn't previously there. For example, if you wanted to render a basketball you would have a single ball with a position and orientation. One pass (sheet) could show the ball with a basic orange color. The second pass(sheet) shows the same ball but with only it's black line pattern (all other information is transparent). put the second sheet on top of the first, and you'll see a ball with both the orange color and the black line pattern. With multipass rendering, there generally isn't a need to explicitly share information between passes because the shared information is the geometry that was re-rendered. With the earlier example, that was the ball's position and orientation on the sheets of paper. As long as that information stays the same for each pass, the two images overlay on top of each other appropriately. Keep in mind that this is only basic multi-pass rendering and I wouldn't be surprised if there are techniques that require more complex information to be shared between passes. EDIT: Taking things back to the technical side. Imagine drawing a sphere with two textures. One texture is the orange color, the other is the black line pattern. Your geometry stays the same for both draw calls. Before drawing the first pass, you set the single texture to the basic orange color. Draw the ball. Then you set some sort of blending operation to compose the current image already drawn to the one you're about to draw. Then you set the texture to black line pattern. Then you draw the same geometry for the ball again.
  8. I'm worried that I'm getting no reply because I failed to include some information or am demonstrating a servere lack of competency. I hope it's because this is too involved of a problem to answer easily though. I can provide a link and login to the full source on WebSVN (read-only, VS2010 project) so the problem can be seen in it's full context.
  9. I'm writing a game using DirectX11 and am finding that shutting it down cleanly is not as trivial of a task as it should be - at least when the application is in fullscreen mode during the close. Basically what I'm noticing is that when my application is in full screen mode while being closed, there are still live object references in the DirectX/DXGI runtime. The first time I encountered this, I did my homework and found that fullscreen swap chains can't be released until the swap chain is switched out of fullscreen mode, so I added a test to set the mode back to windowed before exiting the application. I thought it cleaned things up at first, but then I started stress testing my application a bit and noticed that it still didn't always clean things up while in fullscreen. This behavior is very annoying and I suspect it has something to do with the handling of windows messages (or lack thereof) on events because my code path for cleaning up DirectX11 is static barring the fullscreen check and the standard checks for null before calling Unknown::Release()). I added a log statement, and even when the live objects are found, the log reports that it did detect the app being fullscreen during the shutdown, and made the call to IDXGISwapChain::SetFullscreenState(FALSE, NULL) before calling Release on the swap chain. Here is the shutdown code: [code] //shuts down the graphics subsystem by cleaning up everything associated with it void GraphicsLayer::Shutdown() { if(IsInitialized()) { AELOG_TRACE(m_pLogger, L"Graphics subsystem shutting down..."); /* --Interfaces obtained during enumerations on startup -- doesn't affect anything. for(unsigned int adapterIndex = 0; adapterIndex < m_vGraphicsDevices.size(); ++adapterIndex) { for(unsigned int monitorIndex = 0; monitorIndex < m_vGraphicsDevices.at(adapterIndex).pvMonitors.size(); ++monitorIndex) { m_vGraphicsDevices.at(adapterIndex).pvMonitors.at(monitorIndex).pOutputHandle->Release(); } m_vGraphicsDevices.at(adapterIndex).pAdapter->Release(); } */ DX_RELEASE(m_pInfoQueue); ReleaseSwapChainAndMainBuffers(); DX_RELEASE(m_pImmediateDeviceContext); DX_RELEASE(m_pDXGIFactory); DX_RELEASE(m_pDevice); m_isInitialized = false; AELOG_TRACE(m_pLogger, L"Graphics subsystem shutdown complete."); } else { AELOG_WARN(m_pLogger, "Cannot shutdown already shutdown graphics subsystem."); } } void GraphicsLayer::ReleaseSwapChainAndMainBuffers() { AELOG_DEBUG(m_pLogger, "Releasing swap chain and main buffers"); ReleaseMainBuffers(); //must unfullscreen before being able to release swap chain if(m_pSwapChain) { BOOL isFullscreen; IDXGIOutput *pOutput; m_hr = m_pSwapChain->GetFullscreenState(&isFullscreen, &pOutput); AELOG_DXERR_CONDITIONAL_ERROR(m_pLogger, "Could not obtain full screen state of swap chain!!!", m_hr); if(isFullscreen) { AELOG_TRACE(m_pLogger, "Application found in fullscreen, setting back to windowed."); m_hr = m_pSwapChain->SetFullscreenState(FALSE, NULL); AELOG_DXERR_DEBUG(m_pLogger, "Switch to windowed mode: ", m_hr); pOutput->Release(); } DX_RELEASE(m_pSwapChain); } } void GraphicsLayer::ReleaseMainBuffers() { AELOG_DEBUG(m_pLogger, "Releasing main buffers..."); m_pImmediateDeviceContext->OMSetRenderTargets(0, NULL, NULL); //m_backBuffer and m_depthStencilBuffer are of a type that contaisn the IDirect3D11Texture2D //and references to any views associated with it. The destructor Releases those interfaces. if(m_backBuffer) { delete m_backBuffer; m_backBuffer = nullptr; } if(m_depthStencilBuffer) { delete m_depthStencilBuffer; m_depthStencilBuffer = nullptr; } } [/code] The log during a close, while fullscreen, that doesn't successfully clean things up looks like this: [code]<Log name="kernel" level="TRACE"> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="48" function="Accevo::EngineKernel::EngineKernel()">Constructing engine kernel...</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="272" function="Accevo::EngineKernel::CreateMainWindow()">Creating non-fullscreen window.</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="99" function="Accevo::EngineKernel::StartGraphicsSubsystem()">Starting graphics subsystem</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="42" function="Accevo::GraphicsLayer::Configure()">Configuring graphics layer</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="54" function="Accevo::GraphicsLayer::Initialize()">Initializing graphics layer</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="129" function="Accevo::GraphicsLayer::CreateDeviceAndDXGIFactory()">Creating DirectX11 device and obtaining DXGI factory...</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="174" function="Accevo::GraphicsLayer::CreateDeviceAndDXGIFactory()">DirectX11 device created and DXGIFactory obtained successfully.</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="180" function="Accevo::GraphicsLayer::GetGraphicsConfiguration()">Finding appropriate graphics mode match</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="206" function="Accevo::GraphicsLayer::GetGraphicsConfiguration()">Match found</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="245" function="Accevo::GraphicsLayer::InitSwapChainAndMainBuffers()">Creating swap chain...</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="269" function="Accevo::GraphicsLayer::InitSwapChainAndMainBuffers()">Switching to fullscreen mode.</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="394" function="Accevo::GraphicsLayer::InitMainBuffers()">Initializing main buffers</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="414" function="Accevo::GraphicsLayer::InitMainBuffers()">Successfully initialized main buffers</LogMessage> <LogMessage name="kernel" level="TRACE" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="286" function="Accevo::GraphicsLayer::InitSwapChainAndMainBuffers()">Swap chain and buffers created successfully.</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="128" function="Accevo::EngineKernel::StartGraphicsSubsystem()">Graphics subsystem initialized successfully</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="159" function="Accevo::EngineKernel::StartInputSubsystem()">Input system initialized successfully</LogMessage> <LogMessage name="kernel" level="INFO" time="0" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="187" function="Accevo::EngineKernel::Run()">Running kernel....</LogMessage> <LogMessage name="kernel" level="INFO" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="215" function="Accevo::EngineKernel::Run()">Kernel run complete. Exiting with status 0 (NORMAL)</LogMessage> <LogMessage name="kernel" level="TRACE" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="176" function="Accevo::EngineKernel::Shutdown()">Shutting down kernel...</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\directinput.cpp" line="367" function="Accevo::DirectInput::Shutdown()">Shutting down input system.</LogMessage> <LogMessage name="kernel" level="TRACE" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="485" function="Accevo::GraphicsLayer::Shutdown()">Graphics subsystem shutting down...</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="459" function="Accevo::GraphicsLayer::ReleaseSwapChainAndMainBuffers()">Releasing swap chain and main buffers</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="421" function="Accevo::GraphicsLayer::ReleaseMainBuffers()">Releasing main buffers...</LogMessage> <LogMessage name="kernel" level="TRACE" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="471" function="Accevo::GraphicsLayer::ReleaseSwapChainAndMainBuffers()">Application found in fullscreen, setting back to windowed.</LogMessage> <LogMessage name="kernel" level="DEBUG" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="473" function="Accevo::GraphicsLayer::ReleaseSwapChainAndMainBuffers()">Switch to windowed mode: Error String: S_OK Error Description: The function completed successfully</LogMessage> <LogMessage name="kernel" level="TRACE" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\graphicslayer.cpp" line="507" function="Accevo::GraphicsLayer::Shutdown()">Graphics subsystem shutdown complete.</LogMessage> <LogMessage name="kernel" level="TRACE" time="0.665884" file="c:\users\ebonyseraph\documents\programs\accevo\accevo\src\enginekernel.cpp" line="182" function="Accevo::EngineKernel::Shutdown()">Kernel shutdown complete.</LogMessage> </Log>[/code] Just to clarify the potentially confusing early log message about non-fullscreen window - that's the Win32 call to CreateWindow. My app creates a window with a minimal border, then calls IDXGISwapChain::SetFullscreenState() to switch to fullscreen after the normal window has been created if the app wants a fullscreen window initially. If switched to later, it is being done by DXGI. This is probably of the least help, but to be complete, this is a dump of the live objects: [code] The thread 'Win32 Thread' (0x182c) has exited with code 0 (0x0). D3D11: WARNING: Live Device: Name="unnamed", Addr=0x007863D0, ExtRef=1 [ STATE_CREATION WARNING #2097297: LIVE_DEVICE ] D3D11: WARNING: Live DepthStencilView: Name="unnamed", Addr=0x04896F84, ExtRef=0, IntRef=0 [ STATE_CREATION WARNING #2097247: LIVE_DEPTHSTENCILVIEW ] D3D11: WARNING: Live Texture2D: Name="unnamed", Addr=0x04896D74, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097235: LIVE_TEXTURE2D ] D3D11: WARNING: Live RenderTargetView: Name="unnamed", Addr=0x04896BE4, ExtRef=0, IntRef=0 [ STATE_CREATION WARNING #2097244: LIVE_RENDERTARGETVIEW ] D3D11: WARNING: Live Texture2D: Name="unnamed", Addr=0x0078F3BC, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097235: LIVE_TEXTURE2D ] D3D11: WARNING: Live Query: Name="unnamed", Addr=0x0078819C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097280: LIVE_QUERY ] D3D11: WARNING: Live Sampler: Name="unnamed", Addr=0x00787FEC, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097268: LIVE_SAMPLER ] D3D11: WARNING: Live RasterizerState: Name="unnamed", Addr=0x00787E5C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097277: LIVE_RASTERIZERSTATE ] D3D11: WARNING: Live DepthStencilState: Name="unnamed", Addr=0x00787D04, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097274: LIVE_DEPTHSTENCILSTATE ] D3D11: WARNING: Live BlendState: Name="unnamed", Addr=0x00787C0C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097271: LIVE_BLENDSTATE ] D3D11: WARNING: Live Context: Name="unnamed", Addr=0x0487006C, ExtRef=0, IntRef=1 [ STATE_CREATION WARNING #2097226: LIVE_CONTEXT ] D3D11: WARNING: Live Device Child Summary: Device Addr=0x007863D0 Using ID3D11Debug::ReportLiveDeviceObjects with D3D11_RLDO_DETAIL will help drill into object lifetimes. Objects with ExtRef=0 and IntRef=0 will be eventually destroyed through typical Immediate Context usage. However, if the application requires these objects to be destroyed sooner, ClearState followed by Flush on the Immediate Context will realize their destruction. Live Context: 1 Live Buffer: 0 Live Texture1D: 0 Live Texture2D: 2 Live Texture3D: 0 Live ShaderResourceView: 0 Live RenderTargetView: 1 Live DepthStencilView: 1 Live VertexShader: 0 Live GeometryShader: 0 Live PixelShader: 0 Live InputLayout: 0 Live Sampler: 1 Live BlendState: 1 Live DepthStencilState: 1 Live RasterizerState: 1 Live Query: 1 Live Predicate: 0 Live Counter: 0 Live CommandList: 0 Live HullShader: 0 Live DomainShader: 0 Live ClassInstance: 0 Live ClassLinkage: 0 Live ComputeShader: 0 Live UnorderedAccessView: 0 [ STATE_CREATION WARNING #2097298: LIVE_OBJECT_SUMMARY ] The program '[5844] ModelViewer.exe: Native' has exited with code 0 (0x0). [/code] The app is very bare bones right now and I'm pretty sure the two live textures are the back buffer and depth-stencil buffers, corresponding to the live RenderTargetView and DepthStencilView. I do not have any explicit calls that create samplers, blend states, depthstencil state, rasterizer state, or the query, but I do call OMSetRenderTargets with the backBuffer render target view and the created depth stencil buffer/view. Few things I've tried: -Handling WM_SIZE and recreating the buffers in the swap chain do not resolve this problem. -Disabling DXGI's automatic handling of ALT+ENTER sequences doesn't help this problem. Somethings that I've noticed: -Creating a fullscreen window doesn't seem to execute the same way all the time. Sometimes I see the cursor flicker a bit while other times I do not. However there does not seem to be an association between seeing or not seeing the flicker when the live objects remain. -I have a dual monitor setup, and sometimes the non-primary screen turns black as well and other times it displays normally. There also doesn't seem to be a correlation to whether or not the live objects remain after shutdown and this behavior. -This problem happens whether or not the application started out in fullscreen, or started out windowed and switched to fullscreen later. The only condition that is always true when the live objects to stick around is that the app was in fullscreen mode. -Sometimes if the problem doesn't happen after many successive runs, clicking during the switch to fullscreen may make the problem surface more frequently. Also, my annoying XML editor in the background create a popup box everytime I start my application since the logfile changes. Because of this, there may be a correlation with my app window losing focus as it goes into fullscreen. However, I have had the problem occur with the XML editor closed and without touching the cursor during the startup. I know I gave a lot of information to digest. I don't suspect there is an obvious error I'm making and I'd be happy just to know if this was an unresolvable issue with DirectX with some sort of hack solution around how windows behaves. Any help would be greatly appreciated and thanks in advance. EDIT: I ran PIX and it detected the enumerated adapters and outputs not being released so uncommented that code. With that back in, I still see resource leaks sometimes when I close my app from Visual Studio, but PIX debugging shows that everything is cleaned up and that there are no references to those objects from the application. So the question is which do I believe, and for my understanding, I'dl ike to know why one might be falsely reporting a problem.
  10. Other than the bugs, I see nothing wrong with the new layout. Personally, I think the fonts are too big the way it is now, and I'd rather have more text displayed but I can either change my browser setting or forum display style. As for the main page, I'll have to tolerate it, but I really do hope it goes down about 2pts.
  11. Ouch. Yeah, I really could write this cleaner. I think I'm just getting frustrated trying to do what I'm doing.
  12. I hope this is a topic that isn't better suited for the GDLounge, but I was writing code in a tight loop and was considering the need to comment what's going on, but then realized that it really is hard to explain what is going on with code that deeply nested. Does anyone else feel that way with code in tightly nested loops? You'd have to write a heavy paragraph or two just to explain how that work in that loop fits in the bigger picture, and even worse if you have to explain how and why every variable used in that loop is used.
  13. DX11

    Quote:Original post by InvalidPointer Quote:Original post by Sheradil Well the Link is ... "ok" But there is no DirectInput and no DirectAudio or DirectSound or whatever The Graphics Documentation is more like what im looking for ... But i miss Input / Sound classes, too. I just find those DirectX8 oder DirectX9 Soundclasses ... but thats not what im looking for^^ Because you're looking for something that no longer exists. DirectSound was deprecated with Vista and replaced with XAudio2, and DirectInput was on its way out with Direct3D9 in favor of standard Windows and/or raw input combined with XInput for 360 pads. DirectInput8 actually needed no improvement when DirectX9 came out so they simply didn't update it. I recall reading this in the DirectX9 docs when it came out. However, Windows messages+XInput does not represent a superset of DirectInput8's ability to talk to any type and number of joysticks. Windows messages are good enough for handling mouse and keyboard input, but XInput only talks to XBox360 gamepads. XInput is better than DirectInput8 when you do have an XBox360 controller since it can use features of the controller that most PC gamepads don't have.
  14. I think I have a better understanding now. If I go back to my original issue, there really isn't one at all. What I called a multi-slot resource view, cannot really exist. If I create a 2D texture array programmatically, with only a single resource view, in HLSL it will still only take up 1 slot no matter how big the array is. Ideally that slot should populate Texure2DArray variable in HLSL correct? Also, if I force-fit a Texture2DArray into a Texture2D or Texture1D in HLSL, it would just be interpreted however it is being used which would likely be broken? So every variable type declared in HLSL takes up only 1 resource-view/slot unless declared with array syntax. What is populated in that slot (a resource view) is just memory that will be interpreted when the HLSL uses variable.
  15. My point confusion lies in the fact that I'm writing a lot of this code based on the reference documentation and am using ShaderReflection. The D3D11_SHADER_INPUT_BIND_DESC structure has BindPoint and BindCount members. Can you explain how those correlate to number of resource views and start slot that should be used to set the associated parameters? I'm tinkering around with reflection, examining the output of it based on changing the structure of shaders, and it seems that explicit arrays are flattened into their separate components as used and occupy separate bind slots. I tested a Texture2DArray and that only occupies one too. So really, what is the difference between Texture2DArray and Texture2D[n]? I may be asking these questions far too early.