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
Printable View
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
What is your program reading and writing to your hard drive?
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.
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.
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.
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.
I like that idea a lot!
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.
Applications that change the clipboard are almost as bad as applications that create RAM disks :)
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.Quote:
Originally Posted by Jamie
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.
this is an awesome idea actually
It is. MMF3 please!
I agree
Yeah, on top of that, my suggestion would of course open up for complex files that can contain tons of different types of content. Perfect for custom level stuff.
Of course, this would not be that easy to implement since all extensions would have to support this - I guess the best way is by providing file functions in the SDK..
Yes, of course it would have to be built into the SDK. I think the main trouble would be converting the current extensions since there are so many of them, but I can't see that there would be a problem with creating new extensions if the MMF3 SDK had a good set of features for it.
I think of it as a way to direct the output of an extension. The extension itself cannot decide the destination of anything. No copying things to the clipboard, no writing files to disk, none of that.
Instead, the user chooses whether the output of a "save to file" (of course it wouldn't be that name, lest it would sound like a workaround) action goes to memory, to another extension, or to the internet (via OINC, for instance).
This way we could do all those video and voice streaming users keep asking for, and a lot more cool stuff, and would make MMF a LOT faster, since data won't have to go through the disk.
Of course, the SDK would encourage developers not to create "write to file" options, and we wouldn't need to plug stuff to the binary object, as is done currently (microphone object for instance)
This is a fantastic idea. Would sure as hell make my life so much easier. Currently I am using the binary object (stuggling to) to pack several different data types into 1 file, and if this could be inbuilt into MMF itself would be fantastic.
having a ramdisk internal to MMF is a great idea, and it wouldn't need any extensions to be updated because if they can support a file reference, you could just point them to the ramdisk path using a string built into the ramdisk object (such as RamDiskPath$("TempDisk"))
No, that's not possible, except if you use a real virtual ramdrive mapped to a drive letter, which signals "I use horrible workarounds and create bad software". Nobody needs that. Except for that, MMF can't just catch the extensions' file writing abilities and direct it to it's own internal way to store binary data. Extensions are like programs, MMF can not modify the behaviour of those. The extensions will need to be updated no matter what. It should work more like the Binary Array's workspaces feature, and we all know that isn't a ramdrive just because it can store any binary data.
Sure nifflas, but if that's implemented for MMF3, it can be programmed straight into the SDK, so there will be no need to remake extensions...
Also, porting to java/flash would be a lot easier, since there won't be any access violations or anything.
What? Nifflas is right..Quote:
Originally Posted by Fimbul
Quote:
Originally Posted by Nifflas
Really not all extension need to have this behavior only those that exchange data.
Well, all extensions with file I/O capabilities then, but I thought that was kind of obvious ;)
I'd love to see a better framework for objects to share data and communicate directly. I've had a lot of interest lately in inter-extension communication, mostly focusing on "glue libraries".
I think there still needs to be some mechanism in the middle that allows the developer to apply appropriate transformations to data if the intention is to share between extensions directly, because in general extension authors can't predict ahead of time exactly what you want to do with their output. I guess the event editor itself technically fills this role but that's not always possible or practical.
Eh, sorry, I made a mess trying to get my point across...Quote:
Originally Posted by Jamie
What I meant to say is: no extensions will have to be updated if the SDK for MMF3 has it from the start. This way, all extensions made will already have that feature.
Unless of course you're talking about porting mmf2 extensions to mmf3, but I know nothing about that.
You don't understand how it works though. If the SDK is updated to support some kind of internal memory storage shared between all extensions (which would be awesome), the extensions must be changed to take advantage of those SDK features. Even an SDK can't be made to catch the extension's file I/O abilities and do something else with them.
I think you're misunderstanding some stuff about how an SDK work. They don't have superpowers.
I'm trying to say it would be easier to leave that for MMF3's SDK instead of yet another update, and yet another mass conversion job (remember clickteam is already converting stuff for java, flash and HWA).
Instead of converting stuff, new extension developers would have to use that function, since it's built into the sdk.
Instead of writing that I just wrote a bunch of weird stuff... guess I was sleepy or something... I understand how an SDK works nifflas.
By the way, whatever happened to MMF3D? Everyone just talks about mmf3!
Ah, okey, that makes more sense. I can't say I disagree though (actually, both my first two posts about this feature mentions that it would make most sense in MMF3).
It's already possible to share memory between extensions, as they all run under the same process.
Hi,
When I said that not all extensions need to exchange data, what I meant is that not necessarily have to be in the SDK or the LIB (since it will not be necessary for all case), just enough to create and structure a new header that will be distributed to all developers (as well was the case of the famous rSDK).
This would allow to obtain the benefits of exchanging data from this version and once, it has obtained a final form of data exchange, Clickteam as a company decide whether to implement it, in their library or not.
Not necessarily have to wait until you see a new version of MMF, this benefit can be enjoyed now after establishing a data interchange format.
With respect to security, this is the best way to avoid mismanagement by others.
I like this conversation and I know it will bring something good from it.
Sincerely