Jump to content

siwu

Developers
  • Content Count

    441
  • Joined

  • Last visited

Posts posted by siwu

  1. Hey folks

    Well, all I can say is that I'm not dead :), and I really do appreciate your concern about me, really.

    I'm sorry I dropped out from here, but I had real life issue to settle and a lot of work to do.

    Lately I've been involved in the Mac OSX x86 community, well, before maxxuss took over the job :)

    I'm still in contact with StevieBM on msn, and if you wanna reach me, you can still try the pm :)

    In the mean time, I hope you're still having a great time here, it's been fun to work here for a while, and who knows, maybe I'll come back :)

    Cya folks :)

    Siwu

  2. Any news Siwu?

    It's been about 2.5 months since this release, and for those who have used it, we can all agree it's looking pretty good... but has the trail gone dead again? :(

    Well the thing is I definitely didn't have time to continue the development of Sinapse. Eventually I'll release the sources if I can't continue development.

  3. Siwu, this isn't really my area of expertise, but maybe there's some way to refine your algorithms so that the performance decrease at higher resolutions isn't as dramatic without having to "fake" a 1024 device and expand it out to higher resolutions?

    The problem with really large resolutions is that the 3D card don't handle them very well, combined with the fact that you have 1:1 textures, the result is what you experience right now: slow. The workaround would be to allow the card to render less pixels, hence increase the performance. I'm sure you don't play games at 1920x1200 :)

  4. Been playing around with Sinapse on different computers...sadly on my laptop (1920x1200 resolution, GeForce4 4200 Go), Sinapse really lags too much to be used regularly. On my bf's however (1024x768, GeForce 5200), Sinapse is as smooth as butter. Really really usable. I tested and the vast majority of the difference seems to be attributable to the large resolution difference. When I lower my res to 1024, Sinapse runs smoothly.

    Is there any way you can improve something so that Sinapse doesn't suffer as dramatically from increased resolutions? (I know obviously it won't be 100% as fast).

    In fact, there is a way to do this, but the graphics won't be as sharp as in the native resolution. The technique is to create let's say a 1024x768 device, and then extend it to 1920x1200. I'll have to look into it though... :)

  5. Exception Type: Microsoft.DirectX.Direct3D.OutOfVideoMemoryException

    Hummm, it's weird because Direct3D told that you haven't any video memory left, but at initialization, really weird. Try to delete the SinapseConfig.xml file and run sinapse again.

  6. siwu ... thanks for this fantastic release!

    i've only toyed around with it for a bit but it looks pretty good ... my only major problem with it is that when i expose the windows and then move my mouse onto one of them, they all go invisible and flicker a bit ... i don't know if anybody else is experiencing the same thing.

    also, the animations look great but sometimes aren't very smooth on my computer.

    regardless, this is a fantastic app ... thank you for your hard work!

    EDIT: i was running Y'z shadow and so i quit it and tested synapse again ... the animations were VERY smooth, but i still get the problem of all the windows going completely blank when i move my mouse over any single window.

    Okay I would suggest you to copy Siwu_test1.xml into another file.

    Then open this file and search for this:

    public override void OnMouseEnter(ISinapse Sinapse, IWindow3D Window)
    {
    Sinapse.Effects +=
    Effect.Queue
    (
    new TextWriter(Window, new CosinusInterpolator(1, 0), Window.Text)
    );

    foreach (IWindow3D window in Sinapse.Windows)
    {
    if (window != Window)
    {
    Sinapse.Effects +=
    Effect.Queue
    (
    new Blend(window, new CosinusInterpolator(300, 0), 100)
    );
    }
    }
    }

    And remove this:

    	foreach (IWindow3D window in Sinapse.Windows)
    {
    if (window != Window)
    {
    Sinapse.Effects +=
    Effect.Queue
    (
    new Blend(window, new CosinusInterpolator(300, 0), 100)
    );
    }
    }

    And same thing in:

    public override void OnMouseLeave(ISinapse Sinapse, IWindow3D Window)
    {
    Sinapse.Effects +=
    Effect.Queue
    (
    new TextWriter(Window, new CosinusInterpolator(1, 0), "")
    );

    foreach (IWindow3D window in Sinapse.Windows)
    {
    if (window != Window)
    {
    Sinapse.Effects +=
    Effect.Queue
    (
    new Blend(window, new CosinusInterpolator(300, 0), 255)
    );
    }
    }
    }

    That's it :) you won't execute the blending effect on the other windows :)

  7. Welcome back!

    This is great stuff! Been waiting for a nice FREE exposé clone! Although...

    I feel a little hesitant to download framework 2 beta off microsoft... microsoft is known to be buggy so a framework beta... I dunno... do you have to uninstall the framework 2 beta when the framework 2 final is published? or will it be able to just update it? see I don't wanna put too much of this trash on my computer...

    Okay first, you shouldn't worry about installing beta software from microsoft, I mean, they have the most useable beta software :)

    Also, I've been developping this software for two months now, on a BETA IDE (Visual Studio 2005) and on a BETA Framework. And so far, i've seen ONLY ONE bug in it, and it's related to the context menu. And it's not that bad.

    Also, yes i'm sure you will be able to update the beta.

    I know how you feel, i've been there :), but hey, .NET is really a GREAT and HUGE thing, so go ahead :)

  8. No i'm not dead :)

    Yes, expire is dead, but hey, here is the new beast !

    Okay here is the first release of my new application, Sinapse.

    What is sinapse ? Well, here's the readme:

    Sinapse is a new expose clone, made in C# and C++, for the .Net Framework 2.0 and

    for Windows XP and newer ONLY.

    Here are the features:

    - Scriptable using C# scripts (tutorial soon)

    - Switchable Organizers

    - Full key configuration

    - Configurable corners (action, delay, and region)

    - Exclusion possibilities (with drag and drop on window)

    - Drag and drop aware (drag a file in sinapse, move to the window, wait, and drop in the window)

    - Custom crash window, with report

    - System informations dump

    - Support for Single Pass multitexturing cards as well as MultiPass multitexturing cards

    - Multi monitor support !

    YES it uses the .NET Framework 2.0 BETA, I know, but hey, this thingie brings such great features :)

    YOU NEED THE .NET FRAMEWORK 2.0, DOWNLOAD here :)

    Sinapse_v0.1.zip (387kb)

  9. @raduking:

    You are very courageous to start a new dock :)

    Let me give you my advice: use Direct3D, or DirectDraw :)

    And also, use Visual Studio 2003 or even 2005 Beta 1 C++ Express (free), I can assure you it will be A LOT simpler and pleasent to dev with :)

    Also, if you use 2003, grab Visual Assist X :)

    siwu

  10. About CherryOS, it am pretty surprised that no one noticed in the video the white bar between the actual OSX screen and the window titlebar. JUST LIKE PEARPC (non SDL).

    Also G5 emulation IS possible, but it will be slow as hell (translating 32 bits addresses to 64 bits, and BACK, which is the hardest part of course...). Since G5 have the same amount of memory as PC, it can be done (a G5 memory address can he translated back to 32 bits, because the G5 has less that 4gb of memory, which is the 32 bits integer limit (2^32-1)).

    Just my opinion though...

    siwu

  11. Here's what I posted at the expire board:

    Well, I really doubt it could be possible to achieve border transparency for borders only. or with a lot of dirty stuff (like a layered window emulating the border and non client area) :)

    Let me explain the different rendering depths involved:

    - RGB, which is 1 byte per channel: 1 * 3 * 8 = 24 bits

    - XRGB, which is RGB plus a 1 dummy byte: (1 * 8) + (1 * 3 * 8) = 32 bits

    - ARGB, which is RGB plus a 1 byte alpha channel: (1 * 8) + (1 * 3 * 8) = 32 bits

    So let's not confuse what you are using when you set your screen depth to 32 bits. Actually it is XRGB, NOT ARGB.

    The way the win2000 graphic core handles blending is done without GDI (actually, GDI paints on a XRGB surface when set to 32 bits, looking at the true pixels with the SPrintWindow lib confirmed that). The alpha blending is done afterwards by the kernel.

    But i'm not the god father of the GDI core, so if Stardock can make it, then do it ! :)

    siwu

  12. Originally posted by herd@Sep 4 2004, 12:16 PM

    This would require AveDesk to take complete ownership of the desktop-

    and not only render a set of layered windows... (That's how I understand

    their DirectUI technology, correct me if I'm wrong)

    <{POST_SNAPBACK}>

    Well, I don't think it's working like that.

    Actually, as I saw, they say they use HW acceleration for blitting, and not layered windows.

    That means Direct3D or DirectDraw. And since they are using DirectDraw because you can draw outside the clipping region of a window.

    However, that would require manual overlapping if you have windows opened.

    siwu

  13. Originally posted by wiebeest@Sep 4 2004, 11:06 AM

    That would be very cool indeed.

    At first thought, I would think that would also be very impossible, since M$ winblows is not HW-accelerated, so one should alterter the very core of the OS.

    Then again, by now the developpers on this site and other have shown use so many cool features to be possible within the limitations of windows, I'd not be surprised someone would eventually get it done.

    If pearpc can, why not windows, right?

    <{POST_SNAPBACK}>

    Well, doing widget with OpenGL is impossible. However, doing it with DirectDraw (thus using HW acceleration) is possible. This is how StartDock do with their DirectUI technology (I think, since you can draw wherever on the screen with DirectDraw).

    siwu

  14. Originally posted by Vjay@Aug 31 2004, 11:03 AM

    The exception occures when i load the library. The workingdir is correct. Delphi ... think no. if you load the dll in a cpp program or in a delphi-program shouldnt matter (or you made something big wrong ^^). I cant test it @work (win2k) because we must use a http-proxy and your info-fetch doesnt support that. Also i cant test the sample-prgram cause i dont have a c compiler.

    <{POST_SNAPBACK}>

    Weird, really weird....

    Actually this error is not due to a bad SPW file, but to the library cannot find the SPrintWindowDrv.sys file.

    Well, try to put it in the \Windows or \Windows\System32 directory, of even only C:\.

    siwu

  15. Originally posted by Vjay@Aug 30 2004, 05:50 PM

    WinXP SP2 Geforce3 with actual drivers if this matters.

    Why you cant examine the system-settings @ the first call, instead of an external program. Is this too complex?

    <{POST_SNAPBACK}>

    This error is actually: ERROR_PATH_NOT_FOUND (retrieved via GetLastError()).

    It means that the dll didn't find the SPrintWindowDrv.sys file.

    However, it's pretty weird because the DLL is locating itself and expect to find the driver in the same directory.

    Did you try with the sample program ? Maybe it's because of delphi :/

    You should check the working directory of your executable file, this maybe the cause.

    siwu

  16. Well, you shouldn't forget than Longhorn will ships in 2006, that leaves a LOT of time for changes.

    Does anyone remember OSX RC1 ? it looked like OS9 and aqua wasn't introduced before RC2 :)

    So stop flaming at Longhorn, because from a developper point of view, it will KICK ASS.

    But yeah I do think people do not want only mac related stuff.

    siwu

  17. Okay I made a function that uses SSE to optimize bitmap changes.

    Here it is:

    	__asm
    {
     mov eax, realPtr
     mov ebx, cachePtr
     mov ecx, videoPtr
     mov esi, realSize
     xor edi, edi

     $loop1:
     prefetchnta  16[EAX]  // prefecth next 4 pixels
     prefetchnta  16[EBX]

     movapd  xmm0, [eax]  // read 16 bytes in the window DIB
     movapd  xmm1, [ebx]  // read 16 bytes in the cache DIB

     cmpsd  xmm1, xmm0, 0 // compare the four pixels
     movmskps edi, xmm1  // mov the comparison mask to edi
     test  edi, edi  // check if the pixels are the same
     jnz  $end_loop  // loop if the pixels are the same

     movapd  [ebx], xmm0  // update the cache DIB
     movntdq  [ecx], xmm0  // update the video DIB with non temporal
             // flag to make sure write only is done

     $end_loop:
     add  eax, 16
     add  ebx, 16
     add  ecx, 16
     sub  esi, 16
     test  esi, esi
     jnz  $loop1

     emms
    }

    With this function I am able to maintain a framerate of 35 frames/sec with about 10 windows open. That is passing trough all the bitmaps.

    Note that the bitmaps must be aligned to 16 bytes in this version

    siwu

  18. Originally posted by herd@Aug 28 2004, 01:00 AM

    Maybe not. With all those supercharged GFX cards becoming commonplace,

    it'd be a matter of time. 64 or 128 MB AGP memory unused until you play

    a game - what a waste - Let's unleash that power in a production environment!

    On the other hand, I believe global hooks are evil. There should be a 3D desktop

    take over as in Mac OS X. Believe it or not, the entire desktop is an OpenGL

    scene there, and the frame windows render themselves on OpenGL surfaces. This

    freaking genie effect is so easy to do for Macs, and so hard to do for Windozers.

    Even the dock animations are done with hw accelerated motion blur!

    I somehow have it in my water that his excellency Siwu is opening a door here,

    for evening out the advantages that OS X has over Win32.

    Too bad I am a user mode 2D coder and can't be of any help here. But as a

    knowing bystander, I cheer Siwu to go on. This clearly has more use cases than

    Expiré, I see it as a milestone.

    <{POST_SNAPBACK}>

    Well, the problem in entirely 3D desktop is actually the AGP bandwidth. You simply can't afford to transfer n bitmaps in real time. But with OSX, the bitmap is still your screen res (because of window overlapping, you don't have to send the "overlapped" part of the bitmap).

    But, as I see it, the only problem with the SPrintWindowSetDIB() API is that the bitmap itself will be in video memory (for both writing and reading). Reading from video memory is 40 times SLOWER that writing (because reading is STILL done through PCI). And because the windows kernel reads a lot it's redirected windows bitmaps, it results in a slow framerate (can drop to 5 frames/sec when refreshing a firefox page for example).

    So I thought the good way would be to have the video memory bitmap cached in system memory. Then, just walk trough the real window bitmap, catch the differencies, and then update (so write only, which is kinda fast) the video memory bitmap.

    But the problem is we have to walk trough bitmap that have a maximum dimension of the screen (mostly), and is quite CPU intensive.

    That's why I thought about MMX and SSE instructions, they can help a lot (for example, a memcpy() with MMX+SSE can be 3 times faster than the simple memcpy()).

    For example, SPrintWindow uses the memcpy_amd() API, provided by AMD that uses MMX and SSE.

    But still it's a way to investigate. SPrintWindow unlocked the Windows WM capabilities (which is capable of redirecting windows since Windows 2000, WS_EX_LAYERED).

    Now all the optimizing work needs to be done :)

    siwu

×
×
  • Create New...