Sorry for such easy questions (I can predict Thorsten bashing me already ;)

ps. also sorry for bad english

1. do we have some tutorial for POV _programmers_?

2. how to allocate memory, like if I need an array of N int; what if I need
N floats? Should I just use "float" or something like "tPovColorElement" to
store R, G or B value of a pixel while tracing a pixel
How to deallocate it afterwards, and how to access it (what is the best
practise)

3. how to print debugging informations, best - printf style

4. any must-known tips&tricks?


-- 

Post a reply to this message

Raf256 wrote:
> Sorry for such easy questions (I can predict Thorsten bashing me already ;)

It is not bashing, it is about not spoon-feeding you obvious details you can 
more quickly find yourself if you would just *look* rather than taking the 
longer time to write down the questions here.  It relates to the most basic 
talent any programmer should have picked up by the time he/she gets into the 
POV-Ray source code: The ability to get around in foreign code.  It is the 
same for any foreign code.

> 1. do we have some tutorial for POV _programmers_?

IIRC there is some information somewhere on the MegaPOV website.

> 2. how to allocate memory, like if I need an array of N int; what if I need
> N floats? Should I just use "float" or something like "tPovColorElement" to
> store R, G or B value of a pixel while tracing a pixel
> How to deallocate it afterwards, and how to access it (what is the best
> practise)

You really just need to look in the source code.  As you already looked in 
render.cpp, you should have found plenty of examples how to do exactly this. 
  For example in Initialize_Renderer.  However, if you don't see it there 
instantly, I would strongly recommend to not dare making changes to POV-Ray 
and start with simpler programs you write yourself first.

> 3. how to print debugging informations, best - printf style

Again, this is really easy to find. Certainly you remember some messages 
POV-Ray outputs, as warnings, errors, etc.  So the logical way to find 
something like this is to follow that trail.  Take the message string, 
search teh source code, follow functions from there.  It is the *only* way 
you will ever manage to get around source code you don't know.

> 4. any must-known tips&tricks?

In pre-3.7 source code, yes: Be aware of the globals, and try to stay out of 
their way. They not only bite, they kill unsuspecting programmers and their 
code! ;-)

	Thorsten

Post a reply to this message