[HuC 4] "sgx_load_tile" crashes on the SuperGrafx

[Ryusennin]

First of all, thanks a lot to Elmer for maintaining the development of HuC and its successor. I have enjoyed dabbling with Magic Kit back in the DOS days, but I am not (and will never be) proficient in 6280 assembly. Despite its shortcomings, HuC is a blessing for occasional C programmers like me.

I have recently familiarized myself with loading and scrolling tilemaps larger than the virtual screen, which is a big victory for me. Unfortunately it only seems to work with the standard PCE functions. When trying to use the SGX library, the code freezes the hardware and Mesen, sometimes with severe audio distorsions.

For testing purposes, I recycled HuC's Pro Motion example and made a simple test demo which includes both PCE and SGX functions. You can switch the "hardware" variable between COREGRAFX and SUPERGRAFX to easily test the code on each system. It works fine on PCE but it crashes on SGX. I'm not certain, but it seems to happen when running sgx_load_tile.

Expected result:

This PCE code works fine:

    /* init pce map */
    set_map_data(testmap,MAP_WIDTH,MAP_HEIGHT);
    set_tile_data(testtiles,113,testtable,TILE_WIDTH);
    load_tile(TILE_VRAM);
    load_map(0,0,0,0,MAP_WIDTH,MAP_HEIGHT);
    load_palette(0,testpal,16);

This SGX code freezes:

    /* init sgx map */
    sgx_set_map_data(testmap,MAP_WIDTH,MAP_HEIGHT);
    sgx_set_tile_data(testtiles,113,testtable,TILE_WIDTH);
    sgx_load_tile(TILE_VRAM);
    sgx_load_map(0,0,0,0,MAP_WIDTH,MAP_HEIGHT);
    load_palette(0,testpal,16);

Maybe I am missing something simple, but I can't find any tilemapping example for the SuperGrafx. Hopefully someone will be able to give me some hints.

sgx_load_tile_test.zip

[Ryusennin]

I just gave a quick try to HuCC. Lacking documentation, I had to make some guesses. After commenting out the deprecated sgx.h header and VPC mode instructions, the above code worked right out of the bat. This is very encouraging!

Although that makes me believe the tilemapping functions of the old SGX library might have a long-standing bug. Even at my humble level, I can't be the first to use HuC for SGX development?

[jbrandwood]

Thank you for the kind words. :-)

To be honest, you may well be the second (or possibly the first) person to try those specific SGX functions in HuC!

I suspect that Nicole was probably the first, when she wrote Space Ava (https://github.com/nicolebranagan/spaceava201), but IIRC she had so many problems with HuC's SuperGRAFX and Arcade Card functions that she ended up writing some new functions to use in her game.

HuCC is still under development, and has not been officially announced yet, but I'm glad to hear that it is working for you. All of the teams that are currently testing it seem to be quite happy with the improvements in HuCC.

FWIW, all of the HuC-compatible functions that are supported in HuCC have been rewritten, so I'm glad to hear that the SuperGRAFX map functions are working for you. Full support for the SuperGRAFX (including scrolling) is one of HuCC's goals.

At this point, since you've managed to get your code compiling with HuCC, I'd recommend that you just stick with it, and then report any problems so that I can fix them before the official release.

Since my focus is on pushing HuCC towards release right now, I'm unlikely to try to fix HuC's broken SuperGRAFX functions in the forseeable future, but perhaps someday!

Best wishes,

John

[Ryusennin]

I think you're right, it's not really worth bothering with the old SGX library.

I've spent the best part of the weekend porting my code to HuCC, and most of the work had to do with switching to the new scroll_split function. Native SGX support is a huge boon and the working tilemapping features have convinced me to stick with HuCC :D

My two main hurdles so far:

1. disp_off doesn't seem to work when scroll_split is active. It's a problem when preparing a scene, the display is forcibly switched on, although the assets (tiles, sprites, palettes) are still loading. The screen is only jumbled during 3 or 4 frames, but it is quite jarring. In HuC 4, I often use the scroll function to position the "camera" on the map while the display is off and I load a scene. In HuCC, my workaround is to call scroll_split with a 0x00 disp flag before initializing the scene. That works very nicely, but I'm not sure I'm doing it the right way. sgx_scroll_split, when used alone, is not affected!

2. I haven't found how to change the VPC mode. It seems to be set by default on mode 2 (SP1 > SP2 > BG1 > BG2). My dirty workaround is to force SGX_PARALLAX = 0 in the vdc.asm include, but surely there must be a simpler way to do it. With the old SGX library, we could easily switch to mode 1 (SP1 > BG1 > SP2 > BG2) with the deprecated vpc_win_reg instruction, but I don't know how to that in HuCC. Sometimes mode 1 is preferable, it allows to place SP2 behind both BG2 and BG1, very useful in some situations, like for example the background mountain in this scene:

All in all, I'm already a fan of HuCC! I've done some quick parallax tests on both VDCs and the potential is amazing :)

[jbrandwood]

As mentioned in ... https://github.com/pce-devel/huc/blob/master/examples/hucc/sgx/sgx_test.c

/ HuCC enables and disables both the PC Engine and SuperGRAFX VDCs when disp_on() and disp_off() are called. Disabling them seperately is not normally done in games, but it is easy to accomplish with a bit of inline asm! Note that HuC's scroll(), HuCC's scroll_split() and sgx_scroll_split() all override the current disp_on() or disp_off()! /

In HuC, having an active scroll() region overrides disp_off() for the PCE VDC, but I'm not sure what it does for the SGX VDC, I'd have to look. HuCC should behave the same as HuC if you use the old scroll() instead of the new scroll_split().

In HuCC, if you have an active scroll_split() or sgx_scroll_split(), then disp_off() for that particular VDC will be overridden.

In all cases, the scrolling functions must override disp_off() if there's an active region in order to avoid the VDC from going into its BURST mode accidentally.

From my POV, you've got 3 choices if you want to blank the screen so that uploads aren't visible to the user. 1) Disable all the PCE and SGX scroll regions, and then disp_off() will do what you want. 2) Set a fullscreen scroll region for each VDC chip with a $00 disp flag as you've already found. 3) Blank the screen by clearing the palette. This will work whether there are any scrolling regions or not, and this would be what I'd normally do in my code.

As for setting the VPC, I could certainly provide a function to do that, but all of the original SuperGRAFX games that I have seen just use one setting for the whole screen, set once at the beginning of the game, so that's the model that I have followed.

As you've found, the default is the SGX_PARALLAX setting, and you can change that by setting SGX_PARALLAX=0 as you've found ... you've just done it in the wrong place. HuCC has an hucc-config.inc file that you're supposed to copy to your project's directory and then modify if you want to customize the library settings, such as changing the SGX_PARALLAX setting.

It looks like I haven't added that particular setting to the hucc-config.inc file yet, but I obviously need to do that so it is documented.

Now, apart from that, it sounds like you're wanting to use the VPC setting for layering instead of just using the sprite priority to control layering. The only difference between the 2 main VPC modes is whether you want your high-priority SGX sprites to be in front of BG1 or behind BG1.

; Priority Setting 0b00xx: (useful when VDC #1 is a fullscreen HUD) ; ; FRONT ; SP1'= VDC #1 high priority sprites ; BG1 = VDC #1 background ; SP1 = VDC #1 low priority sprites ; SP2'= VDC #2 high priority sprites ; BG2 = VDC #2 background ; SP2 = VDC #2 low priority sprites ; BACK ; ; Priority Setting 0b01xx: (useful for parallax backgrounds) ; ; FRONT ; SP1'= VDC #1 high priority sprites ; SP2'= VDC #2 high priority sprites ; BG1 = VDC #1 background ; SP1 = VDC #1 low priority sprites ; BG2 = VDC #2 background ; SP2 = VDC #2 low priority sprites ; BACK

Are you saying that feel that there's a need to change the VPC settings between individual game screens, rather than just choosing your game's default at compile time like the shipped SGX titles seemed to do?

[Ryusennin]

Thank you for the tips about the ways to blank the screen. Clearing the palette was a possibility I also thought about, and it will become an interesting one when I try my hand at palette fadeouts.

About the VPC -- a simple VPC function would be most appreciated, as it is sometimes useful to change those priorities from one stage (or screen) to another, depending on the situation and not just at compile time. I did a few "conversion" slideshows and mockups with HuC4 and the old SGX lib, and many times I need to push SP2 behind BG1+BG2.

I might be wrong but according to my tests, mode 2 ("parallax") doesn't allow to do that. SP2 sprites can be lowered behind BG2, but they will still display in front of BG1, which of course generate unwanted results. Mode 1 ("HUD") is sometimes more versatile, especially when converting Super Famicom screens and its three BGs. Compared to the MD or the SFC, the SGX doesn't have much leeway in terms of layer priority management (like no individual tile priority), and I think every mode available is a welcome tool to experiment with.

Some examples where I used mode 1 extensively (Chou Makai Mura with HuC4, Tengai Zero with HuCC): SGX_VPC_Mode1_Examples.zip

[jbrandwood]

I need to take a look at your examples, but unless I'm misundestanding what you're saying, or perhaps we have a different frame of reference for what is layer 1 vs layer 2, then what you're saying does not match what I'm reading in Charles MacDonalds' sgxtech.txt.

From my reading of the document, I can see no way that an SGX sprite can be both behind the SGX background, but in front of the PCE background. The only difference between mode 0 and mode 2 is whether the hi-priority SGX sprites appear behind or in front of the PCE background.

Maybe I'm either misunderstand what you're saying, or misunderstanding the document.

[jbrandwood]

Anyway ... "yes", I'll add the function to set up the VPC, I just don't want developers to have to type that incomprehensible set of numbers unless they really need the capability.

[Ryusennin]

Sorry, the confusion is probably due to me not being technical enough.

I'm also using the old Tomaitheous vernacular... which described the two (actually three) VPC modes in his SGX library as:

Mode 1 = SPR1 > BKG1 > SPR2 > BKG2 ("HUD") Mode 2 = SPR1 > SPR2 > BKG1 > BKG2 ("Parallax")

I understand the priority settings you have described above, but in my tests (in HuC4 and HuCC), the parallax mode ("mode 2") doesn't seem to behave exactly that way. Low-priority SP2 sprites are indeed hidden behind the SGX background, but they still appear in front of some portions of the PCE background.

In my little Tengai Zero experiment, the waterfall scene uses the VPC "HUD" mode (PARALLAX=0). The scene is composed (pretty much like the Super Famicom version) as follows:

1. BG1 is used as an overlay for pine trees

2. BG2 is the main background (bridge, forest, cliff)

3. The waterfall in the back is entirely made with low-pri SP2 (I call it a pseudo "BG3")

This is the expected result with PARALLAX=0:

But if I use the default VPC mode (PARALLAX=1), those low priority sprites will definitely appear behind BG2, but also in front of the BG1 parts that are not covering BG2.

The way I understand it, the low-pri waterfall will remain behind both BG2 (bridge, cliff, etc) and BG1 (the tree tops), as long as the BG1 tree tops are displayed over some "solid" pixels on BG2 (like the ground). The BG1 tree tops that are over empty BG2 space (color 0) will be replaced by the low-pri SP2 waterfall...

I have verified this behaviour on my SuperGrafx and in Mesen.

Here are two ROMs with PARALLAX=0 (correct result) and PARALLAX=1 (incorrect result) for easy comparison: sgx_vpc_tests.zip

Thank you in any case for considering implementing this VPC function. I'm perfectly fine with the parallax mode being configured as the default one, since it obviously fits the name (especially for classic arcade-style games). But having the choice is definitely a plus.

[jbrandwood]

Thank you for teaching an old man something new! :-)

So yes, I was wrong and misunderstood the implications of how the VPC processes the pixels from the SuperGRAFX's two VDC chips in the "parallax" mode, causing low-priority sprites on the 2nd VDC to appear on top of backgound pixels of the 1st VDC.

Wow, that makes the "parallax" mode quite a bit more limited than I had believed.

It may be a few days before I check-in that VPC function to github, I'm right in the middle of some optimization work that I'm not quite ready to check-in yet.

Best wishes,

John

[Ryusennin]

No, thank you for still maintaining and updating HuC, without which dilettante developers like me would be hopeless!

And I agree that the SGX priority possibilities are quite restrictive, which is why the two modes are really useful in different situations. Mode 3 (BKG1 > BKG2 > SPR1 > SPR2) is also interesting with its pseudo "transparency" effect — high priority SPR1 sprites can be seen through BKG1 with the colours of BKG2 (a bit like shadow puppets). The result can be disorienting, and I haven't found it any practical use. Maybe for fancy title screens...

[jbrandwood]

FWIW, I've added some VPC functions to the HuCC library.

They're not the same as the ones in the old HuC library because I wanted to have functions that could produce faster code.

Best wishes,

John

[Ryusennin]

Thank you John, this is great news. I will give it a test tomorrow.

What is the required syntax to make it work? According to hucc-baselib.h the function is named vpc_set_ctl, but the description says "VPC settings for set_vpc_ctl".

[jbrandwood]

The function itself is declared/protyped further down in that header file.

"extern void fastcall xsafe __nop vpc_set_ctl( unsigned int bits );"

So, in C ... vpc_set_ctl( VPC_SPR1_SPR2_BKG1_BKG2 );

Urrgghh ... I switched from the set_vpc_ctl to the vpc_set_ctl name after writing the comment in order to make it closer to the other SGX functions.

[Ryusennin]

Brilliant! The three modes work great, even when switching them in real time. That will prove very useful.

Thanks a lot for restoring this function!