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

Balk

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

146 Neutral

About Balk

  • Rank
    Member

Personal Information

  • Location
    Fishtown, PA
  1. I'm handling all the input through the traditional WndProc message callbacks. I have a feeling I might be incorrectly using AllowSetForegroundWindow in the process that is supposed to give up focus when its done to the dx9 app, and that is what's causing the weird "rending on top, but input falls through to the windows behind".   Thanks, for helping tho!
  2. Yeah, the m_pDevices[j].OnLostDevice(); is handling all of that within. I am able to have it recover properly when I use the mouse and keyboard to select the minimized application. That's why I'm pretty certain it's some sort of focus issue.   void LtGDevice::OnLostDevice() { m_pD3DSprite->OnLostDevice(); SAFE_RELEASE(m_pBackBuffer); SAFE_RELEASE(m_swapChain); // Kill all the tasks... they will be repopulated upon DeviceReset for(unsigned int i = 0; i < m_vScheduledTasks.size(); i++) { SAFE_DELETE(m_vScheduledTasks[i]); } m_vScheduledTasks.clear(); for(map<int, LPDIRECT3DTEXTURE9>::iterator iter = m_mapTextures.begin(); iter != m_mapTextures.end(); ++iter) { SAFE_RELEASE(iter->second); } for(map<FONT_HANDLE, LPD3DXFONT>::iterator iter = m_mapFonts.begin(); iter != m_mapFonts.end(); ++iter) { iter->second->OnLostDevice(); } m_bForceReset = false; }
  3. I have a multi-monitor, multi-full screen dx9 device setup that need to work hand-in-hand with another process. This other process can make the dx9 app minimize so it can take the active foreground window... and when it's done, it signals the dx9 app (via local telnet) to recover itself and become active again.    My finished product needs to accomplish this procedurally, as in I cannot use any input devices to either alt-tab or click the dx9 app in taskbar with mouse. When I try to do it procedurally, the different recovery code I've tried has managed to create two different outcomes.   The dx9 app does maximize, and recovers... but when I click the screen, if any windows are behind the game it immediately loses focus, as if the dx9 app is only rendering overtop the other windows but not actually there. Or, the game comes back up, but shows only a white screen and the device is reports 'D3DERR_DEVICELOST', and never makes it to 'D3DERR_DEVICENOTRESET'... but if you actually click the screen it receives the input properly and plays the game.   I'm almost certain I'm freeing all the dx resources that I need to be, and that it's got to be some sort of focus issue.   I'm also aware that AllowSetForegroundWindow(), needs to present in the other process to be able to give up focus, and it is being called.   The dx9 app is a fairly large engine, so posting the code is a concise matter will be difficult, below is the general idea of things:    All code is from dx9 app: // // A message comes in whether to minimize/maximize if(m_bMinimize) { LOG("minimize!"); ShowWindow(deviceRef.GetWnd(), SW_MINIMIZE);//SW_HIDE); } else { LOG("MAXIMIZE!"); ShowWindow(deviceRef.GetWnd(), SW_SHOWNORMAL); SetForegroundWindow(deviceRef.GetWnd()); }   The below function CheckDevice() is called at the beginning of the render thread loop. It returns whether or not the device is okay. // Returns true if it's okay to render bool LtGRenderThread::CheckDevice() { if(m_bLostDevice) { int j = 0; for(j = 0; j < m_iNumDevices; j++) //for(int j = m_iNumDevices-1; j >= 0; --j) { HRESULT result = m_pDevices[j].m_pD3DDevice->TestCooperativeLevel(); if(FAILED(result)) { if(D3DERR_DEVICENOTRESET == result) { HRESULT result2 = m_pDevices[j].m_pD3DDevice->Reset(&m_pDevices[j].m_tPresentParams); if(FAILED(result2)) { LOGF("Device %i: reset failed: %u", LOG_NORMAL, j, result2); } else { LOGF("Device %i: Reset successful...", LOG_NORMAL, j); } } break; } else LOGF("DEVICE %i has recovered!", LOG_TODO, j); } if(j == m_iNumDevices) { LOG("Reloading all vRAM..."); for(j = 0; j < m_iNumDevices; j++) { m_pDevices[j].OnResetDevice(); } // Tell Update thread that we need to reset the device m_MsgManRef.MarkFlag(MSGMAN_ResetDevice); m_bLostDevice = false; } } else { for(int j = 0; j < m_iNumDevices; j++) { HRESULT result = m_pDevices[j].m_pD3DDevice->TestCooperativeLevel(); if(FAILED(result) || m_pDevices[j].IsForceReset()) { LOG("A device has been lost! (Or forced to reset)"); m_bLostDevice = true; // Clear out all DX resources for(int i = 0; i < m_iNumDevices; i++) m_pDevices[i].OnLostDevice(); m_MsgManRef.MarkFlag(MSGMAN_LostDevice); break; } } } return !m_bLostDevice; }     I'm pretty sure no one is going to respond to this mess. But I'll just try to be hopeful that someone has some experience in doing something similar to this. Thanks for reading.
  4. I'm not sure what you mean by "solid rectangles", but it may be that you don't have the correct render states enabled to draw text.   D3DXSPRITE_ALPHABLEND D3DXSPRITE_SORT_TEXTURE   try enabling those states on the d3dDevice using SetRenderState();
  5. I have a directx 9 application that needs to run on a Windows XP (embedded) machine with two monitors. My first iteration of the renderer was a single [font=courier new,courier,monospace]IDirect3DDevice9[/font] object and then I [font=courier new,courier,monospace]IDirect3DDevice9::CreateAdditionalSwapChain()[/font] per "screen", which rendered out multiple 'windows' positioned and sized to simulate full screen. This worked well, however I'd get lots of screen tearing since I used [font=courier new,courier,monospace]D3DPRESENT_INTERVAL_IMMEDIATE[/font] within the presentation parameters because I don't want to stall the updates waiting for vBlank. Also, I assume that with only one device querying one adapter, I'd not be able to safely assume the vBlank period for both monitors, only the 'main' monitor. So this lead me to re-writing the renderer to use multiple devices (one for each monitor), and each device has its own adapter for its respective monitor. For my purposes, this is working just as well as the additional swap chains method, however I'm back to the same issue of tearing since the alternative is stalling the main thread twice for both vBlank's, which leads to unacceptable framerate jittering. [hr] If I were to put forth the incredible amount of effort of rewriting my engine to be a multi-threaded renderer, will this solve my screen tearing issue? More specifically, am I able to create a thread for each device and render/present them independently? If I must keep all DX API calls on the same thread (which I believe is the case), will stalling multiple times waiting for vBlank still allow me to achieve a 60hz FPS? [size=5][b]-or-[/b][/size] Is there an easier way to know when to invoke [font=courier new,courier,monospace]IDirect3DSwapChain9::Present()[/font] without [font=courier new,courier,monospace]D3DPRESENT_INTERVAL_DEFAULT[/font] and on a single thread? I've tried polling [font=courier new,courier,monospace]IDirect3DSwapChain9::GetRasterStatus()[/font] to manually present an already rendered backbuffer in the vBlank period (per device/monitor), but that doesn't seem to be accurate enough as I still get tearing.
  6. There's nothing really "wrong" with what you have, but a large constraint to your enemy's AI is that it's entirely hardcoded in its logic. A better algorithm that would be more flexible would be to create a node based path that the enemy will take and repeat. The enemy would move toward the next node regardless of its current position, then continue to the next one once it reaches its destination. The nodes in your case would be the four points (X,Y) of the square. Store the nodes in a dynamic container and you gain the flexibility to add or remove nodes on the fly. If the enemy ever gets off its path such as it chased the player, it could resume back on its path when instructed to since it's not hardcoded (and assuming there isn't anything obstructing its path). Another important benefit to using something more flexible is that the system you write that moves the enemy could be reused for other enemies or new levels.
  7. [quote]its just one or two frames, so Im not sure if those are indeed the ones that bumps, would one frame drop be so noticeable?[/quote] Dropping from 60FPS to 30FPS, even if only a single render frame would cause a noticeable 'jump' if an object on the screen (or camera) is translating using a time delta. [quote]What the hell can be causing this, its weird, when I searched for something like this(bumps), ppl solved by turning vsync ON, not vsync causing it...[/quote] Glitches/bumps/jumps shouldn't be resolved with vSync unless their transformations are being updating on a frame by frame basis rather than time (you should almost always be using time for this). Vsync is implemented to reduce screen tearing, which looks like your screen has a horizontal rip in it. [quote]I did found that from times to times, I get a frame running at 0.03xx, witch is a 30fps value[/quote] This is likely due to the fact that your monitor is refreshing at ~60Hz, which means with vSync enabled, Present() will block until your monitor is in the vertical blank state, throttling your game to 60FPS. It will drop to 30FPS if one of the updates takes longer than 60Hz and misses one of these vBlanks, thus the next update won't get around until two vBlanks.
  8. I have an application that needs to run on a duel monitor chassis, and have created two windows with two swap chains, positioned and sized to simulate full screen. My device is set to windowed mode. The way I'm currently handling screen tearing is by setting PresentParams.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE, and manually checking for vertical blank using SwapChain::GetRasterStatus() before rendering, otherwise skipping it until next update loop. My issue is that I still get tearing, but near the top of the screen. Is this because my rendering is taking a little too long, and we leave vBlank before I present? Also, in my case where I have two monitors and I'm rendering in Windowed mode, how does GetRasterStatus() know which monitor to query? What's stopping me from placing the window between the extended desktop? When I set PresetnParams.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT without manually checking for vertical blank, my updates and rendering are throttled to 60FPS (obviously) and gets rid of tearing, but it produces inconsistent framerates which aren't acceptable. When I set PresetnParams.PresentationInterval = D3DPRESENT_INTERVAL_DEFAULT and also manually check for vertical blank my rendering drops from 60FPS -> 30FPS... so it seems to be missing every other vBlank. Any ideas?
  9. Some questions you might want to consider: [list][*]Do you (and your team) feel comfortable in a C++ environment?[*]Will the scope of the game or future games benefit from the switch? Will the game will push your target platform's resources to its limits?[*]How much do you currently rely on XNA's content pipeline?[*]Do you like writing tools and engines? Or more interested in the game development?[*]Do you prefer handling your own memory allocations?[*]Are you targeting XBOX 360 Indie games? I think you have to use XNA for this.[/list]I started writing my personal game engine in XNA and eventually made the switch to DX (early on) because I preferred the flexibility/performance over productivity... and over long term, it'll set me on the right track to keep up with the latest technology. I found it more rewarding knowing I don't have the overhead of .NET framework and have complete control over the memory.
  10. This is odd, but it fixes the issue... When I return from losing focus and my frame rate is dropped, If I force a lost device and reset it... it fixes the performance issue. I didn't think it was possible to be in some sort of limbo state of a lost device, but apparently something in D3D is slowing down when returning focus, and TestCooperativeLeve() was still returning successfully.
  11. That's a good idea to check WM_ACTIVATEAPP for any weird anomalies, and I am handling a lost device properly. However the device doesn't actually get lost when I minimize or alt-tab... probably because I'm in windowed mode. So it must either be something else, or something on the OS level (hope not). I'm not sure what else to check for. [b]Within the task manager, I can right click a process and increase the priority. Can this value be set by the application itself?[/b] [b]Does anyone think this might help?[/b] [i](As a side note, the only time I've been able to lose the device when in windowed mode is to press alt+ctrl+del.)[/i]
  12. I have a DX9 application that creates two windows and renders to each of them. These windows are not full-screen mode, they are windowed mode set to the system's resolution size to emulate full-screen. Everything works fine until the user either alt-tabs or minimizes the window, which the framerate is noticeably slower when they return. [b]-BEFORE LOSING FOCUS-[/b] Update FPS: ~63000 Render FPS: 60 (throttled to match vSync) [b]-AFTER LOSING FOCUS AND RETURNING-[/b] Update FPS: ~25000 Render FPS: 30 I find it odd that the render frames are cut in half perfectly[size="4"][b]*[/b][/size], however the update frames are cut significantly as well so it's clear I'm not getting the same CPU time slice from the OS prior to losing focus. This application is running on an XP Embedded OS system that is pretty bare bones. When I test this same scenario on my dev machine, which is Windows 7 64bit, I don't have this issue. [size="4"][b]*[/b][/size]Now that I think about it... my rendering is on the same thread as the updates are. I just skip the rendering portion if we're not in vSync. I'm starting to think now that since my updates are cut down, I'm missing every other vSync occurrence. It still doesn't explain why my updates are slow when returning focus though, if anyone has any input on that please let me know. Thanks!
  13. m_pd3dDevice[color=#f1e943]->[/color]SetRenderState[color=#f1e943]([/color]D3DRS_ZENABLE[color=#f1e943],[/color] D3DZB_FALSE[color=#f1e943]);[/color] Then render in the order you want to display everything.
  14. Can I render polygons/(orthographic 3D data) over ID3DXSprite? If so how is this done? Are there any good examples on D3DXSPRITE_OBJECTSPACE? I already have everything set up to use screen coordinates and like to keep it that way. Thanks.
  15. I haven't been able to find any good way to render filled shapes in DirectX9... I have a 2D engine currently utilizing the ID3DXSprite interface but I now need the ability to draw procedural graphics such as rounded rectangles, lines, and circles. I've tried ID3DXLine... but I can't fill the shapes I create I've tried Direct2D... but that isn't supported on XP, which is my target platform. I'd prefer hardware accelerated gfx, but I've tried messing with GDI as another option. I wasn't sure how to tie it into my current render loop since I don't use WM_PAINT. I would need to be able to layer GDI drawing calls beneath and above some ID3DXSprite begin/end calls which should be possible right? My last option would be to render orthographic polygons to the screen to make my desired shapes. I tried messing with this briefly using DrawPrimitiveUp(), but it would always render behind my ID3DXSprites regardless of the 'Z' value I gave it. What's a better approach to this method? One that I can specify already transformed coordinates (screen/pixel coordinates)? Thanks, for any help!