This question may be ignorant or off-topic but: How does Pov-Ray
  "plot" images in Windows. I'm looking for the basic code which sends
a pixel to the screen. I've found several C++ programs that seem as if
they would do this but I can't get them to compile with Borland C++.
Pov-Ray seems to use a stable code that works well. It may be that I
don't really need this and that Pov-Ray as it exists will allow me to make
a mirror with a complex surface - but I guess that is a question for 
another group.
Even so, I would like to know how Pov-Ray works.

Thanks for any help.

David

Post a reply to this message

It's true I don't a bumps finish seems to work
David

David H. Burns wrote:
> It may be that I
> don't really need this and that Pov-Ray as it exists will allow me to make
> a mirror with a complex surface - but I guess that is a question for 
> another group.

Post a reply to this message

David H. Burns <dhb### [at] cherokeetelnet> wrote:
> This question may be ignorant or off-topic but: How does Pov-Ray
>   "plot" images in Windows.

  You should read the Windows API documentation. There are also tons of
wrappers around that API which make it easier.

-- 
                                                          - Warp

Post a reply to this message

Thanks. Do you mean Microsoft's Windows API documentation? I find that my
comprehension level for any Microsoft documentation is very low.  I 
suppose that
some of the programs I tried were "wrappers" around Windows. But I haven't
had any luck compiling them with Borland C++ on Windows XP. I suppose the
only solutions may be either to give in to the Microsoft monster and go to
Visual something .net or switch to a Linux. But I would still to know what
module in the Pov-Ray uses to send images to the screen. Or am I being to
simplistic and such a question has no meaning.



Warp wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
>> This question may be ignorant or off-topic but: How does Pov-Ray
>>   "plot" images in Windows.
> 
>   You should read the Windows API documentation. There are also tons of
> wrappers around that API which make it easier.
>

Post a reply to this message

> Visual something .net or switch to a Linux. But I would still to know what
> module in the Pov-Ray uses to send images to the screen. 

You can look at the povray sources for that, but I think you
should rather look at the GDI tutorials listed on

   http://www.functionx.com/bcb/

and then especially

   http://www.functionx.com/bcb/gdi/bitmaps.htm

Post a reply to this message

Thanks. I have looked in the Pov-Ray sources but was
unable to determine the relevant modules. That's what I was asking. Thanks
for the sites. I will take a look at them. Such sites that I have looked 
at seem
to be intended for VC++. I suppose that's OK, PovRay is written in VC++.
Since Microsoft controls virtually all of the computer industry and most
computer hardware is built for Microsoft software, there seems little point
  in going to a lot of trouble trying to learn something else or to 
adapt code
written in any but Microsoft languages to work on computers using
Windows.

Thanks for the help,

David



Christian Froeschlin wrote:
>> Visual something .net or switch to a Linux. But I would still to know 
>> what
>> module in the Pov-Ray uses to send images to the screen. 
> 
> You can look at the povray sources for that, but I think you
> should rather look at the GDI tutorials listed on
> 
>   http://www.functionx.com/bcb/
> 
> and then especially
> 
>   http://www.functionx.com/bcb/gdi/bitmaps.htm

Post a reply to this message

David H. Burns wrote:
>  in going to a lot of trouble trying to learn something else or to adapt 
> code
> written in any but Microsoft languages to work on computers using
> Windows.

I wouldn't go that far. There are a number of nice windowing systems that 
run on multiple platforms (including Windows) and some that also interface 
to multiple languages (including C++).  If you're going to learn a graphics 
system for general use, it's good to learn one whose lessons you can use for 
a long time on many tasks.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

David H. Burns wrote:

> Since Microsoft controls virtually all of the computer industry and most
> computer hardware is built for Microsoft software, 

   FUD !

Post a reply to this message

I assume you mean "F*** you David".Don't be afraid to say what you mean.
Or better still if you can't make a rational reply, don't say anything.

It looks like this thread is dead, probably I never should have started it.
Thanks to all who tried to help.

David


It doesn't look like I'm

tcgetattr wrote:
> David H. Burns wrote:
> 
>> Since Microsoft controls virtually all of the computer industry and most
>> computer hardware is built for Microsoft software, 
> 
>   FUD !

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I assume you mean "F*** you David".Don't be afraid to say what you mean.
> Or better still if you can't make a rational reply, don't say anything.
>
> It looks like this thread is dead, probably I never should have started it.
> Thanks to all who tried to help.
>
> David
>
>
> It doesn't look like I'm
>
>
Not really I’ve never seen tcgetattr post before so just ignore him. Even when
we are P*ss*d off with someone we don’t use that sort of language, here.

Stephen

Post a reply to this message

David H. Burns wrote:
> I assume you mean "F*** you David".

In the context quoted I think FUD is supposed to be the more common acronym 
"Fear Uncertainty Doubt" and not related to your name.

	Thorsten, POV-Team

PS: Note that your post was off-topic to this group.

Post a reply to this message

Thanks, I'd like to think so but I'd never seen the acronym and have no idea
what "Fear Uncertainty Doubt" might mean.
> In the context quoted I think FUD is supposed to be the more common 
> acronym "Fear Uncertainty Doubt" and not related to your name.
> 
>     Thorsten, POV-Team
> 
Yes, and I apologize. I was expressing my frustration and not saying 
anything
useful.
> PS: Note that your post was off-topic to this group.

Post a reply to this message

David H. Burns wrote:
> Thanks, I'd like to think so but I'd never seen the acronym and have no 
> idea what "Fear Uncertainty Doubt" might mean.

Google ;-)

	Thorsten

Post a reply to this message

Thanks, Thorsten. So tcgetattr's comment, when understood, was more or
less appropriate. I remember an old BC cartoon which pictured the dinosaurs
speaking in acronyms before their extinction.

David

Thorsten Froehlich wrote:
> David H. Burns wrote:
>> Thanks, I'd like to think so but I'd never seen the acronym and have 
>> no idea what "Fear Uncertainty Doubt" might mean.
> 
> Google ;-)
> 
>     Thorsten

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
> > This question may be ignorant or off-topic but: How does Pov-Ray
> >   "plot" images in Windows.
>
>   You should read the Windows API documentation. There are also tons of
> wrappers around that API which make it easier.

I recall that when I first tried to do pixel graphics output on a Windows
machine and tried to make any sense of the API, I thought something like "WTF -
I can't possibly need *all* this crap just to paint a single pixel?!"

I mean, come on - the underlying concept has some brain-dead aspect to it for a
multitasking windowing GUI OS: An app needs to re-draw its contents whenever
some other window has been drawn atop and is now moved away again? Can't some
abstraction layer just buffer the whole smash and blit it all over again when
the other window has been moved aside again?

Granted, at the time the API was designed, any other mode of operation would
have appeared to be a waste of memory: Even 2D accelerator cards were still
cutting-edge technology, found only in professional workstations, and it's easy
to criticize with 20/20 hindsight. But anyway: I can perfectly understand why
someone would rather have some sample code to try to adapt, than try to dig
through the API docs themselves. After all, they do *not* make very good
tutorials.

Post a reply to this message

David H. Burns wrote:

> to be intended for VC++. I suppose that's OK, PovRay is written in VC++.
> Since Microsoft controls virtually all of the computer industry and most
> computer hardware is built for Microsoft software

I think your confusing matters a bit. PovRay is available
for multiple platforms including Linux, so the code certainly
is not Microsoft-centric. The Windows version does require
to use the Windows API for platform specific functionality
though. This is not very surprising and not specific to the
compiler used. At the very bottom of it, it's the operating
system which will paint a bitmap on the screen. The graphics
classes of C++ Builder internally use that API as well.

Noone forces you to love Microsoft but I can't help wonder
why you're using Windows in the first place ;)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I suppose that's OK, PovRay is written in VC++.

Actually it isn't. It nowadays does come with project files to conveniently
compile with MS Visual Studio, but it doesn't use the MFC framework, nor any
other framework provided by Microsoft, and may compile just as well with any
other C++ compiler suite. POV-Ray 3.6 official releases were actually built
using the Intel compiler suite; the source code releases didn't even provide
any particular support for Visual Studio back then, so any VS user had to set
up their own project files to compile POV-Ray.

> Since Microsoft controls virtually all of the computer industry and most
> computer hardware is built for Microsoft software, there seems little point
>   in going to a lot of trouble trying to learn something else or to
> adapt code
> written in any but Microsoft languages to work on computers using
> Windows.

That, too, is a common misconception - though not surprisingly. Yes, most
*desktop computer* hardware is designed to run Windows. They *dominate* the
market to a good degree, but to say that they *control* it would be
exaggerated. Mac is too strong in the desktop segment, and Unix derivatives are
too strong in both the desktop and server segments, to let Microsoft just have
their will. Not to mention all those mobile phones, PDAs and embedded systems
which I'd consider part of the computer industry, too: Microsoft has achieved
and maintained a foothold in that segment with Windows CE and especially .NET,
most particularly with smartphones, but I guess in the mobile phone segment
Symbian OS is still strongest, with new competitors gaining ground, and
embedded systems tend to run the wildest operating systems you can possibly
imagine.

And then there's customer power that don't let MS just have their will. Yeah,
sure, the private end users seem to swallow all MS has OEMs cram down their
throat bundled with new PCs. But for instance Vista was an absolute no-go in
most professional environments, which was a serious blow to MS. Serious enough
to release the first Service Pack for Vista under an all-new name... no, not a
name - a good old version number. Imagine that. How come? End user pressure?
Bloody likely not. But companies don't go for those fancy names, and it seems
like Microsoft needed to make a statement that they're heading back for more
serious business.

If Microsoft lost their commercial desktop market share to, say, Mac OS or
Linux, I guess they'd lose their private user market share very soon thereafter.
It's quite convenient to use the same OS at home that you need to familiarize
yourself with at work anyway.

So no, they're not controlling the market. I'd rather say it's the market that
controls them.

Post a reply to this message

My point exactly. Playing with working code is often the best tutorial. 
But, alas,
much available code was written before XP and apparently the API functions
have changed. But then I read that Microsoft Visual Whatever version 8.0 is
incompatible with Version 7.0 .... One seems trapped.

David


clipka wrote:

 > But anyway: I can perfectly understand why
> someone would rather have some sample code to try to adapt, than try to dig
> through the API docs themselves. After all, they do *not* make very good
> tutorials.
> 
> 
>

Post a reply to this message

> Noone forces you to love Microsoft but I can't help wonder
> why you're using Windows in the first place ;)

Stupidity, sheer stupidity! Though economics and the reluctance to abandon
what I'm used to enters into it. I almost bought a Mac instead of the PC I
bought recently. I've kicked myself ever since.

But many are forced to use Windows. At work, one has to use what
one's employer will provide.

But I have learned some things lately. If one wants to do any 
programming for
Windows, one must learn the Windows API. To many things, such as
memory management, are involved. I had a vastly overly simplistic view
  of the situation. I wonder how Linux does things, but I'm afraid 
learning it
at this point is not a live option.

David

Post a reply to this message

clipka wrote:

> That, too, is a common misconception - though not surprisingly. Yes, most
> *desktop computer* hardware is designed to run Windows. They *dominate* the
> market to a good degree, but to say that they *control* it would be
> exaggerated. 

Yes, "dominate" is definitely the word I should have used. And I 
probably should
have said "PC computer market".

David

Post a reply to this message

David H. Burns wrote:
> If one wants to do any programming for Windows, one must learn the Windows API.

This is untrue. There are many portable systems layered on top of Windows 
that keep you from having to learn anything about the Windows API as such. 
Heck, even .NET insulates you 99% from having to know anything about Windows 
as such.

Use a programming language that isn't a thin layer painted over the hardware 
and you're good.  Pick up Tcl, Python, Java or anything else like that, and 
you'll have a portable powerful language that'll do almost anything C++ can, 
yet will run with minor modifications on most OSes.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

Darren New wrote:
> David H. Burns wrote:
>> If one wants to do any programming for Windows, one must learn the 
>> Windows API.
> 
> This is untrue. There are many portable systems layered on top of 
> Windows that keep you from having to learn anything about the Windows 
> API as such. Heck, even .NET insulates you 99% from having to know 
> anything about Windows as such.


Yes, I'm using far too many generalities. Certainly Microsoft products keep
one from having to deal directly with "Windows as such" and I have seen
pretty slick plots done using Python and the appropriate tools. What does
  the Pov-Ray code do in this regard and in what sections of code was
kind of my original question which no one seems to have addressed. But,
  at this point, I don't think it would help me much to know.

David

Post a reply to this message

"Stephen" <mcavoys_AT_aolDOT.com> wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > I assume you mean "F*** you David".Don't be afraid to say what you mean.
> > Or better still if you can't make a rational reply, don't say anything.
> >
> > It looks like this thread is dead, probably I never should have started it.
> > Thanks to all who tried to help.
> >
> > David
> >
> >
> > It doesn't look like I'm
> >
> >
> Not really I’ve never seen tcgetattr post before so just ignore him. Even when
> we are P*ss*d off with someone we don’t use that sort of language, here.

BTW, "FUD" - at least in this context - has most likely nothing to do with The
F-Word, and I'd instead take it as the acronym for "Fear, Uncertainty & Doubt"
- a buzzword for an alleged(*) systematic Microsoft stategy to try keep
customers away from competitors' products by invoking a sufficient deal of
"FUD" about them, to make them think they're on the safer side with MS
products. In this context "Microsoft rules them all, so I'd better stick with
Microsoft myself" would be just about the self-fulfilling prophecy Microsoft
would want their customers to believe.

(* I refuse to make a statement here whether that allegation is true or false. I
personally believe it is true, but have no intention of convincing others to
agree.)

Post a reply to this message

clipka wrote:
> - a buzzword for an alleged(*) systematic Microsoft stategy 

Well, an anyone strategy, really. IBM mastered it long before Microsoft was 
founded. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> But, alas,
> much available code was written before XP and apparently the API functions
> have changed. But then I read that Microsoft Visual Whatever version 8.0 is
> incompatible with Version 7.0 .... One seems trapped.

What's the problem there?

(1) The API functions haven't changed. Some may have been added, that's all.
Otherwise we'd see tons of Windows 95 software not working anymore.

(2) Both Visual Whatever 7.0 and 8.0 are XP-era products.

(3) Visual Whatever 8.0 does load (and convert) old 7.0 projects.

(4) As far as POV-Ray is concerned, it comes with both Visual Studio 7.0 and 8.0
project files :)

There is some truth to it insofar as Microsoft seems to be shifting away from
MFC and even the newer ATL towards the .NET framework. But MS Visual Studio
..NET 2005 (aka VS 8.0) will happily not only compile old VC++ 6.0 MFC code, but
also let you set up new MFC-based projects.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> But I have learned some things lately. If one wants to do any
> programming for
> Windows, one must learn the Windows API. To many things, such as
> memory management, are involved.

That's not true. Maybe you need a basic understanding about how things work in
the Windows API, but most C++ frameworks will happily prevent you from ever
having to get into details, unless you really want to.

If you want to do *without* a framework, then yes, you'll have a steep learning
curve ahead of you.


> I had a vastly overly simplistic view
>   of the situation. I wonder how Linux does things, but I'm afraid
> learning it
> at this point is not a live option.

With Linux the thing gets even more troublesome: There's no such thing as "the"
Linux GUI API. It depends on the desktop environment you're using, e.g. KDE,
Gnome, or what-have-you. The good news is that they all share a common
denominator, the X Windowing System; the bad news is that I heard tell that
it's a monster, too. (But I may be utterly wrong about this; the only time I
ever had to do graphical output on Unix from C/C++ code, I resorted to sending
PostScript output to the screen via GhostScript - But back then I had just
begun to learn C/C++, the Intarwebs was still a toddler, and I didn't have the
slightest clue how to google it all up... or rather, altavista it up :P)

However, I bet that just like with Windows, there's a host of frameworks out
there to simplify your life in Linux as well. And maybe a few that even have an
implementation for both, so that you wouldn't have to change a single thing to
port your app to the other OS.

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> Darren New wrote:
> > David H. Burns wrote:
> >> If one wants to do any programming for Windows, one must learn the
> >> Windows API.
> >
> > This is untrue. There are many portable systems layered on top of
> > Windows that keep you from having to learn anything about the Windows
> > API as such. Heck, even .NET insulates you 99% from having to know
> > anything about Windows as such.
>
>
> Yes, I'm using far too many generalities. Certainly Microsoft products keep
> one from having to deal directly with "Windows as such" and I have seen
> pretty slick plots done using Python and the appropriate tools. What does
>   the Pov-Ray code do in this regard and in what sections of code was
> kind of my original question which no one seems to have addressed. But,
>   at this point, I don't think it would help me much to know.
>
> David

If you want to find out how POV-Ray for Windows does the thing, the point to
start your excursion is probably the .../windows/pvdisplay.cpp file. I never
bothered to dive into the code for POV-Ray's Windows UI, but I just spotted
some Windows API calls there (CreateWindowEx() for instance).

It seems that POV-Ray does things the hard way, using the Windows API directly -
at least as far as the render window is concerned.

Post a reply to this message

clipka wrote:
> towards the .NET framework.

We have three! And every one is a pretty completely different conceptual 
framework from the one before!  Isn't progress wonderful? :-)  I wouldn't 
count learning .NET graphics as a long term investment, altho the general 
concepts (nested widgets, layouts, event dispatch, etc) are similar amongst 
many graphical toolkits.

-- 
   Darren New, San Diego CA, USA (PST)
   Insanity is a small city on the western
   border of the State of Mind.

Post a reply to this message

And it almost killed them. Microsoft didn't appear to have that strategy
before. I'm understand that that change coincides with some changes in
Microsoft management. I didn't understand the buzzword -- a danger
with the use of all buzzwords. Also "FUD" resembles an obscenity.

Darren New wrote:
> clipka wrote:
>> - a buzzword for an alleged(*) systematic Microsoft stategy 
> 
> Well, an anyone strategy, really. IBM mastered it long before Microsoft 
> was founded. :-)
>

Post a reply to this message

Thanks.

clipka wrote:

> If you want to find out how POV-Ray for Windows does the thing, the point to
> start your excursion is probably the .../windows/pvdisplay.cpp file.

Post a reply to this message

Darren New wrote:
> clipka wrote:
>> towards the .NET framework.
> 
> We have three! And every one is a pretty completely different conceptual 
> framework from the one before!  Isn't progress wonderful? :-) 

C. S. Lewis has compared "progress" to a good egg becoming rotten.
Not all change and increase in complexity are good.

  I wouldn't count learning .NET graphics as a long term investment, altho
> the general concepts (nested widgets, layouts, event dispatch, etc) are 
> similar amongst many graphical toolkits.
> 
I bought VB.Net and how to books(the first edition ?). I did figure out how
  to display an image and maybe how to print "Hi there", but didn't really
have the time and interest to learn its peculiarities.

I don't understand current programming strategies -- I may have never
understood programming strategies. In the long run, it's probably better to
  understand the programming, but there are many short terms goals that
don't require that.

Post a reply to this message

David H. Burns wrote:

> much available code was written before XP and apparently the API functions
> have changed. But then I read that Microsoft Visual Whatever version 8.0 is
> incompatible with Version 7.0 .... One seems trapped.

No need to feel trapped. Its fully backward compatible. And
available for free, too. And if you don't like it you can use
C++ Builder. Or MinGW. Or Linux. But you won't get around
learning how to program with whatever you choose ;)

Post a reply to this message

Christian Froeschlin wrote:

> But you won't get around
> learning how to program with whatever you choose ;)

I can program--or at least once I could: in Basic, (and VB not "net"),
Z-80 assembly, and C --oh yes, I fulfilled the language requirement for 
my MS
by writing a "substantial program" in Turbo Pascal (they shouldn't have 
let me
get away with it, they should made me pass a reading test in a "foreign"
human language!) Programming itself is not difficult! But ....well 
anything else
I might say along this line would most certainly be off topic.

The question is not whether to learn to programming, but whether to spend
  a long time learning to use tools which are now available. I might better
spend that time using Pov-Ray itself (in which many beautiful things can be
done)and also with Visual Basic 4.0 (which has only the bare trappings of
OOP).

I need to learn to do a smiley face.

David

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> The question is not whether to learn to programming, but whether to spend
>   a long time learning to use tools which are now available. I might better
> spend that time using Pov-Ray itself (in which many beautiful things can be
> done)and also with Visual Basic 4.0 (which has only the bare trappings of
> OOP).

Unless you intend to completely give up programming, try to dig the OOP concepts
- there's virtually no way around them these days. I guess even POV-Ray's SDL
will move towards OOP in the future.

And I'm perfectly sure it's for the better. I know of no better tool yet to
manage software complexity.

Post a reply to this message

clipka wrote:
> And I'm perfectly sure it's for the better. I know of no better tool yet to
> manage software complexity.

Metaprogramming trumps OO hands down. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> > And I'm perfectly sure it's for the better. I know of no better tool yet to
> > manage software complexity.
>
> Metaprogramming trumps OO hands down. :-)

I'd consider that a quite orthogonal programming techniqe: The output can be
smalltalk just as well as it can be assembler code. (Strictly speaking, *all*
programming these days constitutes metaprogramming: Only very few modern
computers provide interfaces to enter machine programs manually ;))

Likewise, metaprogramming can be used to implement OOP paradigms in a language
that does not support them natively. Actually, that's how C++ started: The first
C++ compilers generated C code.

But yes, metaprogramming does raise OO to the best of its potential: Reflection
rules! :)

Post a reply to this message

You guys have lost me. I'm just one of the laity and haven't been initiated
into the priesthood of programmers and it's mysteries.
(Smile)

David

clipka wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>> And I'm perfectly sure it's for the better. I know of no better tool yet to
>>> manage software complexity.
>> Metaprogramming trumps OO hands down. :-)
> 
> I'd consider that a quite orthogonal programming techniqe: The output can be
> smalltalk just as well as it can be assembler code. (Strictly speaking, *all*
> programming these days constitutes metaprogramming: Only very few modern
> computers provide interfaces to enter machine programs manually ;))
> 
> Likewise, metaprogramming can be used to implement OOP paradigms in a language
> that does not support them natively. Actually, that's how C++ started: The first
> C++ compilers generated C code.
> 
> But yes, metaprogramming does raise OO to the best of its potential: Reflection
> rules! :)
> 
> 
>

Post a reply to this message

clipka wrote:
> Likewise, metaprogramming can be used to implement OOP paradigms in a language
> that does not support them natively. Actually, that's how C++ started: The first
> C++ compilers generated C code.

I don't think my use of the term metaprogramming matches your use of the 
term metaprogramming. Simply writing in a language the computer doesn't 
natively understand isn't metaprogramming in the sense I meant it.

> But yes, metaprogramming does raise OO to the best of its potential: Reflection
> rules! :)

That's closer. When the structures of the program code itself are 
manipulable from inside the program, that's metaprogramming. When a language 
(like C) makes it harder to metaprogram than to just brute-force the code 
you want to implement, you're lacking something.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> That's closer. When the structures of the program code itself are
> manipulable from inside the program, that's metaprogramming. When a language
> (like C) makes it harder to metaprogram than to just brute-force the code
> you want to implement, you're lacking something.

Sure. But without OO concepts embedded in the "metaprogrammed" language, your
choice of metaprogramming patterns is probably limited to code generation. For
more generic manipulation you need a generic manipulation interface - which is
an example of polymorphism, one of the key paradigms of OOP.

So what you consider metaprogramming, I'd consider "OOP deluxe" :)


(Um... sorry for hijacking this topic :})

Post a reply to this message

clipka wrote:
> Sure. But without OO concepts embedded in the "metaprogrammed" language, your
> choice of metaprogramming patterns is probably limited to code generation.

Rerouted to off-topic.

Generally, you meta-program in OO as you need it. See Tcl, FORTH, Lisp, etc. 
  OO is really just a subset of closures, for that matter.

-- 
   Darren New, San Diego CA, USA (PST)
   "We'd like you to back-port all the changes in 2.0
    back to version 1.0."
   "We've done that already. We call it 2.0."

Post a reply to this message

For the record, I have not been able to find the 
.../windows/pvdisplay.cpp file
in the 3.6 source, but at this point, I doubt if it would be any help. I 
played
around with some of the files, but ran into Internet Explorer version error.
when I tried compiling them. Information on the internet from about 10 years
ago didn't help me to correct them. But I'm sure that individual code 
would not
compile anyway. I think I have exhausted that approach. I may later try to
describe the kind of feature I would like to see added to Pov-Ray and
submit it for consideration. But first I need to play around and see if 
Pov-Ray
already has what I want.

David

clipka wrote:

> If you want to find out how POV-Ray for Windows does the thing, the point to
> start your excursion is probably the .../windows/pvdisplay.cpp file.
> 
> 
>

Post a reply to this message