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

Suggestions for the resolution and keycodes list #9

Open
TwoSpacesSG opened this issue Sep 24, 2024 · 5 comments
Open

Suggestions for the resolution and keycodes list #9

TwoSpacesSG opened this issue Sep 24, 2024 · 5 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@TwoSpacesSG
Copy link

There's some weirdness in the resolution and keycode selectors AND some missing stuff ever since the original freej2me. Here are my suggestions.

Weird stuff

  • 96x96 and 104x80 resolutions, I'm not aware of any phones or games that used these. I think by the latter, they were meaning 101x80.
  • "Standard" keycode layout, which seems to have numbers duplicated on the arrow keys. I don't think any actual phones ever did that? It's really confusing to have this on default (there are a few games where numbers and control pad don't do the same thing), I suggest to just remove this one and make Nokia the default since that one is basically the standard, unless there's some deeper meaning I don't get.

Resolutions

Some resolutions that exist are missing, I'll list them alongside devices that used those that have actual games preserved for those. Alternatively you may want to implement a "swap width and height" feature (Nokia Series 60 and KEmnnmod support swapping those in mid-game for screen rotation).

  • 101x80 (various Siemens phones)
  • 130x130 (various Siemens phones)
  • 180x320 (a few actual games for 360x640 devices in half-resolution)
  • 208x320 (Sony Ericsson P-series)
  • 220x176 (Samsung X-series)
  • 240x432 (Sony Ericsson Aino, Samsung SGH-F490)
  • 240x480 (LG KF700)
  • 320x180 (see above)

Keycode layouts

Many more exist than Nokia, Siemens and "Motorola". I attempted to gather a list of all the common ones that are seen in preserved games. You may want to implement a "swap softkeys" feature in order to eliminate the need for key layouts that are just Nokia (for Sagem) and Motorola Triplets (for certain games) but with swapped softkeys.

  • Nokia / Sony Ericsson / Samsung (already present)
  • Motorola E1000 / Motorola V3x / Alcatel / SoftBank (already present)
  • Motorola RAZR2 V8 (example - Sonic and Sega All-Stars Racing (600kb) for the V8)
  • Motorola Triplets (I've seen games with this key layout but with swapped softkeys as well)
  • LG (several but not all LG models used the LG layout)
  • Siemens (already present)
  • Sagem (this one is just Nokia with swapped softkeys)
  • Nokia Keyboard (aka "Nokia E62", some games for such phones require you to switch to keyboard mode to play the game, example - Rayman Kart)
@AShiningRay AShiningRay added enhancement New feature or request good first issue Good for newcomers labels Sep 25, 2024
@AShiningRay
Copy link
Collaborator

These are nice, the resolution list definitely need some touching up (i even did a round on them previously since some really popular screens weren't available), but as for the "swap width and height"setting, isn't this already in place by enabling Screen Rotation? Certain games do generate a non-rotated landscape framebuffer, so in those cases, the screen res itself should be landscape, with that being the case on both FreeJ2ME and KEmulator, which also require a content restart to properly render stuff on the new size.

A quick button to simply swap those would be a neat addition, but i don't feel it is really necessary right now, especially with the compatibility list being in its infancy where the more info we gather, the better.

As for keycode layouts, true, we're not only missing some of them, but also the "Standard" layout isn't exactly Standard. AFAIK it's only there precisely because it mirrors both num keys and nav keys, probably as a means of simplifying inputs for Libretro and RPi targets, as i do recall hex and recompile talking about some controllers not having enough buttons/axes to map complete key layouts. I wouldn't swap it over for Nokia, although i'd gladly rename it to "Gamepad" or something that better explains what it is intended to do... perks of trying to run this on as many platforms as possible early on.

Once i have time, i'll start with the res list do-over, then the key layouts since both are quite important. Until then, you can also submit a PR for those if you feel like it, i wouldn't mind reviewing and helping it along at all, especially with how much stuff still needs fixing here.

@TwoSpacesSG
Copy link
Author

Hi, thank you for the response and clarifications. Regarding screen rotation, there are "2 types" of screen rotation on j2me, some phone versions of games are in "pseudo-landscape", they have you turn the physical phone sideways in order to play the game since the screen with the game is turned 90 degrees. I think Samsung did that or something but I'm not sure. Then on Nokia Series 60, there was a feature where you could turn on the accelerometer, and it would "flip" the screen, I don't know all the tech details (you should probably consult the docs for those, and it's probably implementation dependent between e.g. Symbian 9.2 and 9.3) but one of the things it does for sure is swap the values for width and height, WITHOUT rotating the image, which is the difference between those Samsung versions where the image is rotated, and you have to rotate the physical screen. I think Freej2me and KEmu 0.9.x have the physical screen rotation (though I might be wrong about freej2me), KEmu 1.0.3 replaces this with Series 60's way, and KEmnnmod has both ways, though it can get confusing if you use both ways at once lol.

@AShiningRay
Copy link
Collaborator

That's the thing, AFAIK in FreeJ2ME, some games do complain that you're not in the correct orientation if you boot it up at a given res (320x240 in some versions of Arcadius for example), but work perfectly fine just by switching to its swapped alternative on the list (in this case, 240x320), hence why i think having a dedicated setting to swap them would be, at most, an UX improvement.

Screen rotation in KEmulator, modded included, is kinda wonky from what i've seen. Basically using the "set screen resolution" menu option doesn't work well and i always have to set it from the device settings itself, where you're allowed to set the "emulated" phone and such.

Now, having a Gyroscope implementation is another matter entirely and i think it's a good idea, even if it's just to have a setting where we call its API to simply say that the emulated phone's been rotated for now, as FreeJ2ME lacks this JSR completely.

@TwoSpacesSG
Copy link
Author

Hi, saw your commit, nice stuff. Regarding 180x320, there was a Harry Potter game for the touch-screen Nokia 5800 or something (Order of the Phoenix, if memory serves right), which is a 360x640 phone, but the game is in 180x320, and in the manifest there's an attribute called something like "Nokia-MIDlet-Original-Display-Size: 180,320" which makes the phone upscale the game by two, to the native resolution (yes, S60 has a resolution change feature for j2me). Therefore I suggest to add both the vertical and horizontal variants (320x180) of this resolution, just in case more is discovered.

Turns out I also forgot 101x64 from monochrome Siemens phones: https://lpcwiki.miraheze.org/wiki/Siemens_M50 Although those fit into 101x80, there's a white bar at the bottom, so like with 176x220 and 176x208, it would be nice to add this one as well, sorry about that.

220x176: https://www.gsmarena.com/samsung_x820-1556.php (there are versions of games for it, such as Sonic Jump)

Also I see you added some canvas resolutions for games that don't display in full screen, such as 176x204 (and i think also 128x142?). That's an incredibly deep rabbit hole. Previously I've investigated it with some games and came up with some results. The chart below has a list of canvas resolutions, and then how many pixels you have to add to get the full screen resolution. Note that "softkey bar" refers to commands, which I'm not sure if those are implemented in FJ-p yet.

LG:
128x110 (Softkey Bar: 18)
128x148 (Status Bar: 12)
176x206 (Status Bar: 14)
240x298 (Keypad: 102)
240x304 (Status Bar: 16)
320x224 (Status Bar: 16)

Motorola:
128x96 (Status Bar and Softkey Bar: 32)
128x116 (Status Bar: 12)
128x131 (Status Bar and Softkey Bar: 29)
128x149 (Status Bar: 11)
176x182 (Status Bar and Softkey Bar: 38)
176x204 (Status Bar: 16)
240x267 (Status Bar and Softkey Bar: 53)
240x300 (Status Bar: 20)

(It is sometimes claimed that the last two are 240x266 and 240x299, maybe there is a discrepancy between models)

Sagem:
176x195 (Status Bar: 25)

Samsung:
128x112 (Softkey Bar: 16)
176x205 (Status Bar: 15)
240x297 (Status Bar: 23)

Sony Ericsson:
128x128 (Status Bar and Softkey Bar: 32)
176x176 (Status Bar and Softkey Bar: 44)
208x173 (Keypad: 147)

@AShiningRay
Copy link
Collaborator

Been finding out that there's quite a lot of variance in canvas resolutions as well. Seriously considering turning this whole thing into a "insert your resolution" menu just with some presets alongside it... problem is that this won't fly for libretro, too cumbersome to set on a controller. Although i'm definitely adding 220x176 as it's just a landscape version of another res that exists.

As for games that use the "Nokia-MIDlet-Original-Display-Size" property, it seems that most of the time this is used to scale games by a factor of 2, like the N80 where some games actually render in 176x208 and are then scaled to the phone's 352x416 (there's even a tool to modify 176x208 jars to scale up to 352x416 that way). For this, i think a toggle "scale canvas resolution by 2" that achieves the same effect would be better, since it'll be independent from the set screen res, and halving the screen resolution doesn't require FreeJ2ME to restart as it'll go from a higher res to a lower one that still fits 1:1 so no area gets cut.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants