The Supreme Topic of Miscellaneous Knowledge "Trivia, Research, etc."
#901 Posted 13 July 2014 - 04:53 PM
#902 Posted 30 July 2014 - 09:20 AM
Actually ; any way to know what are the main differences (if any) between versions of the Build Engine every commercial game used?
I do mean differences on the engine side, not on the games side; so SW's RoR would not count for instance.
This post has been edited by MetHy: 30 July 2014 - 09:24 AM
#903 Posted 30 July 2014 - 10:19 AM
Version 5 does not have slopes (Added 08/29/1995), uses a less well organized cache system, textured automap not implemented.
You can almost figure it out from the change log here; http://advsys.net/ken/build.htm
Duke, Redneck, SW and even Blood use Version 7... Though Blood was heavily modified with things like the QSystem (Replacing tags and such) how many of those alterations were technically engine-side and game-side is unknown to me and only a round estimate could be determined by looking at the source from the Alpha.
This post has been edited by High Treason: 30 July 2014 - 10:21 AM
#905 Posted 30 July 2014 - 11:18 AM
I'm very surprised to see that slopes were added that late... which should mean that any slope DN3D has were added during the last months of development.
It would be interesting to learn more about Blood's modified version of the engine, too.
Edit : nvm, deleted my other question since I found the answer to it
This post has been edited by MetHy: 30 July 2014 - 11:20 AM
#906 Posted 30 July 2014 - 12:07 PM
Blood is rather complicated, I am not sure I should post links to the Alpha for you to go and dig through it yourself as it may violate forum policies and I am still prohibited from sending PMs (Can this not be changed?) - Blood Wiki has a page on the Alpha at least
If you can get your hands on it there is some documentation included for XSystem (What I called QSystem before, handles Effects), QAV (Animated tiles - they are a single tile in Build/Artedit, a bit like Smacker), Smacker support for cutscenes (May not be with the Alpha, but the final used this) and all manner of things as well as a lot of maps.
One small paragraph;
Quote
The XSystem is based on extending the three simple object types used in the Build engine: sectors, walls, and sprites. The extensions to these are referred to as XSectors, XWalls, and XSprites, or collectively as XObjects. Internally, the XSystem manages a list of each of each XObject and maintains links between its related object. The links are stored in the extra field, which you cannot edit in MapEdit, but can view with the Tab key in 2D mode.
Apparently this thing does use existing properties in Build then (Note, uses the Extra field to store "links") but allowed very complex control over things, for example what I remember (From the final, Alpha is a little less complex) is, you can set a Sector Type - ALT+F5 (ALT+F6 for sprites), maybe a Sliding Sector. That sector could move on it's own (Slide Sector) or else you could press K on a wall or sprite (Makes it purple) to affect that if it was inside that sector (Slide Marked) and hitting K again would reverse the direction for that one (Green).
Tags were instead TxID and RxID (F10 to find next free, first 100 reserved), Transmit and Recieve on different tags, you can select what triggers them/responds to them, different speed, waveforms and delays for On and Off, different starting state. Can set height for Z Motion Sector/Sprite (F3/F4. F2 to change current state). Can change how the player triggers any of these (Set switches to only respond to guns or whatever) and a lighting/panning system so you can make any sector flicker, fade or whatever in different waveforms, panning acts like Conveyers and can drag the player if the Drag box is ticked.
The RoR system deserves a mention (Sprite Type 6 & 7) because it was very easy to implement, requiring only setting a matching Data 1 field, sector height didn't have to be correct but it was very touch about drawing multiple sectors.
Incidentally, I got started with Build mostly by using Mapedit. Blood uses a different map format it seems, whether they are just compressed/encrypted or actually do differ I do not know.
Quick edit: Found a reference to Dark Forces when it was talking about voiceovers and a note about a moving platform "Like in ShadowWarrior" in the XSystem doc. Also this;
Quote
She will appear, walk towards her target location (a marker sprite), and then disappear. Any actions you wish her to perform should be accomplished with the initial trigger.
Not a difference in the engine or anything, just figured I'd stick it there as it's the first I've heard of any Rachel... Oh, lastly, there was once meant to be a weather system of sorts, some graphics exist for it in either the Alpha or the early Shareware.
This post has been edited by High Treason: 30 July 2014 - 12:35 PM
#907 Posted 02 August 2014 - 02:48 PM
Scans of both sides of the card:
For the record, I'm not sure how 3D Realms or GT Interactive knew my home address.
#908 Posted 03 August 2014 - 03:52 AM
Marphy Black, on 02 August 2014 - 02:48 PM, said:
Perhaps you ordered something from some shareware vendor and they put you on the mailing list?
Or they were just sending those out to everyone.
#909 Posted 14 August 2014 - 11:37 PM
Nothing particularly unseen on the first page, but on the second, there's the Battlelord screenshot seen on some boxes uncropped here to reveal a second Battlelord, a screenshot of Sweeney(?) with the old skybox (similar setup seen in this leaflet), a recreation of a familiar beta screenshot with the final sprites (also seen in this leaflet), and probably the most interesting of the bunch, an inexplicably older screenshot from an unidentified map (also Sweeney?) with the old Pigcops, skybox, and a funky car.
#910 Posted 15 August 2014 - 12:43 PM
I wonder if we have asked Frederik about him having found any original copies of pre-release sreenshots that 3DR sent out to magazines (apart from what was included on CDs of other games and publicly downloadable screenshot packs).
#911 Posted 27 August 2014 - 09:09 AM
MrFlibble, on 15 August 2014 - 12:43 PM, said:
I wonder if we have asked Frederik about him having found any original copies of pre-release sreenshots that 3DR sent out to magazines (apart from what was included on CDs of other games and publicly downloadable screenshot packs).
I found the map files containing the dummy scenes those screenshots were faked with, actually.
#913 Posted 27 August 2014 - 11:15 AM
#914 Posted 27 August 2014 - 11:39 AM
This post has been edited by The Angry Kiwi: 27 August 2014 - 11:40 AM
#915 Posted 27 August 2014 - 12:17 PM
Frederik Schreiber, on 17 April 2014 - 12:31 PM, said:
as part of the re-lauch of the new 3D Realms website.
Guest appearances with 3D Realms Old-Timers, In-Depth Walkthroughs of the History and Data of these builds, etc.
Exciting times ahead
I couldn't be more excited!
#916 Posted 30 August 2014 - 02:56 AM
Recently I've noticed that MobyGames entries for Duke Nukem II and Duke Nukem 3D have these little bits of information:
Quote
Quote
While I suppose that the claim for the Duke Nukem II working title is somewhat plausible, based on the information in the Apogee FAQ (specifically, where it is mentioned that the name Duke Nukem was discovered to be not copyrighted during the development of Duke Nukem II), the information for Duke Nukem 3D's working title seems erroneous to me.
A correction would be in order, however I'd like to first get more info from you guys. Is there any evidence to "Duke Nukum 3D" ever being a "working title"? More importantly, is there any positive evidence against this claim?
#917 Posted 30 August 2014 - 03:20 AM
I'm still not quite sure why they haven't fixed that yet as that was supposed to be for the iOS version.
I'd suggest suggesting a correction now if it has no source.
#918 Posted 30 August 2014 - 03:42 AM
Lunick, on 30 August 2014 - 03:20 AM, said:
I'm still not quite sure why they haven't fixed that yet as that was supposed to be for the iOS version.
I'd suggest suggesting a correction now if it has no source.
I think this is an idiosyncrasy of the MobyGames' site engine. You're not listed in the DOS version credits, it's simply that the year displayed on your page is the same as "Combined View" (not platform specific), and apparently it just uses the earliest year of release on file for that.
[Edit] I made a post about your problem in the MG forums, hopefully it's going to be fixed eventually.
This post has been edited by MrFlibble: 30 August 2014 - 03:48 AM
#919 Posted 30 August 2014 - 06:44 AM
MrFlibble, on 30 August 2014 - 02:56 AM, said:
Duke Nukem talks about Duke Nukum II in his cameo in Cosmo's Cosmic Adventure.
#920 Posted 30 August 2014 - 07:04 AM
On the other hand, I would then have to wonder how old this was;
Given that (If I remember correctly, it was the only one they got working) it's meant to be the oldest prototype of Duke II.
#922 Posted 30 August 2014 - 11:02 AM
MetHy, on 30 July 2014 - 11:18 AM, said:
https://en.wikipedia...al_Engine_games
MetHy, on 30 July 2014 - 11:18 AM, said:
High Treason, on 30 July 2014 - 10:19 AM, said:
It's interesting. While I don't believe Monolith modified the Build object file itself, they did use their own versions of engine functions with extra functionality, particularly in the editor.
High Treason, on 30 August 2014 - 07:04 AM, said:
At the same time, the files are named
NUKUM2.-NM
NUKUM2.-ST
NUKUM2.EXE
NUKUM2.MNI
for all the prototypes that I have. That was only changed near-final, I guess.
MrFlibble, on 30 August 2014 - 02:56 AM, said:
From 1994-04-16:
#923 Posted 30 August 2014 - 12:26 PM
Hendricks266, on 30 August 2014 - 11:02 AM, said:
NUKUM2.-NM
NUKUM2.-ST
NUKUM2.EXE
NUKUM2.MNI
for all the prototypes that I have. That was only changed near-final, I guess.
From 1994-04-16:
Great, thanks a lot!
Lunick, as for your issue with the credits dates, the guys at MG told me that this is already included in the list of site bugs to be fixed.
#924 Posted 15 September 2014 - 04:13 AM
Do you think he was intended only as sprite replacement for some old monster, or made for new enemy from scratch? I think he was supposed to be added as another original enemy next to pigcop in inflatable dragon and seagull. I presume he was being worked at earlier stages of development, as all shots with him dont include any new texture and decoration sprites, except for new look of enemies and he propably have been removed sooner, than his complete sprite sheet could be finished because all screenshots capture him at the exact same angle.
Any theories?
#926 Posted 15 September 2014 - 11:39 AM
Like you said, it only has one pose, so probably there wasn't anything but what is seen in these screenshots.
#928 Posted 18 September 2014 - 06:27 AM
Decided to experiment with these a bit.
At least these two effects exist in the LD code that don't exist in the final version, there might even be more.
While these are useless now, it still interesting to see what different ideas they had in mind before overwriting these slots with other stuff.
SE 18 - Vacuum, Similar to the one seen in various videos.
When paired with a typical SE15 sliding door, the point where the SE is at will be the source of the vacuum.
This will drag all in various enemies and other objects such as explosion sprites.
SE 23 - Flooding sector
A rather buggy effect that changes a dry sector to divable water while flooding it to a set height.
-> Diving itself works the same as normal SE7 underwater transport.
-> As a side effect, Sector #0 gets lowered to the same height as the bottom of the dry pool.
-> Flooding process starts once the player gets in the sector.
-> Biggest bug is that the underwater sector also has it's floor texture changed in to a water texture but it's not divable.
Create an empty pool, this will be the flooding sector. This can be split in to as many child sectors as you wish.
Create the underwater section of the pool, same as above, you are free to split this one.
Link these in a typical SE7 water transport fashion.
Unlike a typical divable water, the top side must be dry and lowered to the same height as the bottom of the underwater sector for the least glitchy outcome.
Now every affected sector that is over or under water has to have the same hitag.
Create a single SE 23 sprite that will determine the height that the water will rise in to on the dry pool sector.
For reference: Dry sector - Dry sector in editor - Underwater sector
- - --
There are other effects that got unused in the final game but actually exist in some of the maps in lameduke so you get to see them in their "natural habitat"
I suggest reading the URL for more information.
SE26 - Escalator
A rather buggy effect that raises and moves a single child sector in a certain direction before resetting it's position instantly. Having multiple of these chained gives the illusion of moving escalator steps.
Seen in E1L5 on LD.
SE5 - "Boss creature" / helicopter
Another effect that is pretty buggy but gets used on E1L7 and E1L8 maps in lameduke.
While infosuite refers it to as the turret, it's obvious what it was meant to be.
SE19 - Airlock windows
Makes the sector go shut (from top) if it detects that a glass was broken inside it. One of the videos suggested that it was combined with the vacuum at one point, possibly the room would have that applied until it got fully shut.
This gets used in E1L1 of LD.
Found another one, as far as I know, this is unused even in LD levels.
SE16 - Rotate reactor sector
This combines two main effects:
1) Piston, once the level starts it will lower the roof of the sector to floor level.
The piston will start moving up and will remain at the roof level unless there is another (any) sprite in the same sector.
Movement speed is slightly faster when the piston goes down and slower when it goes up.
2) It applies rotation to the sector, which is the usual rotation. What makes this different is that this SE also acts as a pivot sprite.
In the end this combines roughly 3 different SEs in to one, along with the variable speed for directions which is not really seen elsewhere.
- This effect works with retail AND lameduke, the main difference is that the retail version accepts only the reactor sprite inside it before it starts working.
once the reactor is destroyed (or the placed sprite in LD), the effect halts. I guess the requirement was changed as in LD you can stop it quite easily with just generic projectiles.
Strict requirements might be why it isn't that well documented. Still quite a lot of potential applications!
I think that is all that LD offers when it comes to SEs, roughly around 26 there seems to be nothing above it.
This post has been edited by oasiz: 18 September 2014 - 01:13 PM
#929 Posted 18 September 2014 - 09:08 AM
#930 Posted 18 September 2014 - 09:35 AM
That's my theory at least.