1. VB-to-Eu converter for Morfit's VB SDK
------ =_NextPart_000_01BF6968.AC919300
Hi all,
Following in Mark Brown's footsteps, I've done a little
tinkering with Morfit's 3D engine, and have attached a
zipped Euphoria program that converts their VB SDK include
file (MORFITVB.BAS) to a Euphoria include file. (It's
fairly small.)
First, visit http://www.morfit.com and download their
VB SDK. Then put MORFITVB.BAS in a common location with
VB_TO_EU.EX and run it. It will produce MORFITEU.E
The new file works well for the few Morfit routines I've
tested. Just "include morfiteu.e", making sure it has
access to the downloaded Morfit DLL, and you're set.
However, take note:
>A word of caution about using the VB include(s). There are more than one! In
>fact, there seem to be special versions of the include for all the examples
>in the VB SDK and they don't all include the same functions. (though I have
>now found at least one function in the VB include which is not in the C++
>one)
Mark and Todd Riggins are working on a more complete API
based on the C++ SDK, and I'm sure you'll want to get a
hold of it as soon as it's released. But for those who want
to jump in right now, VB_TO_EU.EX will give you a start.
Have fun,
Rod Jackson
P.S. -- I've also included a quick-and-dirty .EXW
program that will load any specified Morfit world
from disk and keep displaying it until a key is pressed.
Win32Lib NOT required.
------ =_NextPart_000_01BF6968.AC919300
2. Re: VB-to-Eu converter for Morfit's VB SDK
- Posted by M King <boot_me at GEOCITIES.COM>
Jan 29, 2000
-
Last edited Jan 30, 2000
Hi Rod,
I tried it and it worked great. Even had an animated world running at
an amazing 3 fps. I searched through the genereated .e file, and couldn't
find a wrapper for the mentioned:
Morfit_engine_activate_DirectX
routine. Did they leave it out of the VB version? This was the 3.0 sdk for
vb 6.
I was thinking I might get a major fps jump with this enabled. I tried
activating the 3d card, but didn't get an increase, and tried the ctr-alt-v
that it mentioned to activate the card, but got an error.(it did generate a
3d card file though)
any help would be appreciated. Thanks for the glimps into Morfit. (would
the c version be faster?)
Monty in Oregon
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Friday, January 28, 2000 6:17 AM
Subject: VB-to-Eu converter for Morfit's VB SDK
>Hi all,
>
>Following in Mark Brown's footsteps, I've done a little
>tinkering with Morfit's 3D engine, and have attached a
>zipped Euphoria program that converts their VB SDK include
>file (MORFITVB.BAS) to a Euphoria include file. (It's
>fairly small.)
>
>First, visit http://www.morfit.com and download their
>VB SDK. Then put MORFITVB.BAS in a common location with
>VB_TO_EU.EX and run it. It will produce MORFITEU.E
>
>The new file works well for the few Morfit routines I've
>tested. Just "include morfiteu.e", making sure it has
>access to the downloaded Morfit DLL, and you're set.
>However, take note:
>
>>A word of caution about using the VB include(s). There are more than one!
In
>>fact, there seem to be special versions of the include for all the
examples
>>in the VB SDK and they don't all include the same functions. (though I
have
>>now found at least one function in the VB include which is not in the C++
>>one)
>
>Mark and Todd Riggins are working on a more complete API
>based on the C++ SDK, and I'm sure you'll want to get a
>hold of it as soon as it's released. But for those who want
>to jump in right now, VB_TO_EU.EX will give you a start.
>
>Have fun,
>
>
>Rod Jackson
>
>P.S. -- I've also included a quick-and-dirty .EXW
>program that will load any specified Morfit world
>from disk and keep displaying it until a key is pressed.
>Win32Lib NOT required.
>
>
3. Re: VB-to-Eu converter for Morfit's VB SDK
-----Original Message-----
From: M King <boot_me at GEOCITIES.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Sunday, January 30, 2000 3:51 PM
Subject: Re: VB-to-Eu converter for Morfit's VB SDK
Hi Monty
I'm replying to your post just in case Rod can't (he said he was signing off
for a short while).
> I tried it and it worked great. Even had an animated world running at
>an amazing 3 fps. I searched through the genereated .e file, and couldn't
>find a wrapper for the mentioned:
>Morfit_engine_activate_DirectX
>routine. Did they leave it out of the VB version? This was the 3.0 sdk
for
>vb 6.
I just checked for that function in the VB include and I couldn't find the
function you mentioned (Morfit_engine_activate_DirectX).
I also checked the C include and it is not there either (that I could see).
It is certainly in the documentation though. Perhaps it is obsolete?
You could add it by hand to the file generated by Rod's program using the
following :-
global constant Morfit_engine_activate_DirectX =
The function takes no parameters and returns a C integer which is just OK or
VR_ERROR.
You should be able to add any functions you find missing in this way. (I'd
like to know if you find any more)
If the above doesn't allow you to use the function, check that the dll name
variable (morfit_dll) etc I have used is correct as I haven't had a good
chance to look at Rod's work.
>I was thinking I might get a major fps jump with this enabled. I tried
>activating the 3d card, but didn't get an increase, and tried the ctr-alt-v
>that it mentioned to activate the card, but got an error.(it did generate a
>3d card file though)
>any help would be appreciated. Thanks for the glimps into Morfit. (would
>the c version be faster?)
>Monty in Oregon
>
>
I doubt that the C version would be faster. I would think that the dll for
all versions of the SDK would be the same. The way the functions are called
is different and therefore the need for different includes. I may be wrong
about this but I have had both dll's installed at various stages and there
appears to be no difference.
In speed terms (on my 333Mhz Celeron, 3D card etc) there wasn't all that
much difference between an EU version and the C ones when the functions
being used are simple (ie. they don't use floating point or require pointers
to arrays in memory) and still seems to be quite good when complex functions
are used.
Good luck.
Mark Brown
