|
Notes |
|
|
|
Can you test if this also happens in 3.0?
If so, please extract the necessary parts of complex-doom.v26a2.pk3 and add them to the example wad. complex-doom.v26a2.pk3 is so big that debugging problems of the engine is infeasible with it. |
|
|
|
|
|
Does it happen with the attached wad (includes a very simple baron replacement which emulates the spread attack)? |
|
|
|
|
Hi,
No change with complexspreadattack_1 (see included screenshot).
I will test it tonight with the v3.0. I need someone with more expertise to get it compiled "by the book" (sorry for being linux illiterate).
As for the question to strip complex-doom.v26a2.pk3, well, i'm looking around to find someone to get the job done for me, since i'm not familiar with mapping. I'm even bad at playing doom itself.
Let me take the opportunity to say thanks for the impressive job you all are doing... |
|
|
|
|
update.
In the meanwhile i received a patched binary (http://wiki.zandronum.com/Compiling_the_Zandronum_server_on_a_Raspberry_Pi is the source). Apparently there is a fix for something included in this version).
I still get the same result -> spread attack is still messed up. |
|
|
|
|
|
Can you reproduce it without complex doom? That was the point of the updated test wad. |
|
|
|
(0015223)
|
|
grrfield
|
2016-07-08 17:16
(edited on: 2016-07-08 17:20) |
|
Ok, I must have misunderstood. Here is a resumé of all tests I have performed. I am still waiting for that v3.0 to test. I keep you updated.
complexspreadattack complexspreadattack_v1
With Complexdoom
windows 2.1.2 OK Ok
RPI 2.1.2-r150718-1029 buggy buggy
RPI 2.1.2-r150718-1029M buggy buggy
Without complexdoom
Windows 2.1.2 not applicable ok
RPI 2.1.2-r150718-1029 not applicable buggy
RPI 2.1.2-r150718-1029M not applicable buggy
(not applicable: because monsters have no spread attacks in this scenario)
I add a textfile to the documentation, since I have formatting issues in presenting this table-wise.
|
|
|
|
|
|
I tested it with v3.0. I added the results in an updated textfile for better reading. Conclusion: same results as before: works under windows, does not work correctly on my Pi |
|
|
|
(0015228)
|
|
grrfield
|
2016-07-09 08:51
(edited on: 2016-07-09 08:53) |
|
Friend of me reported same issues with Zandronum3.0-160519 downloaded for mac osX (tested with version complexspreadattack_1.wad (without complexdoom).
He reports the following (in dutch):
"Ik heb net Zandronum3.0-160519 op osX gedownload.
Hiermee heb ik een locale server gestart met enkel complexspreadattacktest_1.wad als wad. (dus geen complex of andere)
Vervolgens heb ik met de osX client geconnect en volgende vaststelling gedaan."
....and then a screenshot demonstrating erroneous firing behaviour.
|
|
|
|
|
|
Error, I uploaded wrong resume. I fixed it now. |
|
|
|
|
Quote
Friend of me reported same issues with Zandronum3.0-160519 downloaded for mac osX (tested with version complexspreadattack_1.wad (without complexdoom).
Does it imply that it happens also offline? |
|
|
|
(0015231)
|
|
Torr Samaho
|
2016-07-09 11:52
(edited on: 2016-07-09 12:18) |
|
I can confirm the broken behavior using complexspreadattacktest_1.wad on my RasPI2. Looks like a sign problem, i.e.
A_CustomMissile("BaronBall", 32, 0, -6)
is treated as
A_CustomMissile("BaronBall", 32, 0, 6)
EDIT: Looks like ACTION_PARAM_ANGLE doesn't work properly. Negative values seem to be mapped to zero.
|
|
|
|
|
The type conversion in ACTION_PARAM_ANGLE seems to be broken on the pi, which means that all angle arguments of all DECORATE code pointers are affected. Changing ACTION_PARAM_ANGLE to the following seems to fix the issue:
#define ACTION_PARAM_ANGLE(var,i) \
angle_t var = angle_t(SDWORD(EvalExpressionF(ParameterIndex+i, self)*ANGLE_90/90.f));
Since ZDoom switched to double precision angles, it's most likely not affected by this issue anymore. |
|
|
|
(0015237)
|
|
Edward-san
|
2016-07-09 15:29
(edited on: 2016-07-09 15:30) |
|
There's an issue with MSVC compiler for x86 when you add an explicit SDWORD cast in the middle, like I reported here (which applies here, too), so the solution would be to move the whole fix in a specific ifdef.
|
|
|
|
|
|
I skimmed through the ZDoom thread you linked there. Isn't the conclusion to use xs_RoundToInt instead of any signed or unsigned casts? |
|
|
|
|
|
Right, I forgot to check again the zdoom thread. I misremembered the solution. |
|
|
|
|
|
|
|
|
|
Does it imply that it happens also offline? -> It does. |
|
|
|
|
|
Should be fixed in 3.0 now. |
|
|
|
|
|
Thanks, i noticed that complex doom just got a bit harder on my 3.0 servers. Thanks |
|
|
|
|
|
Feel free to reopen should this issue pop up in the future. |
|
complexspreadattacktest.wad (1,570) 2016-07-07 21:49
raspberry - wrong firing mode.jpg (671,291) 2016-07-07 21:50
resume.txt (325) 2016-07-08 17:20