#Rewite the IPAS for NT?
15 messages in this thread
Hi, I am a proud owner of 3D Studio Release 4. I also own the Yost Group IPAS
#2, Bubble, Magic, and Mirage. I love what IPAS can do for me, and the power of
3DS.
I heard that the next release of 3DS will be NT based. I'm very glad to hear
that. I'm all pumped up and ready to go for the ultimate true 32 bit
envirement. But I also heard so rumors that all the IPAS for the dos based 3DS
will not be useble in the NT version of 3DS. All the 16 bit IPAS have to be
rewritten to be 32 bit. Is that true? If it's true, what can we do? Will we be
offer to send it the old disks, and get a replacement of the new NT version?
Hi Aaron,
<< Will we be offer to send it the old disks, and get a replacement of the new
NT version? >>
Since many of the 230+ IPAS routines were created by non-Autodesk developers,
many of the upgrade logistics will be determined by the individual developers
after they've gotten to see and review the product at Siggraph.
Personally, I believe that it would be possible to incorporate the use of the
old DOS based IPAS's in the NT version. Naturally, they will not be optimized,
and there will ber a certain loss possible in some kind of translation, but it
would be better than waiting for the majority of non-ADesk IPAS developers to
get around to porting their IPAS's to NT. Not to mention the sheer hassle, and
IPAS routines that are shareware, feeware, and the like that may NEVER get
rewritten to NT.
I believe the capacity to run old DOS IPAS's, even if it needs to be thru a DOS
window, would be a valuable part of this move.
Personally, I've refrained from buying any more IPAS's until I find out what's
going on with updates, unless I REALLY need them. I don't want to have to pay
for an update so soon.
Another issue would be – will ALL the ADesk supported IPAS developers have
their IPAS updates ready for when r5 comes out? If not, you might find a great
number of people waiting to upgrade until their IPAS routines are also upgraded
– unless, of course, you make the DOS IPAS support I mentioned…
Jerome, in the best of all possible worlds, there would be a seamless
transition from DOS 3DS over to NT 3DS. However, since NT is so radically
different from DOS, we'd have to make huge compromises on the NT side in order
to allow the DOS code to continue to run. (That said, in many areas there are
great similarities, which will make things quite easy for IPAS developers.)
Because we're building a 3DS that has to remain current (technologically) for
the next five years, it would be insane for us to make compromises like that.
Yes, there will be a bumpy transition period for a little while, but the extra
capability that you'll get with the NT architecture will more than make up for
it.
And, during the transition, you'll still be able to use your DOS 3DS to get
work done that requires IPAS routines that haven't been ported yet. Also,
since the NT plug-in interface won't require such arcane tools as Phar Lap and
Metaware HighC, I'm _sure_ you'll find much more interesting plug-ins for the
NT version than there ever were for the DOS version (and more of them).
Before you make any hasty judgements, you might want to come to Siggraph and
check out the future. It's not as harsh as you might think.
– G
Thank you very much for the info. I wouldn't have thought you'd have to make
comprimises to the actual 3DS product ITSELF to allow it to run DOS IPAS
routines, I would just think you would need an extender to do the translation
between the full-NT 3DS and the DOS based IPAS. However, I'm not enough of a
developer yet to ssay for sure.
But – you're right, I'd rather see a better 3DS ANY DAY than to cripple it to
avoid a little inconvenience in IPAS replacement. Will the YG IPAS routines
charge for updates to the new platform? Anyways, I wonder how portable meshes
will be from r5 to r4 – will r4 still read them at all?
Oh, and I'm PLANNING on being at SIGGRAPH. Last year was my first, and I
wouldn't miss this one for the world! I'll look forward to seeing all you3DS
people and the new version there!
Just a couple things to keep in mind as the new version gets put together:
(these things are already in the wishlist, but these are important enough that
repeating them couldn't hurt): ***BETTER BOOLEANS*** ***BETTER BOOLEANS***
***BETTER BOOLEANS*** ***MUCH BETTER BOOLEANS*** At least SOME Cad accuracy in
the shaper/lofter, with object snaps and absolute coordinates A routine to
allow strecthing a mesh like silly putty (similar to Magnet)
Thanx!!! -jk
We're going to try our best to make the transition as painless as possible.
– G
>>We're going to try our best to make the transition as painless as possible.
———————
I'm sure you will! I'm actually looking quite forward to R5 and a full blown
32 bit OS, not to mention a lot of new features I've heard speculation about
being included in the new version.
I almost forgot to add something to my little commentry on things to keep in
mind for R5; THIS one is even more up your alley than any of the rest of the
wishlist crew, as it would lend itself so well to an IPAS. That is an
auto-mapping routine. This could be almost as important as CAD accuracy and
better booleans. See my item in Wishlist for more… It shouldn't be too hard
to develop a routine that applies mapping coordiantes automatically to
individual planes around the object for you…
<< wish.. >>
got it.
<<Because we're building a 3DS that has to remain current (technologically) for
the next five years>>
So once you've finished R5 you guys are taking a five year holiday? <g>
DaviD "Lead pompom dancer of the 3DS cheer squad" GouID
Oh yeah… right… five years in Paris. (That's where I'm going. 🙂
Well… at least we won't be rewriting it for another operating system for at
least five years. (These OS switcheroos are pretty intense.)
– G
It might not be possible to support the existing IPAS's _as_is_ under NT, as
they all expect the support of the PharLap DOS extender, which won't be
present.
Dave
It might not be possible to support the existing IPAS's _as_is_ under NT, as
they all expect the support of the PharLap DOS extender, which won't be
present. ———————-
That was my thought – an extender that operates between a full NT 3DS and a DOS
IPAS to "trick" the IPAS, feed it the necessary info, and takl the talk as an
intermediary.
My guess is it's POSSIBLE, one way or another – but would it be so difficult
that there's no way it would ever begin to be worth it?
Oh, well – that's me; never consider something impossible until I'm shown it's
truly, unqestionably, NOT possible <g>
Jerome:
Oh sure, it's no doubt POSSIBLE, but considering that the Yost Group (heck,
Autodesk all together) has in the past chosen to use a third-party DOS extender
rather than write their own seems to suggest that they'd hardly take the time
and effort to do it just to facilitate a few-month transition period from
r4-r5.
The word has been that even when r5 has been released, r4(DOS) will continue to
be made available for an indefinite period of time, so those who CAN'T take the
loss (albeit temporary) of any IPAS routines will still be able to produce
work.
Dave
Oh sure, it's no doubt POSSIBLE, but considering that the Yost Group (heck,
Autodesk all together) has in the past chosen to use a third-party DOS extender
rather than write their own seems to suggest that they'd hardly take the time
and effort to do it just to facilitate a few-month transition period from
r4-r5. ——————————————-
Heh…. quite true. I guess it's more a matter of a cybernetic "bone to chew
on" problem to think of for me. Like "hey! This CAN be done!" and having fun
thinking about it, as opposed to thinking "hey – this is worth the time spent
and SHOULD be done"! 😉
——————————————- The word has been that even when r5
has been released, r4(DOS) will continue to be made available for an indefinite
period of time, so those who CAN'T take the loss (albeit temporary) of any IPAS
routines will still be able to produce work.
——————————————
Which sound like a good idea…
>ultimate true 32 bit<
If and only if they're compiling for Windows NT Alpha cpu. The Intel is
adequate, but not at fullest potential.