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. 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)
  2. 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).
  3. 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).
  4. 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.
  5. 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="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 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>
  6. 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)?
  7. 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...
  8. 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?    
  9. Wessam Bahnassi

    UNICODE doesn't work in fullscreen mode

    It would be nice to post what the problem was :)
  10. 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...
  11. 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 GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!