- Joined: 01 Jul 2016
- Posts: 55
|
GG LineInterrupt CRAM update vs SMS version
 Posted: Tue Apr 18, 2017 9:39 pm
|
Hi,
On the SMS version of my game, I used the LineInterrupt to update the color of BGPal #1 every row (8 lines)
It works perfect and no artefact/CRAM dot is visible.
I had to use inline asm to get it working with sdcc but it works.
On GG, the code doesn't work any longer...
Artefact / CRAM dot are visible on column 2 or 3
I know I had to write one byte more than on the SMS version but i don't see how to optimize it even more....
Please note I'm fighting these artefacts on Emulicious only , since I'm unable to test it on real hardware and Meka 0.7x doesn't produce them (while it was able to render them on my prior buggy SMS version)
So again, after many days trying, I ask for your help :
Did you see something which could be done ?
; write to color 1
ld a, #2
out (0xbf), a
ld a, #0xc0
out (0xbf), a
; byte 1
ld a, 0x0F
out (0xbe), a
; trick to wait some tstates, borrowed from devkitsms source code
; push af
; pop af
; ... commented since it doesn't solve the issue
; byte 2
ld a, 0x0F
out (0xbe), a
if you want to know
GG_setNextBGColoratIndex(1);
GG_setColor(0xF0F);
produce the same artifacts, 3 or 4 columns later
so it seems my asm code is faster...but still not enough
Of course, I use dynamic value for the colors but this code (with hard coded) is the smaller one I tested which produced artefacts
What explain this difference of optimization between the GG (a NTSC SMS) and a "real" SMS ?
|
- Site Admin
- Joined: 19 Oct 1999
- Posts: 14735
- Location: London
|
Posted: Tue Apr 18, 2017 10:50 pm
|
|
Normally you need to waste cycles to time the update during hblank, as by the time you are writing, the raster has moved into the display. If the interrupt handling is fast enough, you can time it in the line you intended instead of having to waste cycles to time it for one line later, because the interrupt fires a bit early.
|
- Joined: 01 Jul 2016
- Posts: 55
|
Posted: Thu Apr 20, 2017 6:04 pm
|
I was aware of this "trick" as it was given as a possible way to handle CRAM change on SMS on my initial request.
But I thought the "hidden" columns of the GG window will also hide the artefact.
It seems I was wrong...
too bad I had to follow this awful hack :(
which means my game loop should be no longer than the 70 ending scanlines
|
- Joined: 05 Sep 2013
- Posts: 3823
- Location: Stockholm, Sweden
|
Posted: Thu May 04, 2017 8:52 am
|
|
mmm... are you using h-scrolled map?
|
- Joined: 01 Jul 2016
- Posts: 55
|
Posted: Sun May 07, 2017 12:06 pm
|
no longer since it bugs my HUD
now I use softscroll
|
- Joined: 05 Sep 2013
- Posts: 3823
- Location: Stockholm, Sweden
|
Posted: Sun May 07, 2017 12:15 pm
|
so I wonder how you can see the artifacts. I mean, they should be 'left' enough for not appearing in the GG screen... are you updating a single color, right?
How many pixel from the left edge the artifacts appear?
Anyway, did you try doing
GG_setColor(0xF0F);
before
GG_setNextBGColoratIndex(1);
?
(I mean you can issue the first GG_setNextBGColoratIndex() as a last operation of your VRAM updates after vblank...)
|
- Joined: 01 Jul 2016
- Posts: 55
|
Posted: Sun May 07, 2017 12:59 pm
|
it's exactly what I though...
"How could I see them ? they should be on the hidden columns"
Yes i updating 1 color every 8 rows
using devkitsms functions, artifacts are 1 or 2 columns later
|
