
siwu
-
Content Count
441 -
Joined
-
Last visited
Posts posted by siwu
-
-
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.
-
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
-
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...
-
@bolero: did you really click the save button ? i know it's a stupid question but still, if you close the dialog, the settings you entered will be discarded
-
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.
-
Okay I would suggest you to copy Siwu_test1.xml into another file.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.
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
-
Okay first, you shouldn't worry about installing beta software from microsoft, I mean, they have the most useable beta softwareWelcome 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...
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
-
This guy can't be the real siwu...
The real siwu would never outwardly recommend downloading .Net Framework
Look: Evidence
*smacks the imposter*
Stupid Frenchie - didn't I tell you ages ago that .Net was great?
I was young, and drunk.
-
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:
YES it uses the .NET Framework 2.0 BETA, I know, but hey, this thingie brings such great featuresSinapse is a new expose clone, made in C# and C++, for the .Net Framework 2.0 andfor 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 !
YOU NEED THE .NET FRAMEWORK 2.0, DOWNLOAD here
Sinapse_v0.1.zip (387kb)
-
ID&T and Tiesto so f*cking rulz !!!
siwu
-
@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
-
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
-
Like, I said, if this can be done, I would be VERY pleased (as well as impressed).
siwu
-
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
-
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
-
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
-
As the changelog says:
v0.1.1: 08/31/2004- Fixed a bug that caused SPrintWindowGetDIB() to return INVALID_PARAMETER error when the pBits pointer in the SPW_DIB structure supplied was NULL.
The download link is the same
siwu
-
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
-
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
-
Originally posted by Photo678@Aug 30 2004, 03:07 PM
Cool,
wait, what is it, screenshots, info??
<{POST_SNAPBACK}>
This is the library I used to make the video of this thread
siwu
-
Hi people !
I'm proud to present the first beta of the SPrintWindow library !
I do hope you will find it cool.
For the moment, some API are quite unstable and are marked as so.
The documentation is included, InfoFetch aswell, and a sample program
SPrintWindow_0.1_BETA.zip (472 kb)
If you like this project, don't forget to
!
siwu
-
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
-
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
-
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
Where's Siwu???
in Siwu's Apps
Posted
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