search

mkrupczak3 / Freedoom-for-Android

Freedoom with GZDoom for Android
GNU General Public License v2.0
88 stars 16 forks source link

Some project cleanup and updates #34

Closed TacoTheDank closed 5 years ago

TacoTheDank commented 5 years ago
TacoTheDank commented 5 years ago

Yeah, I got the email. I'm SUPER new to coding in general, so honestly I would most likely be of no actual help. I can certainly try, though.

mkrupczak3 commented 5 years ago

Gotta start somewhere I guess. I've looked at some of your personal projects, and I'm grateful to be getting some help from someone with more experience than I in android projects. TBH this codebase is still a bit of a mess.

Some of this submodule stuff was giving me a big headache earlier, and I'm really glad you came in and fixed it. I thought at the time that the MobileTouchControls repo that I sourced from was dead, but I may have been mistaken. If this update works, it would really improve the usability of this app with better controls.

@TacoTheDank One question before I merge: Did all of this build and still work on android 5/6 devices? If so, I may put all this together, make a quick commit with some zdoom.ini changes, and push out a new version.

mkrupczak3 commented 5 years ago

Eh, I'll merge and test it on my local environment. I'll just do a roll back if I have any issues.

Again, thanks for the help. Even if this may not seem like much, the update of touch-controls could significantly improve the user experience of the 450,000+ downloaders of this app.

mkrupczak3 commented 5 years ago

@TacoTheDank I'm getting a bunch of build errors in Game.java, the portion of the java code that interfaces with touch controls and the moga controller. I'm not technically savvy enough to know what's going on here, but my guess is that beloko has done a lot of refactoring on both his java code and his C++ touch controls module since my upstream's fork was made.

So far, it looks like the touch controls are working, but the moga controller stuff isn't. I'm going to do some digging.

mkrupczak3 commented 5 years ago

It looks like the "com.bda.controller" symbols aren't being found in the Game.java code, and this may be because either the location of the com.bda.controller.jar file was moved or the code was refactored since my upstream was made. This may just be an easy fix of pointing the code toward the correct location for the jar file.

mkrupczak3 commented 5 years ago

Ok, so it looks like there's some stuff from here: https://github.com/mkrupczak3/GZDoom-Android/tree/77d7e38960634f82d9e9f74c3ac3f9fe9efa666c/TouchControls

That needs to be added into the submodule to make it play nicely with the project. After that, the java stuff (including Game.java) should compile. Similiar edits may need to be added to the other modules, but idk. My brain is pretty fried right now, so I'm going to put this off until later. You're welcome to take a stab at it if you're up to it.

Let me know if you get it building. If we can't get it to build, I might eventually revert the merge, move and move this to another branch.

TacoTheDank commented 5 years ago

I don't know how it affects 5/6 devices, I only have an Android Pie lol.

I think I fixed the missing symbols https://github.com/mkrupczak3/GZDoom-Android/commit/e2a56ff58baca53fa8819027d05703e684d50cce

I checked all the java code and it seems to recognize it now.

TacoTheDank commented 5 years ago

@mkrupczak3 I hope you don't mind, but I'm going to re-arrange the java files according to a .editorconfig, because checking through several files, there are alternating patterns of tabs and spaces, along with other inconsistencies that makes the code harder to read.

Do you prefer tabs or spaces? And would you like to keep opening brackets on new lines, or does it not matter (.editorconfig doesn't have an option for this specifically)?

mkrupczak3 commented 5 years ago

Eh, I like spaces over tabs (usually 4 to an indent) and brackets on the same line.

Code clean-up would be great. Also, was it building with your changes?

TacoTheDank commented 5 years ago

I'll need to check. You do ./gradlew build, right?

mkrupczak3 commented 5 years ago

Uhh, that might work.

I use android studio just because of how big the project is. You may need to set up the native developer kit to compile the gzdoom and audio binaries before the rest will compile though

Instructions for setting up the ndk can be found via googling and in the project read me. There's a accept called build.SH, you'll need to use cygwin on Windows, and you may need to edit the script a bit if you're on Linux or mac

mkrupczak3 commented 5 years ago

So, I just tested recently without doing any recompilation on the C/C++ portions and it builds.

I'm going to push out an update with just your cleanup stuff and a few tiny UI and config fixes. The code is going to be very fragile for a bit, so please don't put anything on the master branch for a bit without a pull request.

The next step will be to recompile all of the submodules (including the ones you reintegrated) using the NDK, then bug fixes if any compile errors crop up with the new submodule versions.

I've been kind of afraid to touch this stuff for a while, NDK builds can be quite fragile. The C/C++ code has needed to be looked at for a while though now, so I think now would be a good opportunity to add in the new compile targets that will be required to publish on google play (64 bit arm, arm v8, etc.) starting August 1st

TacoTheDank commented 5 years ago

Here's the build results, because why not:

JTM@DESKTOP-EN5LSGN MINGW64 ~/StudioProjects/forked/github/GZDoom-Android (master)
$ ./gradlew build
Starting a Gradle Daemon, 1 incompatible Daemon could not be reused, use --status for details

> Task :touchcontrols:compileReleaseJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :doom:compileReleaseJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: C:\Users\JTM\StudioProjects\forked\github\GZDoom-Android\doom\src\main\java\net\nullsum\freedoom\Utils.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :doom:lint
Ran lint on variant debug: 148 issues found
Ran lint on variant release: 148 issues found
Wrote HTML report to file:///C:/Users/JTM/StudioProjects/forked/github/GZDoom-AnWrote XML report to file:///C:/Users/JTM/StudioProjects/forked/github/GZDoom-And
> Task :touchcontrols:lint
Ran lint on variant release: 84 issues found
Ran lint on variant debug: 84 issues found
Wrote HTML report to file:///C:/Users/JTM/StudioProjects/forked/github/GZDoom-Android/touchcontrols/build/reports/lint-results.html
Wrote XML report to file:///C:/Users/JTM/StudioProjects/forked/github/GZDoom-Android/touchcontrols/build/reports/lint-results.xml

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.4.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 3m 44s
106 actionable tasks: 55 executed, 51 up-to-date

I just realized you also tested. I'll keep that here anyway.

I believe arm v8 and 64 bit are the same thing: "arm64-v8a" is what it's called, as opposed to "armeabi-v7a" (which I think is 32 bit).

Here's the documentation for this in general: https://developer.android.com/distribute/best-practices/develop/64-bit NDK documentation: https://developer.android.com/ndk/guides

TacoTheDank commented 5 years ago

Also, why not fork https://github.com/nvllsvm/jpeg8d and maintain it for the project? Think it'd be good.

Also also, you should enable issues for the project.

mkrupczak3 commented 5 years ago

Ah okay.Good idea on the jpeg8d fork. It might also be worth forking from nvllsum's upstream rather than his version since his version is dead.

To enable issues, I'd have to delete the repo and remake it as a standalone rather than a fork of nvllsum's. Since his is dead, I think now would be a good time for that though. Might be worth doing after the new stuff is compiled and working on arm v8. Commit history would still be intact.

mkrupczak3 commented 5 years ago

I'll take more of a look at this later tomorrow

TacoTheDank commented 5 years ago

Alright. I have a few suggestions in the form of a wall of text.

First, re-publish GZDoom-Android under an organization (that we both have access to) specifically created for GZDoom-Android (call it GZDoom-Android, I guess), and add the maintained library forks to the new organization as well (read the second paragraph). After this, archive THIS repository so no more changes can be made, but it will be kept for historical purposes.

"Fork" (get rid of the fork affiliation, but keep the git history) nvllsum's openal-soft-android and jpeg8d (to the new organization, of course), since they're both archived. After the GZDoom-Android repository has been created in the organization, delete "touchcontrols" from the organization's GZDoom-Android repository and turn it into its own repository in the organization (which we'll re-integrate as a submodule in GZDoom-Android's root).

Honestly, I personally think that this project is hopelessly too far behind in its compatibility with newer GZDoom versions 3.x.x and 4.x.x, and not being able to support many WADs that are made for these newer versions (this is something I've seen some complaints about in this app's Google Play reviews), as well as the tons of bug fixes and performance improvements (and other stuff) that came with these newer versions. With the codebase already as fragile as it is with the limited updates we CAN make, and with all the deprecated code, I feel that the best plan of action to be able to update the entire project without going through the horrible endless suffering that is "dependency hell" (which WILL happen if we try to upgrade it in its current state) is to just completely rebuild the app from the ground up using GZDoom 4.x.x as the base, and only integrating third-party libraries that are actually necessary, so we don't end up with so many libraries in jni. The newer base will also allow for much easier support integration with arm64-v8a. If we were to do all this, I would suggest creating an entirely new branch (gzdoom_4.x.x or something similar) with no commits on it for these changes, similar to this, with the plan being that once the entire project is finally updated, we will then make that branch the default, with the older "master" branch kept for historical purposes. Of course, the versioning system for such changes should be from what it currently is (0.x.x) to 2.0.0-alphaX (first testing of new changes, probably super buggy), 2.0.0-betaX (after many bugs have been ironed out and the app runs relatively well), etc. Of course, to not screw over everyone using the app, this would need to be a Google Play beta program (that you should totally set up when this eventually happens btw).

I think this will make this project much easier to maintain in the long run, even if it doesn't look that way right now. Believe me, if I had the know-how to make it happen, I would. But because I currently don't, a lot of this will likely rest entirely upon you.

I use parentheses too much lmao, hopefully this made some sense. Also, it would be cool to see this app in F-Droid.

mkrupczak3 commented 5 years ago

Just read your email, and after reconsideration I think your suggestions are on point. I don't know if I have the stamina yet for a full app rebuild, but something needs to happen in that kind of way. I might take a break from this project for a few days.

My long term goal has been to eventually ask Beloko for his code once I feel the project is in a good place to rebase. I think getting his GPL codebase (if he complies with the license) would give a good starting point, or even a completely new point to base a new version of the app off of.

My vision for this app was to have something that was simple, free, and open source that would let people play doom on their lunch break. I really want to add in a idgames wad browser that uses something like the reddit algorithmhttps://medium.com/hacking-and-gonzo/how-reddit-ranking-algorithms-work-ef111e33d0d9 to allow ranking and show recently added popular wads. I have a small DigitalOcean server I could run a container on for a backend if necessary. I think doing something like this would ultimately be pretty simple in Java code without breaking anything, and would make the app much more engaging allowing people to play small individual level wads whenever they have a quick minute of spare time. I'd really like to do something like this before making any breaking engine changes. If we do this first, it would be pretty easy to add back in with a rebuild.

I don't know for sure, but I think Most wads out there work with GZDoom 2.0. I think the problem reviewers have is with GZDoom mods.

I think you're absolutely right for re-publishing GZDoom-Android under an org and forking some of those repos. This would make maintenance easier.

The GZDoom 4.0 transition is hanging like an anvil , It needs to happen. Eventually this engine is going to be hopelessly out of date and incompatible with everything being released. Thankfully the 1993 game is the "lingua franca" giving some kind of standard, but eventually the community will drift too far apart.

For now, I'd like to focus on recompiling what we've got so far for Arm64-v8a, re-publishing GZDoom-Android and doing the forks like you've suggested, and adding in the wad browser and rating system. Once all this is done, I think that would be a very good minimum viable product for a "play doom on your lunch break" app, and then a more concerted effort could be put towards a rebuild, using code from beloko if possible.

On 6/6/2019 11:44 PM, TacoTheDank wrote:

Alright. I have a few suggestions in the form of a wall of text.

First, re-publish GZDoom-Android under an organization (that we both have access to) specifically created for GZDoom-Android (call it GZDoom-Android, I guess), and add the maintained library forks to the new organization as well (read the second paragraph). After this, archive THIS repository so no more changes can be made, but it will be kept for historical purposes.

"Fork" (get rid of the fork affiliation, but keep the git history) nvllsum's openal-soft-android and jpeg8d (to the new organization, of course), since they're both archived. After the GZDoom-Android repository has been created in the organization, delete "touchcontrols" from the organization's GZDoom-Android repository and turn it into its own repository in the organization (which we'll re-integrate as a submodule in GZDoom-Android's root).

Honestly, I personally think that this project is hopelessly too far behind in its compatibility with newer GZDoom versions 3.x.x and 4.x.x, and not being able to support many WADs that are made for these newer versions (this is something I've seen some complaints about in this app's Google Play reviews), as well as the tons of bug fixes and performance improvements (and other stuff) that came with these newer versions. With the codebase already as fragile as it is with the limited updates we CAN make, I feel that the best plan of action to be able to update the entire project without going through the horrible endless suffering that is "dependency hell" (which WILL happen if we try to upgrade it in its current state) is to just completely rebuild the app from the ground up using GZDoom 4.x.x as the base, and only integrating third-party libraries that are actually necessary, so we don't end up with so many libraries. The newer base will also allow for much easier support integration with arm64-v8a. If we were to do all this, I would suggest creating an entirely new branch (gzdoom_4.x.x or something) with no commits on it for these changes, similar to thishttps://github.com/k0shk0sh/FastHub/tree/fasthub/fasthub-v5, with the plan being that once the entire project is finally updated, we will then make that branch the default, with the older "master" branch kept for historical purposes.

I think this will make this project much easier to maintain in the long run, even if it doesn't look that way right now. Believe me, if I had the know-how to make it happen, I would. But because I currently don't, a lot of this will likely rest entirely upon you.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/mkrupczak3/GZDoom-Android/pull/34?email_source=notifications&email_token=AGCQEX7UUG2K4LC2QPOVNJ3PZHKRDA5CNFSM4HT7N2L2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEYQIQ#issuecomment-499746850, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGCQEXYBJ6DWAJUVPWUIOU3PZHKRDANCNFSM4HT7N2LQ.

TacoTheDank commented 5 years ago

All of that makes perfect sense to me 👍

From what I can see here, you already have forked a DOOM WAD browser app. Perhaps we can just use this as a separate app, rather than implementing the browser into Freedoom (unless it's missing some functionality that you'd like to add).

The funny thing about all this is that I've never even played DOOM, lol. I just find emulators and emulator-like apps super cool, and I like seeing what they are capable of and what can be improved upon.

(On an unrelated note, yeah my email address is stupid, I made it when I was 12 lol)

mkrupczak3 commented 5 years ago

I think the problem with a seprate app is that file permissions are REALLY strict in later versions of android. Cross-app file access is a no-go. Having to copy over files manually is also a bummer from the user's pov.

I really think a ranking system with the reddit algorithm could really increase user engagement. Freedoom itself is kind of meh, but being able to play user wads is the main goal. There'd need to be some frontend code and some kind of back-end server.

So ultimately I'd like to in the near future:

Recompile for v8a

Clean-up forks per your suggestions

Simple wad browser

Rich wad browser with ratings

New version of app on Gzdoom 4.0

EDIT: hotfix should be made to fix bug/ improve first time user experience

TacoTheDank commented 5 years ago

...being able to play user wads is the main goal.

Yep.

And file access is only getting more restrictive anyway.

https://www.androidpolice.com/2019/04/08/scoped-storage-in-android-q-beta-2-limits-how-apps-can-access-files/ https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/ https://9to5google.com/2019/04/25/scoped-storage-will-be-optional-beginning-with-android-q-beta-3/

So ultimately I'd like to in the near future: Recompile for v8a, clean-up forks per your suggestions, simple wad browser, rich wad browser with ratings, new version of app on Gzdoom 4.0

Beautiful list 👍