Jump to content
  • Advertisement

incertia

Member
  • Content count

    110
  • Joined

  • Last visited

Community Reputation

787 Good

About incertia

  • Rank
    Crossbones+
  1. incertia

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

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

    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. In retrospect I suppose a finite signal/slot approach would be better to reduce the minimal amount of look-up overhead because nobody ever needs infinitely many unique events. Notice how mine is essentially an infinite version with the map. As for the type safety concern, it is primarily the user creating all the different events and data structures related to that event, so if the user doesn't know what data type to use then it would be his error. However, there is the off chance that the user may accidentally connect a listener not designed for that specific event, which would definitely cause an error if the expected struct was smaller than expected. The details of CEventManager are entirely up to the user and I was setting up a quick test for myself, so I became a bit careless. On second thought, I will probably update this with a signal/slot approach in the near future because: (1) Nobody needs infinite events (2) I can ensure type safety and infinite arguments with structs and templates (3) There is no need for live pointers to be passed around
  7. incertia

    Practical Guide to Bezier Curves

    Forward differencing is otherwise known as finite differences in the math world.
  8. incertia

    C++11 Lesson Two: Variables!

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!