How to convey an image between two Surface objects

[Pixelthief]

Hrmm I modified it, and yep it appears to not overwrite or otherwise tamper with that memory even through a "restart application". I was figuring just passing the address and marking it not to garbage collect would be volatile with however MMF2 restarts but it looks fine so far. Seems all sort of unsafe, though! I imagine it could lead to all sorts of fun errors if you didn't exclude that memory from the GC- and all sorts of memory leaks when you do

Actually, how do you release the memory from the passed memory address? I noticed that the "restart application" example I rigged up leaked memory like a sieve, presumably since it just kept excluding addresses from the GC and never releasing them. I tried setting the reference state to "1" on the second example frame, and that appeared to do it memory wise- but I just want to be 100% sure its doing what I think its doing.

https://sites.google.com/site/claniraqsfiledump2/files/SurfaceRefs.mfa?attredirects=0&d=1


But yeah my main problem was in capturing the game frame in the first place. I wanted to somehow capture the entire game frame, including all layers and after pixel shaders applied to objects, layers, and the frame itself. The screen capture object can do that, albeit a bit unreliably with old architecture (an ostrich problem), but I was sort of hoping to figure out how to do it straight from the surface object. Besides, that would allow it to run all the faster by passing it straight in memory like your example.

I can't quite wrap my head around how the "blit the background" feature works. I've been tinkering around with sources & destinations and layers and trying to get it to blit anything, but haven't turned up anything so far. It would really help if I could get an example of that But I get a feeling like it might just be more prudent to uh, blit the window itself via passing its handle? Seeing as I'm guessing thats all the screen cap object was doing anyway. Of course then I need some way to figure out the window handle, which ironically the windows control object can't tell me. So thats still a fair bit of stuff to figure out, bleh

[Looki]

Can't view the code and run it because you seem to be using an old INI++ version incompatible with the one I just updated.

Yes, set the reference state of the image to 1 (It SHOULD be 0 to make more sense, as I said before - will be changed in the next build) if you want it to be freed from the memory when the object is destroyed. That's it.

Blitting the background doesn't work in HWA, sorry. Since there still is no HWA SDK I'm not sure I could do about that. Blitting the window handle should work on Vista and above only.. the next build will have an expression for the frame handle, but currently, you could use the DLL object's GetFrameHwnd( "DLL Object" ). But no, this is not more prudent. Not at all.

[Pixelthief]

Oh whoops, actually thats a new INI version that hasn't be released yet, other way around :p. Yeah, good to know the memory is being freed when set to 1 (ok yeah makes more sense if you switch those around, but watch your backwards compatibility)

hrmm you might be right that pulling the frame window might make more hassle than its worth. I might just wait until someday the HWA SDK is out and you can figure out how to yank the image buffer for the backdrop- I mean my duct tape solution with the screen capture object works for now anyway.

I'll just write myself a note to fix this a year from now ~_~

[RGBreality]

Hey, Looki!

The objects do freeze (as in they don't move at all). However, after playing around with some settings (specifically, enabling the "Machine independent speed" setting and playing with the "Timer-based movement" setting on the frame, I was able to get the Active objects to move slowly and not smoothly. On another computer, I found that the Active objects move a little faster--implying that computing power is the culprit.

I would be glad to send you a copy of the MFA file, but since you'd need to see all frame objects in the MFA file so you can see how it runs in this condition, I couldn't separate it out without reducing the MFA's file size. This project is--believe it or not--50 MB. So I can't upload it to you.

To see the effect from a compiled project, you could download it from here:

Ultimus Pieces Screensaver

You can see the effect for yourself from the run-time build.

Thank you again for all your help today!


Most appreciatively...

RGBreality

[Looki]

Ah, I see. It runs pretty smooth for me, but I guess it should be a lot faster. My main problem here is, I really don't know why you're using the Surface object in the second frame. Can't you just add it as backdrop? Does the Surface object merely display the screenshot?

[RGBreality]

Hey, Looki!

The Surface object does indeed just display the screenshot. I would just let MMF2 capture the Desktop on that frame, except that I want the end user to have the ability to either display the "transparent look" of seeing the Desktop, or to display a colored gradient (run by a Background Gradient object).

So, I had two challenges here: (1) how to get the Desktop without using MMF2's default "Capture Desktop at startup" option, and (2) how to be able to toggle the visibility of that Desktop image.

Would you recommend a better way of displaying the Desktop image on the second frame?

By the way, you can compare the speed of the moving Active objects by toggling the visibility of the Surface object. To do so, click on the Options tab at the top of the running screensaver, then deselect the "Display Desktop" option. The Surface object will hide and colored gradients will be in their place. You'll see the Active objects then move much faster and smoother.


RGBreality

[Looki]

Hm.. it's about 1.3x as slow with the desktop. Well, all I can recommend right now is trying to use Blit>From the surface>External>Add backdrop. I'm not sure what else I can do to improve the drawing speed of the Surface.

You could try MMF2 HWA though, that should speed it up for sure.

[RGBreality]

Thanks for all your help today, Looki! I really appreciate it!


RGBreality

[Looki]

You're welcome. After all I want to sort out any problems in the object, too.