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/ |