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

[Rachael]

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 March 22, 2017 by Rachael

[dpJudas]

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.

[beloko]

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.

[riderr3]

IMHO playing Classic Doom on touchscreen is kinda BDSM.

[gnudist]

Edit: Disregard this, I derped

Edited March 27, 2017 by gnudist

[DoodGuy]

How is the development going so far beloko?

[beloko]

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.

[Rachael]

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.

[Graf Zahl]

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.

 

[Danfun64]

@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 March 29, 2017 by Danfun64

[NecrumWarrior]

@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.

[beloko]

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.

 

[NecrumWarrior]

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!

[R13]

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

[DoodGuy]

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

[dpJudas]

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.

[DoodGuy]

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?

[Graf Zahl]

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.

[DoodGuy]

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

[Voros]

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 April 3, 2017 by Voros

[Graf Zahl]

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?

 

[Voros]

It's only when the soundfont is used that cause fps drop. Other than that, it runs fine.

 

http://www.gsmarena.com/zte_blade_iii-4983.php

[Graf Zahl]

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.

 

 

[beloko]

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. 

[NecrumWarrior]

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.

[Average]

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!

[beloko]

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: 

 

 

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 ?

 

[beloko]

 

[Diabolución]

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.

[DoodGuy]

1 hour ago, beloko said:

 

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