BUG #59
Comments
You actually don't need to compile yourself anymore (that was the case on the original repo). The latest builds for cores and jars are all available at the links present on the README ;)
Did you restart the core after changing res? Because text does render incorrectly over here on the sample you sent, but only because i loaded FreeJ2ME at 240x320, and then set it to 128x128 ingame. If the game boots from 128x128 right away, there's no issues with text... That's why i noted in the core that a restart may be required, as some jars rescale fine, others not so much.
Noted. No idea what's happening with this one just yet, but i'll take a look this weekend or so, kinda short on time and my focus was on:
It should shortly, after i push a relatively big commit. This one was an incredible find, as it uses a ton of stuff not properly implemented in FreeJ2ME yet! Do note that it will exhibit flickering and tearing, because FreeJ2ME also doesn't implement buffering at the moment... but the critical stuff was sorted out and i could play a few stages without problem.
Yeah, that's pretty much the whole reason i opted to develop this emulator over KEmulator and J2ME Loader (SquirrelJME has a libretro core too, but it's in its infancy and is more of a JVM reimplementation). I don't tend to focus too much on the libretro aspect, but hopefully that'll change soon as the core's base functionality is getting there.
AFAIK this is exclusive to the libretro core, as it cannot load files with special characters right now, so it's not that this english name was too big (i have some jars here with MUCH bigger names), it's the underline... chinese characters also fall in this category. |
So we finally found a case where the handling null images has to be configurable. Boombakas Pro REQUIRES null images to throw an Exception in order to be playable, whereas House M.D. breaks IF an exception is thrown because it's buggy and doesn't handle NullPointerExceptions. So this basically means we now have the very first compatibility setting in FreeJ2ME. Also, Boombakas Pro checks for the "supports.mixing" sys property at boot and crashes if it is not present... which meant it was a good time to work around some sys properties that were missing beyond this one. Beyond that, this game also loads media files from a DataSource, so that had its implementation finished and tested. Aside from graphics flickering, the game seems to be perfectly playable now. Related to #59. Other than this, there were some minor fixes and cleanups that wouldn't warrant their own commit, like the DirectGraphics pixel format matching KEmulator and J2ME Loader, canvas invalidating the screen contents properly on a jar fullscreen change, etc.
This should allow it to load chinese chars and much more. Also related to #59.
This should allow it to load chinese chars and much more. Also related to #59.
Should be fixed now. Works on linux at least... hopefully it does on windows as well since the fix is on the Java end, not the C core. Edit: I've also noticed you have a CN-localized version of FreeJ2ME-Plus on your github. I've been wanting to make it multi-language for a while, both standalone and Libretro core... If you're interested, we can work towards that at some point, cause i have zero knowledge of chinese! |
There's been an issue for a while where JARs with accompanying JADs on Windows on AWT fail to load if the dir name has Unicode in it or something, not sure about the specifics of that though. Pipyakas: I have yet to try out the new build, but I did notice that the House MD fix slightly broke BreakQuest Mobile, now there was an additional blank image as part of the intro logos, which normally shouldn't be there. But on Nokia S60, both House MD and BreakQuest Mobile work correctly, how come? Is the flickering in that game related to issue #58 which involves flickering in a very large amount of game versions (right now it's by far the largest unfixed issue in FJ+)? Edit, forgot to mention, I guess I can help with the Russian translation when the need arises. |
That shouldn't be a problem anymore though. I've been loading chinese jads through AWT no problem, either directly, or as a companion to the jar.
Hard to know how nokia was treating those cases in their own S60 JVM, they could be creating a transparent 1x1 image for all i know, as it wouldn't write over what's on screen and it would keep things working unless the game really used the exception as part of its logic. But this is not MIDP2-compliant, which mandates that it should throw an exception. This kind of thing is the reason why i decided to make the null image handling into a compatibility setting. Now you can swap between the J2ME correct way of throwing an exception (disabled) or ignoring those null images and continuing along to fix games that are as buggy as some versions of House M.D (enabled). It's just not something you can properly "fix", as it depends entirely on the jar handling null pointer exceptions appropriately, like Break Quest and many others.
Haven't tested any of these yet (really should get on my desktop at some point) to confirm, but in this one, it's VERY jarring on the new game cutscene, though it's far less annoying during normal gameplay.
Nice! |
|
Thank you for the reply and the explanation. I don't really know what exactly makes it fail to load games with JADs then, will require additional testing some time later then. I got my hands on Boombakas Pro, and I can't really tell if it's related to the issue in games like Rayman Golf and Rayman Raving Rabbids TV Party, it could be. |
This was a coincidence XD
Thanks! Now it works fine on Windows too!
Wow, I'm more than happy to provide the translation!
Sorry, I didn't make this clear. |
Right out of the gate, massive optimization to Motorola's FunLights implementation, while the LCD color mask is also slightly faster by being integrated directly into the main render pass. Other than that, Display's callSerially() method for render synchronization has been overhauled to use a thread to process screen repaints instead of relying on a fixed timer interval, improving efficiency and performance by locking better to the game's intended framerate. Furthermore, Canvas now does the entire rendering pass before setting the "isPainting" flag to false, fixing flickering and, as of now, rendering serviceRepaints() kind of useless since repaint() will already run callSerially() if the jar requests a repaint while another is under way. Helps #58 and #59 (Boombakas Pro is fully playable and doesn't flicker anymore, same for the games presented by issue 58).
|
Disregard the commit above, it doesn't fix the issue you just posted on your latest message, it's aimed at fixing the flickering on Boombakas Pro (and A BUNCH of other stuff).
I see... so it's a font scaling issue then. Yeah, this one still needs some work on smaller screens. FreeJ2ME is working with the fonts already bundled in Java, but that doesn't mean it can't be improved... for starters it's smaller than it should be, and there's no filtering being applied, both of which can be extremely helpful for legibility. I'll see if i can get it sorted out today. |
Thins makes fonts much more readable at lower screen resolutions. Related to #59.
|
Just pushed a commit improving this. Here's how it looks like on my end (linux):
Didn't mess up other games at small resolutions and the forced filtering makes things more readable and easier on the eyes. |
|
For fun I checked the Chinese version of WALL-E, which also had very small text at 176x220, and this now looks nicer. I noticed that the GitHub Actions ran out of money or something? I messaged feos about that, but in the meantime on the latest build it's like this:
|
|
Man i really don't like github on my phone (had to restore that message since "edit" and "quote reply" are WAY too close to each other)... anyway.
Yeah, seems like it. Initially i got quite worried after receiving an email stating that a CI run failed right after pushing the changes and getting off to work, lol |
Thank you for your improvement. Now the display effect has been improved to a certain extent. The effect in your image is great, but it is still very difficult for me to achieve it here... I tried to install a Ubuntu in Virtualbox, but the end result still did not achieve the effect shown in the above image. Now it displays like this: P.S. : I also tried to install a Win10 VM, but the result was the same. |
|
Strange, it should be Antialiasing the font... i'll change the hint to Force-enable smoothing and push shortly. If that doesn't help, the only other alternative will be to apply filtering to the whole screen, which i don't think is ideal. |
Using the GASP hint makes it font-dependent, whereas ON should force AA regardless of the font. Might help with #59.
Thank you for your hard work! Now I can see every stroke of every word, very beautiful：) There's a slight blurring of the edges of the font, but that's okay because the 128/*128 resolution is just too small. I tested some 176/*220 or 240/*320 games and they all display the text perfectly! |
If there are special chars in any jar at those resolutions, it won't be readable at all, but i assume devs knew the size of the screen they were developing for. Will not break issue #59, since the issue there is exhibited on a 128x128 game.
|
Recently, I tried to complete all the games that had their bugs fixed. Games
Character encoding Other thoughts on why the game won't save: I will always test the game on FreeJ2ME. |
Quite a few games only work properly when the framerate is limited, so that's nothing out of the ordinary. AFAIK there's Racing Fever 2, Racing Fever GT, Johnny Crash Does Texas, Glider and a few others that are completely unplayable with unlocked framerate. On the topic of saves: Weird, i have a 240x320 version here (english) that appears to save properly. If i load it up, it still shows the last stage i stopped playing at (currently level 3 on retroarch, level 2 on standalone since their saves are separate). I wonder what's happening here...
Yeah that might be a problem, because while "-Dfile.encoding=UTF-8" is a valid workaround, it isn't a real fix for this. That would be rewriting anything that opens and saves files in FreeJ2ME to exclusively use the UTF-8 charset when doing so. That way users don't need to bother with this (at least i hope so). Problem is that there's a lot of different methods doing this kind of thing in the source code so it's not much of a priority at the time.
This one is complicated, because while it is possible to make FreeJ2ME do a sync save of RMS data to disk whenever you ask it to close, it won't be foolproof because users can just Ctrl+C from the terminal and kill it outright. Beyond that, we could also end up saving the RMS in an inconsistent or incomplete state, as we can't surely know why some games wait for an internal exit call to be issued in order to do it. As for FreeJ2ME Retroarch freezing... it does that on Win32 no matter how you close things. If you "Close content" it does that, if you restart it does that... but the good news is that FreeJ2ME itself closes just fine, it's the javaw wrapper process that keeps dangling around afterwards as a zombie process for some reason. |
Windows 10 X64 22H2 Bug Check Steps:
I recorded a test video: Youtube The versions in the test videos are all in Chinese, but the test results are similar to the English versions. P.S. : |
I have compiled the libretro core and placed it in RetroArch for Windows to use.
This is the bug I encountered.
BUG：
BUG explanation
This is the only J2ME core that can currently be used in RetroArch! Its imperfections are obvious, but I am very much looking forward to the further development of this project!
The text was updated successfully, but these errors were encountered: