What the heck happened to Doom Touch/D Touch??

On 2017-03-17 at 9:32 PM, Danfun64 said:

The main problem with using GZDoom-GPL is that for obvious reasons, FMod support was removed, and i'm not sure you can run OpenAL in Android. Also, you might want to look at QZDoom-GPL (available here), which is attempting to restore the Software renderer to GZDoom-GPL.

Much as I love someone plugging for me, I would actually advise against that. The software renderer does not run well on ARM devices at all - and probably won't until the ARM platform matures a bit, or we have a chance to optimize it a bit more.

 

I just went through the trouble of fixing GZDoom-2.5/3.0 on Raspberry Pi - and it does not run well at all. :( Even when instructed to compile for NEON. (Sorry, I know that breaks support for first gen Pi's, but to be honest, I don't think it's even runnable on RPi1 anyway)

 

Beloko was right to use GZDoom-GPL as a base, in its current form, because porting that to GL-ES will ultimately lead to better performance of the engine and the renderer.

Edited by Rachael

Posted (edited)

Share this post


Link to post

Which of the GL renderer paths is it using? If its using the full path with render buffers and post processing effects, then it creates the scene buffer in rgba16f format. Might be worth reducing that to rgba8 maybe if its in ES mode.

 

Also, I did some initial work on OpenGL ES detection, which is currently in the master branch of GZDoom. Not sure how that related to what you're doing and how much it can be merged back. Having the main renderer fully OpenGL ES aware would be nice.

1 person likes this

Share this post


Link to post
43 minutes ago, dpJudas said:

Which of the GL renderer paths is it using? If its using the full path with render buffers and post processing effects, then it creates the scene buffer in rgba16f format. Might be worth reducing that to rgba8 maybe if its in ES mode.

 

Also, I did some initial work on OpenGL ES detection, which is currently in the master branch of GZDoom. Not sure how that related to what you're doing and how much it can be merged back. Having the main renderer fully OpenGL ES aware would be nice.

At the moment it's just using the old fixed GL2 render path using GLES1 with a compatibilty layer, very minimal changes to the render code. A true GLES2 render path would be better and I guess would give more opportunity for optimisations etc.

1 person likes this

Share this post


Link to post

IMHO playing Classic Doom on touchscreen is kinda BDSM.

Share this post


Link to post

Edit: Disregard this, I derped

Edited by gnudist

Posted (edited)

Share this post


Link to post

How is the development going so far beloko?

Share this post


Link to post
2 hours ago, DoodGuy said:

How is the development going so far beloko?

Not too bad, performance is OK now (same as previous version). I have had to disable models for time being as they use mapped buffers which are not support by the version of gles (will fix). I see GZDoom-GPL is now not being update so need to decided if moving to the real gzdoom repo.

2 people like this

Share this post


Link to post

GZDoom-GPL was pretty much just a few commits to remove the non-GPL-compliant code and then merging in from the GZDoom master, anyway. That should be even easier now that it's adopted QZDoom (you probably still won't be much interested in the software renderer for mobile devices, but if you are, more power to you, it's going to take a pretty beefy one to run it well though).

 

So basically, fork GZDoom-GPL as it is now, then downstream the current GZDoom's master, and you should be able to continue where GZDoom-GPL left off - and that should be mergeable into your fork.

1 person likes this

Share this post


Link to post
On 27.3.2017 at 10:49 PM, beloko said:

I see GZDoom-GPL is now not being update so need to decided if moving to the real gzdoom repo.

It depends on what you want to do. The main difference, aside from removing the incompatible OPL code is that it replaces all graphics in gzdoom.pk3 which are derived from the supported games (e.g. the crouched player, Doom's BigFont or the flashing inventory arrows.

 

None of these would pose a problem if the purpose of your app is to play those games the graphics are from - the original Doom license allowed shipping modified assets, as long as they were meant to be used with the game they are from, it is only an issue if the engine is used to run an independent commercial game (that is, aside from the Wolfenstein dogs, when going GPL with GZDoom this is something I'd seriously consider replacing entirely.)

 

Long term I'd prefer to see GLES support in the main repo anyway, it's important not only for Android but also for Raspberry Pi, although I'd expect all these platforms to transition to Vulkan eventually.

 

3 people like this

Share this post


Link to post

@Graf Zahl I'd suggest going the PrBoom-Plus route and have a switch for building both non-free and free (and maybe mixed for cases like the dogs) .pk3 files.

Edited by Danfun64

Posted (edited)

Share this post


Link to post

@beloko I love having Doom on my Android device! I have a bit of feedback though regarding the touch stick input for movement. For me it's really hard to maintain consistent positioning and directions because I often can't mentalize where the center is, so I never know how far to put the stick in any direction for slower movement or to just stop while keeping my thumb on the screen. Adding a dead zone marker for a visual reference of where it is would help a lot imo.

Share this post


Link to post
12 hours ago, NecrumWarrior said:

@beloko I love having Doom on my Android device! I have a bit of feedback though regarding the touch stick input for movement. For me it's really hard to maintain consistent positioning and directions because I often can't mentalize where the center is, so I never know how far to put the stick in any direction for slower movement or to just stop while keeping my thumb on the screen. Adding a dead zone marker for a visual reference of where it is would help a lot imo.

Hey, there is no fixed centre on the two movment pads, when you put your thumb on the screen it resets the the centre to that position. I find when I am playing I very often lift and place my thumb quickly to reset the centre - try doing this. However I can add an option to place a dot where the current centre is so you can visually see it, good idea.

 

Share this post


Link to post
1 hour ago, beloko said:

Hey, there is no fixed centre on the two movment pads, when you put your thumb on the screen it resets the the centre to that position. I find when I am playing I very often lift and place my thumb quickly to reset the centre - try doing this. However I can add an option to place a dot where the current centre is so you can visually see it, good idea.

 

Yeah, I had a feeling that was the case. It's just something I'm really not used to, so it's hard for me to adjust and the game feels way harder as a result. When I'm in a fight I won't want to lift my finger, and sometimes I might need to stop just as part of the strategy. My brain is so hard wired to WASD that I just need the little bit of extra help, so yeah something like that would be very helpful. Thanks for listening!

Share this post


Link to post

Try playing with bluetooth gamepad, it's much more comfortable. Takes some time to properly set up, but after that it's a bliss. Portable Guncaster and Demonsteele? Yes please <3

1 person likes this

Share this post


Link to post

I just wonder how GZDoom 2.3 will run on mobiles. My i5 processor on my PC lags at VANILLA when I have bloom and lens distortion on

Share this post


Link to post

It goes without saying that a mobile can't run it at the same graphical settings as a high end desktop PC. As for your PC having trouble with the bloom pass, I think that says more about your PC really:

 

Performance at 1080p on a NV 980:

1.33 ms (748 fps) no bloom, no lens
2.04 ms (490 fps) bloom
2.15 ms (465 fps) bloom + lens

Bloom cost at 1080p: 0.71 ms
Lens cost at 1080p: 0,11 ms

 

As you can see, the lens pass is almost free, and the bloom pass isn't particular expensive. I originally developed the bloom code when I owned a NV 270, and it never became a problem for me even back then.

Share this post


Link to post

Quick question about QTouch Beloko, do you have any idea why doesn't Rygel's texture pack work on DP but works on FTE engine?

Share this post


Link to post
20 hours ago, DoodGuy said:

I just wonder how GZDoom 2.3 will run on mobiles. My i5 processor on my PC lags at VANILLA when I have bloom and lens distortion on

What kind of graphics card do you have? Those features are solely dependent on graphics hardware.

Share this post


Link to post
2 hours ago, Graf Zahl said:

What kind of graphics card do you have? Those features are solely dependent on graphics hardware.

Some AMD card which name I always forget with 1GB VRAM

Share this post


Link to post

So, I found out why PrBoom+ takes so long to load up when music is involved. The damn 55mb soundfont kept being loaded, even though I set it to use OPL2 only.

 

That 55mb soundfont lowers my fps by 5-10 on PrBoom+, and GZDoom is unplayable because of the lag it produces. This is only when music is turned on and Fluidsynth is used to do so.

 

I asked for a smaller soundfont, and thanks to @rdwpa, I'm using this 3mb soundfont over that 55mb one: https://www.dropbox.com/s/e7y8w0nzv2i3rtw/gm2.sf2?dl=0

 

GZDoom is now playable with music on (I've been playing with music disabled this whole time, so this is big) and PrBoom+ loads  up much more faster now.

 

I think you should change the soundfont provided with this one, as it's less CPU heavy to use.

 

 

Edited by Voros
1 person likes this

Posted (edited)

Share this post


Link to post

That makes me wonder. How can a sound fount have such an effect on performance, even if the associated MIDI synth isn't even used?

I can run GZDoom with 100MB sound fonts and have no issues.

 

What's your system specs?

 

1 person likes this

Share this post


Link to post

Looks like a single core CPU - which would make all the difference with FluidSynth which is not particularly efficient.

That library can easily hog an entire core even on a good desktop with the wrong sound font - of course that would not much affect overall performance much if the game can run on another core.

 

 

Share this post


Link to post
13 hours ago, Voros said:

So, I found out why PrBoom+ takes so long to load up when music is involved. The damn 55mb soundfont kept being loaded, even though I set it to use OPL2 only.

 

That 55mb soundfont lowers my fps by 5-10 on PrBoom+, and GZDoom is unplayable because of the lag it produces.

 

I asked for a smaller soundfont, and thanks to @rdwpa, I'm using this 3mb soundfont over that 55mb one: https://www.dropbox.com/s/e7y8w0nzv2i3rtw/gm2.sf2?dl=0

 

GZDoom is now playable with music on (I've been playing with music disabled this whole time, so this is big) and PrBoom+ loads  up much more faster now.

 

I think you should change the soundfont provided with this one, as it's less CPU heavy to use.

 

 

Thanks for the this info, as Graf says it's very strange it should effect performance so much even when not being used?! I'll try that sound font out and will probably replace the one big I'm using. I have an old HTC desire I can test with which looks similar spec to that device. 

Share this post


Link to post
On 3/30/2017 at 6:59 AM, R13 said:

Try playing with bluetooth gamepad, it's much more comfortable. Takes some time to properly set up, but after that it's a bliss. Portable Guncaster and Demonsteele? Yes please <3

Late response but, yeah I actually plan on getting one but I need to save for a car right now so the one I want has to wait. I am slowly adjusting to it though, even if I can't play nearly as well as I do on PC.

1 person likes this

Share this post


Link to post

Hey guys,  I've got a GPD XD Android portable but Doom Touch just doesn't control very well on it.  It has built in controls that the console treats as an xinput device.  No matter what I do with the settings I always have on-screen buttons and the controls won't map properly at all.  Movement is 'glitchy' and twitchy.

 

Anyone any ideas how to make the game play smoothly with xinput controls?  The main reason I bought the GPD was to play Doom on the go with proper controls... It's driving me nuts!

Share this post


Link to post
6 hours ago, Average said:

Hey guys,  I've got a GPD XD Android portable but Doom Touch just doesn't control very well on it.  It has built in controls that the console treats as an xinput device.  No matter what I do with the settings I always have on-screen buttons and the controls won't map properly at all.  Movement is 'glitchy' and twitchy.

 

Anyone any ideas how to make the game play smoothly with xinput controls?  The main reason I bought the GPD was to play Doom on the go with proper controls... It's driving me nuts!

Hi, firstly are you using the gamepad tab to configure it? Looks something like: device-2014-08-03-010649.png

 

 

I'm not sure what xinput means with regards to Android, I expect the gamepad to be mapped to normal Gamepad events present in Android (MotionEvent ect)

 

Do the buttons/axis work with test apps such as https://play.google.com/store/apps/details?id=ru.elron.gamepadtester&hl=en_GB ?

 

Share this post


Link to post

Is that bug of the bundled Chocolate Doom fixed? I mean, screenblocks setting will not stick and will revert to the default value, even if the user edits directly the DEFAULT.CFG file to change it.

Share this post


Link to post
1 hour ago, beloko said:

 

So is this gonna be a new app or just a big update?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now