![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>Real Soon Now... and a couple
> small features I want to add.
famous last words of all programmers.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> and how to implement them myself if necessary. For example: a game
> project with extremely severe speed requirements, developing for
> platforms where the STL isn't useable,
read "Game Architecture and Design" by Rollings and Morris and you'll
realize these notions are very outdated. programs are getting too big,
and computers too fast for any one person or team to develop all the
code in-house or worry about speed optimization. libraries are the
future. just look at the quake engines. those are libraries. other
developers are starting to make other specific libraries, like physics,
installation, or interface libraries. the book i mentioned talks about
this and has application for all fields of software development; it just
goes in to games a little more.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39B9D82F.9D3E3C56@yahoo.com>, ryan constantine
<rco### [at] yahoo com> wrote:
> read "Game Architecture and Design" by Rollings and Morris and you'll
> realize these notions are very outdated. programs are getting too big,
> and computers too fast for any one person or team to develop all the
> code in-house or worry about speed optimization.
This is true for most applications, but only gets rid of one of my
arguments, and isn't applicable to all situations.
What about my other arguments? Platforms where the STL doesn't exist or
is too bulky, new languages, etc.
> libraries are the future. just look at the quake engines. those are
> libraries. other developers are starting to make other specific
> libraries, like physics, installation, or interface libraries.
This has very little to do with the reason I want to learn those
algorithms. Besides, I might end up programming one of those libraries!
They don't just come out of nowhere, they are written by programmers who
know how to do that stuff.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39B9D612.294DF35E@yahoo.com>, ryan constantine
<rco### [at] yahoo com> wrote:
> >Real Soon Now... and a couple
> > small features I want to add.
>
> famous last words of all programmers.
Specifically, there are two features I want to add:
A small optimization in case of "turbulence 0", maybe for all places
that can use turbulence.
Glow transformations.
I have added two new glow types, but they are unfinished(they don't work
right when the glow is covered by or partly embedded in an object). I
don't plan to finish them before releasing a new version, though.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
| I have added two new glow types, but they are unfinished(they don't work
| right when the glow is covered by or partly embedded in an object). I
| don't plan to finish them before releasing a new version, though.
What two new glow types? Enlighten me!
H.E. Day
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <01c01a81$c5b12c40$697889d0@daysix>, "H. E. Day"
<Pov### [at] aol com> wrote:
> What two new glow types? Enlighten me!
A sphere glow with constant density(sort of like a transparent sphere
with fade_color, but a bit faster and doesn't require intersection
calculations), and a glow using the exp() function.
I added a keyword to scale the size, and added another keyword to limit
the glow to a spherical area(this might speed some scenes up). The
keywords are "size" and "radius".
I added a falloff exponent feature, to adjust the rate at which the glow
dims with distance.
I have removed the turbulence feature, but you can now specify any
warps. It will be slightly slower with turbulence and the same speed
without it, but you will have more flexibility now, with black holes,
displace warps, etc.
I added the ability to transform the glow. Scaling only affects the
position, though, since there are currently only point sources.
And here are some features which won't be in the next version, but which
I am planning:
A pigment to control the color(definitely not realistic, but potentially
useful).
Different rendering modes: emission/additive, like it does now,
multiplicative, a mode which imitates scattering media, with constant
density(or some density functions which can be calculated directly), etc.
And I still haven't added that optimization for "turbulence 0", it isn't
a very high priority, since there is an obvious workaround.
I am also thinking of a similar lens flare feature. A separate patch,
not part of the glow feature, but based on the same rendering methods,
and with additional stuff to make it more flare-like.
--
Christopher James Huff
Personal: chr### [at] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
: If you get an error message you end up having to analyse error messages and
: try to figure out what is wrong.
This is a very common problem with templates (specially ones that have
many parameters).
I don't think there's any bullet-proof solution to the problem. When I really
want to analyze an error message which mentions some STL template, I filter
it (with sed or perl) to get rid of the template parameters. The error message
gets a lot clearer.
Usually I don't need to decipher the error message. I only look at the
line of code (ie. in my code) that caused the problem and usually see what
it was. Some times it's more difficult, however. Some error types you just have
to know to see them (eg. trying to use a class without copy constructor with
STL).
: Now, this isn't even an example with an STL problem and it can still be hard
: to understand the problem. Try making a simple mistake just like declaring
: a nested template with '>>' at the end. How useful is the error message you
: get from _your_ compiler?
Believe me, the error messages of gcc are MYSTICAL! :)
For example, can you say what causes this error message?
request for member `clear' in `x', which is of non-aggregate type `string ()()'
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff <chr### [at] mac com> wrote:
: If I use the STL, I don't know exactly what is happening in my program.
: If something goes wrong with a program using something I implemented, I
: know the code, and can figure out the problem quickly. If something goes
: wrong and I am using the STL, I end up trying to figure out why STL
: files are producing errors, whether or not the problem is actually *in*
: the STL.
Do you use the string class? Do you use streams? Do you use any standard
function?
Do you know exactly what does each one of them do?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
: Is this by any chance the only example you have? ;-)
Yes. And why not? I could write more similar examples, but what would
be the point? I think one is enough.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thorsten Froehlich <tho### [at] trf de> wrote:
: The return is missing...
The standard says that the return is optional (don't ask me why).
: Total: O(n * log(n) + n * log(n))
This is equal to O(n * log(n))
: I can get:
: Total: O(2 * n + n * log(n))
This is also equal to O(n * log(n))
So in terms of O both ways are equally fast.
: How? That is simple: I read in the words. Then sort them and then just
: count when retrieving.
But it uses more memory (specially if there are many repetitions).
: Of course I can do this using the STL (see below)! But your example shows
: something dangerous you forgot: the STL can trick you into thinking you
: have found a good algorithm, but in fact yours is nearly log(n) times slower
: than mine for most cases (for log(n) > 2)!
The O-notation doesn't know the term "log(n) times slower" if the speed
is already at least O(log(n)).
My version and your version have both the same O value and there's a good
reason for this in this case: Your version can be a lot slower when the
input is very big and there's a lot of repetition (imagine that the input
is "word1 word2 word1 word2..." millions of times). The speed is still
O(n*log(n)) in relation with the size of the input, but the speed factor can
vary a lot.
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |