Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i_w3 library fails to work on Linux, BSD and macOS #96

Closed
atsb opened this issue Dec 24, 2022 · 12 comments
Closed

i_w3 library fails to work on Linux, BSD and macOS #96

atsb opened this issue Dec 24, 2022 · 12 comments

Comments

@atsb
Copy link
Owner

atsb commented Dec 24, 2022

Compilation errors, and after fixing, a new error is below:

********* ERROR *********
R_InitSprites: Sprite PLAY frame A has rotations and a rot=0 lump

Unfortunately, all code must be compatible with all 5 supported Operating Systems (Including Intel and M1 macOS systems). Currently, the build is broken on anything that is not Windows.

I think this should be looked at again.

@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 24, 2022

Compilation errors, and after fixing, a new error is below:

********* ERROR *********
R_InitSprites: Sprite PLAY frame A has rotations and a rot=0 lump

Unfortunately, all code must be compatible with all 5 supported Operating Systems (Including Intel and M1 macOS systems). Currently, the build is broken on anything that is not Windows.

I think this should be looked at again.

Weird, it was designed to work properly with other platforms

@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 24, 2022

maybe it´s just the bash files.

@atsb
Copy link
Owner Author

atsb commented Dec 24, 2022

I fixed the bash file because the c file wasn't there. It is a bit weird. But we can look into this after the holidays, no huge rush. A good amount of debugging would probably show an obvious issue somewhere, perhaps types again. It is very sensitive to these things.

@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 24, 2022

I fixed the bash file because the c file wasn't there. It is a bit weird. But we can look into this after the holidays, no huge rush. A good amount of debugging would probably show an obvious issue somewhere, perhaps types again. It is very sensitive to these things.

ok, just like i imaginated.

@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 24, 2022

Try again, now.

@atsb
Copy link
Owner Author

atsb commented Dec 24, 2022

In file included from deh_main.c:24:
i_w3swrapper.h:58:9: error: unknown type name ‘uint8_t’
   58 | typedef uint8_t  w3suint8_t;
      |         ^~~~~~~
i_w3swrapper.h:59:9: error: unknown type name ‘uint16_t’
   59 | typedef uint16_t w3suint16_t;
      |         ^~~~~~~~
i_w3swrapper.h:60:9: error: unknown type name ‘uint64_t’
   60 | typedef uint64_t w3suint64_t;
      |         ^~~~~~~~
i_w3swrapper.h:104:1: warning: parameter names (without types) in function declaration
  104 | void w3ssleep(usecs);
      | ^~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:58:18: error: conflicting types for ‘w3suint8_t’; have ‘uint8_t’ {aka ‘unsigned char’}
   58 | typedef uint8_t  w3suint8_t;
      |                  ^~~~~~~~~~
In file included from deh_main.c:24:
i_w3swrapper.h:58:18: note: previous declaration of ‘w3suint8_t’ with type ‘w3suint8_t’ {aka ‘int’}
   58 | typedef uint8_t  w3suint8_t;
      |                  ^~~~~~~~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:59:18: error: conflicting types for ‘w3suint16_t’; have ‘uint16_t’ {aka ‘short unsigned int’}
   59 | typedef uint16_t w3suint16_t;
      |                  ^~~~~~~~~~~
In file included from deh_main.c:24:
i_w3swrapper.h:59:18: note: previous declaration of ‘w3suint16_t’ with type ‘w3suint16_t’ {aka ‘int’}
   59 | typedef uint16_t w3suint16_t;
      |                  ^~~~~~~~~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:60:18: error: conflicting types for ‘w3suint64_t’; have ‘uint64_t’ {aka ‘long unsigned int’}
   60 | typedef uint64_t w3suint64_t;
      |                  ^~~~~~~~~~~
In file included from deh_main.c:24:
i_w3swrapper.h:60:18: note: previous declaration of ‘w3suint64_t’ with type ‘w3suint64_t’ {aka ‘int’}
   60 | typedef uint64_t w3suint64_t;
      |                  ^~~~~~~~~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:63:21: error: conflicting types for ‘byte’; have ‘w3suint8_t’ {aka ‘unsigned char’}
   63 | typedef w3suint8_t  byte;
      |                     ^~~~
In file included from deh_main.c:24:
i_w3swrapper.h:63:21: note: previous declaration of ‘byte’ with type ‘byte’ {aka ‘int’}
   63 | typedef w3suint8_t  byte;
      |                     ^~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:64:21: error: conflicting types for ‘word’; have ‘w3suint16_t’ {aka ‘short unsigned int’}
   64 | typedef w3suint16_t word;
      |                     ^~~~
In file included from deh_main.c:24:
i_w3swrapper.h:64:21: note: previous declaration of ‘word’ with type ‘word’ {aka ‘int’}
   64 | typedef w3suint16_t word;
      |                     ^~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:65:21: error: conflicting types for ‘dword’; have ‘w3suint64_t’ {aka ‘long unsigned int’}
   65 | typedef w3suint64_t dword;
      |                     ^~~~~
In file included from deh_main.c:24:
i_w3swrapper.h:65:21: note: previous declaration of ‘dword’ with type ‘dword’ {aka ‘int’}
   65 | typedef w3suint64_t dword;
      |                     ^~~~~
In file included from doomtype.h:36,
                 from deh_main.c:28:
i_w3swrapper.h:104:1: warning: parameter names (without types) in function declaration
  104 | void w3ssleep(usecs);

That is with the wrapper C file in build.sh and with no other changes.

@atsb
Copy link
Owner Author

atsb commented Dec 27, 2022

Still hapens on both DGL PR and master. I will debug why this happens. Maybe some code that needs hardening.

@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 27, 2022

Still hapens on both DGL PR and master. I will debug why this happens. Maybe some code that needs hardening.

Weird since x64 was working

@atsb
Copy link
Owner Author

atsb commented Dec 27, 2022

My guess is Linux and Mac don’t work for some reason due to a difference in width depending on windows or unix

@atsb
Copy link
Owner Author

atsb commented Dec 29, 2022

I'll close this and we can come back to it when we are ready to backport into stable / it works well enough that I'll backport from stable into this one.

@atsb atsb closed this as completed Dec 29, 2022
@Wolf3s
Copy link
Contributor

Wolf3s commented Dec 30, 2022

@atsb good news i got finally the linux building and cross-platform however it´s not working yet.

@atsb
Copy link
Owner Author

atsb commented Dec 30, 2022

I believe in you! I tried for 3 days to find a solution to the error but I couldn't do it, that's why I made stable. Knowing the code, it is probably one small thing that is cascading through the Init code and causing a tiny mismatch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants