English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 28 December 2013, 23:14   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
AGA border sprites

Just noticed something playing with AGA emulation. I'm guessing the same thing happens on a real Amiga, but anyway...

Using an AGA config, boot Workbench 3.1. Use Overscan prefs to change the NTSC text overscan size to the maximum possible (724x241). Use the default mouse pointer with hotspot at the top left. Enable border sprites using BSprite.

With an NTSC non-interlaced WB, move the pointer to the extreme right. Notice that the sprite brightness reduces. That's because the sprite is sort-of interlaced; half its lines are shown in each frame, with the others transparent. With an NTSC interlaced WB the effect is different; the pointer shimmers more noticeably. With a PAL WB (interlaced or not) the pointer disappears when it is in the rightmost position.

Is the effect with NTSC related to the long/short line toggle?

Update/addition: I noticed another issue with the same setup (border sprites enabled). Open Pointer preferences and draw some vertical lines at the right edge of the pointer image. Click Use. Move the pointer to the extreme right, then slowly left. Notice that the thickness of the rightmost vertical line (which should be one low-res pixel width) changes as you move the pointer. It alternates between one low-res pixel and half that, until the right edge of the pointer is inside the WB screen are again. A similar thing applies when you set the pointer to high-res; there, the rightmost pixel alternates between normal and disappeared as you move the pointer in from the right.

If you set the Workbench screen mode to super-high res and pointer sprite to low res, the rightmost pixel column of the pointer sprite changes width from 1→2→3→4→1 etc. shres pixels as you move the pointer to the left. With a high-res pointer, the rightmost two pixel columns of the pointer are affected.

I can upload a bootable ADF with those settings if you want.

Update 2: I also got WinUAE (2.7.0 official) to hang/crash by setting full overscan, enabling border sprites and setting the pointer hotspot towards the right of the image, then moving the pointer to/around the upper left of the screen. I managed to trigger the crash in both PAL and NTSC super-high res laced modes (32-colour if that's relevant), but it didn't happen immediately, or every time.

On the crash WinUAE log output was many lines of this:
JIT: Argh --- Am already in a handler. Shouldn't happen!

Last edited by mark_k; 29 December 2013 at 16:22.
mark_k is offline  
AdSense AdSense  
Old 29 December 2013, 18:00   #2
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Another issue I noticed, this applies when using a super-high res Workbench with border sprites enabled. No overscan needed. When the pointer moves near the bottom of the screen, some stripes appear at the lower right below the active WB screen area. More stripes also appear to the right of those when you move the pointer towards the lower right.

There's a similar issue with stripes at the top right of the screen, when you set a mouse pointer which has its hotspot towards the bottom of the sprite, and move the pointer to the top of the screen.
Attached Thumbnails
Click image for larger version

Name:	SHResBorderSpriteProblem1.png
Views:	165
Size:	5.9 KB
ID:	38439   Click image for larger version

Name:	SHResBorderSpriteProblem2.png
Views:	144
Size:	5.9 KB
ID:	38440  
mark_k is offline  
Old 31 December 2013, 12:27   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,522
Will test later.. (Border corruption is of course a bug)

btw, JIT "caused" crashes are useless, try without JIT.
Toni Wilen is online now  
Old 04 January 2014, 20:26   #4
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Things look slightly different now with WinUAE 2.7.1b1. The stripes are multi-coloured and there are a few stray single pixels.

I also noticed that one pixel row of the sprite is a lighter red than the others. That only applies to a single scanline in the left ~1/3 of the display though. In the pic below you can see where that effect ends. (That effect is present in 2.7.0 too.)
Attached Thumbnails
Click image for larger version

Name:	2710b1_border_sprites_pngout.png
Views:	130
Size:	4.5 KB
ID:	38529  
mark_k is offline  
Old 04 January 2014, 21:23   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,522
Right border sprite missing pixels fixed. (When border sprite was detected, rightmost pixel that needs to be drawn calculation didn't include possible extra pixels needed for sprite pixel doubling/quadrupling)

EDIT: I can't duplicate any max right edge disappearing or "interlaced" sprite effects.

Last edited by Toni Wilen; 04 January 2014 at 21:36.
Toni Wilen is online now  
Old 04 January 2014, 22:23   #6
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Testing the latest winuae.exe (datestamp 2014-01-04 20:20), there is still a single right pixel of the pointer sprite missing/present, alternating as you move the pointer to the left.

Also the top and bottom stripes are still present. But you only mentioned the right border being fixed so I'm guessing you know that already.

Edit to add: the max right edge disappearing (PAL) / interlaced (NTSC) effect does happen for me with WinUAE 2.7.0 but not with 2.7.1b1. The attached zip file contains a bootable ADF and config. Boot with Kickstart 3.1 ROM. With WinUAE 2.7.0, double-click the MaxOverscan.pre icon, then move pointer to the right.

Edit 2: If you boot that disk, then double-click one of the high-res pointer preset icons, the right half of the sprite is missing. That's an OS bug rather than an emulation problem, right?
Attached Thumbnails
Click image for larger version

Name:	20140104_2020_right_pixel_pngout.png
Views:	121
Size:	4.3 KB
ID:	38530   Click image for larger version

Name:	20140104_2020_top_stripes.png
Views:	122
Size:	5.6 KB
ID:	38531   Click image for larger version

Name:	20140104_2020_bottom_stripes.png
Views:	118
Size:	5.6 KB
ID:	38532  
Attached Files
File Type: zip BorderSpritesTest.zip (287.0 KB, 81 views)

Last edited by mark_k; 04 January 2014 at 22:45.
mark_k is offline  
Old 05 January 2014, 09:30   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,522
Both borders should be fixed now.

Disappearing sprite was caused by bad update in 2.7.0 (which also broke part of Elfmania scoreboard).

Quote:
If you boot that disk, then double-click one of the high-res pointer preset icons, the right half of the sprite is missing. That's an OS bug rather than an emulation problem, right?
Bug or restriction. Sprite size change (16 <> 32 <> 64 wide) requires copperlist modification and perhaps old programs assume mouse cursor change must be immediate, without calls to slow routines that are needed to rebuild copperlist.

Last edited by Toni Wilen; 05 January 2014 at 10:04.
Toni Wilen is online now  
Old 06 January 2014, 13:23   #8
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
With the latest winuae.exe everything seems fine with border sprites, except that strange "slightly lighter red line" when the pointer extends above the top of the Workbench screen.

The width of the lighter region seems to vary depending on screen res (high res or super high res) and depth.

Could it perhaps not be an emulation problem, but related to the graphics.library copperlist? I took a screen capture to see exactly what the colours were. The red sprite colour is E04040, whereas the lighter colour is EE4444. Notice that the OCS/ECS colour E44 would convert to 24-bit AGA EE4444. But maybe there's a bug in graphics.library which, except for that one partial scanline, incorrectly converts it to E04040??? Does it happen on a real AGA machine?

Quote:
Originally Posted by Toni Wilen View Post
Bug or restriction. Sprite size change (16 <> 32 <> 64 wide) requires copperlist modification and perhaps old programs assume mouse cursor change must be immediate, without calls to slow routines that are needed to rebuild copperlist.
Perhaps it's a bug in IPrefs then? Even running a program which opens a custom screen (which should cause the system copperlist to be rebuilt) doesn't restore the missing right half of the pointer.

Last edited by mark_k; 06 January 2014 at 13:43.
mark_k is offline  
Old 06 January 2014, 13:44   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,522
Quote:
Originally Posted by mark_k View Post
Could it perhaps not be an emulation problem, but related to the graphics.library copperlist? I took a screen capture to see exactly what the colours were. The red sprite colour is E04040, whereas the lighter colour is EE4444. Notice that the OCS/ECS colour E44 would convert to 24-bit AGA EE4444. But maybe there's a bug in graphics.library which, for at least that one partial scanline, incorrectly converts it to E04040??? Does it happen on a real AGA machine?
It is AGA hardware "problem", full AGA color palette update needs two color register writes, first high 4 bits of all color components is written (does same as OCS/ECS), this also automatically updates low 4 bits to emulate OCS/ECS colors (E44 becomes EE4444, FFF becomes FFFFFF because F0F0F0 would not be full white anymore on AGA when running OCS/ECS software). Next write updates low 4 bits to final color value (000 is written: E04040). Color can be slightly wrong between those two writes and it can be wrong quite long time (more than 2 scanlines in worst case) because copperlist normally writes all colors' high bits and then all low bits (which is more optimal, switching between low and high bits requires yet another write to separate control registers)
Toni Wilen is online now  
Old 06 January 2014, 14:35   #10
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,479
Ah that explains it. I guess Pointer prefs sets the pointer colour to E04040 (when in reality EE4444 would be more correct). It seems the ROM default pointer red colour is EE4444.
mark_k is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Best border black program for Workbench Bloodwych support.Apps 5 19 January 2011 01:07
ECS/AGA Border trick - HELP! KevG Coders. General 7 06 April 2010 12:02
EHB sprites with AGA chipset ? FrenchShark Coders. General 4 17 September 2009 06:37
Multiscan - Productivity and Gray Border illy5603 support.Hardware 7 18 August 2008 07:48
Scandoubler and the border DopPie support.Hardware 0 11 September 2004 19:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:29.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.16983 seconds with 12 queries