Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MBornes5] Graphics rendering glitch #444

Closed
kapfab opened this issue Oct 4, 2024 · 4 comments
Closed

[MBornes5] Graphics rendering glitch #444

kapfab opened this issue Oct 4, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@kapfab
Copy link

kapfab commented Oct 4, 2024

Description

Opolua does not behave like a real device for a specific graphics rendering operation.

Metadata

Key Value
Title MBornes5
Source URL https://archive.org/download/3-libjune-05/3LIBJUNE05.iso/library/epocgames/millesbournes/MBornes5.SIS

Details

When the last card of the player’s hand (the one at the bottom) is discarded, it should disappear (other cards are just blanked).
That’s what happens on a real device.
With Opolua, this last card does not disappear when discarded: it's sent behind the other cards and stays visible (see screenshot).

This behaviour makes me think of gRANK or gORDER making use of an incorrect drawable position (z-index), maybe just shifted by 1, but this might be something else.

MBornes5_Glitch

@tomsci
Copy link
Collaborator

tomsci commented Oct 11, 2024

Thanks for the report. Looking at the code there is a potential off-by-one error due to the toolbar clock widget, which internally is treated like another window but shouldn't be considered by the window positioning calculations. That might be the cause.

@tomsci tomsci added the bug Something isn't working label Oct 11, 2024
@tomsci
Copy link
Collaborator

tomsci commented Oct 17, 2024

Interestingly, this turns out to not be due to z-ordering but because MBorne5 specifies a mode of $101 in a call to gCREATEBIT, a value which is technically only valid when creating a window with gCREATE. Our implementation was failing to create the bitmap due to the (perceived) invalid mode but not erroring the program, meaning when it tried to clear that bit of the screen by copying from the invalid bitmap, nothing happened. Ignoring the invalid mode makes the program render correctly.

So there are several fixes to be made here:

  • Ignore any flags in the mode in gCREATEBIT to match how the psion 5 (apparently) does it
  • Failing to construct a bitmap in the native code should cause an error rather than silently continuing with out-of-sync info between Lua and Swift logic.
  • Using an invalid bitmap id in a gCOPY call should cause a KErrDrawNotOpen error.

@kapfab
Copy link
Author

kapfab commented Oct 17, 2024

Good news, this will probably benefit a few other programs!

@jbmorley
Copy link
Collaborator

@kapfab Seems like these kinds of oddities would be great to record in some OPL-level documentation. 🤔

tomsci added a commit that referenced this issue Oct 19, 2024
even though they are technically incorrect for this API. Also errors
from gCREATE, gCREATEBIT and draw operations now return an error to the
program rather than silently continuing.

Also allow SPRITEDELETE: with an invalid id. (Also needed to keep
MBornes5 happy)

fixes #444.
@tomsci tomsci closed this as completed in ae1e070 Oct 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants