[NNC]

During my Blast Radius playtesting, ck and me were talking about palette respawns once again, and how it doesn't work bosses aside in the vanilla game, despite the several uses of pal21 respawn troops especially in the first 3 episodes.

Now I'm thinking again, basically all those red liztroop spawns in the game are "straight in your face" ones, where you can clearly see the same flashy animation that is also used by the red troop's teleport. For example in Hollywood, that weird respawn in the cinema chairs look like some kind of introduction for the red troop, similarly to the one at the backdoor. Then there is a second one from both routes in the main lobby before you can get the shotgun. I mean, the troop spawns in flashy style, and can use the same flash later on.

Similarly, the straight into your face respawn troops in Red Light District (in the bar shooting the girls), Death Row (in the church), Launch Facility (at the start), The Abyss (near at the end with the deep abyss), and several others in Incubator, Warp Factor do the same. The most common respawns are not straight into your face, and none one them are using palettes. I didn't check beyond mid-episode 2, I guess this whole concept had been lifted later on, but this is a trend that is not a coincidence.

[Reaper_Man]

FWIW looking in the source code, the lack of palette transfer from RESPAWN to the enemy it spawns is intentional. In the case of the Liztroop, the palette is always forced to 22 if it isn't already set. However for all enemies, it doesn't check for the palette of the spawning RESPAWN and apply it first, so the Liztroop sees a default 0 palette. This is not the case for bosses, which does check if it was spawned by a RESPAWN and if so, transfers its palette to the boss. Because this behavior was never changed between 1.3 and 1.5, we have to assume they wanted to enforce this behavior, and because EDuke tries to maintain compatibility, that's why this behavior persists. Thankfully you can work around this using Events

As for the Liztroop Captains, I would guess the opposite - RESPAWNs were already using the TRANSPORTERSTAR effect, and they added in the Captains after having the "in your face" spawns as a way to change up gameplay dynamically.

[ck3D]

 Reaper_Man, on 18 February 2023 - 08:08 AM, said:

In the case of the Liztroop, the palette is always forced to 22 if it isn't already set.

Oh no way, so that explains the whole blue uniform in the base .art and editor, green uniform in the game pseudo-mystery. I'm trying to remember how the troopers looked in every possible port now, off the top of my head Duke Nukem 64 still had the blue ones even in game. Now I can imagine that they only gave the Liztroop base sprites a blue uniform so that it would be palette friendly and wonder if that means they ever actually had plans for the blue ones (or other colors), but realistically the green swap sounds more like a quick afterthought to help convey 'trooper' in the enemy's aesthetic (and also completely polarize them in reference to the red ones on the color wheel).

[MrFlibble]

 ck3D, on 18 February 2023 - 10:33 PM, said:

wonder if that means they ever actually had plans for the blue ones (or other colors)

It was quite a widespread practice for sprites with swappable palettes to use some kind of default "neutral" colour in the data files, which might not coincide with any colour seen in-game for those sprites.

For example, in StarCraft the remappable areas of units and buildings are in gradients of some pink-purplish colour in the game data, which is never used in any player colour scheme.

In Red Alert, all units and structures have the gold colour in the game data, like GDI in C&C, even though this is not the default colour scheme for any side in the single-player campaign.

in Daggerfall, all player paperdoll clothes that have colour variations are blue in the game data (although that is one of the colours which appear in the game).

I also have a vague memory of some game where the remappable colour was a slightly lighter or darker version of one of the colours used in-game, but I cannot remember it right now.

[jimbob]

i remember raiden in MK being like green or red, despite that not being his natural color.

[edit] wich i realise has no bearing on duke whatsoever... but anyway.

[brullov]

While searching for the info for my upcoming video about interesting Duke Nukem 3D art facts, I found the source textures for the signs. They are even in the same order in the game as in this catalog. It is Autodesk Texture Universe, released in 1994. Unfortunately, I can not find it online or a CD version to buy. Maybe somebody has access? I'd love to check it.

[ck3D]

Would anyone on here happen to have the specific castle.map this gentleman here says he has been looking for for years, the one which apparently was most prominently featured in the Prima guide?

[Fantinaikos]

Someone ever heard of '96 Crazy Drake before? It is, well... pretty obvious what the cover art is a parody of.

Should be an Earthworm Jim inspired platform with "6 episodes, with over 20 levels, 6 bonus levels and 6 special levels and one supersecret".

[MrFlibble]

I played the shareware version but this is the first time I see this cover art. Nice!

[Gargoyle]

I was playing through E2 for the 69th time and while blasting octabrains with the devastator in the E2L7's waste tunnel, this wall opened up:



Mind was blown but I do recall opening this wall before, maybe in one of my earliest playthroughs. Always went for the red door above because of the kills.

[Fox]

I always went through the wall

[NNC]

It took me like 10 years to find the shrinker in Warp Factor. That was, IIRC my latest discovery in the game. The jetpack in Raw Meat and the caribbean wall with expander ammo in Derelict were also very late discoveries.

[Aleks]

 The Watchtower, on 02 June 2023 - 11:10 AM, said:

It took me like 10 years to find the shrinker in Warp Factor. That was, IIRC my latest discovery in the game. The jetpack in Raw Meat and the caribbean wall with expander ammo in Derelict were also very late discoveries.

Wow. While the shrinker in Warp Factor and expander ammo in Derelict were "always" quite obvious to me, I had no idea about the jetpack in Raw Meat, just checked and noticed it - incredible

[Gargoyle]

Before the previous discovery, my latest finds were the fake wall with the armor and the scuba gear in E1L4 and the underwater RPG in the same level (learned both of these from BMD's walkthrough 4 years ago). Also, chaingun ammo in the toxic waste secret in E1L6.

[Doom64hunter]

 Aleks, on 02 June 2023 - 11:44 AM, said:

Wow. While the shrinker in Warp Factor and expander ammo in Derelict were "always" quite obvious to me, I had no idea about the jetpack in Raw Meat, just checked and noticed it - incredible

The jetpack?





Which one?

Yeah I didn't know about either of them until I checked.

Another one I only found a few years ago was the freezer ammo with an atomic health and armor behind the fake walls in the center pool in E2L9.

[Aleks]

 Doom64hunter, on 04 June 2023 - 06:33 AM, said:

The jetpack?

duke0000.png

duke0001.png

Which one?

Yeah I didn't know about either of them until I checked.

Another one I only found a few years ago was the freezer ammo with an atomic health and armor behind the fake walls in the center pool in E2L9.

I definitely meant the one from the first screenshot, which I only checked in Mapster yesterday. Not sure about the second one, but it's something I vaguely remember, so might have found it at some point.

[Gargoyle]

 Doom64hunter, on 04 June 2023 - 06:33 AM, said:

duke0000.png

Another one learned from BMD which I totally forgot. Need to DM E3L1 more.

[ck3D]

I just found a new Build quirk I wasn't aware of before; it's known that elevators and rising/lowering floors will carry sprites that are directly inside the sector, but I've realized traveling cranes also counted as such (as moving sprites, they adapt to sectnum). That means by placing elevators in the path of a traveling crane, it's possible for Duke to diagonally offset the crane's movement even when the crane is carrying another sprite, or even Duke himself, for however long the traveling crane crossing the elevator takes. The crane seems programmed to return to exact fixed points, which means it will get stuck against walls if it can't directly travel to reach it anymore until the elevator is triggered again (and then the second there's leeway again it will zoom past and keep going). On the other hand, that means it's a consistent effect, you can't really mess it up, just like elevators too are generally pretty consistent, which means it's possible to sort of have some control over those diagonal shifts with the occasional obstacle. When Duke is being carried, the player can't move or face anything but directly ahead, but they can still shoot and use and thus activate the elevator underneath them again to escape the softlock (and so the elevator should be directly underneath the obstacle, and generally it should be manual). It's probably possible to pin enemies onto walls like that too, so that they stand still but I haven't tested that yet.

[VGames]

Are we allowed to change the name of the Eduke32 executable and the icon When it’s included with a mod we’ve released?

[Fox]

I don't think that's a problem, it's written everywhere it's Eduke32

[VGames]

 Fox, on 26 June 2023 - 03:14 PM, said:

I don't think that's a problem, it's written everywhere it's Eduke32

Ok cool. Thanks for the response. I’m not gonna change the details of the app in its properties. I want it to say eduke 32 and all that in there. I just wanted to rename it and give it my own mods icon. Thanks again.

[ck3D]

One more recent small-time realization re: crane behavior: apparently having a Protozoid Slimer down on the ground in the crane's path below will block it and everytime it's hitting the enemy's space the crane will reset to its last visited point, if it's carrying the player they can get stuck on a loop for as long as the enemy doesn't move or isn't killed (but since the player can't aim whilst being carried, their only choice would be to drop a blind pipebomb). Maybe that's every enemy, maybe that's only in specific conditions, as far as I'm concerned it was the return trip of the crane which was getting interrupted (from 'point B'), from player perspective the snap back to the spot is so instant it could almost pass off as teleporting.

[Fox]

If I had to guess, the temp flags (aka htg_t) used by the crane target is shared with the slimer behavior which is hard-coded.

[Aleks]

 ck3D, on 28 June 2023 - 09:52 PM, said:

One more recent small-time realization re: crane behavior: apparently having a Protozoid Slimer down on the ground in the crane's path below will block it and everytime it's hitting the enemy's space the crane will reset to its last visited point, if it's carrying the player they can get stuck on a loop for as long as the enemy doesn't move or isn't killed (but since the player can't aim whilst being carried, their only choice would be to drop a blind pipebomb). Maybe that's every enemy, maybe that's only in specific conditions, as far as I'm concerned it was the return trip of the crane which was getting interrupted (from 'point B'), from player perspective the snap back to the spot is so instant it could almost pass off as teleporting.

Isn't it similar to RPVs getting stuck when having enemies directly below them?

[ck3D]

 Aleks, on 29 June 2023 - 05:06 AM, said:

Isn't it similar to RPVs getting stuck when having enemies directly below them?

In a way it is, but the RPV's just get stuck and that's just annoying if anything, whereas the crane has the practical function that it can carry Duke, and slimers are interesting because they can be spawned and they react to viewpoints (e.g. they'll crawl towards the security camera when observed through a screen), so maybe there's a far-fetched puzzle or six one could come up with involving those elements, I don't know. The snap back to the crane's anchor point whilst the player is being carried is pretty unique, too.

[Fox]

 Aleks, on 29 June 2023 - 05:06 AM, said:

Isn't it similar to RPVs getting stuck when having enemies directly below them?

Sounds more like a 2.5D collision problem

[NY00123]

The following animation demonstrates behaviors that may greatly depend on internals of how a program runs, if not the environment.
I reproduced this in a 2019-era map of mine. It's probably not surprising that I didn't observe this earlier, given that it's apparently most visible starting from an early 2022 build of EDuke32.

So, as should be known by now, the Build Engine's original software renderer has limitations when it comes to rendering walls whose tiles don't have power-of-2 heights in pixels, say 11 pixels.

But how may it look like across different renderers, or even just the software renderer with different revisions? I'll concentrate at the software renderer here.

See the given animation and reference map, using tile 799 with the height of 11 pixels (I originally used this tile for a stairway):

1. The first frame (an otherwise black-colored column having a somewhat brighter pixel on the bottom) matches EDuke32 SVN r8071 and earlier revisions, and also matches DOS v1.5.
2. The second one (all pixels being black-colored) matches SVN r8072, along with r9899-3b9f04270. At far as I can tell, it still matches Linux release builds of later revisions of EDuke32.
3. The third one (bright red-colored column) matches Linux debug builds (RELEASE=0 OPTLEVEL=0 in my case) of r9900-629b3f330 and later revisions.

For reference, the impacting commits are:

r8072 (SVN) - "Align cache1d memory blocks to system page size"
r9900-629b3f330 - "mimalloc: update to 6ead2840ec620f1fc06297c310c902e56835c0a7"

Attached thumbnail(s)

• 

Attached File(s)

•  steptest.7z (194bytes)
  Number of downloads: 64

[ck3D]

No idea how rare this may or may not be, but it just went up either way:



Didn't know the Shrinker/Expander term already was coined so early, that's a bit unexpected.

[DNSkill]

This looks like the same version used in that British game show, but different footage entirely.

[Fox]

The launcher behavior in the N64 version is way too much like that RPG, it's even heat-seeking