incertia

Members
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

787 Good

About incertia

  • Rank
    Crossbones+
  1. Adjusting window sizes in X11

    Okay so it looks like a window manager issue. Launching X without a window manager creates the borders on the outside.
  2. Adjusting window sizes in X11

    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 Vulkan Queues

    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. Array Problem in C

    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. AES Encryption

    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. DirectX 12 Announced

    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. RB-Tree or AVL trees

    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?