|
Post by turboxray on Mar 19, 2020 16:08:04 GMT
monstersgoboom I was looking at your tweet and I'm pretty interested in what's going on between the discrepancies. Can you explain the white line indication? Is with width of the line, the vram upload length? Or is it the placement of the white line in relation to the display (as in blank is vram upload time)? And I didn't see the green indicator on the real hardware. The reason I'm curious, is that I've done a lot of vram bandwidth tests during active display and didn't find much of a difference between mednafen and the realhardware (it's was pretty minimal). I'm curious if you're doing something different.
|
|
|
Post by monstersgoboom on Mar 19, 2020 17:03:45 GMT
vsync(); border(RGB(0,0,0)); ; fixed amount to push my code to visible on the screen load_vram(0x6000,map,xxxxx); border(RGB(0,0,7)); mycode(); border(RGB(0,0,0));
I found that the my code section was much closer to the bottom of the display with hardware, mednafen was closer, ootake was a decent chunk higher than either.
The green was RGB(0,1,0); on my TV that just looks black.
|
|
|
Post by turboxray on Mar 19, 2020 17:21:59 GMT
The visual display method is nice, but using the TIMER method might be more accurate (set the TIMER to 7khz and increment a WORD on each call). Or potentially starting the visual measure method during active display rather than v-int, using an starting H-int to set a flag. Both would be more accurate. The reason being, is that vblank isn't straight forward on the PCE like it is on the NES/SNES/Gen. And Emulators could potentially slightly off here.
Also, make sure your unused sprites have a Y offset set to 0. If you have uninitialized stuff in the SATB and it's causing them be offscreen X range but not Y range, this is going to affect your vram bandwidth because the VDC will still fetch those cells (i.e. it doesn't care where it is in the X range, only Y range gets evaluated). It might not be an issue, but it's a factor to rule out.
The difference between real hardware and mednafen looks to be about 16-ish scanlines? How many words are you writing to vram? If you halve the amount transferred, is the difference still 16-ish or smaller?
|
|
|
Post by monstersgoboom on Mar 19, 2020 17:54:33 GMT
The visual display method is nice, but using the TIMER method might be more accurate (set the TIMER to 7khz and increment a WORD on each call). Or potentially starting the visual measure method during active display rather than v-int, using an starting H-int to set a flag. Both would be more accurate. The reason being, is that vblank isn't straight forward on the PCE like it is on the NES/SNES/Gen. And Emulators could potentially slightly off here. Also, make sure your unused sprites have a Y offset set to 0. If you have uninitialized stuff in the SATB and it's causing them be offscreen X range but not Y range, this is going to affect your vram bandwidth because the VDC will still fetch those cells (i.e. it doesn't care where it is in the X range, only Y range gets evaluated). It might not be an issue, but it's a factor to rule out. The difference between real hardware and mednafen looks to be about 16-ish scanlines? How many words are you writing to vram? If you halve the amount transferred, is the difference still 16-ish or smaller? I'll look into timer if i need more accuracy thanks. ( I tend to go by the "does it fit in a frame" method of profiling ) As far as i can tell dealing with h-int and hsync from with HuC isn't easily supported ? ( I was looking at doing some copper bars / sky colors thing ) anyway. It looks like `init_satb` does set the sprites to 0
|
|
|
Post by gredler on Mar 19, 2020 19:37:34 GMT
As far as i can tell dealing with h-int and hsync from with HuC isn't easily supported ? ( I was looking at doing some copper bars / sky colors thing ) anyway. I have been wishing we could create gradients by changing the 0,0 color per horizontal line for skies, but not sure that's straightforward in HuC especially for beginners.
|
|
|
Post by monstersgoboom on Mar 20, 2020 2:14:41 GMT
As far as i can tell dealing with h-int and hsync from with HuC isn't easily supported ? ( I was looking at doing some copper bars / sky colors thing ) anyway. I have been wishing we could create gradients by changing the 0,0 color per horizontal line for skies, but not sure that's straightforward in HuC especially for beginners. I too wish it was doable, seems really missing and I "think" it could be done if someone was a bit of a wizard .
|
|
|
Post by DarkKobold on Mar 20, 2020 22:54:03 GMT
As an aside, would you be willing to share how you did slopes? They look great.
|
|
|
Post by monstersgoboom on Mar 21, 2020 23:14:13 GMT
As an aside, would you be willing to share how you did slopes? They look great. Basically if you know what slope you're on you can adjust floor height. 45 degree is something like. x_intile = player_x & 15 new_floor = basefloor - x_intile Or new,_floor = basefloor - 16 + x_intile Depending on which slope it is / or \ Does that make sense ? Other slopes are just variants of that logic DarkKobold
|
|
|
Post by turboxray on Mar 22, 2020 15:39:07 GMT
Doing an H-int routine for BG color changes isn't that bad even in HuC. Yeah, it's going to be asm but I had quite a few working examples.
The problem, is the you pretty need to remove the existing H-int routine, which means using a different system for scrolling. If you guys give me some specs to work with, I can give you a lib to import.
|
|
|
Post by monstersgoboom on Mar 22, 2020 16:48:15 GMT
Doing an H-int routine for BG color changes isn't that bad even in HuC. Yeah, it's going to be asm but I had quite a few working examples. The problem, is the you pretty need to remove the existing H-int routine, which means using a different system for scrolling. If you guys give me some specs to work with, I can give you a lib to import. My needs are to keep at least 2 scroll windows ( one for hud ) . I envisioned supplying at 480 byte table in ram with colors. But the colors could 'stop' at the second scroll if needed ?
|
|