More answers
So, here you go.
> FROM: Martine Enthead
> All these "fileselectors" use the same feelfunction, but should
> someway be seperated so that I can update the right image and info
> window. The only variable I get into the feelfunction is (Dialog *d) >
and there seems to be no way to get the identifier!?
>
> -M.E
Well, because the Dialogue structure is navigated as a heirarchy, there is no
index around during the do_dialogue phase. One could be derived from the base
address of the array minus the address of the current structure, divided by the
size of Dialog structure. You could also identify the unique dialog from its
x,y location.
> ==============================================
> FROM: John Foust – Syndesis Corporation, 76004,1763 >
> SUBJECT: Latest IPAS questions >
> To: Jonas Ruikis 73172,1351
>
> 1. The 3DE.EXE dialog editor program causes a QEMM illegal
> instruction error on my system, although I'm able to run 3DS without >
trouble.
Aw, tisk. 3DE is an unsupported product, use at your own risk.
> 2. Is there an official registry for the VERSION numbers for the >
static DlgEntry cdialog[]? Must these be unique amongst all the
> other IPAS routines available on the system? If not, what are these >
numbers used for?
These numbers are matched against the IPAS routine name, so they must be unique
among each routine. They should be changed whenever the state date's layout is
changed, so you don't end up loading the new version of the routine, with old
data that is organized incorrectly.
> 3. Are there functions or packet commands to set materials within a >
PXP, or any type of IPAS for that matter? I see the EXP_MATERIAL
> packet, which can return a material name from a number, or a number >
from a name. But no material attributes such as color, etc. can be > set
or retrieved. Without a way to do this, my conversion tools are > limited
to "geometry only" and ignore materials completely.
There is no way to create a material through IPAS.
> 4. If there is no longer any support for Weitek coprocessors, then >
why is the "_I" suffix still required for IPAS routines? It eats up > two
of the eight filename characters for no reason.?
Because _W routines still exist, and they even work on a Weitek/Intel equipped
system.
> 5. In "exprtn.h", there is some indication that a PXP can be called >
"from another module". What does that mean? Line 525:
>
> #define PXP_MAGIC_2 0xBC51AFFE /* Used when PXP is called >
from other module */
It's internal fluff that never got implemented in 3DSR3.
> 6. I've had several instances where I make an absolutely
> insignificant change to a PXP, re-compile, re-link, and when I select >
it and click OK in the 3D Editor, I get a protection fault. Does the >
link order and total code size have some effect on what happens when > 3DS
loads an IPAS?
Um, if you are compiling, linking, and running the PXP without ever killing
3DS,
there could be all sorts of wierd things going on becase 3DS has no concept of
"reloading" an IPAS routine. You could also have a bug.
> 7. Should I be expecting individual answers to my questions?
Jonas, you should answer this one.
> ============================================== >
> FROM: John Foust – Syndesis Corporation, 76004,1763 > To: Jonas
Ruikis 73172,1351
>
> I didn't have your phone number, so I left a message on the MM tech >
support voice mail.
>
> 1. The default memory model for Metaware is "small", aka -Ms. And >
previous IPAS routines didn't specify the memory model. So the
> #pragma Memory_model(Small) isn't really necessary, is it? Why was >
it introduced?
Because you never know when Metaware is going to change the defaults on you,
and it
doesn't hurt to be explicit about what you want.
> When they say "small model", it's not the same thing as 16-bit
> compilers with 64K segment, 64K total code and data restrictions, >
right? But if their segments are actually 4 gig or so, what's the
> point of "small" at all? How large can my code get before I need to >
prepend "far" modifiers to all my function declarations?
Small in the 32-bit world is 4 gigs.
Far pointers have very little to do with size of data in 32-bit compilation.
In 32-bit mode, "far" modifiers create 42 bit pointers (seg+address). 3D
Studio
runs in a different segment than the IPAS routine, so it uses far pointers to
communicate. I suggest reading intel's 486 manuals for more info on protected
mo de
memory management.
> 2. As for the #pragma Align_members(1), I believe I am free to do >
this in any code under Metaware:
>
> #pragma Push_align_members(1); > #include "pxp.h"
> #pragma Pop_align_members;
>
> to allow my code to have its own structure packing. Do you see any >
problems with this?
That seems about right, but you may also need to do it for some function
calls too, as "align_members" also effects data packing on the function stack.
> ============================================== >
>
> FROM: Don Hanson [BLACKBOX], 71344,2201 > TO: Jonas Ruikis,
73172,1351
> DATE: 02/20/94 at 21:41
>
> SUBJECT: questions and comments >
> Hi Jonas,
>
> Well now, the new dialog library and 3de.exe are very cool and will >
doubtless be the way of the future. There are however some annoying >
traits, and some things about which I must ask you.
>
> Comments: 3de.exe makes it very tedious to build menus as you work. >
Each time another button/string/etc. is added, the defined numbers in >
the .3de file usually all change. This means you must write them
> down, hunt through your .c program and change the define numbers to
> match.Note that this is NOT the case for editable fields, ie. when you >
add another integer field to a menu the define numbers all change, but >
the mainedit[x] simply adds the new variable to the END of the
> mainedit list. If possible, I would recommend that the define numbers >
be calculated in the same manner as the mainedit[x] fields to ease
> programming.
That would be a nice feature, but we are not actually doing any work on 3DE.
It's a use at your own risk application.
> Question: In orbit.c there are four defined state variable
> indexes,1-4,(32-35) These are defined as ST_variablename. The State >
structure definition (73-79) does not include the ST_ prefix. In the
> ClientSetStateVar and ClientGetStateVar the case ST_ version calls the >
non-ST_ version. I am unclear why this must be done. Is it to avoid >
confusion with the "real" define numbers called in the .3de file?
It was easier to do it that way.
> Question/Comment: The description of the functions is very good, but >
the real-world use of buttons/sliders/editable fields/etc. appears
> lacking. Some pseudo code in the manual showing all the necessary
> statements to support that editable field would be nice/very useful.
All I can say is that 3DE is very difficult and awkward. We almost killed it
for that reason as we didn't have the engineering time to spend on it. It is
much more tedious to create Dialogue structures by hand, but then again, you
might actually understand them better if you do.
> Question: In orbit.c please explain what is going on in lines
> 369-373. state.tiltLR is the state structure variable. Why must
> slid[0] and main_slid[0] both be updated with state.tiltLR? What is >
slid[0]? Where is it declared? (.3de file?)
slid is declared at the beginning of the ClientDoCustomDialog function and is
used as a temporary variable.
> Question: regarding using appropriate key type in
> kxp_get_key_by_number, I'm afraid I'm still lost. It was stated: >
KXPKey avec;
> KXPVecKey *akey = (KXPVecKey *)&avec;
> So we now use akey as type KXPVecKey. How is the data accessed under >
akey? akey.avec.e[0]? akey.x? Is avec still used? avec.e[0]?
> Why the heck can't we go KXPVecKey akey; ???
It's done that way because all keys, regardless of content, must be the same
size for 3D Studio to deal with them. If you notice, in the final release,
I stuck place holders in the KXP*Key structures so that they are all the same
size now, so you don't have to pay any attention to this pointer casting
nonsense .
> Comment: I think the KEYHEAD info should be included/returned in the >
InterpData structure/command.
I agree, that would be nice, should we get an opportunity to change the
internal workings of 3D Studio, we will consider it.
> Question: Do you have any working examples of app_data being used in a >
program? There is an example of searching for an app_data header in
> the manual, but the manual also states that each program must read the >
headers, and then write ALL of them back to the file. A practical
> working example would be invaluable.
Try looking at the INFO.C that ships with the final release. It has a set of
functions for working with app_data.