• 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

787 Good

About incertia

  • Rank
  1. Okay so it looks like a window manager issue. Launching X without a window manager creates the borders on the outside.
  2. Hmm, so if a window manager desides to grow a border internally, that should be a bug? My current issue is with XMonad, where I have configured it to give floating windows a border width of two pixels, and the client area shrinks to make room for the border.
  3. Under Windows platforms, we have access to AdjustWindowRectEx to make sure that the client area has the desired size. Due to the diversity of window managers available on Linux systems, is there a way to have X11 ask the current window manager what the correct properties should be to get the desired client area, or should we wait for the first expose event to determine the correct settings?   On a related note, is there a way to impose window size restrictions in X11? Or is it up to the window manager to honor the WM_NORMAL_HINTS property?
  4. Vulkan

    This is a what if scenario, no real reason behind it.   Thanks for sharing your experiences though. I guess I'll stick with just creating one queue for now. 
  5. I'm working my way through some vulkan examples, and I just want to make sure that my understanding of queues is correct.   Each physical device has a set (\(Q\)) of queue families, and each queue family has some amount \(N_{q \in Q}\) queues that can be used. When creating a logical device, you specify some amount of logical queues you want to create, such that the sum of each queueCount property for each queue family \(q\) is not greater than \(N_q\) (maybe some unforseen circumstance has led us to a VkDeviceQueueCreateInfo array of [(family=0,cnt=2), (family=1,cnt=1), (family=0,cnt=1)]). The driver will take care of multiplexing the queues, e.g. if I create two logical devices with 8 queues each from the same queue family, whether or not the driver assigns both logical queues \(0, \dots, 7\) to physical queues \(0, \dots 7\) or \(0, \dots, 15\) is none of my concern, the plumbing is all taken care of by the driver.   Different queues can be submitted in paralle, but extra safety should be taken care of to make sure that the command buffers don't screw with each other if they interact with the same object. Retrieving queues gets retrieved in the order created. e.g. If my VkDeviceQueueCreateInfo array looked like [(cnt=2,priorities=[1.0,0.5]), (cnt=1,priorities=[0.2])], I can expect that vkGetDeviceQueue(device, family, [0, 1, 2]) has priorities [1.0, 0.5, 0.2]). Queue priorities are a relative number, such that the following metaphor makes sense: if each queue can be represented as a thread, a priority of 1.0 means that the thread should work as hard as it possibly can while a priority of 0.5 means that it should only work half as hard, with the union of all threads representing the queue processing power of the entire physical device.   If I said something wrong, please feel free to correct me. I want to make sure I'm not misunderstanding something fundamental.
  6. So I'm trying to implement a doubly linked list again after horribly failing the last time I tried a few years ago, and I was remined again why I disliked reversing the list through pointer exchange. // assume ListNode is a valid type // and head/tail are initialized properly somewhere and filled with data ListNode *head; ListNode *tail; void reverse(ListNode&* start, ListNode&* end){ ListNode *c = start; while(c && c != end->next){ std::swap(c->next, c->prev); c = c->prev; } // some extra logic goes here, i'm not sure what } // reverse(head, tail), reverse(head->next->next, tail->prev) should all be // valid function calls on the dll I can never seem to figure out what that extra bit of logic is to correctly update the references and pointers from other nodes. std::swap(startPoint->next, endPoint->prev); std::swap(startPoint, endPoint); does not seem to be enough to correct the pointers.
  7. You are quite ambiguous with the results don't really come out to what they should be. This code will never put the value 0 into the new array because NULL evaluates to 0 and you only add non-zero values. C/C++ is not like Java in which null refers to nothing. In C/C++, NULL evaluates to 0 and you set pointers to NULL or nullptr because accessing memory at location 0 is guaranteed to crash your program. Setting the ones you don't want to -1 would work better because rand() % 10 will always be positive because rand() is always positive. Perhaps you could give your program's output and your expected output.
  8. I don't have any Rijndael at hand with me right now, but this is a working version of Rijndael and you can just add some stuff to get the expanded key.
  9. Things would make a lot more sense if you also posted how you chain these calls together in your actual program.
  10. They do not necessarily have to be adjacent I believe. Present basically flips the buffers by swapping the pointers to the array containing pixel data of the back and display buffer or just copies the contents of the back buffer to the display buffer. It's one of these, but I'm not quite sure which.
  11. Windows 7 support seems to be a key issue around here and I agree. With most PCs running Windows 7, it would be a shame for Microsoft to make this a Windows 8 or even Windows 8.1+ exclusive. However, if Windows 9 manages to be as successful as Windows XP and not as retarded as Windows 8 (why would you ever port Windows phone to PC?), we can probably throw the previous statement out the window. If multi-threading support has been seriously improved, this will be a great plus to the game development and gaming industry. We no longer need to purchase super expensive CPUs with high clock speeds so that one core can do all the work. Instead, standard consumer level CPUs will no longer become the bottleneck for gaming enthusiasts. Obviously this is the direct challenger to AMD's Mantle. However, I foresee this as being more successful than Mantle simply because it's not specific to a single brand of GPU. Despite AMD's promise that Mantle will be non-proprietary at some point, we don't know when and having Mantle only usable on GCN architecture right now does not seem very promising. If something like OpenMantle were to be developed though... That would be a game changer.
  12. 1. The function did not do anything to p_swapchain. The function is simply retrieving the buffer from the swap chain. You gave the function a pointer to your local pBackBuffer pointer, so the function can fill it with relevant information. 2. If you set BufferCount to 2, you do not need to generate more calls to GetBuffer. The back buffer is always stored at position 0 and this is the buffer you should be rendering to. 3. Setting the setting to DXGI_SWAP_EFFECT_DISCARD just means that the contents of the back buffer are discarded/erased when the buffers are flipped (i.e. you call Present). 4. You cannot really specify a certain type (i.e. int, char) in C++. Having Direct3D depend on RTTI (runtime type information) can also be a huge hassle so we work around that problem with universally unique identifiers (UUIDs). Each UUID is unique for each interface so the function can just compare interfaces to find out exactly what you are requesting.
  13. Very recently I spoke to a developer of Warhammer Online who now works at Google. According to him, RB trees are quite slow as well as cache inefficient (sometimes even page faults). The best way IMO would be to have a fixed size tree that is linear in memory, similar to how L. Spiro did her instant insertion quadtree.
  14. Are you sure the bottom is actually some sort of executable region of code instead of say, the bss section?