Advertisement Jump to content
  • Advertisement

Wessam Bahnassi

  • Content Count

  • Joined

  • Last visited

Community Reputation

167 Neutral

1 Follower

About Wessam Bahnassi

  • Rank

Personal Information


  • Twitter

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. A shot in the dark, have you tried initializing COM for your reloaded DLLs? (CoInitializeEx)
  2. For a non-console single-threaded Windows app, use SetTimer() and anticipate WM_TIMER in your WndProc. But this already enforces a certain structure on your program which you haven't said much about yet.. so I have to ask, what kind of program is this on Windows? A console app? A window-less app? A service? Otherwise you need to have a message loop under which your app operates rather than it being an endless processing loop. If you have such a message pumping loop, then where does your processing code execute with regards to the message pump?
  3. To my knowledge 16-bit DOS realtime mode was the last OS that allowed installing such interrupts ad that was NOT multithreaded 😊. Joking aside, you said your system is entirely single-threaded. Why do you want to preempt "all other threads"? Simplify the problem to a minimum, as the solution's cost will grow with the problem's complexity. Generally speaking, in a multithreaded program, you use synchronization objects to achieve what you're describing. For example, a master thread controlling a value that all other threads just watch and sleep on until it is set. To be cross-platform, your best bet is to stick to the std library and pray your platform compilers support the version you need. For the use case above, it seems std::condition_variable from C++ 11 is what you need. That said, by reading the intro of your post, it seems this is all unnecessary complexity and the problem can be solved in a simpler way if you describe it better or review the design.
  4. Wessam Bahnassi

    Virtual destructors and override

    Addung override to your inherited destructors is a good idea. The compiler will error if the base class is not using a virtual destructor, and should pass successfully if the base class has a virtual destructor. If you are seeing any other behavior then the compiler might be non-conformant. (I hope it's not the case)
  5. If performance is a problem for you then it might help. Less uniforms to handle means less work on the CPU everytime you change them or swap shaders. Less samplers to sample... well.. obviously it's faster on the GPU also if you can afford grouping the texture channels together (sometimes it's not a good idea e.g. when using block compression with channels containing totally unrelated info with different frequencies of change).
  6. Wessam Bahnassi

    Bitblitting with transparency

    One more idea to add is RLE-style memcpys/skips for 1-bit transparency. Depending on the transparency pattern in the sprite, this can either be very fast or more taxing (e.g. dithered transparency will be the worst case).
  7. Wessam Bahnassi

    Bitblitting with transparency

    MemCpy can't help here. But that routine is still useful for cases where you know transparency is not required (e.g. the user disables transparency on the sprite). For transparent sprites, a 1-bit transparency could be done fast by replacing the overwrite with AND/OR and a mask generated from the transparent bit in the sprite. Prototype it in regular C code, then rewrite it with intrinsics (get inspired from how memcpy or memset are implemented) to make things a tad faster. If the memory you're writing to is write-combined (e.g. some display buffer) then be careful to write continuously. The worst thing to do is an if-statement that skips writing to the target location for transparent pixels. But I must also mention that such memory types are not usually primed for reads, so it is generally a bad idea to do any pixel blending on such memory.
  8. Setting the Width/Height of the Window will not guarantee you a certain required client area. To guarantee that, you have to do it by relying on an element within the window to act as your client area, and have the window size to that element. In the example below I used a top-level Grid element. You can see how the actual widths and heights of both the window and client area element are. Note the SizeToContent attribute on the Window. <Window x:Class="WpfApp1.MainWindow" xmlns="" xmlns:x="" SizeToContent="WidthAndHeight" x:Name="window"> <Grid x:Name="clientArea" Width="1200" Height="900"> <StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="ActualWidth: " /> <TextBlock Text="{Binding ActualWidth, ElementName=window}" /> </StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="ActualHeight: " /> <TextBlock Text="{Binding ActualHeight, ElementName=window}" /> </StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="ClientWidth: " /> <TextBlock Text="{Binding ActualWidth, ElementName=clientArea}" /> </StackPanel> <StackPanel Orientation="Horizontal"> <TextBlock Text="ClientHeight: " /> <TextBlock Text="{Binding ActualHeight, ElementName=clientArea}" /> </StackPanel> </StackPanel> </Grid> </Window>
  9. Hmm. That's weird. One suggestion is to set all MinWidth and MaxWidth and Width to the value you want (i.e. 1200) and the same for height. Is your desire is to get 1200x900 client area or total window area (i.e. including any decorations)?
  10. Wessam Bahnassi

    How to mipmap procedural shaders?

      Anti-aliasing in terms of today's APIs works on geometry edges not on shading.       Yup, that's closer to a sensible approach. du/dv tells you the frequency you're being sampled at... so theoretically you do "multisampling" at higher frequencies and average the results. But I want to know if anyone has smarter/faster ideas than this...
  11. A general observation for shaders that rely on procedural functions f(u,v) to generate colors is that such shaders may alias so hard at the distance. For example, if f(u,v) generates periodic lines on u and v then on distant surfaces those lines alias strongly (see attachment). If we replace the procedural function with a mipmapped texture lookup then the result improves a lot. So my question is, is there a generic way to make a function f(u,v) "mipmap" in a pixel shader aside from the texture approach?    
  12. Wessam Bahnassi

    UNICODE doesn't work in fullscreen mode

    It would be nice to post what the problem was :)
  13. Wessam Bahnassi

    UNICODE doesn't work in fullscreen mode

    As I said before. D3D does inject a WndProc for special handling of certain window messages in full-screen. That's why I suggested you save aside your WndProc before creating the D3D device in full-screen, then re-attaching it again after device creation is done. And remember, play nice and call D3D's WndProc in yours. Now I'm not sure where exactly the call should be, but I think you should call D3D's WndProc at the start of your WndProc, and if it returns that the message isn't handled, then your WndProc code kicks in. I'm sensing a bad recursion here, so take care...
  14. Wessam Bahnassi

    UNICODE doesn't work in fullscreen mode

    Same here. I can correctly write unicode text both on windowed and full-screen mode. So it seems that only IsWindowUnicode() that's giving a bad reading. I've checked if anything has changed in the window/class style during display changes, but everything is fine. And guess what, Spy++ still reports that your window is unicode... Really strange :|
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!