Shock Value

6th March 2004 03:08 UTC

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.

skupers

6th March 2004 15:36 UTC

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

Nic01

7th March 2004 03:57 UTC

For Atero, you can make a CA map.

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

Shock Value

7th March 2004 06:55 UTC

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. :)

dirkdeftly

11th March 2004 23:45 UTC

ca = cellular automata

jheriko

16th March 2004 02:46 UTC

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.

D12

8th April 2004 17:49 UTC

ca=Creation Advanced

TomyLobo

17th April 2004 06:56 UTC

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);

Shock Value

17th April 2004 18:08 UTC

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.

dirkdeftly

19th April 2004 07:25 UTC

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 :p

TomyLobo

19th April 2004 07:47 UTC

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? :D

Neoavs

19th April 2004 15:25 UTC

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 :)

TomyLobo

19th April 2004 19:05 UTC

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 :D)

Neoavs

20th April 2004 16:55 UTC

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++?

TomyLobo

20th April 2004 18:57 UTC

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.