Update README to clarify DirPlayer's functionality#80
Conversation
Clarified the purpose of DirPlayer and added a note about Shockwave Flash games.
|
I can understand that you might be angry about it that we can't provide updates faster, but you need to keep in mind that we're offering dirplayer for free and working on it in your spare time. So please have some more patience. |
|
Really cool you wanted to contribute, I see and hear what you're putting out here. But I think a clearer approach is to instead outline the file types supported. For updating the README its probably something to discuss first than to make a PR for straight away - perhaps having a discussion in the discord is best first. |
|
Resolved,may you review this again? @markhughes |
|
I've fixed that,can you review again? |
| DirPlayer is a Shockwave Player emulator written in Rust that aims to make playing old browser games possible on modern browsers. | ||
| DirPlayer is a Shockwave Player emulator written in Rust that aims to make playing applications and games made using Director possible on modern browsers. | ||
|
|
||
| This cannot run Flash games. For those, you can use Ruffle. |
There was a problem hiding this comment.
There is (or should be) no expectation that a Shockwave emulator would run Flash games. We are working on adding support for Flash content *embedded* in Shockwave movies using Ruffle, but playing top-level SWF files remains out of scope for this project, and as it is currently written, this line creates more questions than it answers. If you really feel like this should be highlighted, I agree with @markhughes's suggestion to outline supported file formats as it would be a much clearer way to indicate this.
get_concrete_sprite_rect already has wide_h_shrink/tall_w_shrink bbox rules for "one dim matches + other moderately shrunk" cases on wide and tall bitmaps. Add the symmetric case: wide bitmap (bw > bh), height matches (|sh-bh|<=3), width moderately shrunk but at least 2/3 of bitmap width — treat as bbox approximation, not crop. The 2/3 threshold is stricter than wide_h_shrink's 1/2 because a horizontal crop of a horizontal bar is a plausible real crop; we only promote to bbox when the sprite is >=66.7% wide. Verified against the calibration suite: sprite #80 (134x9 in a 189x9 bitmap, 71%) correctly becomes BBOX while the true-crop cases #779/#782/#772 (sprites at ~57% of bitmap width) stay as SPRITE.
Clarified the purpose of DirPlayer and added a note about Shockwave Flash games.