[NightFright]

Texture alignment in E3L3 "Flood Zone":

[Fox]

That's one example of how the 64 engine interpret the textures differently from the PC. But I think it's beyond me to fix that (if that's something that needs to be fixed).

[OpenMaw]

What do you mean? It's just a matter of going into the map and fixing it, right?

[Helixhorned]

The original tile #3421 has dimensions 56x192, the replacement one 56x64. No bugs at all, the wall just needs realignment.

[Fox]

That's not the case, I use a copy of the tile inside the /tiles/temp folder with the proper dimensions for tilefromtexture.

Commando Nukem, on 11 August 2013 - 06:50 AM, said:

What do you mean? It's just a matter of going into the map and fixing it, right?

No, because that map was extracted from the ROM. But the mod is not necessarily wrong — even if it's not identical to the console, I don't think the mappers had it different.

Edit: Here is a comparsion beetween Eduke32 and an emulator.



Besides the erroneous texture for the credit cards, if you look closely the counter walls you will notice that the shading is different. That's because the 64 display the same shade and pal for the top and bottom texture (cstat 2), which kinda sucks because you loose some map effects.

Anyway, my point is that the mappers clearly used the Build editor with little modifications, so these aren't what I would call mistakes even if doesn't match the console version.

[NY00123]

Although I haven't got to try it in its current form, very good job! These years of work have been worth the effort.

About one wall's aligning and other walls' shading:
- May the differences in the wall aligning come from the fact that the texture's height (in pixels) is not a power-of-two integer? The last .MAP format as supported by EDuke32 may change some things regarding that.
- As for the counter walls' shading, I guess that can be automatically "fixed" (i.e. look more vanilla-like) using some CON code, without modifying any MAP file directly?

Again, nice mod.

[Fox]

I checked the DOS version and it looks the same as Eduke32.

It would be possible to correct the shade or pal with a CON, but I don't think it's a bad thing.

[OpenMaw]

I'm still not following why you can't edit the maps to fix these problems when they rise. The Flood Zone sign should simply be a matter of changing the vertical panning until it stops being stupid.

And i'd disagree with saying it's not an issue. Visual accuracy should be more important in these cases if somethings is very clearly broken...Right?

[Fox]

But my point is that it's not broken. For some reason they decided to add a cstat of 4 to that wall.

[OpenMaw]

...How exactly is the misalignment in Flood Zone not "broken" ? It's clearly wrong.

[Fox]

These maps have been extracted from the ROM, I am not touching them.

[OpenMaw]

...Okay? Why? Are they of religious significance?

I mean, it took me ten seconds to fix.

[Fox]

The water is too bright. And you should add a pavement to that empty street.

[NY00123]

EDIT: Gotten Duke64, now going to check this...

Since I *still* don't have the latest version of Duke64.. (I know what may someone going to tell me after this post!... ok downloading)

Has anybody considered trying to load the Duke64 variation of the Flood Zone map using Mapster32 and then saving a copy of it using the latest revision of the .MAP format, eventually checking what happens to that wall? (As its tile NPOT (Non-Power-Of-Two) height in pixels.)

---

Well, that is interesting. The tile's alignment seems to be *ok* within Mapster32. Maybe it already displays things under the assumption the newer .MAP format is in use.

EDIT: Yeah, when I set a wall to have some random tilenum representing a tile with a non-POT height, it is repeating *correctly*, which is surely not the case using the original .MAP format in EDuke32 and DOS Duke.

[OpenMaw]

Fox, on 11 August 2013 - 10:55 AM, said:

The water is too bright. And you should add a pavement to that empty street.

That was about as clever is mahogany hitting a child in the face, Fox. This is about making simple repairs to make the TC closer to what was presented in the original 64 version. It's not about enhancing the level of detail, but merely fixing the detail that already exists. Don't turn into a twit.

[NightFright]

About the Flood Zone sign glitch:

I guess since this mod is meant to be run with EDuke32 exclusively, there should be nothing wrong with very minor edits of the levels - provided they are done in order to maintain an accurate reproduction of the levels as they appear on the N64.

As far as I am concerned, there's no need to be shy to apply such map changes. It's not like anyone will reimport everything back into a ROM and complain if it doesn't run on the console properly any more.

Personally, I won't die if it remains unchanged, the level is perfectly playable without doing anything. However, we are (mostly) PC users, and on this platform, we have the tools to make things look right. Why not take advantage of this opportunity?

[Radar]

It may be that if Fox modifies one thing to better match the original, he'll end up feeling compelled to have to modify every other wall that doesn't have the texture panned and stretched exactly like the original N64 game, which is like all of them.

[OpenMaw]

I'm not about to presume his motives. It's simple, this is a clearly messed up wall texture that can be fixed in under a minute. Things like signs that are out of alignment and obviously not as they were intended should be fixed to best match the N64 experience. The same for all the Duke Talk that is either absent or using the Duke3D versions instead of the 64 versions. I do not see why there is even a discussion to be had here. If Fox is unwilling to do the work, that's fine, but it should still be done by someone.

[NY00123]

I guess it is about the feeling of preservation of the maps in their original forms, and hopefully find "proper" fixes later (in the sense that the maps do not have to be modified).

On a side note, I have finally found the post where I got introduced to the NPOT tile height support for walls: http://forums.duke4....831#entry131831
(Link found in the Lunatic thread: http://forums.duke4....w-introduction/)

It may not be ready, though. Even after modifying L22.MAP to have a few additional sectors, involving TROR in the way (hence forcing .map version 9), the glitch is still seen in-game.

[Saiyuki234]

Can someone please post some gameplay footage of this mod? (i cant play it because im using Zorin OS, based off of ubuntu and it effing sucks balls and i cant use eduke 32 or play any games on the laptop im using)

[BR4ZIL]

Commando Nukem, on 11 August 2013 - 01:20 PM, said:

I'm not about to presume his motives. It's simple, this is a clearly messed up wall texture that can be fixed in under a minute. Things like signs that are out of alignment and obviously not as they were intended should be fixed to best match the N64 experience. The same for all the Duke Talk that is either absent or using the Duke3D versions instead of the 64 versions. I do not see why there is even a discussion to be had here. If Fox is unwilling to do the work, that's fine, but it should still be done by someone.

Wait, what Duke Talk quotes are missing? i have played through Episode 1 and didint noticed anything diferent from the N64 version.

[Fox]

Commando Nukem, on 11 August 2013 - 01:20 PM, said:

I'm not about to presume his motives. It's simple, this is a clearly messed up wall texture that can be fixed in under a minute. Things like signs that are out of alignment and obviously not as they were intended should be fixed to best match the N64 experience. The same for all the Duke Talk that is either absent or using the Duke3D versions instead of the 64 versions. I do not see why there is even a discussion to be had here. If Fox is unwilling to do the work, that's fine, but it should still be done by someone.

But the map was intended to look like that by the level designers (Bill Beacham and Kev Harvey), if anything the console version that is displaying the texture wrong.

[Micky C]

What if they changed it like that in the map because the console was displaying it wrong and did it to make it right?

[Fox]

But they didn't make it right, this is what it looks like after the ceiling rise:



Like I said, the problem is that they added a cstat of 4 to the wall.

[OpenMaw]

BR4ZIL, on 11 August 2013 - 07:37 PM, said:

Wait, what Duke Talk quotes are missing? i have played through Episode 1 and didint noticed anything diferent from the N64 version.

During the intro he says "Come Get Some" instead of "Holy Cow"

"I think i'll climb aboard" - is the Duke 3D version, not the Duke 64 version.

On San Andreas fault he doesn't say "Holy Cow" instead he says "Come Get Some."

When the battlelord is first revealed in the ship Duke is supposed to say "Eww... Who's your plastic surgeon?"

During the encounter with the overlord Duke is supposed to start the fight by saying "In a perfect world, you'd already be dead!"


And so on.

Fox, on 11 August 2013 - 09:01 PM, said:

But the map was intended to look like that by the level designers (Bill Beacham and Kev Harvey), if anything the console version that is displaying the texture wrong.

It was most definitely not intended to look fucked up. Even in the picture you showed it starts out looking right. It's still not behaving as it should, and we know for a fact what would have been intended there. It looks like shit.

[Mr. Nukem Roses]

this mod is a pretty good one. 99% like Duke 64. the only thing i've found different bout this & the n64 one is that some one-liners are in the wrong place. like it was mentioned. the intro, san andreas fault. and even meeting the babe on the abyss level. Duke says "come get some" instead of "holy cow" i have yet encountered these other problems others are mentioning

[Helixhorned]

Fox, on 11 August 2013 - 08:16 AM, said:

That's not the case, I use a copy of the tile inside the /tiles/temp folder with the proper dimensions for tilefromtexture.

I see, you have three cases where you define that tile:

./art.def:texture 3421 { pal 0 { file "art/3421.png" nocompress nodownsize } }
./textures.def:tilefromtexture 4008 { file "tiles/temp/3421.png" }
./textures.def:texture 4008 { pal 0 { file "tiles/3421.png" nocompress nodownsize } }

I don't yet understand why/whether all of them are necessary, but for now, it seems that you are right: the texture is stretched out along the whole wall (above and underwater) in its initial position, under some invocations of EDuke32.

Quote

Anyway, my point is that the mappers clearly used the Build editor with little modifications, so these aren't what I would call mistakes even if doesn't match the console version.

They used a different engine, right? This is the central point -- the editor is merely a tool built on it. Everyone trying to replicate Build (take Polymer for example) will always have to deal with a lot of corner cases and even inconsistencies, and that's the most likely reason maps don't look 100% the same between Nintendo-Duke64 and EDuke32-Duke64. They simply didn't get the Build rendering completely replicated.

NY00123, on 11 August 2013 - 10:57 AM, said:

Well, that is interesting. The tile's alignment seems to be *ok* within Mapster32. Maybe it already displays things under the assumption the newer .MAP format is in use.
EDIT: Yeah, when I set a wall to have some random tilenum representing a tile with a non-POT height, it is repeating *correctly*, which is surely not the case using the original .MAP format in EDuke32 and DOS Duke.

The new map format is not available as of now and I don't plan to make it available until Lunatic release. Non-POT tiles display "correctly" in the OpenGL modes anyway, but have some (completely backward) hacks to make it appear as if they look like in the classic renderer. Of course, this only works for some cases, not in general. See a detailed discussion here and in following posts.

Saiyuki234, on 11 August 2013 - 01:55 PM, said:

Can someone please post some gameplay footage of this mod? (i cant play it because im using Zorin OS, based off of ubuntu and it effing sucks balls and i cant use eduke 32 or play any games on the laptop im using)

It should be possible to build EDuke32 under any OS providing a decent development environment. Refer to the page on the wiki. If you don't have the necessary OpenGL dependencies, you can still build a non-OpenGL version (see Makefile.common, "USE_OPENGL").

Fox, on 11 August 2013 - 09:51 PM, said:

But they didn't make it right, this is what it looks like after the ceiling rise:

If that's the case, I agree with you. It's best not to touch the maps, but do a detailed analysis of why discrepancies like these happen first. That said, a couple of other points are currently unclear to me (these are more notes to myself than requests to anyone):

• Mapster32 doesn't display the "cat" tile, but the original one. Likely to have something to do with the complicated DEFs.
  
• Loading E3L3 once (e.g. "./duke64.sh -map E3L3" in my setup) actually displays the bottom part correctly! Doing "dnscotty 303" afterwards makes it misaligned. Scratch that, they're all named like "l<number>.map".

[NightFright]

I actually can't tell if the E3L3 sign was showing like that without reloading the map. Should also add that I was playing this on a Samsung NC10 netbook, so it's not your typical hardware. Guess it's possible I reloaded at least once before I was reaching that spot.

[Fox]

Helixhorned, on 12 August 2013 - 01:34 AM, said:

I see, you have three cases where you define that tile:

./art.def:texture 3421 { pal 0 { file "art/3421.png" nocompress nodownsize } }
./textures.def:tilefromtexture 4008 { file "tiles/temp/3421.png" }
./textures.def:texture 4008 { pal 0 { file "tiles/3421.png" nocompress nodownsize } }

I don't yet understand why/whether all of them are necessary, but for now, it seems that you are right: the texture is stretched out along the whole wall (above and underwater) in its initial position, under some invocations of EDuke32.

They are necessary in some way. The first line force the original tile to have highres texture properties (shade and pal). The second line is the new tile, however I was forced to stretch it because I could only get the compressed textures ripped. The last one is the same as the first, but for the new tile.

Helixhorned, on 12 August 2013 - 01:34 AM, said:

If that's the case, I agree with you. It's best not to touch the maps, but do a detailed analysis of why discrepancies like these happen first. That said, a couple of other points are currently unclear to me (these are more notes to myself than requests to anyone):

I am not sure why this is happening, but I think it may have something to do with the SE lo-tag 32 (ceiling rise/fall). But in the end it seems to be more of a level design flaw.

Helixhorned, on 12 August 2013 - 01:34 AM, said:

[*]Mapster32 doesn't display the "cat" tile, but the original one. Likely to have something to do with the complicated DEFs.

That's the hack I am using to allow the censored tiles to be turned off. If you look at the list of tiles, I have moved them to the end of the custom arts. But I left them with the filenames that matches the tiles as they are in the ROM, not the mod.

[MusicallyInspired]

What is the big deal with fixing the texture orientation? Didn't you say yourself, Fox, that you can fix bugs and stuff that was in the N64 version for the mod?