Closed linsmod closed 1 year ago
Hello. Do you know more about who is making this? I already did this last year for fun but I did not publish the solution. I was able to play a melee game on a Samsung S10+, as long as the map was small. So if we knew who is making this, I might be able to give them code to springload what they are doing so they do not waste time!
There are a few fatal typos in Warsmash for Desktop that make it stop working on Android LibGDX. The worst one was when we do a buffer bind and for some reason Android LibGDX uses the buffer only as a ByteBuffer but the desktop solution will do an instanceof check and find if it was passed a FloatBuffer and if so multiply the user specified size by 4. So there is some insane math going wrong for no reason on Android, and if Android was a focus it is possible to write the code that would work on both platforms. https://www.youtube.com/watch?v=oE8-DJ2EhYs
(Pardon the vulgarity in the second half of the video, but the first part is an interesting view of the technology)
We are trying to create the android version based on WarsmashModEngine project recently.
Actually, it should be rendered correctly, much code changes made on desktop version already broke the rendering. this android version is from the broken core.
I have not found out where the problem is. now the rendering problem is both on android and desktop. the main code is in the project WarsmashModEngine.core and shares to android and desktop. if one solved and another one should be ok. Now is trying to restart porting from the WarsmashModEngine-master code and keep it rendering game things correctly after every code changes.
An android-opengl lib is used to implement an AndroidOpenALAudio and AndroidOpenALAudioDevice. but it may does not work correctly... play() is called but no sound out from the phone's speakers.
Some third-party libs are used, and some code changes is made to implement the javax.awt.ImageIO and java.awt.image.BufferedImage for android. it works. typically, the android graphics packages should be used to handle this, but we have no idea how to use it with BufferedImage and JpegImageParser .
We use IDEA as development environment. would like to use pull request share works, want to keep the coding format style same as WarsmashModEngine, tried setup but failed. the code format function on IDEA comes with many unnecessary formatting changes, it makes the code merging not easy.
I was recently using IDEA for some fun and I tried to modify the settings to use a similar format. Generally most of WarsmashModEngine here was written with Eclipse with the automatic autoformat on save. So whenever I save, it will format the files. That way they were all in the same format without thinking. But a small number of the files were made while on vacation on a laptop without the same format settings, or sometimes with IDEA. But it seems that "Editor > Code Style > Java" in the IDEA has options that can try to match the code style of the original Eclipse format settings used on WarsmashModEngine. I changed a few checkbox values. You are right it is not the same, however.
Is your Android version on GitHub or did you do this privately? I have a private version that is not on GitHub but I could potentially put it onto GitHub. The private version of mine was highly modified. I did not use the java.awt.image.BufferedImage
fix for Android. Instead, because I just wanted a working demonstration, I created a new empty LibGDX game project and then pasted in code from WarsmashModEngine in pieces until it would work. And I skipped the desktop Java java.awt.image.BufferedImage
part. This meant two things:
units\human\footman\footman.png
bundled as a part of the Android APK for example. By doing this, LibGDX could load the texture without using Warsmash specific code, so it was easier to do.PathTextures\2x2Simple.tga
or whatever from the original game) I converted these also to PNG. That way again there was no BufferedImage
. This meant that the core
stuff with the simulation
java package that does game logic based off of building red and green squares on the ground had to change in the game logic. So for Android I tried to use Pixmap class from LibGDX. Using the Pixmap for this purpose was supposed to be better I thought, but it always had a problem. When I was on my Android playing the game if I would chop down a tree, the process that removes the tree pathing map from the ground and redoes the image blitting was loading the Pixmap in an improper way and causing a tremendous lag. I stopped and never investigated the reason why.So, rather than to use BufferedImage
on the android port that I tried to make last year, I simply entirely replaced the code that used that so instead it would use a LibGDX class Pixmap that is Android compatible. But this means that my version did not have BLP parser. So it was less Warcraft supporting. It would only work with the Melee maps and ingame unit models. Even the war3mapMap.blp
minimap file from the w3x
would fail to load. So the minimap was empty (solid black).
I think instead of BufferedImage if you really want this to work on Android, maybe it is best to make a BLP plugin for LibGDX. That way, you can skip BufferedImage class entirely and go straight from a BLP in a file and then parse it into an OpenGL texture.
Because my android port was made in the manner described above, this was destructive to the Git history. It branched off and then later when I updated WarsmashModEngine, the folder on my hard drive WarsmashMobile that was like a test did not also update. So it is trapped in time in the 2022 summer version of WarsmashModEngine and is one year behind.
Maybe you could reformat the entire project with IDEA all at once in an automated way, and then forever after the code would match whatever IDEA style you were using?
I'd like to share the dev progress:
can shows the background in a not much correctly drawing in MenuUI, do not know where the problem is. and meet another problem, CPathfindingProcessor will OOM on phone. my testing case: load the small map: Booty bay in single player mode.
some coding or changes before this: 1) upgraded libgdx to 1.11, few code changes. 2) packed google awt and image decoding stuffs into to another jar, bufferedImage and imageio then can works on phone, with blp and tga parsing support. 3) store the glsl codes to files and put it to assets, created gles3.2 version copy and fixed runtime errors. 4) auto convert blp to png and store in file format as a cache when trying to decode a blp resource. this speeded up the loading. 5) new key-value config style and its parsing adaption to easy locating mpq files on android filesystem external storage.
KvStyle=1 [DataSources] MpqPath="${EXTERNAL_STORAGE_ROOT}/war3files/" MapPath="${EXTERNAL_STORAGE_ROOT}/war3files/Maps/" MpqFile="war3.mpq,War3x.mpq,War3xlocal.mpq,War3Patch.mpq"
class BlpTexture is replaced to BlpGdxTexture. and it works fine now in BLPHandler .
@Override protected void load(final InputStream src, final Object options) { ResourceInfo info = (ResourceInfo) options; try { Pixmap pixmap = ImageUtils.getPixmap(info); final Texture texture = new Texture(pixmap); setFilter(texture); setGdxTexture(texture); } catch (final IOException e) { throw new RuntimeException(e); } }
pixmap works in 2d drawing. but it not working in 3d like in class GroundTexture, the buffer size not equal to it pix size (w*h). then errors.
size not equal to it pix size cause offset invalid in buffer.position() method:
width = pixmap.getWidth(); height = pixmap.getWidth(); buffer = pixmap.getPixels();
do not know how to resolve it, have to kept bufferedimage in there now. google-awt-imageio decoding is much slower than pixmap, even in desktop.
code is uploaded. https://github.com/lintrust/WarsmashModEngine-Android
We are new here to game development and may need more time find out solutions to problems if touch the technical details such like OpenGL, rendering and algorithms.
The previous works you made on targeting it to android should be helped; may could be merged if possible.
Hello. Do you know more about who is making this? I already did this last year for fun but I did not publish the solution. I was able to play a melee game on a Samsung S10+, as long as the map was small. So if we knew who is making this, I might be able to give them code to springload what they are doing so they do not waste time!
There are a few fatal typos in Warsmash for Desktop that make it stop working on Android LibGDX. The worst one was when we do a buffer bind and for some reason Android LibGDX uses the buffer only as a ByteBuffer but the desktop solution will do an instanceof check and find if it was passed a FloatBuffer and if so multiply the user specified size by 4. So there is some insane math going wrong for no reason on Android, and if Android was a focus it is possible to write the code that would work on both platforms. https://www.youtube.com/watch?v=oE8-DJ2EhYs
(Pardon the vulgarity in the second half of the video, but the first part is an interesting view of the technology)
Hi~ I'd like to hear what the insane is. these screenshots are from my phone. still rendering problem.
Interesting project~