Mangagamer's Rance VI issue on latest xsystem4 release

[KaroNiko]

Clicking on the first available option (ask the guy about an exit) in the base screen menu, after the dialogue, an error occurs (incomplete framebuffer; see the picture below); clicking on ok, unfortunately the game does not continue, but throws out into the title selection screen. Thank you for your attention and especially for this unexpected and fantastic port.

Edit: Even selecting the third option (Rance attack), It gives the same error, and you cannot continue.

Edit2: Even selecting the important "???" event, after the text related to it, it gives the same error. Ultimately, you cannot proceed in the story.

Update: Finally, I found that this error occurs only after the fourth event choice (whatever it is) the first three times it goes smoothly and returns to the menu of choices without issue.

[KaroNiko]

[kichikuou]

On my device, this happens when CSpriteScrollbar::Build() creates a sprite with a size of 42 x 11340 pixels, and tries to draw on that sprite. GL_MAX_TEXTURE_SIZE is 8192 on my test device (Fire HD 8, 10th gen), so a texture with a height of 11340 cannot be created.

Details

It happens when there is only one element in the menu on the base screen. In the game script, CSpriteScrollbar::Build() calculates the height of the scrollbar using the following formula:

m_nBarSize = (m_nHeight / m_fMaxNumber) * m_fViewNumber;

Where

• m_nHeight = 315, the height of the scrollbar CG,
• m_fMaxNumber = 1, the number of items in the menu,
• m_fViewNumber = 18, the menu is 18 elements high.

This calculates m_nBarSize as 5670. MG Rance6 internally doubles the width and height of every sprite, so the final sprite height is 11340.

The above formula makes no sense if m_fMaxNumber < m_fViewNumber, but the game script creates this sprite anyway and draws to it. (This sprite is never displayed on the screen if m_fMaxNumber < m_fViewNumber.)

The game script doesn't have any error checks, so xsystem4 has to somehow handle this sprite creation and drawing without crashing.

A Similar Case

The "Ludo-Rathowm Continent Edition" SR mod had a similar issue, where a sprite with a width of 16000 was created. The sprite was visible on the screen, but was transparent except for a small portion on the left side. This was a programming error that created sprites with unnecessarily large widths, which was fixed in an unreleased version, but the unfixed version is still widely used.

How to Fix This?

I think xsystem4 should clamp the size with GL_MAX_TEXTURE_SIZE when a sprite is created with a large dimension. If the game tries to use the outside of the clamped area for drawing, it will have trouble, but it will work fine for the above two cases.

[kichikuou]

This will be fixed in the next release. If you need the fix today, you can download an apk here.

[KaroNiko]

Wow... you two were quick to fix it; I didn't expect it so soon! Hey @kichikuou , you didn't have to bother to provide a version especially for me right away. I really appreciate that. This means a lot to me.

While I'm at it, I'm testing it now; in fact it works perfectly. I will provisionally set aside Daibanchou to play this one instead. Much obliged, really. 🙏

[kichikuou]

Glad to hear it is working.

No worries, I've set it up to automatically build an APK when I upload code changes to GitHub, and I'm just posting a link to the result.

[KaroNiko]

Hey @kichikuou, sorry for yet another disturbance. Is it possible to install Tada's enhancement patch and Satsu DLC patch without new issues arising? Or are they incompatible? https://alicesoft.fandom.com/wiki/User_blog:RottenBlock/TADA%27s_Rance_VI_beta_2.05_now_in_English! https://alicesoft.fandom.com/wiki/Takega_Satsu/Rance_VI

[kichikuou]

I'm not familiar with the internals of those patches; you might want to ask RottenBlock at the Wiki.

[KaroNiko]

Hi @kichikuou, and sorry for yet another unexpected intervention of mine 😅. I would like to report a slight issue regarding this title (not serious but still annoying) not so important as to merit a separate thread. Moving an item and dragging it with your finger to attribute it to a character is quite difficult; you can't grab it and if you succeed, after several attempts, you often lose it on the way in dragging it. Said otherwise, as if it detects the finger touch late, or not at all. Very strange, because instead you can easily drag the various characters with your finger to form the party of 6 people. On what can this difference depend? Is this defect fixable? Thank you.

[kichikuou]

I'm not sure if I'm reproducing the problem.

https://github.com/kichikuou/xsystem4-android/assets/12679772/1301635d-2818-496b-a523-8f8f384e25d9

It takes a while to get feedback after touching an item, but don't worry about it and just start moving your finger. If you hold your finger down for more than a second, it means you pressed the Ctrl key.

BTW, don't hesitate to start a new thread. If you comment on a closed thread, it may get missed.

[KaroNiko]

Nah, obviously the solution was not that simple, otherwise I would have already found it myself. If you can't reproduce this defect, it apparently depends on my device (maybe processor too slow?); it is noticeable in the clip that it detects touch late, or not at all (but only in this case). https://drive.google.com/file/d/1KWaNdD_MsuSY2J4CWzWazPIcO_w9Nd5K/view?usp=drivesdk

P.S. Your clip, as far as I can tell, would appear to be broken.

Edit: I enabled sharing via link. My inattention. Apologies.

[kichikuou]

Transcoded my clip above to H.264. Can you play it now?

https://drive.google.com/file/d/1KWaNdD_MsuSY2J4CWzWazPIcO_w9Nd5K/view?usp=drivesdk

It seems I don't have permission to access that file.

[KaroNiko]

Yeah, I see your video now. 👍 I activated the sharing of mine, which I thought was already activated. My bad. 😅

[kichikuou]

Thanks, I can see your clip now.

It does indeed seem to be slow. If you could send me the save files under Android\data\data\io.github.kichikuou.xsystem4\files\.xsystem4, I will try it again in my environment.

[KaroNiko]

Of course. But I suppose the features of my device are sufficient: Also, why is it slow only on this occasion, and not when I drag the characters to form the group? And not during the 3D dungeon phase or during turn-based battles? 🤔 SaveData.zip

[kichikuou]

I tried using your save data, but it didn't make a difference.

It takes more than a second for the visual feedback to appear after I touch an item, so if I wait that long, I can't drag it. But if I move my finger immediately after touching it, I can drag it consistently.

My test device is a Fire HD 8 10th gen (6x Cortex-A55 2.0GHz), which is a bit faster than yours. But I don't think the slowness explains the inability to drag.

[KaroNiko]

Okay. All right. Thank you for your interest and for your continued dedication to this amazing project. 😆

[KaroNiko]

Changing topic, haven't you ever thought of porting @nunuhara's AI5-SDL2 to Android? This would allow us to play the english version (which supports japanese voice acting from the Sega Saturn version) of the legendary Elf's YU-NO on tablets. Of course, it is not that I want to put any pressure on this... 😅 In truth, today it is possible to play this title on tablets through Neko Project 2, but without voice acting, that is, losing half of its value. Pure curiosity, nothing more: you deserve a trophy already for porting those AliceSoft's game engines to android. 🏆

[kichikuou]

Maybe someday? Given the low availability of "elf Classics" in Japan, I don't have a strong motivation to port it right now.