SAS/C and extern "C"

[emufan]

thanks alkis, i saw this, but is this enough?
one thing mandatory, they want a SPACE between each of the settings.

i have to test the plugin again, *brb*

#1) it doesnt work. Blinker plugin is different plugin type,
it saves its properties in the object file, and this does work.
even just removing the c++ part from load/save.

other plugins save to the scene file and here i get only the plugin tag
with a empty line - which should hold the parameters.

once started the plugin, the load function should read from that scene file,
result it some big random numbers, in the plugin option panel.

i do some more tests.

[alkis]

It's not mandatory.
They are saving strings with spaces in between. My proposal saves (and loads) raw structure data. If blinkc.c works, I can't see how this technique won't work here.

[emufan]

Originally Posted by alkis

It's not mandatory.
They are saving strings with spaces in between. My proposal saves (and loads) raw structure data. If blinkc.c works, I can't see how this technique won't work here.

thats what i ask myself.

in one plugin the author fixed a space in the "save" function - it didnt work before,
i so i got that "info" from

#1) in lwran.h there is a LWIO_SCENE and LWIO_OBJECT mode.
and i found a support file for the layout load/save operations.
header file is at the end of the c file.

they deal with LWIO_ modes

LWIO_OBJECT mode: (*lState->read) (lState->readData, (char *) &len, 1);
LWIO_SCENE mode: (*lState->read) (lState->readData, str, maxStr);

#2) btw. i've uploaded the Lightwave SDK 5.6 to the ftp, it comes with html docs.
it lists compatibility of funtions for version 4.0 and 5.0.
much more info compared to the tiny standard sdk.

[alkis]

don't throw several new things at once. One thing at a time. Does load/save now work?

[emufan]

Originally Posted by alkis

don't throw several new things at once. One thing at a time. Does load/save now work?

i cannot say for sure.

just to explain a bit:
there are differnt types of plugins, for example: Surface shader, Image Shader

blinker is a Surface shader - it's settings will be saved with the object file, you apply the plugin to.
it manipulates some surface settings.

VidLines - is a Image shader, it draws some tv look-alike lines on the image,
in the very last step of a rendering.
the Image Shader settings will be stored in the scene file.

#1) just tested the fader plugin ( based on Blinker ) is surface plugin,
this one does store and read ( save/load) the settings from the manipulated object.

so your load/save routine does work with object files.

so maybe it is somehow different if the plugin has to save the setings in the scene file.

#2) if there is a difference, then we would see it in the original c++ source code.
there seems nothing to hint on the IOMODE ( object vs scene)

in lwran.h - also in the old 5.0 version,
LWLoadState/ LWSaveState structs lists a ioMODE member.

not sure if it is of any importance.

#3) take a look at lod.c - this plugin does write settings to scene files.
and it does some IOMODE magic with sprintf .

LOD Level Of Detail -> uses different objects dependent of the distance to the camera eye.

in the scene file it look like this:

Plugin ObjReplacementHandler 1 LOD
 3
objects/lod/saguaro_h.lwo
0
objects/lod/saguaro_m.lwo
150
objects/lod/saguaro_l.lwo
300
EndPlugin

this of course differs from other plugins.

[alkis]

Give this a shot.

[emufan]

Originally Posted by alkis

Give this a shot.

you are a magican

Plugin ImageFilterHandler 1 T42_Vidlines
 10
 3
 6
 0.100000
 0.050000
EndPlugin

did save and load of the scene, values are preserved. very cool

now i can fix the other plugins. thanks alot


#1) just looking at the code, looks universal.
you added pluginio.c - this is cool.
new load/save function looks easy enough to replicate

#2) how do i #define WORD?
found it, definition in .h file, have to move the #define block on top of src file.
lesson learned

#3) you've added readDouble and and writeDouble, nice one

#4) first one is fixed:

Plugin ImageFilterHandler 1 T42_ImageProc
 7.000000
 0
 10.000000
 3.000000
 2.000000
 4.000000
 2.000000
 7.000000
 3.000000
 9.000000
 2.000000
EndPlugin

#5) fixed now 4 plugins, all do work, saving their settings to the scene file.
this is really a great achievement. there are still some plugins in WIP state.
but this will be solved for sure too.

thanks alot for your help, alkis

[emufan]

another WIP plugin, while linking says this:

SAS/C Amiga Compiler 6.58
Copyright (c) 1988-1995 SAS Institute Inc.
Slink - Version 6.58
Copyright (c) 1988-1995 SAS Institute, Inc.  All Rights Reserved.

Error 502: _malloc symbol - Distance for Reloc16 > 32768

  First Reference in Unit vhud.c at offset 00000098 in file 'vhud.o'
  To Unit malloc.o at offset 0000e558 in file 'LIB:sc.lib'

*** SMAKE: Error return from child process ***

there are 2x malloc in the src file (150kb)

line: 356:        lw = malloc(sizeof(struct IFPLUGIN_TAG));
....
line: 3279:         udata = malloc(sizeof(struct callback_TAG));
...

something is going to be too big? any idea?

#1) in the sasc manual, is a solution:

Compile the file with -code=far, or
            declare the function with the __far keyword.

not sure how to do that, but i'll have a look.

#2) in SCOPTIONS file, add: CODE=FAR

[emufan]

another attempt with goo plugin. initially the original c++ src was fixed,
but the resulting SASC binary does not work at all - hence the conversion to c

i converted allmost all like seen in the other successfull builds.
with goo, there is a include file, with c++ class, constructors.
this differs from other class defintions - i cannot convert it to c.

attached, original cc, c src which builds, but missing functions,
and the c scr with partially included stuff from lwglobals.hh

alkis?

[alkis]

Originally Posted by emufan

#2) in SCOPTIONS file, add: CODE=FAR

Put that in smakefile (for that plugin) so you won't need to worry about the scoptions file.

[emufan]

Originally Posted by alkis

Put that in smakefile (for that plugin) so you won't need to worry about the scoptions file.

allright

CFLAGS  = cpu=68020 math=68881 opt nostkchk idir=$(UINC) CODE=FAR

[alkis]

Any chance this works?

[emufan]

Originally Posted by alkis

Any chance this works?

almost

Melt mode does melting the obhect. when it starts ( frame 5) it starts with skrinking the object by 50%, next it does the melting.
with OOZE mode nothing happens.

i try the peecee version, to get a clue what it should do.
*argh* only sgi binary of the plugin :/

#1) looking at the source and your changes. i guess i now understand what to do in such case.
thanks, another lesson learned

#2) i found somthing:

//Flags function
XCALL_(unsigned int) flags(LWInstance)
{
        return LWDMF_WORLD;
////return NULL;
}

i reverted the return value, so now it does a good melt
one initial value seems wrong, lastg value in the gui, is 0.0078, but working value is 1.
in the scene file the last value is 0, i have to look at the value in the src.

--> it is float fObjBounds , it is always handled as float,
but whatever is saved in the scene file (save fucntion),
when opening the gui, it allways says: 0.0078
rather strange.

#3) in the save function, there was/is an "ends as last entry,
this one is nowhere defined in the source,
so i skiped it in my save conversion:

XCALL_(LWError) save(LWInstance inst, const LWSaveState *lwss)
{
        GOO *defInst = (GOO *)(inst);
                writeInt(lwss, defInst->uStartMelt);
                writeInt(lwss, defInst->uMaxTime);
                writeFloat(lwss, defInst->fObjBounds);
                writeFloat(lwss, defInst->fGroundPlane);
                writeFloat(lwss, defInst->fFlatWidth);
                writeInt(lwss, defInst->tTypeGoo);


        // ostr << defInst->uStartMelt << SPACE << defInst->uMaxTime;
        // ostr << SPACE << defInst->fObjBounds;
        // ostr << SPACE << defInst->fGroundPlane << SPACE << defInst->fFlatWidth << SPACE;
        // ostr << defInst->tTypeGoo << ends;

can we skip "ends" ? it shouldnt matter, since load does not read a value with name "ends",
but i dunno exactly.

[alkis]

Hmm, try changing line 326 from double val; to float val;

Ok, I realised I reformated the code and I might have changed the lines...here is the code

float readFloat(const LWLoadState       *lState)
{
	if (lState->ioMode == LWIO_OBJECT) {
		float            val;
		(*lState->read) (lState->readData, (char *) &val, 4);
		BSWAP_L(val);
		return val;
	} else {
		char             buf[50];
		float           val;
		(*lState->read) (lState->readData, buf, 50);
		sscanf (buf, "%f", &val);
		return (float) val;
	}
}

change is marked red.

[emufan]

Originally Posted by alkis

change is marked red.

this did the trick.
maybe we should write a bug report to newtek, for their pluginio.c code

while melt does work ok, there is not a single pixel moving in Ooze mode.

#1) i've managed to build the win32 version with MSVC6 and
cl.exe using original c++ src code, just changing:

//	istrstream istr(cInBuf, 64);
	std::istringstream istr(cInBuf, 64);
//	ostrstream ostr(cOutBuf, 64);
	std::ostringstream ostr(cOutBuf, 64);

it does work the same way, as the amiga version.
melt does work well, while ooze does nothing,
maybe it needs some experimenting with the values.

so for now i'd say, goo is done.

thanks again alkis

ps: is HiSOFT C++ 4.0 any good?

[alkis]

well, if you look at the source code in evaluate you'll see that ooze doesn't have any real work to be done. it's just two ifs and no frame-dependent code. So, I don't think the original author wanted it to do anything more.

Never tried HiSOFT C++ 4.0. I've heard it's a sort of customised gcc and the impressions of it all arround are mixed.

[emufan]

that was a good pointer. from the lines in the src, it does manipulate values
dependent on position of the object to the groundplane.
so now when moving an object below the ground plane, it does
animate the oozing/melting.
melt does work with a static, non moving objects. while ooze will handle animated objects.

#1) ok, i skip hisoft.
c++ to c conversion is more fun anyway and it does work very well

[emufan]

some small issue with a cpp source and sas/c:

"abs undeclared" - i exchanged all "abs with "fabs", which was used in another cpp source.
is this an issue - is there another solution?

[alkis]

abs is for integers, fabs is for floats.
abs is/should-be prototyped in <stdlib.h>
fabs is/should-be prototyped in <math.h>

check the type of the argument and use the apropiate one.

[emufan]

Originally Posted by alkis

abs is for integers, fabs is for floats.
abs is/should-be prototyped in <stdlib.h>
fabs is/should-be prototyped in <math.h>

check the type of the argument and use the apropiate one.

thanks alkis

both are included, only int stuff, for some coordinates:

    switch (bi->ndigits)
            {
            case 0:
                    l = abs((int)storeit[1]);
                    if (l > 9999) l = 9999;
                    sprintf(buffer,"%.4d",l);
                    break;
            case 1:
                    l = abs((int)storeit[1]);
                    if (l > 99999) l = 99999;
                    sprintf(buffer,"%.6d",l);
                    break;
            default:
                    l = abs((int)storeit[1]);
                    if (l > 99999999) l = 99999999;
                    sprintf(buffer,"%.8d",l);
                    break;
            }

sc:include/math.h only has fabs
sc:include/stdlib.h only defines abs #ifndef _cplusplus

stdlib.h has a labs "long int", should i use this?

#2) the CODE=FAR issue went away, after I disabled the strstream stuff.
it's a lot stuff to replace - so i just disabled the load and save routines, for now

#3) the strsteam stuff i'll replace with the working c alternative, shouldn't matter