[Radar]

Thank you sir. It would be nice if there was a way to do them all at once, but this will do.

[LAW]

Is there a maximum number of locators the train can follow without causing errors in Eduke? I have a train with over 100 locators and after one full pass, the train starts running in circles like a mad

[Forge]

start deleting them one at a time and come back with what you found. then we'll all know.

[ck3D]

i need someone to give me pointers on the different video modes for duke 3D because i am terrible at remembering what does what on the technical side and i am not too knowledgeable about graphic cards either.

the main issue i am having is that i have built maps (released and unreleased) on a laptop before that looked the way they were supposed to on that computer, but on my home computer they look a lot darker, some locations are almost pitch black whereas they are fine and well lit on the laptop. is that solely a matter of monitor brightness (i don't even know which one i should trust then ?) or could it be related to graphic card differences ? should i just brighten up everything in my map in the editor on my home computer to make sure it is compatible with every monitor ? also it might be that i am using different video modes by mistake, i think i am using polymost on the laptop (32 bpp with polymer unchecked) but then the textures look a little more hi-res than in classic mode (and the palettes are different too), whereas on my home computer it all looks like classic mode regardless of what video mode i am using (i just get massive lags if i ever check the polymer box due to the lights being cast by fires and stuff which is the only difference i can tell).

note that on my home computer i just updated my version of eduke32 (which was years old due to technical reasons) to the latest snapshot. the version of eduke32 i am using on the laptop is slightly older by a few weeks. i am under the impression than everything looks even darker on my home computer now that i have updated my old snapshot, but i might be delusional. has anyone a clue as to what's going on ?

[Radar]

So you mean to say that your pitch black maps like Anorak City were unintentional all this time? MIND = BLOWN

[ck3D]

anorak city was supposed to be dark but not pitch black. as far as i remember it came out at the exact same time as a new revision of eduke32 that made any texture in a map with a value darker than 25 render as pitch black, which ruined a lot of the nuances i had put into it. but i was never too sure if it only happened in certain video modes, or if it was a general thing. in fact as you can see, i am very confused about how those video modes work. it seems like i never get the same results and looks from computer to computer, especially not on my home computer in fact.

on the other hand i did face a problem with my map wide awake. i made it on a laptop on which it looked the way it was supposed to, and it was bright enough and the visibility was more than fair. but as soon as i imported it on my home computer it was very very dark and the visibility was off and down, by quite an awful lot. i never really knew how other people played that one, i mean, how it looked on their computers, if the buildings looked pitch black or what. even the screenshots on different reviewing sites look different, is it again because whoever took them was playing in a certain video mode ? i mean it could be the notorious 8-bit / 32-bit thing where maps look slightly darker in one mode than in the other one (and parallexed skies do not render the same either), but how come it all looks the same and all dark on my home computer regardless of the setting i am using ?

[Hendricks266]

ck3D, on 09 July 2013 - 07:07 AM, said:

as far as i remember it came out at the exact same time as a new revision of eduke32 that made any texture in a map with a value darker than 25 render as pitch black, which ruined a lot of the nuances i had put into it.

If you still have the version with the ruined nuances, I could write an m32script to shift the shade values lighter so the nuances return.

[Gambini]

ck3D, on 09 July 2013 - 05:50 AM, said:

i need someone to give me pointers on the different video modes for duke 3D because i am terrible at remembering what does what on the technical side and i am not too knowledgeable about graphic cards either.

Anybody with no bias on their prefered renderer knows that the Software mode is the reference point, which all other renderers and modes should imitate as accurate as possible. This has not been always the true, Open-GL modes have been through multiple alterations over the years, and there were so many shading variants that you should figure the mess it is to pick a map from, say 2008, and try to make it look like it looked back then.

For you, being not too bothered by technological advancements, it will be easier to just stick to software mode -when it comes to shading-
Since I remember you have not been able to use polymost for many years. Until your computer crapped or something. This means all your maps prior that were built for software, which is the best, because if they were built for something else, they would be surely fucked up now.

Now if you built more maps after that, and you were using Polymost (which you likely did) they may look too dark or too bright now since Polymost has been altered many many many times. So, in order to ensure that all your maps have an equal shading be sure to launch the game (or mapster) in 8bpp, and then fix the shading for it. Then get updated builds for both your labtop and desktop pc and see if they still look like they should when running 32bpp.

[Mikko]

For years it didn't really help that the Software mode was very dark by default and the gamma/brightness switches didn't work.

[Radar]

When was it fixed?

[Helixhorned]

Mikko_Sandt, on 10 July 2013 - 02:57 AM, said:

For years it didn't really help that the Software mode was very dark by default and the gamma/brightness switches didn't work.

Um, that's with almost certainty an issue with the driver and/or the video interface (e.g. on SDL 1.3, gamma doesn't work last time I checked). The experience with NVidia cards goes like this for me:

• Windows XP: gamma controls work OK
  
• Windows 7: gamma controls don't work in fullscreen, but do in windowed mode (you can disable borders to get pseudo-fullscreen, which as a bonus also runs better)
  
• Linux: gamma controls work, but I'm always setting up a borderless window as it's not exactly easy to get an 8-bit fullscreen mode

Now, on ATI cards the situation might be different, but I can't say for sure because I don't own such a machine. On the occasional tests with my brother's PC (ATI/Vista), gamma controls did not work everywhere, but I haven't tested the borderless window trick.

Bottom line: classic is the reference. Color correction like gamma should ideally be set up using some sort of reference image, such as those found on the web. As usual with such system-specific stuff, your mileage may vary.

[ck3D]

Hendricks266, on 09 July 2013 - 11:17 AM, said:

If you still have the version with the ruined nuances, I could write an m32script to shift the shade values lighter so the nuances return.

thank you for your proposal of help which i really appreciate, although it appears the way i expressed myself might have led to some confusion, the version of the map i released is the only one i ever made and was the one that people ended up complaining about because of the darkness post-release, sometimes going as far as saying as some areas were 'pitch black'. i didn't understand why at first seeing as it looked just right on my computer - mind you, it was back in early 2011 and even back then i had not updated my version of eduke in a while (because the newer versions wouldn't support OpenGL on my graphic card, basically for the longest time i had to stick with an older eduke snapshot ran through a .bat file in order to use the 'forcegl' command for 32 bit mode to work on that computer). i only understood what everyone meant when someone posted screenshots and informed me of how a recent update of eduke32 had changed how shading values worked and made it so that from then on, any texture in a map with a shade value over 25 would just be rendered as pitch black in 32 bit, which was a new thing back then. seeing as the map (as well as a lot of my former maps) had some very dark places with a lot of subtle nuances over the 25 mark nonetheless (in classic mode, textures are still distinguishable over a range of values greater than 25), i was screwed. brightening up the shade values would not help because it would ruin the original look i intended in classic mode, in addition to not looking right in 32 bit already.

sorry if i am typing a lot of gibberish and i am misinformed when it comes to the history of eduke32 snapshots and how they started treating shading values differently in certain modes, i don't mean to be inaccurate and maybe some of the stuff i am saying is coming off as nonsense from a technical point of view. it's just that i have only got to update my eduke32 a few times ever since the port came out, and it seems like shading values were always treated differently, plus i have used mapster / duke 3D on so many computers with different graphic cards and monitors that i am confused, from my point of view as a strict user i just don't understand why there are so many differences. for instance i am still puzzled as to why 8 bit and 32 bit look the exact same on my home computer, whereas they certainly don't on some others i have tried ? sometimes the game looks dark and grainy just like classic mode when it's actually ran in 32 bit, some other times the textures look perfectly smooth with brighter shades ? could that be related to the graphic card on my home computer that has a hard time supporting polymost, and thus 'reverts back' to classic mode whenever it is ran in 32 bit ? (but it renders polymer lights fine)

ps. if that helps it appears that the graphic card on my computer is indeed an ATI card

[Mikko]

ck3D, on 11 July 2013 - 05:05 AM, said:

sometimes the game looks dark and grainy just like classic mode when it's actually ran in 32 bit, some other times the textures look perfectly smooth with brighter shades ? could that be related to the graphic card on my home computer that has a hard time supporting polymost, and thus 'reverts back' to classic mode whenever it is ran in 32 bit ? (but it renders polymer lights fine)

Note that recent EDuke32 snapshots have r_usetileshades set to 1 by default, which makes the game look more "dark & grainy".

[Mark]

I seem to remember that there is a setting to determine how far an enemy will sink into a non submersible water sector but I don't remember what it is.

[DavoX]

I really really need that the SE 8 (Upen door Up lights) modifies also the shading of wall alligned sprites. Is there a way to achieve this? either normally or with con code?

[Fox]

Mark., on 13 July 2013 - 05:23 AM, said:

I seem to remember that there is a setting to determine how far an enemy will sink into a non submersible water sector but I don't remember what it is.

I don't know if there is a setting, but I believe they sink 5120 units by default.

[necroslut]

Is there a way to make sprites blockable but not hitscan, like you can with mask walls? I'm making a multi-floor location using spritework and want to have fences you can shoot through but not walk through.

[blizzart]

I'm not sure, but making sprites invisible could help.

You can use them to block the player.

[necroslut]

blizzart, on 03 November 2013 - 02:44 PM, said:

I'm not sure, but making sprites invisible could help.

You can use them to block the player.

Yeah but making them blocking will also make them hitscan? I'd like to have them blocking movement but not bullets/projectiles...

[Forge]

necroslut, on 03 November 2013 - 11:07 AM, said:

Is there a way to make sprites blockable but not hitscan, like you can with mask walls? I'm making a multi-floor location using spritework and want to have fences you can shoot through but not walk through.

you mean like a fence? The player can shoot through it, jump over it, but not run through it?

Don't think so. You can put blocking walls around them, which allow shooting through, but that will prevent the player from jumping over/going under

[Hendricks266]

You can shoot through transparent areas of a tile (like a fence) with use of the "texhitscan" tilefromtexture token.

[necroslut]

Hendricks266, on 03 November 2013 - 09:08 PM, said:

You can shoot through transparent areas of a tile (like a fence) with use of the "texhitscan" tilefromtexture token.

I don't want to use any "special stuff" for this map though, but it's good to know for future projects.
It does seem however like the basic fence texture (#913) is hardcoded to be non-hitscan no matter what you set it to (when used as a sprite, not a texture) :l so I guess I'll just have to use that one.

[Fox]

necroslut, on 03 November 2013 - 11:07 AM, said:

Is there a way to make sprites blockable but not hitscan, like you can with mask walls? I'm making a multi-floor location using spritework and want to have fences you can shoot through but not walk through.

No. Unfortunately, Duke 3D is hard-coded to automatically make "solid" sprites "hitable" when the map is loaded.

[necroslut]

Fox, on 03 November 2013 - 10:28 PM, said:

No. Unfortunately, Duke 3D is hard-coded to automatically make "solid" sprites "hitable" when the map is loaded.

Yeah, I noticed... with the exception of #913. I guess you could do something with .con also.

[Helixhorned]

On spawn, the MASKWALL* sprites keep cstat bits 32, 16, 8 and 4, and unconditionally set bit 1 and clear the remaining ones:

// game.c, in A_Spawn()
        case MASKWALL1__STATIC:
(...)
        case MASKWALL15__STATIC:
            j = sp->cstat&60;
            sp->cstat = j|1;
            changespritestat(i, STAT_DEFAULT);
            break;

As EVENT_SPAWN is run after this hard-wired code, you could set or clear desired bits there, though if you want to know whether they are set/cleared in the map, you'd have to back up the values from somewhere before the premap spawn (such as EVENT_LOADACTOR).

[necroslut]

Mark., on 13 July 2013 - 05:23 AM, said:

I seem to remember that there is a setting to determine how far an enemy will sink into a non submersible water sector but I don't remember what it is.

I also seem to remember something like this but can't find anything in any of the FAQ's I've checked. Are we remembering incorrectly?

[Mark]

No. I remember reading about it on the forums when I was making my first map.

After thinking it over, I think it controlled how far the player sinks down, not the enemies. If that's the case I don't need the info any more.

[Bruno]

Hello !

I need some help for my introduction "cutscene" map for my Dukeplus remake of E1M1.

I want to finish this cutscene without seeing the HUD and "without seeing from duke eyes". After my last SE camera, it should be the end of the map. But it doesn't. Indeed, After last camera, it began to play "in duke eyes"... And I try with a sector 66535, but it doesn't work as I want to (Just after the map was loading, it makes the map ending..............)

Is there any code for an end SE camera ? or whatever... thanks.

sorry for my poor English skills.

[RichardStorm]

Anything odd to know about sprite.extra ? sometimes i get 0 using getactor[whatever].extra... i set it via mapster... nothing overrides extra value ...

[Fox]

I believe that for some actors, such as Sector Effectors, .extra is used for other functions.