[Request] RAM Disk Object?

[Jsonic]

Basically something that can allow me to read and write data of any type to RAM.

The program I'm working on is suffering its biggest slowdown because its reading and writing to my Hard Drive.

Thanks in advance

[James]

What is your program reading and writing to your hard drive?

[Jsonic]

Screen capture image files, the Screen Capture Object supports capturing to the clipboard, but the Mode7 ex object doesn't have a way to load from the Clipboard. So I capture to the hard drive and load from the hard drive. It seems the easiest solution is a RAM disk drive. Otherwise a new version of the Mode7 ex object would be needed.

[Nifflas]

Ah, well, to be honest the ideal thing would be if MMF had a way to easily transfer binary data between extensions without having to store them onto the hard drive first. I'd say that MMF3 should ideally have built storage for binary data with file read/write actions, then all other extensions should only transfer data from/to those and never on their own have file reading/writing capabilities. That itself would solve all these issues perfectly.

Unfortunately, the thing which you suggest about using a RAM drive is not an option. I wouldn't want to use a tool that mounts a virtual drive to transfer data within the application itself. That will give your program a huge "dodgy workaround warning" label. You'll have to find another solution for now.

[James]

You can't expect users to run an application that installs a driver for a RAM disk. It's a problem with the screen capture object that's never been sorted.

[Fernando]

Hi Jsonic,

the problem with ram-disk is that they are very operating system depending. (so if you use in Windows 2000 is quite different as win98 an we are in windows 7 now, for example)

maybe what someone can do is to create a binary array extension that allow you to write a binary file to it and read it, but again the convention use in MMF will force you to write again in hard disk and read it after.

Also something that can be implemented by developers, guided by MMF its a structure to exchange binary data among extensions, a regulation for the structure, the way to be write and read, etc.

for example:

you have an array read by the array extension, and the list view object required this information another action will be exchange inside data 1.

In the case of SQLLite to mention one, this allow to link several edit box object so they will refresh data instantly since they linked together.

[James]

I like that idea a lot!

[Jsonic]

How about the clipboard. can we get data going in and out of there?

On the other hand, I've found a tool that makes ram disk in vista 64, and the program speed improves tremendously. Getting into RAM one way or another is the way to go.

[James]

Applications that change the clipboard are almost as bad as applications that create RAM disks

[Nifflas]

I like that idea a lot!

I actually prefer mine though, at least for MMF3. The runtime should have it's own features for loading binary data to the memory and writing binary data back to files and a few nice actions 'n conditions to make your application do so. Then the extensions would not have file read/write abilities at all, they should (in order to follow the set standards) only have the ability to read/write from those memory areas.

That would reduce the extension bloat, make it easier to "vitalize" extensions since there would be a lot fewer cases where the extensions would have file writing abilities (clickteam would only have to put the limit at one place, and that's the file write actions of the runtime), and it would open up for the concept of "secure" sub-apps that can not write files (which is a problem I'll have with my new game, as some level components are sub-apps, so somebody can basically make a level that overwrites sensitive files on the harddrive). I like standards.