Hi, just my small contribution (nothing official, I'm a poor lone some 
cowboy...)

So far here are the blocking bugs which should, IMHO, be solved before 
any official definitive release, at least for source on linux/unix:

(Smellenbergh, 16th August)
1. isosurface contained by a sphere, with bounding box activated

 - Looks like a coincidence surface when rendered (noisy filling, half-
transparent)
 - No Problem when bounding box (MB) are not used


(geep999, 24th August)
2. Segfault on scenes/portfolio/m_textures.ini

 - Was not buggy in beta-25b (for normal default Q rendering)
 - happen for Q0, Q1, Q6 to Q11 (but not Q2 to Q5)
 - For the arcanists, removing only changeset 4608 (trace.cpp & trace.h 
only, related to the caching of colours for lightsources, IIRC...) does 
restore a fine render for Q6 to Q11 (at a big price... back to more 
raycastings)

 - Q0 & Q1: duma report an issue in trace.cpp, at 

filCol[pRED]   *= min(1.0, 1.0 - listWNRX->back().reflec[pRED]);

around line 903, with Trace::ComputeLightedTexture starting at 676.
(your source might vary)

I guess there is no such reflec at Q0 & 1, right ?



Special bonus during investigation with duma (NEW! well, sort of):
3. There is something really fishy with the X display window
 (already purported by me (Le Forgeron) 5th March, well I hope that the 
one)

 - To be able to use duma with m_textures.ini, -D must be used or a crash 
is generated for disp_sdl.cpp:573 
( pov_frontend::UnixSDLDisplay::UpdateScreen ) everytime.
 - without duma, I guess that the random bug is triggered by some access 
to a random value/pointer... lucky time, all ends well/ bad time, you're 
stuck)




P.S.: geep999, you spoiled me with duma !-)

Post a reply to this message

>  - To be able to use duma with m_textures.ini, -D must be used or a crash 
> is generated for disp_sdl.cpp:573 

	As a quick test, could you try wrapping this line with a pair of
SDL_LockSurface(m_screen) / SDL_UnlockSurface(m_screen) commands?

	Thanks,
	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> >  - To be able to use duma with m_textures.ini, -D must be used or a crash
> > is generated for disp_sdl.cpp:573
>
>  As a quick test, could you try wrapping this line with a pair of
> SDL_LockSurface(m_screen) / SDL_UnlockSurface(m_screen) commands?
>
>  Thanks,
>  - NC

Would be an excellent knick-knack (?) (in italian: soprammobile).
Tasty.

Antialias?

Post a reply to this message

"Carlo C." <nomail@nomail> wrote:

> Would be an excellent knick-knack (?) (in italian: soprammobile).
> Tasty.
>
> Antialias?

I wrong. I do not know how I did. I wanted to respond to another message.

Excuse me.

Post a reply to this message

Le Thu, 18 Sep 2008 15:32:49 +0200, Nicolas Calimet a modifié des petits
morceaux de l'univers pour nous faire lire :

>>  - To be able to use duma with m_textures.ini, -D must be used or a
>>  crash
>> is generated for disp_sdl.cpp:573
> 
> 	As a quick test, could you try wrapping this line with a pair of
> SDL_LockSurface(m_screen) / SDL_UnlockSurface(m_screen) commands?
> 
> 	Thanks,
> 	- NC

Your words are my command.


Well, duma is far more happy on m_textures.ini with that code:

	void UnixSDLDisplay::UpdateScreen(bool Force = false)
	{
		if (!m_valid)
			return;
		if (Force || m_PxCnt >= UpdateInterval)
		{
                        SDL_LockSurface(m_screen);
			SDL_BlitSurface(m_display, &m_update_rect, 
m_screen, &m_update_rect);
                        SDL_UnlockSurface(m_screen);
			SDL_UpdateRect(m_screen, m_update_rect.x, 
m_update_rect.y, m_update_rect.w, m_update_rect.h);
			m_PxCnt = 0;
		}
	}
	


*BUT*

the rendering window now is fully black, all the time.
(if SDL_BlitSurface is not in the locked section, duma is not happy;
no big difference to include UpdateRect or not)
The rendered picture is fine.

Post a reply to this message

>                         SDL_LockSurface(m_screen);
> 			SDL_BlitSurface(m_display, &m_update_rect, 
> m_screen, &m_update_rect);
>                         SDL_UnlockSurface(m_screen);
> 			SDL_UpdateRect(m_screen, m_update_rect.x, 
> m_update_rect.y, m_update_rect.w, m_update_rect.h);

	Maybe the following will be better (for a quick test only -- best is
to properly deal with surface locking in all cases):

if (SDL_LockSurface(m_screen) == 0) {
   SDL_BlitSurface(m_display, &m_update_rect, m_screen, &m_update_rect);
   SDL_UpdateRect(m_screen, m_update_rect.x, m_update_rect.y, m_update_rect.w,
m_update_rect.h);
   SDL_UnlockSurface(m_screen);
}

	Thanks for doing those tests  :)
	- NC

Post a reply to this message

Le Mon, 22 Sep 2008 14:32:17 +0200, Nicolas Calimet a modifié des petits
morceaux de l'univers pour nous faire lire :

> 
> if (SDL_LockSurface(m_screen) == 0) {
>    SDL_BlitSurface(m_display, &m_update_rect, m_screen, &m_update_rect);
>    SDL_UpdateRect(m_screen, m_update_rect.x, m_update_rect.y,
>    m_update_rect.w, m_update_rect.h); SDL_UnlockSurface(m_screen);
> }
> 
> 	Thanks for doing those tests  :)
> 	- NC

Well, it is just plain black as previewing window.
Making duma happy, avoiding random locking on initialisation of the 
window, but what is worth a previewing window which remains black all the 
time ? (kind of rhetorical question, a real solution should be a working 
previewing window... without random lock...  please ?)

Post a reply to this message

Nicolas Calimet wrote:
> Maybe the following will be better (for a quick test only -- best is
> to properly deal with surface locking in all cases):
> 
> if (SDL_LockSurface(m_screen) == 0) {
>    SDL_BlitSurface(m_display, &m_update_rect, m_screen, &m_update_rect);
>    SDL_UpdateRect(m_screen, m_update_rect.x, m_update_rect.y,
>    m_update_rect.w, m_update_rect.h); SDL_UnlockSurface(m_screen);
> }

Surfaces that need locking must be locked before messing with the bitmap
array directly. Surfaces must NOT be locked for Blit to work.

Post a reply to this message