gmegabuf saver APE

If anyone has any extra time to spare it would be nice to see an APE that could save/load gmegabuf data. Perhaps it could save to a file (like a .gmb file or something). Users of certain presets that I am making might appreciate this (they involve extensive data creation/visualization using gmegabuf). I'm sure this isn't something everyone would use, but I know that I would benefit from it. Of course, I'd make it myself but I don't have and experience with programming. Thanks in advance.

Yeah, you could make levels for AVS games using a global megabuffer saver.

For Atero, you can make a CA map.

For me, you can make... well, too many things.

What's a CA map?

Also, in the topic, "and" in the second to last last sentence is supposed to be "any", but it's too late to edit. 🙂

ca = cellular automata

If someone could point me at the latest 'ape sdk' i'll slap this together. I've looked on nsdn and the link seems to have vanished with the site changes. The version I have at the moment doesn't have the megabuf.

EDIT: I found the SDK hidden in the wa502 sdk, no gmegabuf support yet.

ca=Creation Advanced

another idea i had would be to generate code from the gmegabuf data that is read from a file for the VM and directly compiling&executing it.

file -> APE -> AVS code -> compile -> execute

that's the only way to access the gmegabuf in an APE for now 🙁
hmm and maybe someone with ASM knowledge could look at the output of the VM compiler to maybe see how to do it directly (maybe) 🙂

[edit]

declarations:

VM_CONTEXT vmcontext;

VM_CODEHANDLE vmc_gmegabuf_write;



double *ind;

double *val;



code:

vmcontext = g_extinfo->allocVM();

vmc_gmegabuf_write = g_extinfo->compileVMcode(vmcontext, "assign(gmegabuf(ind),val)");

ind = g_extinfo->regVMvariable(vmcontext, "ind");

val = g_extinfo->regVMvariable(vmcontext, "val");

*ind = 0.0;

*val = 1.1;

g_extinfo->executeCode(vmc_gmegabuf_write, visdata);

g_extinfo->freeCode(vmc_gmegabuf_write);

g_extinfo->freeVM(vmcontext);

works 🙂
Set ind to an index and val to a value and do the executeCode line.
"val" is then stored in the specified gmegabuf index.

if someone could put that sloppy piece of s...ourcecode in an APE, we'd have a nice gmegabuf saver APE 🙂
[/edit]

That sounds like a good idea, and indeed probably the only possible solution since we can't access gmegabuf directly. It would be awesome if someone could write an APE soon so I could include it with my new pack. I have a preset that allows you to create building designs floor-by-floor and it's a shame that all that information is lost when you are done. Hopefully other AVS artists could take advantage of it as well.

I had an idea this afternoon...why not make this a parser extention? That would make it a whole lot easier to use configuration files etc., and it would be a lot more flexible too.
It shouldn't involve that much of a redesign of the parser, and it would be completely safe, given the limitation that you could only write to .cnf (config) files within the AVS directory. That would avoid ugly happenings when neonazi viruswriters do something like delete win.com, as well as neonazi viruswriter apprentices who try to delete the entire contents of the avs directory.
I think it should be something along the lines of read(file,line) and write(file,line,append|overwrite), as well as crfile(file) and delfile(file). The only large limitations would be the inability to use strings, and thus the inability to use variables in the file parameter. I don't really see what huge and immediate harm this would do, but a rewrite to include string support would be vastly easier to do sooner than later.
So, any takers? Personally I think this has a lot to offer, if only to the end purpose of AVS penis size comparisons between the senior coders 😛

hmm i can think of an APE with 4 controls
- a dropdown/edit box for a filename (maybe later on the possibility to provide a list of files from which you can select via code)
- Init and Frame boxes for setting modes, like block types and if whether you want to read at all. these block types might include (un)signed char, int(8/16/32/64), float, double or even text input on a 1 value per line basis.
double or text would be enough for a start i think... could be extended later on 🙂
- an edit box "Block" for working with 1 block of data (for example 1 double)
most times you'll write "gmegabuf(pn)=v" though 🙂

btw what's a win.com? 😁

hehe, win.com is an application that was used to start the Windows 9x OS, it was like the Windows but with no GUI.

And now lets get back to topic:
Yes, this thing could be cool. Now, TomyLobo, I don't understand 50 % of your last post 🙂

i know what a win.com is, it's just that i'm a win2k user since RC2 and thus had no need for a win.com for a long time 😉

that post was mainly addressed to the coders 🙂 they'll understand it (hopefully 😁)

Well, i know some basic c++, and understand what is a float, double, unsigned char, but just don't understand the whole 'block' thing you're trying to explain here.

btw. are there any good books on window rendering (GUI and stuff) in c++?

to read data from a binary file, you have to know how it was written into that file, i.e. it's data type. The APE could be written in a way that it splits the file into chunks, converts them to AVS's data type (double, that is) and pass them to AVS as a variable one by one. I referred to these chunks as blocks.