About M3G support

[nikita36078]

You can find the full m3g engine source here: https://github.com/SymbianSource/oss.FCL.sf.app.JRT/blob/master/javauis/m3g_qt/javasrc https://github.com/SymbianSource/oss.FCL.sf.app.JRT/blob/master/javauis/m3g_qt/src https://github.com/SymbianSource/oss.FCL.sf.os.graphics/blob/master/m3g/m3gcore11/src I hope it helps :-)

[hex007]

@recompileorg This might help.

[recompileorg]

This is fantastic. If I had the time, I'd knock this out myself. Maybe around the new year.

Though this would make a great project for someone. It's big, but not too complicated. A great way to contribute something significant without needing to learn much of the code base or risk breaking anything.

[Florin9doi]

What's about the licence?

[hex007]

@Florin9doi Refer to this https://github.com/SymbianSource/oss.FCL.sf.app.JRT/blob/master/legalnotice.txt

[barteo]

Back in 2010, I implemented M3G (JSR-184) as a commercial project. This library was built on top of https://github.com/barteo/microemu and used JOGL. If there is an interest I can relicense it to open source license to match freej2me and contribute the code.

[hex007]

@barteo That would be great. Thanks. @recompileorg What do you think?

[recompileorg]

That would be fantastic. I was just happy to see anything that could reduce the ambiguity of the documentation.

[barteo]

@hex007 @recompileorg Please take a look at the source code and let's talk later whether you think it would be possible to integrate this code into the project.

In c-microemu-jsr-184-common/thirdparty.txt, there are listed dependencies with other licenses.

jsr-184-m3g.zip

[vadosnaprimer]

Guys you're causing me tears of happiness. A year ago I forked the entire PhoneME repo from Java's site. They released it under GPL. I have it converted to git here: https://github.com/PhoneJ2ME Also converted their site hosted in the repo: https://phonej2me.github.io/ It has detailed building instructions, just in case.

Basically, it's Sun's and Java's full emulator for j2me, but there's not a single download link to its binaries on google anymore, and this year they also killed the site as well, with the entire repo. Thank God I have it all. The original project got adopted by these: http://davy.preuveneers.be/phoneme/ https://sourceforge.net/projects/pspkvm/ Which kinda proves that one can make a headless build out of it, which is more or less what libretro wants. Since packages in it can be easily added, maybe it'd make sense to switch to PhoneME for libretro, or just borrow their Java classes.

What I'm getting at, the critical package that is missing from that project is m3g, because it belongs to Nokia, and they never opensourced it, they just provided the source code to examine and reimplement. And now their site is dead as well. But fortunately, I have a couple of backups of their m3g package taken from some obscure ftps belonging to some obscure universities.

Also, I forked some implementations of m3g from other projects: https://github.com/vadosnaprimer/swingme/tree/master/me4se/opt https://github.com/vadosnaprimer/matos-profiles/tree/master/matos-midp-msa/src/main/java/javax/microedition/m3g (this one seems to be just stubs) https://github.com/vadosnaprimer/desktop-m3g https://github.com/vadosnaprimer/java-m3g

Lastly, I decompiled KEmulator Lite (which emulates perfectly my main test game, Rally3D), as well as related jars from Nokia SDK for S60. The latter is likely already presented in the Symbian source. After comparing these to my forks above, ALL these versions of m3g are completely different, so if one wants to make sure the version he uses is a free reimplementation, and not accidentally original property of Nokia, I don't know of any ways to verify this anymore.

[jan-kleks]

@vadosnaprimer It probably does not matter, but just in case I will mention that there is also a GP2X version of PhoneME.

[vadosnaprimer]

@jan-kleks I don't see any links to the emulator there. Just to the game.

[jan-kleks]

@vadosnaprimer The link is in the bottom. "Finished packaging it for the GP2x (Gamepark) with PhoneME for j2ME..."

[vadosnaprimer]

@jan-kleks

Just to the game.

[jan-kleks]

@vadosnaprimer Here's another link. You can find changes to the original codebase in the "source" directory.

Hmm... I don't have a GP2X, but I'm almost sure that the author of the blog (the previous link) has created a bundle which consists of this racing game + the emulator (with his own fixes, so it's like a more "updated version"), otherwise the game wouldn't be playable on the GP2X... Never mind. :)

[jan-kleks]

@vadosnaprimer Okay, I think I have found the latest version with changes to the source code included.

[vadosnaprimer]

BTW the actual license of Symbian's m3g is Eclipse Public License v1.0:

https://github.com/SymbianSource/oss.FCL.sf.app.JRT/blob/master/javauis/m3g_qt/javasrc/javax/microedition/m3g/AnimationController.java

It can't be used with GPL, but maybe there's a way to link them at runtime?

[recompileorg]

The best thing to do would be to document m3g, which is doable given what we have, then re-implement everything in pure java.

It would probably be better if we had at least two people involved. One person to document the API (preferably JavaDoc style, but anything is better than just some source code) and another person to do the implementation strictly from the documentation.

I've had m3g stubbed out for a while. I even have a few of the more obvious things implemented. If anyone wants to document everything, I'd be happy to do the implementation.

[vadosnaprimer]

How detailed are such docs allowed to be? Also, all implementations I've seen do most of the functions differently, so it's unclear which one is better.

[recompileorg]

There typically isn't anything prescriptive about the implementation in the documentation, nor should there be. When you do see something like that, it's usually something like a standard algorithm, so that certain guarantees about the output can be assumed by the user.

An example in reverse: I have some pretty big changes in the pipe to the m3d implementation, though it will have little effect on the output, save fixing some rendering errors. I haven't documented what we know about it so far (lazy!) though when I do it wouldn't make sense to specify, for example, what method to use to fill a polygon.

[LeLocTai]

With respect, I think it unrealistic to expect other people to do documentation like you said. People contribute to open source projects for one of 2 reason:

• Enjoyment
• Pad resume

Its difficult enough to get people to document their own code, so enjoyment is out. Resume padder usually only work for famous projects, so they're also out.

I think the realistic way forward is to aim to make 1 popular game work. The implementation might not be complete or correct, but it would pull in contributors, or at least give us some meaningful goal to chase. I never played any 3d games back in the day, so someone else got to do the suggestion part ¯_(ツ)_/¯.

[recompileorg]

@LeLocTai Unrealistic or not, we have a volunteer. It's also the only practical solution to the problem. We need our implementation to be isolated from the only reference to the API we have available to us.

Your suggestion will not work as we don't have any information about the API in question other than someone else's implementation.

Thanks for the needless criticism and for volunteering to do nothing to contribute. Feel free to make similar contributions to other people's projects. I'm sure they'll be welcome.

[LeLocTai]

It is great that we have a volunteer. I am simply making a suggestion, not a criticism. The reason being that the project was abandoned for a year, so I'm guessed its from lack of interest.

[recompileorg]

The project was not "abandoned for a year" Hell, this thread wasn't even "abandoned for a year"! We've had actual people make real suggestions and even contribute code as recently as last week.

What they didn't do was tell us that we're too stupid to attract volunteers and we should instead follow your suggestions, even though you're completely unwilling to do anything to contribute yourself.

Here's a suggestion for you: Don't criticize the work of others based solely on what you've "guessed" about a project you know virtually nothing about.

A much better approach would be to ask if any progress has been made and tell us why you're looking forward to M3G support. (Though your first post suggests that you have no interest in M3G support, so I have no idea why you're posting here anyway).

[LeLocTai]

Well, I think either we have some cultural different, or you are not in the best mood right now. I'm not criticising you or the project. My understand of "suggestion" is like "idea" or "proposal", which is can be implemented or not, based on considerations from you guys.

You are correct that I'm not particularly interested in m3g, but more about the project as a whole. This issue interest me since it is complex, and I don't want to work on something complex without establishing some coordination first.

Anyway, I'm not looking for unnecessary discussion, so my participation to this conversation end here.

[vadosnaprimer]

Speaking of docs, this isn't what you mean @recompileorg? m3g-specification-1.1.zip

[recompileorg]

@vadosnaprimer -- I don't know where you found it, but it's fantastic! I'll start on it asap.

[vadosnaprimer]

Probably here. http://fivedots.coe.psu.ac.th/Software.coe/J2ME/M3G/ They have some more stuff, like Reference Implementation binaries.

[recompileorg]

I better get to archiving!

[XerTheSquirrel]

The technical specification of M3G is rather impressive! As the developer of SquirrelJME it would be interesting for there to be an open source implementation of M3G which could be plugged into various JVMs.

I wish you luck with this!

[recompileorg]

Thanks. I hope to get some time over the holidays to get it up and running.

I'm actually a little surprised that you're interested in whatever we can put together. I figured you'd want to implement a lot of M3G in native code -- something our project just can't reasonably do.

Still, I'm a big fan of SquirrelJME. I'm glad that we can be of some help.

[vadosnaprimer]

Any luck with this one so far?

[crwxrws]

I spent a few days implementing some of the M3G classes and methods in pure Java, and I have succeeded in making a 3D game playable.

Currently it's in proof-of-concept stage - it's only rendering a wireframe and semi-transparent faces, and it's rather memory unfriendly. I based the implementation on the m3g-specification-1.1.pdf document found in this thread.

I would like to share my progress with you all, once I clean it up a bit. A fair warning: this is my first time implementing 3D rendering, so there's probably plenty of room for improvement.

[recompileorg]

@crwxrws That's fantastic! I can't wait to see what you've accomplished.

It's great to see new contributors, particularly on M3G support. My time is very limited and I've felt a lot of guilt over the lack of attention I've paid to this after all the work others have put in to finding usable documentation. I stubbed it out and just never got back to it. I've glad someone picked it up.

Don't worry about your code. You have a wire frame rendering, which means you're most of the way there. Even in wire frame, there will be a lot of people very happy to see their favorite games running.

I have quite a bit of experience with 3d graphics, so I'm happy to help you get memory use under control and get you started on filled polys and textures if you need a hand.

[crwxrws]

@recompileorg Thank you for the kind words!

I have just published my changes at: https://github.com/crwxrws/freej2me/tree/impl-m3g

I made two commits. The first one includes implementations for: Camera, IndexBuffer, Transform, TriangleStripArray, VertexArray, VertexBuffer. These should be almost completely following the spec document. The second commit includes a partial implementation of Graphics3D, this is where the main rendering method is.

I have only implemented the parts of Graphics3D that are required for the game I am testing with, so other games might not work just yet. Since I am rather busy myself, I cannot promise further progress, but I am definitely interested in putting more work into this. I think a good next step would be to get clipping, the depth buffer, and texturing to work, and if I really get stuck I might reach out to you, @recompileorg, but I enjoy learning on my own, so I will start with that. :)

[crwxrws]

I wanted to mention that once we have a pretty complete Java implementation, I would be happy to experiment with a native port. For best portability I assume C would be ideal. Additionally, I wonder if we can leverage OpenGL and/or Vulkan in some way.

I believe multiple implementations (backends) could exist, and the best one could be selected at runtime to do the job. This way the Java implementation could be the always available fallback, while alternative, better performing backends could be optional. Of course we're a bit far from that right now, but it doesn't seem unachievable.

[recompileorg]

@crwxrws If you decide to do a non-java implementation, you might want to coordinate with @XerTheSquirrel who heads up the SquirrelJME project.

https://github.com/SquirrelJME/SquirrelJME

It's an absolutely amazing project with their own JVM implementation.

[crwxrws]

@recompileorg Thanks! That looks like quite a big project.

I have implemented texturing, finally. No blending yet, but clipping works properly, as well as the depth buffer. I think it's time for some screenshots. The first one is from the wireframe-only version, and the second one is from the current version. Code is available in the same branch.

[crwxrws]

I have noticed that there are different 3D APIs in J2ME, or at least there is Micro3D, which is also mostly just stubs at the moment. Since there is considerable overlap between the two, I was thinking that I could put most of the 3D code in its own unit, and use it as a backend for both M3G and Micro3D. This would also allow for a better code structure, and if we decide to have a native implementation, then it would be enough to implement this backend in native code, and it could work with both M3G and Micro3D.

I wanted to ask what you think about this, if it aligns with your ideas of the project and if you think there is a better way to go about it. :)

[recompileorg]

@crwxrws Nice work! It's really coming along.

I'd strongly recommend against trying to "unify" the various 3D APIs.

m3g, m3d, micro3d, and m3d(O) are all very different. While they seem to do the same thing, they're not similar enough to easily share anything between. Even some things you'd think could easily be shared, like vector and matrix functions, are different enough that it doesn't make sense to try to make them share the same code.

Take a look at what's been implemented in Util3D and Vector3D in com.mascotcapsule.micro3d.v3 and I think you'll see what I mean. For another example, m3d(0) inverts the colors textures from how that image type treats them elsewhere (com.nokia.mid.m3d.Texture.java). I'm sure there are a lot of other oddities like that which would needlessly complicate attempts to generalize 3d graphics.

I expect things will be easier for future maintainers if we keep the code for the various 3D APIs completely separated. If, after everything is implemented and stable, it appears there is some common functionality that makes sense to factor out, we can revisit it them. Otherwise, I fear that we'll ultimately be introducing needless complexity without any clear and obvious benefit.

[XerTheSquirrel]

I would say a pure Java version, albeit at a loss of performance would be good for references and be a bit more portable across different JVMs.

For SquirrelJME, all of the various 3D APIs I plan to build on top of OpenGL ES. Then initially I will be implementing a software based OpenGL ES implementation. Once that is done I would then be adding hardware acceleration support through a simplified OpenGL ES interface.

[crwxrws]

Very well, that all makes sense. That's why I asked. :) That said, I will remain focused on M3G for now. I hope to get it feature complete in a timely manner.

Indeed the software-based OpenGL ES sounds like a good idea. After all, M3G inherits a lot from OpenGL 1.3.

[vadosnaprimer]

Very well, that all makes sense. That's why I asked. :) That said, I will remain focused on M3G for now. I hope to get it feature complete in a timely manner.

Indeed the software-based OpenGL ES sounds like a good idea. After all, M3G inherits a lot from OpenGL 1.3.

Hi! Any news? :)

[crwxrws]

@vadosnaprimer I wish! A full-time job has pretty much taken over my life. I would love to see this get finished, though. And I would be happy to work on it, assuming I have the time and energy.

@AShiningRay Sorry for not reacting to your mention. I'm happy to hear that my incomplete implementation has significant impact. Regarding my code... it probably shows that this is my first time messing with 3D graphics, and that I rarely write Java.

@vadosnaprimer @AShiningRay I would like to improve the maintainability and completeness of the code. I wonder if discussing it in a more chat-like environment would be a good idea? Anyone up for it?

[AShiningRay]

@vadosnaprimer I wish! A full-time job has pretty much taken over my life. I would love to see this get finished, though. And I would be happy to work on it, assuming I have the time and energy.

@AShiningRay Sorry for not reacting to your mention. I'm happy to hear that my incomplete implementation has significant impact. Regarding my code... it probably shows that this is my first time messing with 3D graphics, and that I rarely write Java.

@vadosnaprimer @AShiningRay I would like to improve the maintainability and completeness of the code. I wonder if discussing it in a more chat-like environment would be a good idea? Anyone up for it?

Rather busy these last few days, but sure... i don't think i'll be able to help much in regards to M3G though.

[crwxrws]

@AShiningRay

i don't think i'll be able to help much in regards to M3G though.

Alright, I will try to handle the M3G specifics by myself.

I've thought about my approach. Previously I really wanted to provide a nearly complete M3G implementation in one go. But if I aim for that, realistically I will never finish it. So I decided to focus on smaller chunks.

Right now I'm working on the Loader class. It handles the deserialization of the M3G file format. Some games use it, some don't. I think it's a good start, because once it's ready, it will allow us to use more games for debugging, with proper objects and fewer nulls.

I already had an ugly implementation on a local branch, but I'm rewriting it in a way that fits better.

[vadosnaprimer]

Awesome to hear!!!

[crwxrws]

Update: the Loader is coming together.

Of course it's not all in that one source file. I added a few classes to javax.microedition.m3g.load to keep things organized. I can move them elsewhere if desired.

I think most of the messier details are done, and now it's just some repetitive implementation in each M3G class. I'm adding an extra constructor to each M3G class with a single Deserializer parameter that helps with loading data from M3G files.

[vadosnaprimer]

Woohoo nice!!

[mrDoctorWho]

m3g seems to be already properly implemented in a fork: https://github.com/zb3/freej2me. Looks like the author has ported some stuff from Symbian OS and other emulators (like J2ME Loader).

[AShiningRay]

m3g seems to be already properly implemented in a fork: https://github.com/zb3/freej2me. Looks like the author has ported some stuff from Symbian OS and other emulators (like J2ME Loader).

It has no hope of being merged into master though, license's not compatible, and it also relies on external libs, whereas main FreeJ2ME has been pushing for a 100% java implementation for better portability. Tons of stuff there that's just external libs being shoved into the project.

Not saying that's a bad approach by any means, just that the way things are there now, there's no chance of any of them being merged due to licensing issues and requirements for arch-specific binaries for a ton of stuff.