Greetings,

I think there might be some kind of problem ... here's my observations:

I'm rendering a scene (no radiosity) using these command line options:
+sp64 +ep16 +bs16

I'd expect to get several course looking passes before the final render,
instead I get a solid colored display that blinks several times (the
number of times I'd expect with the sp/ep settings I'm using) then a
final pass with the expected behavior (smaller blocks being rendered
because I'm using +bs16 rather than the default of +bs32)

While I'm on the subject ... radiosity pretrace uses mosaic preview to
display the results of the pretrace steps right? I see this same
behavior (the solid colored display blinking, but it changes color with
each pass) before the final pass is rendered.

I WAS running a customized beta37a compiled on openSUSE 11.2 and decided
to give the last officially released linux  (beta 35a) a try to see if
it was something I did, so I uninstalled my beta37a and built 35a (after
extending the expire) and still see the same behavior.

Can anyone else confirm this?

Cheers Jim

Post a reply to this message

Am 21.05.2010 15:28, schrieb Jim Holsenback:

> I'm rendering a scene (no radiosity) using these command line options:
> +sp64 +ep16 +bs16
>
> I'd expect to get several course looking passes before the final render,
> instead I get a solid colored display that blinks several times (the
> number of times I'd expect with the sp/ep settings I'm using) then a
> final pass with the expected behavior (smaller blocks being rendered
> because I'm using +bs16 rather than the default of +bs32)
...
> Can anyone else confirm this?

I think I can confirm from the Unix source code, which looks somewhat 
fishy and would indeed fit that bill if I understand it right.

The implementation of UnixSDLDisplay::DrawFilledRectangle() in 
disp_sdl.cpp, which should draw a single-colored rectangle in the 
preview window, looks corrupted to me:

- It trims the coordinates to fit inside the image rectangle, which is ok.

- It scales the coordinates to screen coordinates if necessary, which 
looks ok as well.

- It calls the function UnixSDLDisplay::UpdateCoord(), which seems to 
keep track of a (single) display region that needs to be re-painted. 
There seems to be nothing wrong here either.

- It apparently converts the pixel color to the format expected by Unix, 
which looks trivial.

- It fills the *entire* rectangle marked for update with the converted 
colour, which seems utterly wrong to me.

- It seems to restart a delay timer to prevent all-too-frequent 
re-painting of the display.


Can you please try changing the code as follows: Replace the line in 
unix/disp_sdl.cpp, function UnixSDLDisplay::DrawFilledRectangle() 
(somewhere around line 513) reading:

     SDL_FillRect(m_display, &m_update_rect, sdl_col);

with the following code:

     SDL_Rect tempRect;
     tempRect.x = ix1;
     tempRect.y = iy1;
     tempRect.w = ix2 - ix1; // might need an additional +1
     tempRect.h = iy2 - iy1; // might need an additional +1
     SDL_FillRect(m_display, &tempRect, sdl_col);

I /think/ that should fix it. Feedback would be very much appreciated 
(please also feel invited to file a bug report).

Post a reply to this message

Am 21.05.2010 16:26, schrieb clipka:

> - It seems to restart a delay timer to prevent all-too-frequent
> re-painting of the display.

(Hm, no - that's not what it does; the last step actually causes 
re-painting of the display to happen ASAP.)

Post a reply to this message

Am 21.05.2010 16:26, schrieb clipka:
>> Can anyone else confirm this?
>
> I think I can confirm from the Unix source code, which looks somewhat
> fishy and would indeed fit that bill if I understand it right.

Looks like the issue would typically only manifest with fast-rendering 
images...?

Post a reply to this message

On 05/21/2010 11:40 AM, clipka wrote:
> Looks like the issue would typically only manifest with fast-rendering
> images...?

don't think so (could be wrong) ... I recall an image (previous) that
had a rather lengthy pretrace phase and just shrugged it off until I
started playing with something I was trying to understand before adding
it to the docs.

Post a reply to this message

On 05/21/2010 11:26 AM, clipka wrote:
> I /think/ that should fix it. Feedback would be very much appreciated

nailed it :-) way to go!

> (please also feel invited to file a bug report).

yes .. i'll follow up

Post a reply to this message

Am 21.05.2010 20:46, schrieb Jim Holsenback:
> On 05/21/2010 11:26 AM, clipka wrote:
>> I /think/ that should fix it. Feedback would be very much appreciated
>
> nailed it :-) way to go!

Glad to hear that; was there any need to modify the code in any way, or 
did it compile exactly as posted? (Unfortunately I can't test the code 
myself; I haven't yet managed to get SDL support running for my Linux 
compiles.)

Post a reply to this message

On 05/21/2010 05:06 PM, clipka wrote:
> 
> Glad to hear that; was there any need to modify the code in any way, or
> did it compile exactly as posted? (Unfortunately I can't test the code
> myself; I haven't yet managed to get SDL support running for my Linux
> compiles.)

cut & paste ... no changes

Thanks!

Post a reply to this message