Trying to port gzdoom-me-gec-maint1.9 to Android.

[BrutalDoomisAwesome]

I'm trying to port gzdoom-me-gec-maint1.9 to Android by using Freedoom-for-Android which is a port (GZDoom-for-Android) of a port of (OpenGames).

 

I've done a github repo just using the jni files with a modfyied version of gzdoom-me-gec-maint1.9 with the code from emileb's freedoom_for_android_gz1.9.

 

I'm using the github workflows and it came up with the error 

 

jni/gzdoom/src/p_user.cpp:1900:38: error: 'operator|' is a private member of 'TFlags<ActorFlag>'
                !(player->mo->flags & MF_NOGRAVITY | player->mo->flags2 & MF2_FLY))//[GEC]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm using x86 x86_64 armeabi-v7a as the CPU arch.

[Graf Zahl]

Put the two single bit tests into parentheses. The expression as written is not correct but apparently did not error out when it was added to the code. In current GZDoom that line does not exist anymore.

 

[BrutalDoomisAwesome]

I know I may sound stupid. But I have no clue where the two single bit tests are.

[drfrag]

!((player->mo->flags & MF_NOGRAVITY) | (player->mo->flags2 & MF2_FLY)))//[GEC]

 

[BrutalDoomisAwesome]

3 hours ago, drfrag said:

!((player->mo->flags & MF_NOGRAVITY) | (player->mo->flags2 & MF2_FLY)))//[GEC]

 

Did it exactly how you have it but it came up with the same error. Maybe this might help clear it up.

 

jni/doom/src/p_user.cpp:1900:40: error: 'operator|' is a private member of 'TFlags<ActorFlag>'
                !((player->mo->flags & MF_NOGRAVITY) | (player->mo->flags2 & MF2_FLY)))//[GEC]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
jni/doom/src/tflags.h:97:28: note: declared private here
        template<typename X> Self operator| (X value) const { return Self::FromInt (Value | value); }
                                  ^

 

Edited October 8, 2021 by BrutalDoomisAwesome

[Graf Zahl]

22 minutes ago, BrutalDoomisAwesome said:

Did it exactly how you have it but it came up with the same error. Maybe this might help clear it up.

 

jni/doom/src/p_user.cpp:1900:40: error: 'operator|' is a private member of 'TFlags<ActorFlag>'
                !((player->mo->flags & MF_NOGRAVITY) | (player->mo->flags2 & MF2_FLY)))//[GEC]
                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
jni/doom/src/tflags.h:97:28: note: declared private here
        template<typename X> Self operator| (X value) const { return Self::FromInt (Value | value); }
                                  ^

 

Replace the '|' with '||'.

Makes me wonder how this managed to slip through into a public repo. The code is just broken as written.

 

 

[BrutalDoomisAwesome]

 

1 hour ago, Graf Zahl said:

Replace the '|' with '||'.

Makes me wonder how this managed to slip through into a public repo. The code is just broken as written.

 

 

Thanks, p_users compiled bit then it stoped on gl/scene/gl_flats.cpp

 

jni/gzdoom/src/gl/scene/gl_flats.cpp:186:3: error: use of undeclared identifier 'nearPt'; did you mean 'nearPt2'?
                nearPt = pos + tmpVec;
                ^~~~~~
                nearPt2
                  
jni/gzdoom/src/gl/scene/gl_flats.cpp:141:8: note: 'nearPt2' declared here
Vector nearPt2, up, right, t1;

 

[Graf Zahl]

In the current GZDoom source that variable is called nearPt.

I'm a bit puzzled here. What kind of source is this to contain such errors?

[RetroAkaMe]

1 minute ago, Graf Zahl said:

In the current GZDoom source that variable is called nearPt.

I'm a bit puzzled here. What kind of source is this to contain such errors?

A source of a guy trying to do something without no experience.

[Gibbon]

1 minute ago, RetroAkaMe said:

A source of a guy trying to do something without no experience.

Looks like it, the syntax is just wrong

[Kizoky]

45 minutes ago, RetroAkaMe said:

A source of a guy trying to do something without no experience.

You've gotta start somewhere.

[Redneckerz]

53 minutes ago, Graf Zahl said:

In the current GZDoom source that variable is called nearPt.

I'm a bit puzzled here. What kind of source is this to contain such errors?

The DZDoom source, id wager.

 

52 minutes ago, RetroAkaMe said:

A source of a guy trying to do something without no experience.

Harsh words, but true words. This is not to villify the OP, but judging by the response i can tell that this isn't his umpteenth foray into coding.

 

6 minutes ago, Kizoky said:

You've gotta start somewhere.

That usually does not involve trying to port over a heavily source-customized engine of an old GZDoom build to a port of GZDoom that's also not up to date and for which you need to replace the rendering effects with GLES equivalents.

 

There is ambition, and there is sense. This is a case where sense triumphs ambition. Why not port Linux Doom over or start at a reference port?

[BrutalDoomisAwesome]

 

1 hour ago, Redneckerz said:

2 hours ago, Graf Zahl said:

In the current GZDoom source that variable is called nearPt.

I'm a bit puzzled here. What kind of source is this to contain such errors?

The DZDoom source, id wager.

It's Pre-DZDoom stage.

 

 

1 hour ago, Redneckerz said:

2 hours ago, RetroAkaMe said:

A source of a guy trying to do something without no experience.

Harsh words, but true words. This is not to villify the OP, but judging by the response i can tell that this isn't his umpteenth foray into coding.

 

Don't worry about it. plus I know I suck. But it everybodies gotta try sometime no matter if their out of their element.

 

 

And here's the code it's referencing too.

 

https://github.com/7dog123/gec/blob/2ef07c85488795a47d03fb57b8c9187baa3fc20f/jni/gzdoom/src/gl/scene/gl_flats.cpp#L141

 

https://github.com/7dog123/gec/blob/2ef07c85488795a47d03fb57b8c9187baa3fc20f/jni/gzdoom/src/gl/scene/gl_flats.cpp#L186

Edited October 8, 2021 by BrutalDoomisAwesome

[ketmar]

lol, it's so broken on non-m$ compilers… (and on newer m$ compilers too, i guess).

 

2op: not the best codebase to start with. it is simply and plainly broken.

[Gibbon]

1 hour ago, ketmar said:

lol, it's so broken on non-m$ compilers… (and on newer m$ compilers too, i guess).

 

2op: not the best codebase to start with. it is simply and plainly broken.

Indeed.  OP: if you want to learn, it is better to start with something that works rather than something that is broken.  This is for your own motivation.

[Redneckerz]

10 hours ago, BrutalDoomisAwesome said:

 

It's Pre-DZDoom stage.

We call it DZDoom because thats how most folks remember it anyway. A new version of DZDoom is in development.

10 hours ago, BrutalDoomisAwesome said:

 

 

Don't worry about it. plus I know I suck. But it everybodies gotta try sometime no matter if their out of their element.

You are better off starting off with the original codebase and work from there.

10 hours ago, BrutalDoomisAwesome said:

 

 

2 hours ago, Gibbon said:

Indeed.  OP: if you want to learn, it is better to start with something that works rather than something that is broken.  This is for your own motivation.

DZDoom works on the intended platform. Since the new DZ will likely drop GZDoom as its codebase, any Android port would slso be outdated anyway.

[ketmar]

23 hours ago, Redneckerz said:

DZDoom works on the intended platform.

it doesn't mean that its code is not… broken ;-) in some interesting ways. in its current state you basically have two codebases there: one is more-or-less working for the one specific configuration, and another, non-working one, for different configuration. which makes the whole codebase unreliable.

 

sure, it may work for the original author, and i didn't meant that it cannot work. i meant that for OP purposes this codebase can be considered "broken". i meant no offences to the original author, sorry.

Edited October 10, 2021 by ketmar

[Redneckerz]

1 hour ago, ketmar said:

it doesn't mean that its code is not… broken ;-) in some interesting ways.

Lets say every codebase is broken because every codebase is known to have bugs. No codebase is ever bugfree :)

1 hour ago, ketmar said:

in its current state you basically have two codebases there: one is more-or-less working for the one specific configuration, and another, non-working one, for different configuration. which makes the whole codebase unreliable.

DZDoom was never intended to run on ARM. In light of the OP i see this as being ambitious to a fault. Its best to start else where.

 

[ketmar]

On 10/10/2021 at 1:11 PM, Redneckerz said:

DZDoom was never intended to run on ARM.

it's not about ARM: it is broken even on the intended architecture if you change the compiler to mingw, for example. which is fine… but why the code contains ifdefs for non-supported compilers then, and why those ifdefs are not subtly broken, but sometimes simply syntactically/semantically incorrect? if you're targeting the specific compiler, and changing some code that is ifdefed, then there is no reason to keep the old and broken parts at all. it is just a messy coding, and i myself would avoid using such codebase if possible.

Edited October 16, 2021 by ketmar

[CBM]

8 minutes ago, ketmar said:

it's not about ARM: it is broken even on the intended architecture if you change the compiler to mingw, for example. which is fine… but why the code contains ifdefs for non-supported compilers then, and why those ifdefs are not subtly broken, but sometimes simply syntactically/semantically incorrect? if you're targeting the specific compiler, and changing some code that is ifdefed, then there is no reason to keep the old and broken parts at all. it is just a messy coding, and i myself would avoid using such codebase if possible.

shouldnt somebody refactor that codebase and remove all the ifdefs that targets unsupported compilers?

 

as well as any code that is syntactically and/or semantically incorrect when using mingw?

 

 

[Redneckerz]

1 hour ago, ketmar said:

it's not about ARM: it is broken even on the intended architecture if you change the compiler to mingw, for example. which is fine… but why the code contains ifdefs for non-supported compilers then, and why those ifdefs are not subtly broken, but sometimes simply syntactically/semantically incorrect?

I recall that Erick/Gerardo had this discussion before and i don't feel it necessary to do a course of grading Doom programmer's coding skills by one another. It will just lead to quarrels that nobody gets better from.

1 hour ago, ketmar said:

if you're targeting the specific compiler, and changing some code that is ifdefed, then there is no reason to keep the old and broken parts at all. it is just a messy coding, and i myself would avoid using such codebase if possible.

Then again it isn't your codebase, as you are working on your own, so that's atleast convienient.

1 hour ago, CBM said:

shouldnt somebody refactor that codebase and remove all the ifdefs that targets unsupported compilers?

 

as well as any code that is syntactically and/or semantically incorrect when using mingw?

Why? that DZDoom build will be not developed either way.

[CBM]

39 minutes ago, Redneckerz said:

Why? that DZDoom build will be not developed either way.

 

Fair point.

[ketmar]

54 minutes ago, Redneckerz said:

i don't feel it necessary to do a course of grading Doom programmer's coding skills by one another

i failed to made myself clear yet again, sorry. what i meant is "this codebase is not in a good shape, alas", not "authors of this port are bad programmers". there are plenty of reasons why it could end up like that (you really should look at some of my projects to see what Really Bad Code looks like ;-). nobody's obliged to deliver ideal code, especially for free. sorry again, didn't mean to personally attack anyone.

Edited October 16, 2021 by ketmar

[Redneckerz]

5 hours ago, ketmar said:

i failed to made myself clear yet again, sorry. what i meant is "this codebase is not in a good shape, alas", not "authors of this port are bad programmers". there are plenty of reasons why it could end up like that (you really should look at some of my projects to see what Really Bad Code looks like ;-). nobody's obliged to deliver ideal code, especially for free. sorry again, didn't mean to personally attack anyone.

Not everyone can write perfect code.

[Graf Zahl]

1 hour ago, Redneckerz said:

Not everyone can write perfect code.

 

That doesn't help the next person who wants to work with that code. The code is bad, so it is not optimal to work with.

 

[Redneckerz]

2 hours ago, Graf Zahl said:

That doesn't help the next person who wants to work with that code.

Why arent you tagging the creators of said port along then?

2 hours ago, Graf Zahl said:

The code is bad, so it is not optimal to work with.

Luckily nobody has to.

[Graf Zahl]

WTF are you trying to say here?

 

Is is no longer allow for reasons of politeness to point out that a certain code base has issues that make it difficult to work with?

 

[ketmar]

yes, i'm with Graf here. i don't see anything wrong in talking about the codebase. we are not making assumptions about authors here, but we also not obliged to run to the authors and tell 'em about this too. Red, you're definitely trying to die on some hill, but please, show us that hill first, maybe there are actually no things to argue about? ;-)

 

p.s. and you (Red) said several times that this codebase is discontinued, so there are even less reasons to make bugreports against it.

Edited October 17, 2021 by ketmar

[Redneckerz]

2 hours ago, Graf Zahl said:

WTF are you trying to say here?

That you may want to tag @Erick194 or Gerardo194 regarding these compiler issues with the codebase. That's the WTF i am trying to say here.

Perhaps they can pick up something from someone with a more seasoned reputation with the ZDoom/GZDoom codebase (Namely, you).

 

2 hours ago, ketmar said:

p.s. and you (Red) said several times that this codebase is discontinued, so there are even less reasons to make bugreports against it.

Unless there are some great suggestions that could be picked up from it for the next project - presumably LZDoom - based.

 

Else the code remains bad.

[Gibbon]

Thing is, yes while we shouldn't just bash code for being bad.  I think it helps in this case.  I mean, just look at those issues from the beginning of the thread.  Any half decent programmer wouldn't have butchered it like that and pushed it to a public repo.  I wouldn't be able to sleep at night if I did that.

 

It also helps the OP to know just what state it is in, you don't want to spend so much time only to find out you've only scratched the surface of the rabbit hole.