Re: [hatari-devel] Videl borders

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On perjantai 02 maaliskuu 2012, Laurent Sallafranque wrote:
> I explained in a previous mail my problem about it, but I haven't got
> any answear.
> Maybe Mikro could help here ?
> 
> The problem is that I don't use the correct values to compute the
> horizontal borders.
> I don't understand the good formula to compute them.
> 
> But all the code I changed will permit easily to add the correct
> horizontal borders as soon as I know how to compute them (there's only
> VIDEL_getWidth() to change).

Well, at least this change from the original code like this:
  for (w=0; w<scrwidth; w++) {
    hvram_line[w] = p2cline[zoomxtable[w]];

To these:
  for (w=0; w<(vw*coefx); w++)
    hvram_column[w] = p2cline[videl_zoom.zoomxtable[w - videl.leftBorderSize 
* coefx]];

    srcword = SDL_SwapBE16(fvram_column[videl_zoom.zoomxtable[w - 
videl.leftBorderSize * coefx]]);


Seems suspicious as it results in negative videl_zoom.zoomxtable[]
array offsets if there's a left border...


Btw. I was also able to get screen to be vertically screwed by using:
	--max-width 680 --max-height 500 --force-max yes

And then switching to 80 columns mode.  See attachment.
(with borders off it's fine)


Hatari crashes if it doesn't get the full resolution:
   --borders off --max-width 580 --max-height 500 --force-max

When switching to 80 columns mode.

Program received signal SIGSEGV, Segmentation fault.
0x0815775b in VIDEL_ConvertScreenZoom (vw=640, vh=200, vbpp=<value optimized 
out>, nextline=160) at /home/eero/work/hatari/src/falcon/videl.c:1621
1621                                                            
hvram_column[w] = p2cline[videl_zoom.zoomxtable[w]];

But that's a minor issue as it shouldn't happen on normal computers,
they have large enough screens (unlike some handhelds).


	- Eero

Valgrind says of the crash part:
==4549== Invalid read of size 4
==4549==    at 0x8157766: VIDEL_ConvertScreenZoom (videl.c:1620)
==4549==    by 0x8159BFA: VIDEL_renderScreen (videl.c:804)
==4549==    by 0x8126044: Video_InterruptHandler_VBL (video.c:2696)
==4549==    by 0x81712B2: m68k_run_2p (newcpu.c:3586)
==4549==    by 0x816F5C1: m68k_go (newcpu.c:3769)
==4549==    by 0x8109233: M68000_Start (m68000.c:253)
==4549==    by 0x810A07D: main (main.c:782)
==4549==  Address 0x51f1e20 is 0 bytes after a block of size 2,320 alloc'd
==4549==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4549==    by 0x815614C: VIDEL_ConvertScreenZoom (videl.c:1385)
==4549==    by 0x8159BFA: VIDEL_renderScreen (videl.c:804)
==4549==    by 0x8126044: Video_InterruptHandler_VBL (video.c:2696)
==4549==    by 0x81712B2: m68k_run_2p (newcpu.c:3586)
==4549==    by 0x816F5C1: m68k_go (newcpu.c:3769)
==4549==    by 0x8109233: M68000_Start (m68000.c:253)
==4549==    by 0x810A07D: main (main.c:782)
==4549== 
==4549== Invalid read of size 4
==4549==    at 0x8157758: VIDEL_ConvertScreenZoom (videl.c:1621)
==4549==    by 0x8159BFA: VIDEL_renderScreen (videl.c:804)
==4549==    by 0x8126044: Video_InterruptHandler_VBL (video.c:2696)
==4549==    by 0x81712B2: m68k_run_2p (newcpu.c:3586)
==4549==    by 0x816F5C1: m68k_go (newcpu.c:3769)
==4549==    by 0x8109233: M68000_Start (m68000.c:253)
==4549==    by 0x810A07D: main (main.c:782)
==4549==  Address 0x51f1e24 is 4 bytes after a block of size 2,320 alloc'd
==4549==    at 0x4023F50: malloc (vg_replace_malloc.c:236)
==4549==    by 0x815614C: VIDEL_ConvertScreenZoom (videl.c:1385)
==4549==    by 0x8159BFA: VIDEL_renderScreen (videl.c:804)
==4549==    by 0x8126044: Video_InterruptHandler_VBL (video.c:2696)
==4549==    by 0x81712B2: m68k_run_2p (newcpu.c:3586)
==4549==    by 0x816F5C1: m68k_go (newcpu.c:3769)
==4549==    by 0x8109233: M68000_Start (m68000.c:253)
==4549==    by 0x810A07D: main (main.c:782)
==4549== 
==4549== Invalid read of size 4
==4549==    at 0x815775B: VIDEL_ConvertScreenZoom (videl.c:1621)
==4549==    by 0x8159BFA: VIDEL_renderScreen (videl.c:804)
==4549==    by 0x8126044: Video_InterruptHandler_VBL (video.c:2696)
==4549==    by 0x81712B2: m68k_run_2p (newcpu.c:3586)
==4549==    by 0x816F5C1: m68k_go (newcpu.c:3769)
==4549==    by 0x8109233: M68000_Start (m68000.c:253)
==4549==    by 0x810A07D: main (main.c:782)
==4549==  Address 0x51f4b20 is not stack'd, malloc'd or (recently) free'd


I guess it's better if the array would be one pixel larger
with the zoom factor in extra pixel pointing to previous value.

Attachment: grab0002.png
Description: PNG image



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/