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

AlanWu

Members
  • Content count

    61
  • Joined

  • Last visited

Community Reputation

241 Neutral

About AlanWu

  • Rank
    Member
  1. MS releases new D3D versions on roughly the same schedule as new GL versions appear. D3D9~=GL2, D3D10~=GL3, D3D11~=GL4, D3D12~=Vulkan. All those old APIs still work fine, despite being obsolete/deprecated. You can already use GL on Windows systems (Vulkan is basically just GL5), so there should already be no point to DirectX any more... Right?   Good idea. However, if I use toGL to change my D3D9 codes into OpenGL, will there be a big drop in performance?
  2. Thank you for replying. So apparently drivers is an issue. 
  3.   As I said, I think it is perfectly fine to render buttons, etc.. directly instead of creating seperate window elements for them. I wouldn't worry about the other way around though, whats the problem with programs analyzing your UI? The one advantage over having seperate windows is if you really have a window that pops up, like an asset editor, and you want the user to be able to tab between it and your editor. THEN is the time to pop up a seperate window.   But again, if you are planning on using this for an editor, I once again like to urge my opinion: DON'T. I did it myself, and its a path of no joy. Do you want to do this as a learning experience? Thats is fine, in this case keep going. Do you want to be productive and create a future-rich editor in no time? Then stop with this approach, and just get Qt. You'll have most of your editor in like 6 months compared to 2 years of pain. I did this myself, and yeah, I still to this day sometimes cringe over the bugs and flaws of the UI system, and having to write a new sort of advanced widget type is always a pain (next up would be allowing windows to be reinserted into the docking structures for me, ugh). Don't worry about factors like external applications being able to analyze your UI then, its a non-issue, since literally every other UI application is built that way, only very few do their UIs themselfes (Unreal Engine it appears, but their manpower/knowledge behind this is also much better).         To put more emphasise on it, the main disadvantage is that its awefully unproductive, even if you need to learn QT, its like 4-16 times faster. Learning a QT widget is like maximum of few hours of reading the (good) documentary and trying it out, writing the same widget can take days, and you'll spend even more time fixing bugs, and polishing. Again, if you are in for the learning experience, its fine, but don't expect to gain anything from doing it other than that.         I still don't think you have to worry about this. Remote desktop manages to capture all 3D game applications so far (I once was foolish enough to try playing highend games over the internet on my phone, lol). The point is, its regardless of what those applications use, they will most likely capture the content of the framebuffer, and don't even care what application is visible, so you don't need to care eigther. If in doubt, try it. Just render a colored quad in OpenGL and pop in your target capturing program, and see if it works (it should).   Thank you very much for your full and detailed answer. I'll consider about that! :)
  4. Thank you for replying. I am planning for editors/tools. I guess I didn't express what I meant clear enough, sorry about that. What I meant by child windows are window components like buttons and edit box(they're child windows in MFC). I personally think it's better just to render the components, instead of creating child windows for them. Actually, what is point of that? That allows other programs to easily analyze my GUI. What do you think? What I meant by screenshot is the case when other programs try to screenshot my GUI, such as remote desktop. Some of those program uses GDI to screenshot so..   Are there any disadvantage if I use OpenGL to make GUI for editors/tools? I think the two disadvantages I mentioned above are not really disadvantages. What do you guys think?
  5. Hey guys, I think using OpenGL/DirectX to build GUI is a very good idea because it has hardware acceleration and advanced graphical features, which can produce a dynamic and awesome-looking GUI. However I can't find many GUI engines that are based on OpenGL/DirectX. I searched about the disadvantage of using OpenGL/DirectX to build GUI and the two disadvantages I found is: The GUI that are based on OpenGL/DirectX bypass a lot of abstract layers and access graphics card directly, which can cause issues when trying to screenshot the GUI (or windows made by the GUI) by GDI. Also, usually a window is made up of a lot of child windows, e.g. button, edit box, etc. The GUI that are based on OpenGL/DirectX don't have any child windows so the layer is invisible to outside(other programs). I think the screenshot problem can be solved by cooperate GDI into the GUI engine (probably use GUI to draw the buffer?). For not having any child windows, I personally think it has no problem and is an advantage since you don't want other program to analyze your GUI easily. What do you guys think? Thanks!
  6. Thank you guys very much. I now know what I need to do. I've never used OpenGL and it seems I need to do much more work with it than if I use DirectX. Since I want to support old computers, I might go with OpenGL 2.1. I'll decide that later.
  7.   Yes. You can use DirectX directly on windows, while with OpenGL you have to eigther import the DLL commands yourself (don't do it), or use an external wrapper libary like GLEW, to even be able to do anything with it. Also with DirectX you can directly use your created Windows hWnd, while in OpenGL you must configure your window to have a special HDC and use that. Other than that, using OpenGL is not that much different than using it on any other platform (supposed you even write the application creation code yourself and don't use SFML or what not). In any way this is NO reason to use DirectX on Windows if you already have an OpenGL renderer.     Recent OpenGL version have a very bad support rate, I know PCs from < 3 years ago that don't even support 3.4 or whatnot. As for features, if you are making a 2D game, there are not that many of use for you anyways. The wikipedia-page on OpenGL has a full list of it, but I don't see what you could really need. For example, I decided to require at least OpenGL 3.1 as they introduced uniform buffer objects which tied in with my pipeline much more (otherwise I'd have to redesign that), but you shouldn't need that. So OpenGL 2.0 should be just fine. Thank you for your reply. I'll consider about that.
  8. Ugh... those users are a nightmare by themselves. I wouldn't want them as customers. Even if they pay you (chances are they don't, otherwise they'd not have a computer that they pulled out of the trash can), they cannot possibly pay you enough for the support cost they will cause. True. My customers have to know how to follow instructions at least. It seems OpenGL 2.1 is really bad and can potentially cause a lot of problems?
  9. Haha I like your stories. Yea driver quality, that was what I was trying to ask. The point is that I want to support old machines. I wonder if driver can be an issue if I use OpenGL? Also, I hope to support almost every machine, including those very old PC (about 10 years old I guess?) Since I am making a 2D engine, I don't need many advanced features. Is OpenGL ver. 2.0 my best option or should I use a later version?
  10. Yea it helps. Thank you! :) Some more questions: 1. Some people say DirectX has less gotchas and headaches than OpenGL on windows. Some also say OpenGL has worse drivers than DirectX. What exactly are they referring to? Will there be any problems or is there anything I need to be aware if I use OpenGL on windows? 2. I hope to support almost every machine, including those very old PC (about 10 years old I guess?) Since I am making a 2D engine, I don't need many advanced features. Is OpenGL ver. 2.0 my best option or should I use a later version?
  11. I am planning to make a game engine. My target platforms are: android, ios, windows, mac, lunix. OpenGL should be enough for all of my target platforms but is there anything I need to be aware? (Because I see some game engines support both DirectX and OpenGL while supporting only those platforms I mentioned above) Thanks!
  12. A viewing frustum is the region in the modeled world that you can see at different distances away from your eye. In other words, it tells what direction a light ray comes in will contribute the image. Question: Does it mean that if a light travels at a direction that doesn't fit the viewing frustum, the light won't contribute to the image? Will the light refract at the viewport of the viewing frustum just like light refracts at the surface of our eyes?   Thank you very much!
  13.   Well, since you are using a index buffer, you are really drawing 6 vertices (or 12 respectively), and not 4. Four sort of worked with the trianglestrip since for a strip, 4 indices form a quad, but each index gets expandet to its corresponding vertex, so unless I am very mistaken (I'm just recalling this from the top of my head) it should be the number of indices in a index-buffer driven render process here. Or is it working the way you have it now with trianglelist and 4/8?   I think I am correct because the writer of Inroduction to 3D GAME Programming with DirectX 9.0 write this code: Device->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, 0, 0, 8, 0, 12); It is a cube. It has 8 vertices, 6 surface (12 triangles).
  14. Thank you a lot. I understand it now. For Question No.1, (as,as,as,as) is from MSDN. http://msdn.microsoft.com/en-us/library/windows/desktop/bb172508(v=vs.85).aspx What about Question No.3 ,4 and 6?