FAQ me!
hey Alter-Fox

As a pro musician I have been dealing with varying levels of performance anxiety (the "proper" term these days) for many years, and I will presume to give two pieces of advice:

1. feeling nervous means you care about what you are doing, and are a thinker (as opposed to being too stupid to be nervous Wink Don't dwell on it (easier said than done, I know)
2. the only cure for it is to get out there and do lots of whatever it is.

The nervous energy can be turned into an asset once you learn how to work with it (it is like an unbroken bronco, powerful and wild but potentially very useful once you learn to control it) - experience is where it's at.

good luck!
Hi. I've been looking for a walkthrough. I've had Rebirth for D2 for a month or so and it's working great. But I'm stuck in a reactor chamber in one of the fire mines. When I go in the chamber the pass through goes away and I can't get out after killing the reactor. Can you help? Thanks
It is possible to replace the 2d sprites with real 3d models? Or at least to allow the sprites to rotate so they don't appear to rotate with the player, in other words give the 2d sprites the same behavior of the hostages sprite.

The 2d sprites bothered me even when the game was new.
Do you ever plan on fixing up the software renderer and making it available either as its own build or alongside the GL renderer in a single build? I love software Descent but the software build Blzut3 made for me has a few bugs in it (polygons tearing/flickering occasionally, a strange flicker of the door texture for one frame when you fly through a door).

Extra bonus points if you can restore the demo's Descent 1-style briefings and escape sequences and make them usable in retail D2--again, the build I have has those but they're buggy (robot screens use the wrong palette for the robot rendering, escape sequences have no music) and require assets from d2demo.hog to be inserted into descent2.hog, causing an error message (non-fatal but annoying) about the hog being the wrong size. But those are far less important to me than the renderer itself.
Yes, the sprites can be replaced. All we need is for someone to define new sprites that can be rotated appropriately, and code to handle tracking/rendering that.

I very much doubt there will ever be a build that can runtime switch between OGL and pure SDL. There are 127 places in the source that compile-time include statements specially for OGL (that is, those places omit statements when a pure SDL build is made). There are 67 places in the source that compile-time include statements specially for SDL (that is, those places omit statements when an OGL build is made). Some of those are "simple" exclusions, like not implementing a function that is not needed in that configuration. Others are logic changes or include/exclude data that is only needed in one build. All those sites would need to be converted to be runtime switchable - or you could just keep separate OGL and SDL builds. Both should be buildable from any given commit, and that approach works today.

No comment on whether anyone will publish pure SDL builds on the site. Personally, my experience has been that the OGL build always works as well as, if not better than, pure SDL. AFP is mainly responsible for builds that end up on the site, so it's mostly up to him whether a pure SDL build is published here.

All the briefing/escape stuff should be fixable. From your description, I don't know what base you are comparing, so it's hard to say whether it has been fixed or is easy to fix. Please file a separate report in the Bugs forum (or, if you have a Github account, file a Github issue - those are somewhat easier to work with) identifying the commit from which your build was made, steps to reproduce (assume I have access to both retail and shareware data), and expected versus actual results (assume I will not recognize inconsistencies or mistakes unless specifically called out).
For me, it's not about whether the OGL "works better"--of course it's going to run faster and nearly everything has basic OpenGL these days, but OpenGL doesn't look much like the software renderer that the game was built around and all its assets were designed for. The way the light becomes darker in the distance (compare to other software rendered 3D games of the era like Doom and Duke 3D), the flattening of colors in the dark making everything look darker and grimier. After all, the philosophy page says you can't take the 1995 away from Descent, right? The original software renderer is part of that 1995 and I think it deserves to be seen. Sad

I will look into how I put together the modified .hog and ask Blzut3 what version he forked from. Hopefully I should have a bug report ready in a couple of days.
That's a great summary of all the reasons why I love the software renderer too. Smile There's one other limitation of Rebirth's software renderer: it currently doesn't support scaling a low-resolution game screen to fit a high-resolution display. D1's original resolution of 320 x 200 tends to be stretched wide and ultra-blurry on modern displays (and many displays don't support 320 x 200 at all). It would need scaling and aspect ratio correction to 4:3 to look as it did on old CRT displays. I use DOSBox a lot, since it has those features - but fortunately, there are plans to add those features to Rebirth sometime in the future as well.
OK, unfortunately Blzut3 lost his modified source code but I do have the diff: https://pastebin.com/29MQ20kp

The builds themselves: https://www.sendspace.com/file/xjttk3

And here's the Git version as reported by the main menu:
[Image: NA3pa6y.png]

To reproduce the flickering door bug, open a door in any map in either game in a software build and fly through it. At the very moment the center of your ship crosses the threshold you should see the door texture flicker on screen for a frame or two. It's easy to miss, especially at a high refresh rate, but it happens every time.

I don't remember what I added to the .hog exactly, but it involved briefing screens, .bbm files, and some other files that Descent 1 and the Descent 2 demo use for the escape sequences. I can PM you the whole .hog if you need it.
OK, I'm a bit confused. Why does it matter that he lost his copy of the source? Did he not convey Complete Corresponding Source to you (or otherwise publish it) at the time he published the builds? Where is his Git repository hosted?

Per section 6, such work should have been conveyed:
  1. ... accompanied by the Corresponding Source ...
  2. ... accompanied by a written offer, valid for at least three years ... to give anyone who possesses the object code either
    1. a copy of the Corresponding Source ...
    2. access to copy the Corresponding Source from a network server at no charge
  3. (not applicable here)
  4. ... and offer equivalent access to the Corresponding Source in the same way through the same place ...
  5. ... provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public
Which of these branches did Blzut3 exercise? I suspect he elected (d) and you did not take him up on it.

Regrettably, the Git version shown in the screenshot does not parse. It is likely that Blzut3 made at least one commit locally.
$ git log -1 a8bb7ae3b
fatal: ambiguous argument 'a8bb7ae3b': unknown revision or path not in the working tree.
In the main history, 0.59.100-620-g is 0.59.100-620-g2d430596c532e52f2b62b4594944255a369c5847. That is not the description shown in the screenshot, so there must be some divergence. The output of git log --oneline -10 or so (possibly a higher number) in Blzut3's repository would make clear how different it is. Alternately, someone with his Git history could use git merge-base a8bb7ae3b github/master to find the most recent public commit present in his tree, then git diff between that commit and his tip.

As for the palette issue, I encountered the same when I defined an extension to permit level authors to show robots in their briefings (rather than use robot movies). It can be fixed in software, but only at the expense of making the frame appearance change a bit.

As I understand the earlier posting, the HOG in question is a derivative of descent2.hog. Thus, it cannot be redistributed.

I will examine the linked diff when next I have time to work on Rebirth.
The builds were never published. He did not give me the source because it was a completely informal thing, he was fiddling around like DXX-Rebirth and I asked for some software binaries since he had the toolchain set up at the time. I didn't foresee I would need the source later (I am not a programmer myself) so I didn't ask for it. Anyway, you have already duplicated his work by adding it as a DXX-Rebirth specific .txb tag and I thank you for that. As for making the frame look a bit different, I think that's perfectly fine, the robot is the focus the screen, not the frame. The only other change was that the movie player was disabled. If the movie player is disabled and the escape assets are available, it will play the D1/demo-style escape sequence.

Blzut3 has identified the commit it's based on as 8b713978fcdbb0433ddcb57387f19fee565f9fdd.

As for "redistributing it", I find the insistence on legal protocol in what would be a private exchange between two owners of legal copies rather strange.

Forum Jump:

Users browsing this thread: 1 Guest(s)