General information about this board
#1
Hello everyone,

This board is the place for the testing of the most current DXX-Rebirth builds based on the "unification" repository, generously provided by A Future Pilot.

You can get the new builds here: http://www.dxx-rebirth.com/frm/index.php...007.0.html
or you can get the sourcecode from GitHub: https://github.com/dxx-rebirth/dxx-rebirth


What is unification?

As stated, they are based on the unification repository. This repository introduces heavy changes to the DXX-Rebirth codebase: Unifying the D1X-Rebirth and D2X-Rebirth sources into a single code tree (without sacrificing unique elements from either game) and introducing a large rewrite and port to C++ - mostly done by kp who invested countless hours into this within the past year. It is not a complete rewrite of the project but many things behind the scenes have changed. While there is still much work ahead, the goal is to create a cleaner and safer code which is easier to debug, breaks with old limits and barriers, etc.


What is to be expected? What should be tested?

As you can imagine, these builds are highly experimental. Expect the unexpected and whatever you can and want to test is invaluable for us to turn this codebase into a stable release.


How do I report bugs?

Like with normal bugs, please submit as much information as you can to describe the bug and how to reproduce it. Things like Savegames, screenshots, demos, etc. can help, too if they are able to show off the bug.
When you report it, please state if you encounter it in D1X-Rebirth, D2X-Rebirth or both.
Also each Windows build comes with a date. Please add this to your report as well. If you compile from source from GitHub yourself, please add the current commit, your build is based on.
Do not be afraid of spamming: Keep each bug report in a separate thread and do not hesitate to add more of your feedback into an existing bug report.


What about other feedback?

Every bit of feedback is very welcome. Feel free to tell me what you think about possible changes, what you like, what not - whatever comes to your mind.


So what comes next?

Again, please be aware these builds are still very experimental. Be patient and do not expect a stable experience, yet. We are working hard and kp adds new commits every single day. And with your help, we can create the best DXX-Rebirth release!

When the unification branch reaches stability - based on your feedback, I will release this as v0.60. After that, new releases will follow on a regular basis.
The greatest pleasure in life is to do what people say you cannot do.
Uhm... Honey, there's a head in the toilet!
Reply
#2
Oh, a question: Would it be better if I built the betas with the debug flag set?
Reply
#3
If you can, please provide both debug and non-debug when you do your next iteration.  The debug builds trap mistakes more quickly, but in some cases they trap things that were never right (pre-unification and sometimes pre-Rebirth).  In a few cases, I have hit traps where the code was fine and the trap was wrong to trigger, rather than the trap catching a valid bug.  Exposing beta testers to debug builds is probably fine, but the decreased stability could be frustrating for people who just want to treat it as a technical preview.

To build both at once, use an scons line like dxx=options,d+ d_debug=1.  This will build twice, once with debugging and once without.  You will need to set d_builddir or enable builddir_prefix, so that the two outputs do not overwrite each other.
Reply
#4
OK, will do!

Also, I'm planning to build once a week unless a major bug is fixed, or feature introduced. If it's something that I may not have noticed, could you point it out to me so I'll know to rebuild? (I'm planning on making a new build tonight to fix the homer crash).
Reply
#5
Will do.  If you provide Linux builds, please consider providing a variant built with -fsanitize=address.  AddressSanitizer builds run at ~half speed and use a huge amount of shadow memory (but still run fine without much physical RAM), but the payoff is very precise error checking.  All array accesses are instrumented and any out-of-bound event is immediately fatal.
Reply
#6
If there's enough demand I'll provide Linux builds, but I think most people running Linux can compile themselves without much problem.
Reply
#7
I just realized...in my own Linux builds that I use to test, I should pprobably add the -fsanitize option you mentioned, huh?
Reply
#8
Yes.
Reply
#9
I tried adding -fsanitize=address but I got

Code:
scons: warning: Ignoring missing SConscript 'sanitize=address'
File "/usr/bin/scons", line 199, in <module>
scons: done reading SConscript files.
scons: Building targets ...
scons: `.' is up to date.
scons: done building targets.
Reply
#10
-fsanitize=address should be in your CXXFLAGS, not passed as an option to scons.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)