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

Swatter555

Members
  • Content count

    204
  • Joined

  • Last visited

Community Reputation

127 Neutral

About Swatter555

  • Rank
    Member
  1. I am stuck.   - I cannot compile the linked program because I have a poor mans version of Visual Studio.   - Even if I could compile the program and use it, DIrect2D automatically scales everything if I declare my application as DPI aware.   Bottom line, unless I figure out how to disable Direct2D automatic scaling, I cannot implement a custom scaling solution. Unless someone can tell me a way to disable virtualization without making my application DPI aware.
  2. marcClintDion-   Thanks for the tutorial. It helps to go back and think about the basics. As I was thinking about supporting different resolutions, my first thought was just to express all graphical elements as a percentage of the viewing surface. Say a button would be 2% by 1.5%. I haven't really had much time to test it, but it seems like a good idea. Although, I would imagine the screen would not be a carbon copy across all resolutions, but then again that might be ok.   Then again, I really cannot escape the logic of what irreversible is saying. I guess that is the answer.   As I said though, Direct2D automatically scales, but I would assume that can be disabled. I wish someone would write a book on Direct2D, MSDN is only so useful.   Let me see about implementing a true scaling method like irrev is talking about. Ill test it across various settings and get back to you.
  3. I will do my best to understand here, I am pretty tired so hopefully I make sense.   PunCrathod-   In Visual Studio Express 2012, there is a flag for DPI awareness that says it automatically makes changes to the manifest. At least that's what it says. Does that not really work?   I may be tired, but doesn't the formula: <horizontal DPI> * <width, in pixels> / <default horizontal DPI> result in a larger window at higher DPI?   I must not be understanding what is going on correctly, but when someone changes their DPI, they are wanting larger text and icons. I read one MSDN page that encouraged people to use their max monitor resolutions and just use higher DPI settings if they have trouble with small icons and print. I just don't see how that effectively increases monitor resolution. You have bigger text and other items in the same space.   Unless you are truly dealing with a display device that handles higher dpi, your just resizing your display elements. I am missing something.   irreversible- Thanks for the link. Once I understand what the heck Windows and Direct2D is doing, that something I can look into.
  4. I have been trying to Google combinations of those terms like crazy and I can find very little info. I am coding a full-screen application using the DIrect2D API, which automatically scales rendering to current DPI setting. That is all fine and dandy, but higher DPIs effectively decreases resolution. If I were creating a windowed app, I would create a larger window and everything would scale nicely. However, for full-screen, part of the screen is going to be clipped.   I have turned up very little info on my internet searches, so I am kinda stuck about what I should do. I could make the app use windowed mode, but that opens up a can of worms in itself. Direct2D uses dips for everything, so I don't think I can tell it not to scale things. What am I missing about DPI awareness and full-screen applications?        
  5. [quote name='Swatter555' timestamp='1334821168' post='4932715'] Direct2D's BeginDraw and EndDraw operate only in response to WM_PAINT messages sent by the window message pump. Setting up a traditional game loop results in the window never updating. You can call Render() outside of the winProc, but it will ignore it. I experienced it first and then read it in the D2D documentation. Perhaps I am misunderstanding your post or perhaps you need to further elaborate. I do want to create a traditional win32 application, but I need to control the render rate properly. [/quote] I was mistaken, you can place the OnPaint/Render in the traditional manner. Not sure why I couldn't get it to work before and I no doubt misunderstood MSDN docs I read. I do remember reading that you needed to call OnPaint in response to WM_PAINT, which is probably true, but I just didn't understand it in context. Even so, I still can't get rid of the bottleneck. I must be misusing D2D in some way with the large number of little bitmaps I am drawing for the map.
  6. I went ahead and took out my SendMessage calls and substituted it with InvalidateRect calls. Unfortunately the strange bottleneck behavior remains. Does anybody actively use Direct2D around here who can guide me on how to use it properly in a game application? The MSDN examples only update the frame/window on resize or other rare conditions. If D2D is tailored to games (or is supposed to be), I am truly in the dark to making it work properly. How many truly robust game applications only update the frame/window on rare occasions? For all of the cool things Direct2D does, there are too many drawbacks. 1) The only real examples I find are on MSDN (which are of limited value). 2) Nobody seems to work with it. 3) Trying to run a robust/updating game application through the windows message pump seems pure folly. Please, someone guide me down the correct path!
  7. Direct2D's BeginDraw and EndDraw operate only in response to WM_PAINT messages sent by the window message pump. Setting up a traditional game loop results in the window never updating. You can call Render() outside of the winProc, but it will ignore it. I experienced it first and then read it in the D2D documentation. Perhaps I am misunderstanding your post or perhaps you need to further elaborate. I do want to create a traditional win32 application, but I need to control the render rate properly.
  8. I have created my own rendering engine using D2D and I have ran into problems much of the way, most of these problems have dealt with the windows message pump in one way or another. Each step of the way I tested and tested to make sure the code was solid, but I am getting some strange behavior when rendering my 2D hex map. During execution, everything seems to run fine, efficiently and as expected. However, randomly, at some point during execution the frame rate creeps to almost nothing. Sometimes it returns to normal, sometimes it doesn't. Generally, in debug mode, the game loop executes a couple million times a second (doesnt do much), while paint calls are made 33 times a second. When the slowdown occurs, both slow down to 17. The code that renders the map is simply 2 nested for loops rendering a single small bitmap, nothing complicated going on (no other rendering occurring besides diag text). I suspect the message pump is to blame again and my lack of understanding about what is truly going on behind the scenes. I regulate the number of paint calls using SendMessage (WM_PAINT). Most programmers don't use Direct2D and dont have to deal with the windows message pump in game application settings, so I couldn't find any direct examples about how to regulate paint calls. I don't even know is that is related to the problem. I hesitate to post code because I truly have no idea what is going wrong. Any advice, suggestions? I plan to get a book dedicated to win32 programming when my budget allows, so cross that one off the list. I found rendering textured quads so much simpler in D3D. I don't know if I am riding the new technological wave or barking up the wrong tree with Direct2D. There are some cool things on the horizon for Direct2D, so I hope I can resolve these issues.
  9. I am using a game window that sizes to current screen resolution. I am also rendering graphics with the Direct2D API, which is dependent on the windows message pump WM_PAINT messages. I am fiddling around with changing desktop resolution (as a user might) and trying to get not only the window to resize correctly, but also getting the RenderTarget to resize correctly. Without getting too far in the weeds, my RenderTarget is not resizing correctly immediately after res change (I am resizing it with LPARAM from the WinProc). It seems to be a timing issue, because I can minimize then reactivate and the RenderTarget sizes correctly. It seems like the LPARAM from the WinProc isn't passing the correct client size on the resizes that happen immediately after res change. Does that make any sense? [code]LRESULT CALLBACK WindowProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { //Get window width and height UINT width = LOWORD(lParam); UINT height = HIWORD(lParam); //Route the message switch(message) { case WM_CREATE: { }break; case WM_DISPLAYCHANGE: { InvalidateRect(hwnd, NULL, false); //Entry into log CTools::GameLogAdd(false,"WM_DISPLAYCHANGE"); }break; case WM_SIZE: { //Resizes window and render target if(pApp->IsInitComplete()) { //Resize the window pApp->GetD2DPtr()->OnResize(hwnd,width,height); }//end if if(SIZE_MINIMIZED == wParam) { }//end if if(SIZE_MAXIMIZED == wParam) { }//end if }break; case WM_NCLBUTTONDOWN: { //Prevents user from moving window via title bar if (HTCAPTION == wParam) return 0; }break; case WM_DESTROY: { PostQuitMessage(0); return 0; }break; case WM_PAINT: { //Call Direct2D rendering routines if(pApp->IsInitComplete()) { pView->OnPaint(); ValidateRect(hwnd, NULL); }//end if }break; case WM_KEYDOWN: { switch(wParam) { case VK_SPACE: { }break; }//end switch }break; }//end switch //Handle any remaining messages return DefWindowProc (hwnd, message, wParam, lParam); } UINT CDirect2D::OnResize(HWND _hwnd,UINT _width,UINT _height) { //Check if window is able to be resized if(!IsResizable()) return FAIL; //Get current screen size int width = GetSystemMetrics(SM_CXSCREEN); int height = GetSystemMetrics(SM_CYSCREEN); //Reset window position MoveWindow(_hwnd,0,0,width,height, true); //Resize the Direct2D render target GetRenderTarget()->Resize(D2D1::SizeU(_width, _height)); //Entry into log CTools::GameLogAdd(false,"D2D OnResize: Called"); return SUCCESS; }[/code]
  10. Quote:Original post by ET3D Quote:Original post by Swatter555 Thank you for the reply. I am aware of alpha blending and other ways to perform such actions, but as I said that is not something I want to do. I am performing many, many calculations determining what will go onto each tile. Also, I dont want to perform up to 20 x 16 x (up to 15+) blending operations each frame. You misunderstand. What I suggested is doing this once, into render targets, then reusing the render targets during the frames. Your response suggests to me that you don't understand render targets. I'd suggest that you read about them. I once again thank you for the reply. Render targets return a IDirect3DSurface9 pointer, which is easy enough to understand and that would certainly make sense, but as I said I am using the irrlicht open source engine which I would doubt would allow such operations without modification. It is possible to uncover the directx device directly, but that is discouraged from what I understand. That is reason that I was asking for solutions that allowed manipulation of the textures using the lock method, which is a functionality allowed by the engine. Also, as I read the thread even closer it seems like I simply cannot state exactly what I was looking for. To be as exact as I can, I was searching for a way to combine 2 textures, using the lock/unlock methods that would allow me to copy the needed pixels from a source texture to a target texture. Irrlicht will either use the alpha value of a texture for transparency, or it will accept a color key when the texture is loaded. I am loading the textures intially with color keying, and I am very confused how this will affect copying pixels from the source to the target. I hope I have clarified what I am asking for, I am not sure how else to ask it. Thanks for the help and interest. I edited the message for clarity, which I am lacking to a large degree in this thread. [Edited by - Swatter555 on March 25, 2007 10:04:05 AM]
  11. Thank you for the reply. I am aware of alpha blending and other ways to perform such actions, but as I said that is not something I want to do. I am performing many, many calculations determining what will go onto each tile. Also, I dont want to perform up to 20 x 16 x (up to 15+) blending operations each frame. Each tile could have up to 15 layers. To me the simplest option is to combine the textures once during initilization by locking the texture and copying one texture onto the other, that is the root of my inquiry. My question is how do I properly copy one texture onto another using the lock operation while still maintaining the colorkey value on the textures. If you tell me that performing 4800 blending operations per frame wont hurt performance, then that might be something I would consider.
  12. Exactly what I am doing is combining a base texture (say a grass tile) with another (say a trees tile). The final result will be the base grass texture plus the trees texture. I might need 5 - 10 textures combined into one ultimately, so I can simply draw one texture for one tile each frame. I dont really know how to be more specific than that, please elaborate on exactly what info you need.
  13. To be clear, I am not talking about alpha blending. I need to combine two textures together, I believe using the lock method. I cant seem to find the correct terms to google, so I will give it a try here. Now, I am trying to combine several textures together to form my 2d map tile. There could be so many potential "layers" that locking the texture and copying the next texture on top seems to be the best way. I am using an open source 3D engine (irrlicht) that doesnt like it when you directly uncover the directx pointers, but locking textures isnt a problem though. All of the textures I use are colorkeyed, so I need to preserve that. How can I properly perform those actions? If anyone knows of any links to a article that directly covers this, I would appreciate it.
  14. I don't know exactly what market you are trying to tap, but I would think your ideal market would be small independent development teams and individual developers. I would think that larger teams would develop their own GUI system in-house, with more flexibility built in. So, I would definately say the price should be dialed to a level that could be contained within the small budget of small developers. If you want a clue as to a price you should charge, look at other products aimed at independent developers. Garage Games has a number of products aimed at small developers. If I were to classify your product in a price/usefulness category, I would be thinking about something like GameSpace or some similiar product. I would also recommend that you have a native english speaker re-write the text on the website. It just doesn't look professional enough (completely my opinion and I could be wrong) for me to spend alot of money there.
  15. Thanks for the assistance, I will continue trying to get it to work. It might be a problem with the engine Im using.I need make sure its not that.