Where will the pair be going in the future?

I imagine that if the project is not abandoned, they will continue to
grow closer and closer. Eventually (in a far future?) it would be
possible to use one program with the ease of use and visualization of
Moray, and all the scripting power of straight pov code.

In an ideal world, the end product would be a renderer that is a good
tool for the most diehard POVer, but also something a complete newbie
can jump into and feel comfortable.

Ah well... it's a nice dream. Every step Moray takes is one step closer
to realising the dream.

Post a reply to this message

Perhaps we ought to consider making Moray more general- its current
abilities to export
only to POV-Ray hamper its success. Moray is possible the BEST SOLIDS
MODELER available for the price. As such, it would be nice if it could
export to other renderers that accept solids(BMRT...) so that it would
become a bit more portable, and reach a larger audience(read customer
base).

Simon de Vet wrote:

> Where will the pair be going in the future?
>
> I imagine that if the project is not abandoned, they will continue to
> grow closer and closer. Eventually (in a far future?) it would be
> possible to use one program with the ease of use and visualization of
> Moray, and all the scripting power of straight pov code.
>
> In an ideal world, the end product would be a renderer that is a good
> tool for the most diehard POVer, but also something a complete newbie
> can jump into and feel comfortable.
>
> Ah well... it's a nice dream. Every step Moray takes is one step closer
> to realising the dream.



--
The problem with the gene pool is that there is no lifeguard.

Post a reply to this message

Hi Alex Magidow, you recently wrote in moray.win:

> Perhaps we ought to consider making Moray more general- its current
> abilities to export only to POV-Ray hamper its success. 
Yes, this is the direction we are taking. While we still anticipate
POV-Ray as being the renderer we will support most closely, other
renderers are definitely on the list of things to support.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

POvray should contine to be developed as it is, a seperate entity. its one
of the render engines strongest points compared to other commercial high end
software. (more features would not go amiss tho - and maybe quicker
ingegration of the various patches)

Moray on the other hand, needs to be able to keep up with the latest POVray
developments (ie UVPOV) , the best and simplest method i can think of is its
plugin system, which seems to have gotten over most of the early hiccups

Moray would vastly benifit from a script type plugin, for example, one that
you can paste a chunk of while do's into and it will build the output as
moray objects, on that same note the ability to parse POV script would be a
real step forward - even a limited subset of the full language would be
extremly usefull - however wether this should be as a plugin or part of
moray depends on who would be best suited to write and maintain it (i think
Lutz would shudder somewhat if this was lumped on his shoulders!!)

A simpler plugin system (as discussed on sdk-list) would be a real
advantage, something allong the lines of beginner VB would be perfect - draw
your UI then write simple and easy to learn code to power it.

(I have just started VB6 and i am amazed at how short the learning curve
really is - ok there are 1 million and 1 things i am doing badly, my code is
about as optomised as a pair of giant clown shoes with running spikes on,
and there are thousands of things i just dont know how to do)

But, would a moray plugin system need anything more complicated than drawing
common controls, naming them, and some form of basic code to tie it all
together, especially if the plugin is only going to manipulate or create
objects in moray.

more complex plugins may well be suited to the current VC SDK system, think
about it, if your going to program a new render engine or animation system,
and think you can accomplish this at the outset, you most likely already use
VC or another high end dev tool.

Moray would also benifit from support of other solids based render engines
(some one mentioned BMRT) but this would ONLY be worth doing if moray could
be as compatable with that system as it is with POVray, being able to use a
only a subset of the target render engines capabilities would be almost
pointless - a bit like the early polyray plugin.

Moray would also benifit from an overhauled patch modelling system,
personally i find the current system a nightmare to use properly, and as
spatch seems to be dead in the water these days maybe a merger of sorts
would be a good idea.

Better CSG evaluation is also needed, having played with truespace recently
and watched it perfectly evaluate CSG objects on screen, moray seems quite
clumsy compared.

a texture cache would be nice for the tex editor, so libraried textures once
rendered can be previewed instantly. but while this would not be a complex
task to program, having a large chunk of valuable HD space taken up may not
be what everyone wants.

object masking would be essential as well, meaning the ability from within
moray to turn of parts of the scene, replacing them with a single large
bounding box. currently i have difficulty modelling when this start to get
very complex - there are just to many objects for me to be able to see what
i am doing, even though where ever possable i model everything seperatly and
combine later. this would also help to combat big scene slowdown.

another thing that would help with big scene slowdown, would be a better
method of redrawing the scene, Moray tends to overdraw the same pixel many
many times (once for every object that intersects that pixel).

the abitlty to color objects in the modelling windows would be nice also, i
dont know about anyone else but playing hunt the grey object in a haystack
of grey objects gets a little tricky.

====

Ok thats me about requested out  :), dont get me worng, moray is one of my
favorite modelling tools and i love it to bits.

Rick

Post a reply to this message

Alex Magidow wrote:

> The problem with the gene pool is that there is no lifeguard.

Yes, I know that it's got nothing to do with moray but a lifeguard (in
human scales) would be the death of the genepool. That ain't working and
history shows it.

Post a reply to this message

Hi Rick, you recently wrote in moray.win:

> [lost of good suggestions snipped]

Thanks for the great feedback. I'll make sure we think about all your
points. One of them is already in the next version (the Material
Editor and Library cache the textures).

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly,
> and as spatch seems to be dead in the water these days maybe a 
> merger of sorts would be a good idea.

Indeed!
It would already help a lot if you could change the patches in 3D
windows (there is at least one in the edit tab, normally).

> object masking would be essential as well, meaning the ability from
> within moray to turn of parts of the scene, replacing them with a 
> single large bounding box. currently i have difficulty modelling 
> when this start to get very complex - there are just to many 
> objects for me to be able to see what i am doing, even though where 
> ever possable i model everything seperatly and combine later. this 
> would also help to combat big scene slowdown.

there are methods to do this (global visibility settings- check the
manual to understand the system). The problem is not that this doesn't
exist, but I think it's too difficult to use, so I've never actually
used it.

> another thing that would help with big scene slowdown, would be a
> better method of redrawing the scene, Moray tends to overdraw the 
> same pixel many many times (once for every object that intersects 
> that pixel).

Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
just always consist of the same number of lines. What if this depended
from their actual pixel size of the screen? While big spheres could
gain accuracy, smaller ones could be drawn with fewer lines, thus
speeding up things a lot.

=====

Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
...

Florian

Post a reply to this message

Simon de Vet wrote:

> Where will the pair be going in the future?
>
> I imagine that if the project is not abandoned, they will continue to
> grow closer and closer. Eventually (in a far future?) it would be
> possible to use one program with the ease of use and visualization of
> Moray, and all the scripting power of straight pov code.

>
>
> In an ideal world, the end product would be a renderer that is a good
> tool for the most diehard POVer, but also something a complete newbie
> can jump into and feel comfortable.
>
> Ah well... it's a nice dream. Every step Moray takes is one step closer
> to realising the dream.

Well the scripting as a plug in that would allow users of Moray to copy
snippets of Pov code into the "editor window" then let moray make the
object it's way from the code would be a GREAT help IMHO....

Post a reply to this message

Hi Florian Fischer, you recently wrote in moray.win:

> there are methods to do this (global visibility settings- check the
> manual to understand the system). The problem is not that this doesn't
> exist, but I think it's too difficult to use, so I've never actually
> used it.
Yes, this is not a optimal solution and one of the things we have
planned for a later version (not the next one) is a normal layer
system as many other packages have them.

> Rick wrote: 
> > another thing that would help with big scene slowdown, would be a
> > better method of redrawing the scene, Moray tends to overdraw the 
> > same pixel many many times (once for every object that intersects 
> > that pixel).
Yes, only the edges are drawn and if they overlap (which they always
do when there are lots of objects, they are drawn multiple times.
Checking whether the pixel has been drawn wouldn't change anything,
except slow down the redraws.

> Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
> just always consist of the same number of lines. What if this depended
> from their actual pixel size of the screen? While big spheres could
> gain accuracy, smaller ones could be drawn with fewer lines, thus
> speeding up things a lot.
That's a good idea, but is unsuitable for the current way that the
edges are handled in Moray. This is because you could have up to four
different settings for size on screen and we'd then need four
*different* edge lists, instead of the single one we have now. This
means four-times the memory footprint.

> Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
Hehe, and you haven't even seen the long list that we'd like to
implement<g>.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Rick wrote:
> 

> Moray would also benifit from support of other solids based render engines
> (some one mentioned BMRT) but this would ONLY be worth doing if moray could
> be as compatable with that system as it is with POVray, being able to use a
> only a subset of the target render engines capabilities would be almost
> pointless - a bit like the early polyray plugin.

I believe that the way to get compatability with other rendering engines
is through some of the newest additions to the plugin interface.  Most
notably the ability of one plugin to talk to another.

The idea here is that features of one rendering system that aren't
supported by Moray (or by POV-Ray for that matter) could be implemented
as a plugin, which would then directly talk to the plugin that is
supporting the alternate renderer.

> 
> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly, and as
> spatch seems to be dead in the water these days maybe a merger of sorts
> would be a good idea.

I agree - polygonal modelling capabilities with conversion to
subdivision surfaces.

> object masking would be essential as well, meaning the ability from within
> moray to turn of parts of the scene, replacing them with a single large
> bounding box.

You can do that.  A nice addition to the current capability would be to
have layers.

Xander

Post a reply to this message

> Thanks for the great feedback. I'll make sure we think about all your
> points. One of them is already in the next version (the Material
> Editor and Library cache the textures).

Hurrah! psychic Lutz !

Rick

Post a reply to this message

> > object masking would be essential as well, meaning the ability from
within
> > moray to turn of parts of the scene, replacing them with a single large
> > bounding box.
>
> You can do that.  A nice addition to the current capability would be to
> have layers.

damn, i knew i missed something! - yes and layers :)

Rick

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote in article <3846a0f6@news.povray.org>...


> A simpler plugin system (as discussed on sdk-list) would be a real
> advantage, something allong the lines of beginner VB would be perfect -
draw
> your UI then write simple and easy to learn code to power it.


	For christ's sake, not VB - that's a horrible
travesty of a programming language. It's not even 
object-oriented! 




> the ability to parse POV script would be a
> real step forward - even a limited subset of the full language would be
> extremly usefull 

	I wrote a grammar for a subset of POV using
a Java parser called JavaCC. I use it to turn POV models
(output from Moray) into nested objects that I can combine 
and manipulate and then turn back into POV format. It
works fine but I'd like a formal description of POV language - 
does such exist?

				David

Post a reply to this message

> It works fine but I'd like a formal description of POV language -
> does such exist?

No.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

> > A simpler plugin system (as discussed on sdk-list) would be a real
> > advantage, something allong the lines of beginner VB would be perfect -
> draw
> > your UI then write simple and easy to learn code to power it.
>
>
> For christ's sake, not VB - that's a horrible
> travesty of a programming language. It's not even
> object-oriented!

Err, i think you will find it is, and remeber i was refering for a plugin
language for the masses, if VB was a little quicker, and didnt require
runtimes, nobody would bother with VC. (except maybe from the hard asses who
browse the web with a text based browser)

Rick

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote in article <387325fa@news.povray.org>...


> > VB is not even object-oriented!

> Err, i think you will find it is

	No, it's not, because it has 
no Inheritance. 



	If you want reasons why I called it 'horrible' 
I could write a much longer reply, but this is not the
correct newsgroup.


>, and remeber i was refering for a plugin
> language for the masses

	Well, VB won't do anything for 
the Linux masses.


				David

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote in message
news:387325fa@news.povray.org...
> > > A simpler plugin system (as discussed on sdk-list) would be a real
> > > advantage, something allong the lines of beginner VB would be
perfect -
> > draw
> > > your UI then write simple and easy to learn code to power it.
> >
> >
> > For christ's sake, not VB - that's a horrible
> > travesty of a programming language. It's not even
> > object-oriented!
>
> Err, i think you will find it is, and remeber i was refering for a plugin
> language for the masses, if VB was a little quicker, and didnt require
> runtimes, nobody would bother with VC.

No, not really. As long as I have the choice of using Java or C++, I
wouldn't want to program in VB if it was super fast and I was being beaten
with a stick if I didn't. I only would do it for money. Much money. :-)

Johannes.

Post a reply to this message

"David Byrden" <Dav### [at] byrdencomspampreventer> wrote in message
news:01bf5777$b0dc1000$be8391c2@goyra...
> Rick <pov### [at] dialpipexcom> wrote in article
<387325fa@news.povray.org>...

> Well, VB won't do anything for
> the Linux masses.
>
Err, well, that's kinda a moot point, as Moray doesn't do a whole lot for
the Linux masses, either. Actually, Moray is the reason I switched back to
the wunderful world o' Windows :P  There were a few other reasons, but I
simply couldn't find a *nix based modeller that could touch Morays
capabilities and ease of use, and I doubt Lutz has any plans on porting it
any time soon (Matter of fact, I believe I would be shot if I seriously
suggested/expected him to :) )


Krystian

Post a reply to this message

> Well, VB won't do anything for
> the Linux masses.

who cares - they cannot run Moray anyhow!!!!

Rick

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote:
:> Well, VB won't do anything for
:> the Linux masses.

: who cares

  This is the typical attitude...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

No!!! We don't need anymore VB programmers please stop development
IMMEDIATELY.
If you want a RAD (Rapid Application Development) try Borland's Delphi
product. Then you could move up to C++ Builder and before you know it you'll
be doing programming you would have never thought possible.

"Rick" <pov### [at] dialpipexcom> wrote in message
news:3846a0f6@news.povray.org...
> (I have just started VB6 and i am amazed at how short the learning curve
> really is - ok there are 1 million and 1 things i am doing badly, my code
is
> about as optomised as a pair of giant clown shoes with running spikes on,
> and there are thousands of things i just dont know how to do)

Post a reply to this message

i am intreged by delphi, and a lot of people have said it kick VB ass, but
on the other hand, i dont have delphi, and as VB6 goes, so far its damn easy
to program, and as RAD is what i am after, VB works well for me..

I can see a point where VB will become a pain in the arse, for example when
i end up using the win api all the time, but i am not doing that at the
moment, so far VB does everything i want, quickly, and with very little
effort.

dont knock VB to much, it has it place, and as long as you dont try certain
things, or expect C++ or ASM performance it works fine, i grew up on C64
basic years ago, and VB is very similar, finding you can write win apps,
without actually having to really learn another language is a huge boon, and
as everything i write is for myself, never intended to be distributed, and
speed is just not a concern - as long as it gets the job done, and donst
give me any headaches in the process, its fine..

you should try it sometime :)

I have also used VC6, and while it has a greater kick of speed, greater
control, its incredably difficult compared to VB, and i dont have the time
to get my head around MFC propperly, so when my apps outgrow VB, i dont
think VC will be the answer, and when i get to that point, delphi may prove
to be perfect, untill then

VB ROOLS (i have never had so much fun while i was working - *not strictly
true - but this is neither the time or the place to go into that!*)

Rick



"Nicholas Hanson" <da_### [at] hotmailcom> wrote in message
news:3877fc8e@news.povray.org...
> No!!! We don't need anymore VB programmers please stop development
> IMMEDIATELY.
> If you want a RAD (Rapid Application Development) try Borland's Delphi
> product. Then you could move up to C++ Builder and before you know it
you'll
> be doing programming you would have never thought possible.
>
> "Rick" <pov### [at] dialpipexcom> wrote in message
> news:3846a0f6@news.povray.org...
> > (I have just started VB6 and i am amazed at how short the learning curve
> > really is - ok there are 1 million and 1 things i am doing badly, my
code
> is
> > about as optomised as a pair of giant clown shoes with running spikes
on,
> > and there are thousands of things i just dont know how to do)
>
>
>

Post a reply to this message

"Rick" <pov### [at] dialpipexcom> wrote in message
news:387882fe@news.povray.org...
> i am intreged by delphi, and a lot of people have said it kick VB ass, but
> on the other hand, i dont have delphi, and as VB6 goes, so far its damn
easy
> to program, and as RAD is what i am after, VB works well for me..

I find Delphi even easier to program than VB and it's a native code
compiler.

> I can see a point where VB will become a pain in the arse, for example
when
> i end up using the win api all the time, but i am not doing that at the
> moment, so far VB does everything i want, quickly, and with very little
> effort.

But by learning on it you are developing very nasty programming habits that
will haunt you later if you choose to go deeper into programming. At the
very least please get into the habit of using OPTION EXPLICIT instead of
declaring everything as varient automatically. It really is a bad language
to learn on.

> dont knock VB to much, it has it place,

I'm not saying the language has no purpose, I use it myself. I don't develop
applications for it however. I use VBScript in ASP pages, I use VBScript in
WSH Scripts, and I use VBA for Office scripting and though I can use
JavaScript for two of those I like to use a common scripting language. It is
a great SCRIPTING LANGUAGE but for Application development and especially
for learning programming it's a bad tool to use.

> and as long as you dont try certain
> things, or expect C++ or ASM performance it works fine, i grew up on C64
> basic years ago, and VB is very similar, finding you can write win apps,
> without actually having to really learn another language is a huge boon,
and
> as everything i write is for myself, never intended to be distributed, and
> speed is just not a concern - as long as it gets the job done, and donst
> give me any headaches in the process, its fine..

But Delphi is just as easy to use, compiles faster code (I find it's better
than even C++ -=USING MFC=-), and actually teaches you good programming habi
ts since it's strongly typed and far more object oriented than VB. Just FYI
if you don't know the language Delphi is based on is PASCAL so you may
already know some of the basic syntax.

> you should try it sometime :)

I'm actually a MCP and I work for a company that is a MCSP so I'm VERY
familiar with it. We have 6 copies of Visual Studio Enterprise and I still
have Delphi installed because it's just superior. I would like to note that
this is my personal opinion not those of the company I work for.

> I have also used VC6, and while it has a greater kick of speed, greater
> control, its incredably difficult compared to VB, and i dont have the time
> to get my head around MFC propperly, so when my apps outgrow VB, i dont
> think VC will be the answer, and when i get to that point, delphi may
prove
> to be perfect, untill then

I agree with out completely. VC is a very powerful tool and I recommend it
FOR EXPERIENCED PROGRAMMERS but it doesn't hold your hand at all and is VERY
BAD to learn on. Delphi on the other hand has all capabilities and ease of
use that Visual Basic does but is much more. Also it shares a common VCL and
interface with Borland's C++ Builder (which is FAR easier to use than VC++)
so it leads to a natural progression... I do think VC++ is better than C++
Builder but it's far more difficult to use so for a new person I'd recommend
this sequence:

Delphi -> C++ Builder -> VC++

> VB ROOLS (i have never had so much fun while i was working - *not strictly
> true - but this is neither the time or the place to go into that!*)

I bet you wouldn't say that after even a half hour with Delphi. It's ease of
use and power are unmatched it just doesn't have they hype.

For the record I think the Win32 version of Povray (well the interface
anyway) was written in Delphi (or at least was at one point). As was
HomeSite, Age of Wonders, etc.

Post a reply to this message

ok, you convinced me, i will try delphi when i get chance.

I did do some basic pascal in college, so i do have a bare bones
understanding of it, and i did learn a lot of good and bad programming
techniques, i do try to write basic in the same way i would write C -
otherwise its to easy to get into a real mess - but this can be said of any
lang.

most of my routines are wirtten on paper first, tweaked on paper, then
finally entered and most of the time (barring typo's) tend to work first
time, i never just jump into the editor and write the code off the top of my
head.

but i do take your point that in VB is so easy just to throw all good coding
sense out of the window.

VB isnt that bad to learn on, if your already familar with good coding
prctices, and for quick 'take this' and 'do that' apps is fine, i did some
VB3 at college as well, and yes - that sucked big time.

btw - at college they still teach basic pascal (with turbo pas 3) then in
the second year, you move onto VB, daft i know, you would think that year 2
would build on year 1, like teaching delphi in year2, or starting with C++
and doing VC in year 2.

i think this tread has ventured into the off-topic group, if you reply -
reply there.

Rick

Post a reply to this message

Nicholas Hanson wrote:

> "Rick" <pov### [at] dialpipexcom> wrote in message
> news:387882fe@news.povray.org...
> > i am intreged by delphi, and a lot of people have said it kick VB ass, but
> > on the other hand, i dont have delphi, and as VB6 goes, so far its damn
> easy
> > to program, and as RAD is what i am after, VB works well for me..
>
> I find Delphi even easier to program than VB and it's a native code
> compiler.

AFAIK, VB 5 and up do compile to native code...

>
>
> > I can see a point where VB will become a pain in the arse, for example
> when
> > i end up using the win api all the time, but i am not doing that at the
> > moment, so far VB does everything i want, quickly, and with very little
> > effort.
>
> But by learning on it you are developing very nasty programming habits that
> will haunt you later if you choose to go deeper into programming. At the
> very least please get into the habit of using OPTION EXPLICIT instead of
> declaring everything as varient automatically. It really is a bad language
> to learn on.
>

I have to agree. You can learn it in a trimester at school(I know, I just took a
class in it), but its really a bad language to start learning. I prefer the
blood and guts approach of learning C/C++. They're much nicer language, and
after using them, and using VB, you'll desperately wish you had pointers in VB.

>
> > dont knock VB to much, it has it place,
>
> I'm not saying the language has no purpose, I use it myself. I don't develop
> applications for it however. I use VBScript in ASP pages, I use VBScript in
> WSH Scripts, and I use VBA for Office scripting and though I can use
> JavaScript for two of those I like to use a common scripting language. It is
> a great SCRIPTING LANGUAGE but for Application development and especially
> for learning programming it's a bad tool to use.
>

Its nice in that it takes six seconds to get something done that takes 100 lines
of code in C(ya, the code is cut and paste, but you know what I mean)

>
> > and as long as you dont try certain
> > things, or expect C++ or ASM performance it works fine, i grew up on C64
> > basic years ago, and VB is very similar, finding you can write win apps,
> > without actually having to really learn another language is a huge boon,
> and
> > as everything i write is for myself, never intended to be distributed, and
> > speed is just not a concern - as long as it gets the job done, and donst
> > give me any headaches in the process, its fine..
>
> But Delphi is just as easy to use, compiles faster code (I find it's better
> than even C++ -=USING MFC=-), and actually teaches you good programming habi
> ts since it's strongly typed and far more object oriented than VB. Just FYI
> if you don't know the language Delphi is based on is PASCAL so you may
> already know some of the basic syntax.
>

Pascal? Delphi? I've only vaugly heard of these. Anywhere with some good infor
on Delphi?

>
> > you should try it sometime :)
>
> I'm actually a MCP and I work for a company that is a MCSP so I'm VERY
> familiar with it. We have 6 copies of Visual Studio Enterprise and I still
> have Delphi installed because it's just superior. I would like to note that
> this is my personal opinion not those of the company I work for.
>
> > I have also used VC6, and while it has a greater kick of speed, greater
> > control, its incredably difficult compared to VB, and i dont have the time
> > to get my head around MFC propperly, so when my apps outgrow VB, i dont
> > think VC will be the answer, and when i get to that point, delphi may
> prove
> > to be perfect, untill then
>
> I agree with out completely. VC is a very powerful tool and I recommend it
> FOR EXPERIENCED PROGRAMMERS but it doesn't hold your hand at all and is VERY
> BAD to learn on. Delphi on the other hand has all capabilities and ease of
> use that Visual Basic does but is much more. Also it shares a common VCL and
> interface with Borland's C++ Builder (which is FAR easier to use than VC++)
> so it leads to a natural progression... I do think VC++ is better than C++
> Builder but it's far more difficult to use so for a new person I'd recommend
> this sequence:
>
> Delphi -> C++ Builder -> VC++
>

Ouch, sounds expensive...sounds REALLY expensive.

>
> > VB ROOLS (i have never had so much fun while i was working - *not strictly
> > true - but this is neither the time or the place to go into that!*)
>
> I bet you wouldn't say that after even a half hour with Delphi. It's ease of
> use and power are unmatched it just doesn't have they hype.
>
> For the record I think the Win32 version of Povray (well the interface
> anyway) was written in Delphi (or at least was at one point). As was
> HomeSite, Age of Wonders, etc.

Interesting. Pity Borland doesn't release free trial versions<G>...

--
LuAnne: You know, at the beauty academy they teach us that people aren't
black or white or yellow or red, but their hair can be.

Post a reply to this message

"Alex Magidow" <axi### [at] mninternet> wrote in message
news:387B2C36.99E359D6@mninter.net...
> AFAIK, VB 5 and up do compile to native code...

Not the standard version. The pro might, I'm not sure, but I know the
enterprise does. However you still need to keep the runtime dll. I don't
think it's possible to make a program that is ONLY the exe like you can in
Delphi. Plus I haven't tried it but I've heard VB can't make all kinds of
COM objects as Delphi can. In fact the only thing that I know of that Delphi
can't make is a certain type of device driver and VB can't make that either.
It can only be made in C.

> I have to agree. You can learn it in a trimester at school(I know, I just
took a
> class in it), but its really a bad language to start learning. I prefer
the
> blood and guts approach of learning C/C++. They're much nicer language,
and
> after using them, and using VB, you'll desperately wish you had pointers
in VB.

I wouldn't go that far. C/C++ is an extremely difficult thing to learn for
someone with no programming experience. It has constructs that make no sense
at all and the only good explination is the programmers were just too lazy
to type a few extra characters. Also is uses archaic symbols heavily instead
of words that make sense and it's case sensitive which is just stupid. To a
non-programmer ORANGE means the exact same thing as orange but they are two
entirely different entities in C/C++.

I stand by Pascal/Delphi as the beginners language and C/C++ as the expert
one. In fact as I said if you only program C++ using MFC then Delphi is
probably still a better choice.

> Its nice in that it takes six seconds to get something done that takes 100
lines
> of code in C(ya, the code is cut and paste, but you know what I mean)

I agree but this is also a feature of Delphi and it doesn't teach you the
nasty habits. VB really has no strenghts at all that I can think of over
Delphi. Everything that VB can do Delphi can do also and the inverse is not
true.

> Pascal? Delphi? I've only vaugly heard of these. Anywhere with some good
infor
> on Delphi?

Well I think PASCAL is pretty much a dead language now. It used to be the
language you were taught on in before you moved up to C/C++. For example I
took AP Computer Science in high school and the AP test was in Pascal as
well as the first year of college at most major universities. I think they
switched the test to C in '94 so that pretty much meant the end of Pascal.
Delphi is based very loosly on it and calls it's underlying language Object
Pascal. You can find info on Delphi at http://www.borland.com/delphi


> Ouch, sounds expensive...sounds REALLY expensive.

Well you aren't supposed to buy them all at once. When I say move from one
to the other I kind of meant over years after you've MASTERED each not just
got the hang of them. For the record though Delphi 5 Pro comes with C++
Builder Standard and Delphi 5 Enterprise comes with C++ Builder Pro so you
only have to buy one.

> Interesting. Pity Borland doesn't release free trial versions<G>...

Then they'd have no income. Unlike MS they don't have Office or Windows to
fall back on for profits. You might be able to get some stripped down
version or something in one of the books for it, I'm not sure.

Post a reply to this message