Archive: "file writer" APE


1st August 2004 00:47 UTC

"file writer" APE
I don't know how useful this would be, but I thought it might be nice to have a "file loader/writer" APE that would save and restore the global variables and array to/from a file.

Essentially, it would monitor a global and would load or save the globals data when it reached an arbitrary number.

The author could set it to always have the same name, or to have the user select a name.

This could be nice for presets such as Shock Value's architectural design some games so level progress could be saved.


2nd August 2004 01:57 UTC

I had the exact idea recently. I wrote down several pages of what it could look and act like. But I have little programming skill. I was going to work until I had a rough working version and then give someone smarter the source to fix it up, but I can't figure it out.

I think it should basicly look like the effect list with read/write commands. There should be a scroolbar for reg00-99 with checkboxes on the side to save wanted variables all at once and then restore them manualy or when the code says to. An option for restoring the global megabuffer may be possible but would require good optomisation and possibly compression to prevent huge presets.

When I get spare time I will draw an example of what I had in mind, around Tuesday afternoon. Architectural Design is an excellent preset, and I believe that it would be the first to use this APE.


2nd August 2004 20:31 UTC

The gmegabuf need not be complicated/bloated...just have two fields asking the user for the range to save.


5th August 2004 21:24 UTC

this idea was posted before by the aforementioned shock-value :)
http://forums.winamp.com/showthread....light=gmegabuf


6th August 2004 03:07 UTC

Sorry I'm late on an example of what it might look like. Cat had to be put down and I have had no sleep. Will do it Saturday.


6th August 2004 05:11 UTC

Sorry about that...I've gone through that twice.


6th August 2004 22:09 UTC

avsmandan: it can't really be done with the current APE SDK... you only have access to the registers but not to the gmegabuf from your APE


6th August 2004 22:23 UTC

Are you sure about that? The Texer II ape uses gmegabuf.


6th August 2004 22:52 UTC

I can't code anything yet anyway, let alone start with the Winamp SDK. I was creating an outline of how it would work, I just can't yet code complex c++. I have all of tomorrow to do something, so I'll try to create my idea of what the APE should look like, mabey a working one, and link it.


7th August 2004 13:07 UTC

Texer II doesnt use gmegabuf
Texer II uses the evallib
which enables you to use gmegabuf in your scripts... you can use this to transport things from the gmegabuf to your APE... but this is VERY slow


7th August 2004 15:50 UTC

I don't think it matters if loading is slow because you could load the data/high scores once and use it. Later, you could also save the data you wanted using getkbmouse and code. If it took a second or two loading a few points of data then I think it is okay as long as it isn't used constantly. Since we have access to the registers we can still save a lot without any loss of framerate.


7th August 2004 19:10 UTC

to save gmegabuf completely you would need at least 10,000 runs of a piece of AVS code


8th August 2004 18:40 UTC

wow...that's almost a tenth a second, on a bad day. :rolleyes:
one 1,000 point superscope with a=b, ten frames. it's not that slow. even if you were saving the whole of gmegabuf, it wouldn't take that long...like avsmandan said, you're only doing it once.

however, i think what we need is an extention upon evallib that gives us a save() function:
save(0 (megabuf) or 1 (gmegabuf),start,stop,index)
which would save g/megabuf data to a data file (presetname.dat) under a certain index number. this way you could easily save and restore more than one set of data. i wouldn't think that it would be that hard to implement, either, especially considering the speed of which megabuf (the biggest hack of an array i've ever seen) was coded...


8th August 2004 19:46 UTC

Except for the fact that there is no one actively working on AVS right now...