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


  • Content count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About LarsMiddendorf

  • Rank
  1. What about MDX1.1 and D3D9Ex? Will it be supported ?
  2. Nice. Looks interesting. Too bad it only runs on Vista.
  3. Aha, thanks. That could be a good solution to remove the non-orthogonality between the default and additional swap chains. I hope this doesn't degrade performace. On NVidia cards there is/was sometimes only early-Z on the first FrameBuffer Object (OpenGL.)
  4. Can I delete the default swapchain? For example what should be done if the window with the default swap chain is closed and the other window with the additional swap chain remains open?
  5. Is there a problem when doing the following for a MDI application. 1)Create one backbuffer with the size of the MDI parent window. Use D3DSWAPEFFECT_COPY. Then foreach MDI child 2)Before rendering to a child window, change viewport. 3)Override Window Handle and Rectangle at Device.Present
  6. I encountered the same problem and I've got a list with WeakReferences to the owner object for every opengl texture id. Every time a new texture is loaded and of course at the end, all WeakReferences are checked and if the owner is no longer alive, the texture id is also deleted. The problem with the C# destructor is, that it is called from another thread and opengl rc are per thread.
  7. You can uses the generic GraphicsBuffer<T> that has got a special write method for the generic type. All functions returning a GraphicsBuffer are overloaded and can also return a generic GraphicsBuffer.
  8. I think it has moved to EffectCompiler.CompileShader(EffectHandle functioname,string target,ShaderFlags flags)
  9. It seems that they have changed the event handling. Even if Device.IsUsingEventHandlers is set to true, resizing the control doesn't cause the device to be reset like in older versions. Where can I find more information on the new API. The documentation in the SDK decribes only the old MDX.
  10. The only problem using C# as a scripting language is that you cannot unload and update your classes, if the assembly is loaded into the same AppDomain. But creating a secondary AppDomain is also not very usable because calls between different AppDomains are very expensive.
  11. [QUOTE]So, plugins are a perfect middle way between old school unflexible pipelines, and the complete abstraction of the rendering system into meta shaders. Once we have well working meta shaders (we will probably need hardware supported JIT compilers for that), we can just trash the plugin approach. And I'll be happy about it, because the system has in fact several drawbacks. Just not the ones you were thinking of :) [/QUOTE] How will your meta shaders look like ?
  12. @Yann L: How do you solve the problem with the big number of shader permutations? With PS30 HW you can put 4 or more lights(with shadowmaps) into one rendering pass. But each light/fog should also have its own shader fragment: point light, spot lights, lights with a cubemap, volumetric fog. Combined with some material shaders the number of combinations grows exponentially. Precompiling is impossible but creating on the fly is also slow. Cg's interfaces are nice, but they don't really help here, because the cause a recompilation. Generating asm shaders is doable, but you lose specific compiler optimizations(and it's even impossible with glsl).
  13. C# is great and becomes even greater with each release. Queries as a language feature is a nice idea. But I'm sceptically about the ML-style features like the combination of lambda-expressions, type interference and generics, which allow to write code, that is difficult to read, because the types are no longer obvious. http://blogs.msdn.com/abhinaba/archive/2005/09/17/469568.aspx
  14. You could also try this. One .cs file(safe), but only .Net 2.0 . http://www.3d-seite.de/csopengl
  15. OpenGL

    @zedzeek: This doesn't really solve the problem. I can't specify each shader and I always want render one pass with PS30 to save geometry bandwidth. Each light has got it's own shader and the number of light shaders is not limited or predefined to support all types of light and fog effects. I don't want to and I just can't create a special shader for each type of light/material interaction. So the shaders must be generated dynamically. This works ok, if only doing one light per pass, because the light/material combinations can be often reused. But when rendering all lights in one pass there are too many combinations and recompiling a Cg shader or linking a GLSL shader is not free. Linking a GLSL Shader with NVidia drivers takes ~50ms so it is even impossible to link a large number of shaders at startup. Perhaps deffered shading is the most elegant solution to this problem, because materials and lights are rendered seperate. @Sorting: What about batching in OpenGL. How important is it? When using static index buffers, merging index lists is only possible if two geometry block are lying directly one behind the other.