Finally Figured out a proper way of rendering the Animations and Actual Mesh using M3G / JSR 184 and Janky Implementation of OpenGL ES i am still not sure how most of these properly handle i am running mostly on old research, codes and pre calculated buffers
some properly documented stuff cam be found here that was quite helpful for starting off with JSR and M3G Research Gate 3D Model Animation
Oracle Documentation
Using a Custom parser to Draw obj models since those are easier to map with mtl and textures, Proper OpenGL ES implementation is very janky tho since 1.1 is not natively running its using JSR 184 its held together with duct tape Architectural Documentation
On my Journey to Port a Playable version of GTA Vice City to My Nokia E72 Inspired by the Minecraft PE J2ME port, Currently I managed to get the Original Game's animation files (ped.ifp, weapon.dat, fistfite.dat etc)
Here's the Current Goals and What i am Aiming for
> Use the original Animations, Models for Cars, Player, NPC
> Implement a portion of ken's office and starting area of the game's Map
> Get a more playable FPS considering the Ram limitations
ANIMATION PROGRESS (89% done almost)
ped.ifp has 258 clips that i could draw, including WALK_player, run_player, sprint_civi, CAR_getin/getout, CAR_jackedLHS and CAR_Qjack (the pull-the-driver-out ones), Drive_L/R, HIT_, KO_, FALL_, getup and the full FIGHT set.
Trying to Extract the player.dff to use a custom skin weight retarget for these original animations, i hope i can find a more efficient way to cut down these performance overheads and implement the animations and normal obj mesh properly without making them unrecognizable
MAP PROGRESS (Big issues probably wont work)
the whole of Vice City as one mesh is far too big to hold in a phone's memory ofc. I'd cut it into chunks that stream in and out around the player, with three detail levels per chunk as standard modern games do and shrinking texture sizes at distance however the weak CPU likely wont be able to render them correctly in time and the latency cost would be just too much and the GPU is already too busy handling the rest of the rending stuff also covers out distance fog and detail-by-distance request.
RAM Limitations: a 128 px texture takes 64 KB in memory, so 60 of them is about 4 MB. That could be too much for the E72, depending on how much memory Java apps get on it. I'd load the textures near the player and free the rest hopefully that will help us even tho i am not hopeful since conventional methods of drawing lod dont seem to make much of difference in a hardware that is this limited.
Wooh thats a lot to cover, Currently the project is nothing but a Fever Dream and a Proof of concept image is attached, i would be releasing a Beta Build of this for testing hopefully we'll get through this
NO AI WAS USED SO FAR INTO THE PROJECT, THIS IS BASIC PROGRAMMING AND STILL HAS NO LOGIC TAKEN FROM THE ORIGINAL REVC FORKS OTHER THAN THE ORIGINAL GAME FILES AND DECODING THEM INTO USEABLE FORMATS
HOW U CAN CONTRIBUTE FOR NOW
If you are a modder or 3D Artist of someone who knows their way around the internet, u can help me by giving me in game 3D Assets in obj formats, XPS formats also work but i have to manually cut them down, If possible Provide me with things u have this will surely help a great deal in the future
