• 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

4411 Excellent

About C0lumbo

  • Rank
    Advanced Member
  1. I wish Android would do some equivalent of iOS's multipeer and bundle all their direct device-to-device technologies under one comms layer agnostic API. I don't really want to have to write code to support bluetooth, WiFi Direct and WiFi Aware (new for Android O - https://developer.android.com/preview/features/wifi-aware.html) just for some 1 vs 1 multiplayer to accomodate a minority of users who want to play when there's no router around.
  2.   0.5/0.1/0.1 is a dark shade of red.  This is what it looks like. If you view the screenshot in an image editor you'll see that they have RGB 121/23/22 which is (mostly) correct (allowing for rounding and FP imprecision). Is this a single-buffered GL context?   Doh - I misread it as RGBA .5f 1f 1f 1.0f somehow!
  3. In your no-blending example, why are you getting red dots when the shader output is RGBA .5f, .1f, .1f, 1.0f ? Typo?
  4.   Agree that this is your only option. Another thing to bear in mind is that if you have a desync bug in your client code that only affects certain clients (e.g. maybe it affects users with certain hardware, or users with certain options set) then you're in real danger of flagging them as a cheat (a false positive) so you must be careful in your punishment strategy. In terms of spotting the specific cheat you've identified, I don't really know, but if you're on Steam, then perhaps Valve-anti-cheat could help. If you block this one particular cheat implementation, then another will pop up in its place.
  5. I've also seen a big drop in downloads from China starting from about the same date. Was bouncing from around 50 to 100 downloads per day in China, just dropped to 10-30 from April 4th. That said, March seems to have been a good month for us in China, and we've only really dropped to pre-March levels, so my data isn't very conclusive. I have decided I'm not going to bother chasing Chinese approval.
  6. Using a copy from a VkBuffer instead of from a linear texture is definitely the right track. Trying to use a linear texture for staging is an exercise in frustration because you run into the irritating limitations that apply to linear textures (like limited format/mipmap support). You shouldn't have to worry about implementation specifics though. Section 18.4 contains pseudocode describing how it expects your texture data to be laid out in your VkBuffer prior to a call to vkCmdCopyBufferToImage. Assuming you're not using a block compressed format, the spec says: rowLength = region->bufferRowLength; if (rowLength == 0) rowLength = region->imageExtent.width; imageHeight = region->bufferImageHeight; if (imageHeight == 0) imageHeight = region->imageExtent.height; elementSize = <element size of the format of the src/dstImage>; address of (x,y,z) = region->bufferOffset + (((z * imageHeight) + y) * rowLength + x) * elementSize; where x,y,z range from (0,0,0) to region->imageExtent.{width,height,depth}. There is no need to worry about implementation specifics for staging texture data, that's the driver's problem/responsibility.
  7. It isn't clear from the OP why you don't plan to go to university, but if you wanted to get a degree, I reckon you'd be able to get onto plenty of computer science or games programming courses on the strength of those A-level results (although to get into better universities, you might need to retake that math A level). I'm not saying you should get a degree, or that you have to, but just saying that if you think your A-level results have excluded you from that path, then I don't think it's the case.
  8. Wonder if Apple are talking down the stock so they can buy out the whole company.
  9. The big UK conference is Develop in Brighton: http://www.developconference.com/passes-and-prices University of Essex have something called The Games Hub. This is a slightly old news story but has contact details for the guy who runs things there (top bloke) and you can find out what it's all about: https://www.essex.ac.uk/news/event.aspx?e_id=10916 Depending on your level of experience, you might be able to get some guidance, or give out guidance to enthusiastic students.
  10. Vulkan

      Yes. Although I think it's rare that VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT is the best option for synchonisation commands. If your sync primitive is waiting on a previous render to texture which you'll read in a fragment shader, then VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT is overkill, it's only the fragment shader that needs to wait - so your dstStageMask might be VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT. Or if you're waiting for a vertex shader to finish reading from a texture before you scribble over the top of it, then srcStageMask might be VK_PIPELINE_STAGE_VERTEX_SHADER_BIT.
  11. Vulkan

    Interesting question. I believe it corresponds to the VK_PIPELINE_STAGE_* enums. In this case, if you wanted to use a synchronisation primitive like vkCmdPipelineBarrier to wait on completion of vkCmdClearDepthStencilImage, you need to use VK_PIPELINE_STAGE_TRANSFER_BIT. Edit: So a less abbreviated version of the 'pipeline' heading would be 'pipeline stage in which this command is executed'
  12. DrMemory might be a decent alternative to valgrind to avoid the need to run on a linux VM. You might also find memory issues by using _CrtCheckMemory or _CRTDBG_CHECK_ALWAYS_DF: See https://msdn.microsoft.com/en-us/library/974tc9t1.aspx
  13.   Yeah - I suspect that too. I wouldn't be surprised if the management of the CPU/GPU clock speed is dynamic enough that launching a new program or alt-tabbing out could lead to a temporary speed recovery.
  14. OpenGL

    Whenever I fix a bug, particularly one that takes a lot of time, I spend a moment thinking about how it could be avoided or caught faster in the future. Usually that involves adding some asserts. In this case, the trick is to enable floating point exceptions - at least on your PC build - with floating point exceptions enabled you'd have crashed immediately on the divide-by-zero and would have fixed the bug in just a few moments : https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/
  15. AFAIK, you're fighting a losing battle trying to get pixel perfect results with GL_LINEAR in OpenGL. DirectX9 guaranteed you could do it by rendering at the right size with a half-pixel offset, but I think with OpenGL you just have to avoid bi-linear filtering. Note, I'm not 100% confident in that assertion, so very happy to be corrected.