Hello,

I started developing a simple real-time game with POV yesterday. I wrote 
a program in C++ to pass arrow key presses to an .inc file, in the form 
of a #declared vector. Everything was going great, I almost finished up 
the maze game I was working on. No errors at at all. But today I started 
receiving errors possibly related to my text file not being fully 
written before POV can read the vector :(

I don't know why errors would suddenly start cropping up today. Maybe I 
just got lucky yesterday...

Is there another way to pass custom key presses to a POV scene 
on-the-fly? Possibly as a .dll GUI extension? Or maybe a way to ensure 
that POV doesn't read the #include before it's finished being written? 
I'm not even sure if that's the problem :/

Sam

Post a reply to this message

Hi Sam,
A very cool idea!

I know of no way aside from hacking the POVRay source to support something like
this directly. But, for what you are trying to do, perhaps the quick thing would
be writing to another file and then replace the one being read with a system
'mv' command or similar. It should be the case that only complete files would be
available to POVRay for read that way.
Regards, Bill

stbenge <not### [at] hotmailcom> wrote:
> Hello,
>
> I started developing a simple real-time game with POV yesterday. I wrote
> a program in C++ to pass arrow key presses to an .inc file, in the form
> of a #declared vector. Everything was going great, I almost finished up
> the maze game I was working on. No errors at at all. But today I started
> receiving errors possibly related to my text file not being fully
> written before POV can read the vector :(
>
> I don't know why errors would suddenly start cropping up today. Maybe I
> just got lucky yesterday...
>
> Is there another way to pass custom key presses to a POV scene
> on-the-fly? Possibly as a .dll GUI extension? Or maybe a way to ensure
> that POV doesn't read the #include before it's finished being written?
> I'm not even sure if that's the problem :/
>
> Sam

Post a reply to this message

William Pokorny wrote:
> Hi Sam,
> A very cool idea!

Yeah, I hope it works out! As processors become faster, more complex 
raytraced games could be made, maybe with a patched Version of POV...

> I know of no way aside from hacking the POVRay source to support something like
> this directly. But, for what you are trying to do, perhaps the quick thing would
> be writing to another file and then replace the one being read with a system
> 'mv' command or similar. It should be the case that only complete files would be
> available to POVRay for read that way.
> Regards, Bill

I will investigate this. Not sure how to go about it, since my 
programming skills are few. But I'll google "'mv' 'system command' 
windows" or some such.

Thanks for answering!

Sam

Post a reply to this message

stbenge wrote:
> I will investigate this. Not sure how to go about it, since my 
> programming skills are few. But I'll google "'mv' 'system command' 
> windows" or some such.

Gah, I'm getting nowhere! I just found out that I hate daniweb. I 
thought the stdio function "rename()" was going to work, but it won't 
save over a file if it already exists. remove()ing the old one and 
rename()ing the next one won't work, of course.

I wish there was a replace() command for copying over a file. I couldn't 
make heads or tails of this "mv" system command.... that is, I can't 
seem to find anything useful by googling. Not yet, anyway.

There's always a tomorrow. Well, until the sun goes supernova :P

Post a reply to this message

Can't you decide inside your programm to only launch POV-Ray when the writing is
over ?...
Or are you using a separate daemon to continously render images ?...

Post a reply to this message

Gyscos wrote:
> Can't you decide inside your programm to only launch POV-Ray when the writing is
> over ?...

I would like to do this, keeping the same instance of POV open while I 
render on-demand from an external program, but have no idea how to do it.

Post a reply to this message

stbenge wrote:

> I started developing a simple real-time game with POV yesterday. 

Umm ... what's your definition of real-time here? ;)

> receiving errors possibly related to my text file not being fully 
> written before POV can read the vector :(

How do you start the render and wait for it to finish?

Maybe you could try calling fflush() after writing the data.

> Is there another way to pass custom key presses to a POV scene 

Sure, you can pass a define via command line:

   pvengine +whatever ... maze.pov Declare=Arrow=2

Then the scene would have a variable "Arrow" defined with value 2.

Post a reply to this message

Christian Froeschlin wrote:
> stbenge wrote:
> 
>> I started developing a simple real-time game with POV yesterday. 
> 
> Umm ... what's your definition of real-time here? ;)

Anywhere between 70-12 FPS for a 100x100 to 200x200 render on a quad 
core. This doesn't involve using the +rtr command line option. Instead, 
I'm having to use +kff1215752192, which should be enough time for 
solving the maze.

>> receiving errors possibly related to my text file not being fully 
>> written before POV can read the vector :(
> 
> How do you start the render and wait for it to finish?

I don't :/ My program simply writes to an .inc file every time an arrow 
key is pressed. I might be able to optimize this by writing only once if 
a key is still being pressed.

> Maybe you could try calling fflush() after writing the data.

I will look into that. Currently, I do this:

myfile.open(file_temp);
myfile << "#declare dir=";
myfile << vEcToR << ";\n";
myfile.close();

ifstream ifs(file_temp,ios::in|ios::binary);
ofstream ofs(file,ios::out | ios::binary);
ofs << ifs.rdbuf();

I haven't had a problem with this new setup yet, but I feel like I'm 
just getting lucky again.

>> Is there another way to pass custom key presses to a POV scene 
> 
> Sure, you can pass a define via command line:
> 
>   pvengine +whatever ... maze.pov Declare=Arrow=2
> 
> Then the scene would have a variable "Arrow" defined with value 2.

How do I do this? With a system() command? If so, how do I find out 
where 'pvengine' is?

Sam

Post a reply to this message

stbenge schrieb:
> 
> I don't :/ My program simply writes to an .inc file every time an arrow 
> key is pressed. I might be able to optimize this by writing only once if 
> a key is still being pressed.

You might do it as follows:

- In your program, update the .inc file only after verifying that a 
certain "acknowledge marker" ("ACK") file does exist; after having 
written the .inc file, have the program delete the ACK file.

- In your scene file, use the file_exists() function to check whether 
the ACK file does exist; if not, include the .inc file, then use 
#fopen/#write to generate/overwrite a temporary .inc file to contain the 
very same data, and after that use the same mechanism to create the ACK 
file. If however the ACK file does exist already, simply include the 
temporary .inc file instead.

I think that should do the trick without conflicts.

Make sure to init the system properly (e.g. by making sure the ACK file 
is not present, and the main .inc file exists and has some content that 
makes sense), and to provide for a way to recover in case the system 
should become "stuck" for some unexpected reason (e.g. time out if the 
POV-Ray script fails to create the ACK file in due time; you can also 
put the current frame number into the temporary .inc file and cross 
check, to create a timeout mechanism on the POV-Ray side in case the 
program fails to clear the ACK file at regular intervals)

Post a reply to this message

stbenge wrote:
> Gah, I'm getting nowhere! I just found out that I hate daniweb. I
> thought the stdio function "rename()" was going to work, but it won't
> save over a file if it already exists.

The documentation I have says:

"If newpath already exists it will be atomically replaced (subject to a few
conditions; see ERRORS below), so that there is no point at which another
process attempting to access newpath will find it missing."

Those "few conditions" were all about moving directories, thus irrelevant in
this case.

Post a reply to this message