 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The POV macro feature is very useful, for recursion and commonly used
shapes, and saves time and code. The POv language is becoming more like
a programming language than a scene-description language. However, there
are limits to this language, first of all it is interpreted, secondly it
does not have many features of a normal programming language. I'm not
saying the POV-team should make a C++ compiler out of POV. My suggestion
is simply this: I think theres should be an integer variable type in
POV, it would take less memory than floats for many macro operations.
Also there should be some bit-fiddling functions for these, they would
be very useful for many operations, avoiding the int(mod(byte/4,2)) kind
of things that are cumbersome in both coding and parsing. Of course I
realize that POV is totally free and all, so if it's too much to ask,
fine.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't think saving memory is an issue for that.
What I'd like to see is the ability to examine and/or change properties of
things after they're declared.
Larry Fontaine <lfo### [at] isd net> wrote in message
news:37E2E85B.1FB0AA21@isd.net...
> The POV macro feature is very useful, for recursion and commonly used
> shapes, and saves time and code. The POv language is becoming more like
> a programming language than a scene-description language. However, there
> are limits to this language, first of all it is interpreted, secondly it
> does not have many features of a normal programming language. I'm not
> saying the POV-team should make a C++ compiler out of POV. My suggestion
> is simply this: I think theres should be an integer variable type in
> POV, it would take less memory than floats for many macro operations.
> Also there should be some bit-fiddling functions for these, they would
> be very useful for many operations, avoiding the int(mod(byte/4,2)) kind
> of things that are cumbersome in both coding and parsing. Of course I
> realize that POV is totally free and all, so if it's too much to ask,
> fine.
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John M. Dlugosz wrote:
>
> I don't think saving memory is an issue for that.
>
> What I'd like to see is the ability to examine and/or change
> properties of things after they're declared.
To at least *see* what type a given object is, would be a boon.
To be able to explicitly declare integers should enable faster indexing
into arrays, a real bonus for some of the heavy macros; the float-to-
integer conversions would no longer be necessary.
Regards,
John
--
ICQ: 46085459
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <van### [at] erolscom> wrote in message
news:37EAEA25.50D1BD20@erols.com...
> John M. Dlugosz wrote:
> To be able to explicitly declare integers should enable faster indexing
> into arrays, a real bonus for some of the heavy macros; the float-to-
> integer conversions would no longer be necessary.
You're assuming that a float-to-int conversion is slow.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John M. Dlugosz <joh### [at] dlugoszcom> wrote:
: You're assuming that a float-to-int conversion is slow.
That depends on what you consider slow and how much can the compiler
optimize.
An optimal conversion would take less than 10 clock ticks which is very fast
(about as fast or even faster than a division).
However some compilers make quite poor code. They set the settings of the
FPU each time a conversion is performed and this takes lots of time.
The worst thing would be doing the conversion without the FPU.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
