[Hendricks266]

Fox, on 20 February 2015 - 02:52 PM, said:

Small issue with screentext. If I use 16 bits precision, center aligned texts are offset with precision, making it harder to reproduce the default status bar scaled.

I don't understand.

[Fox]

If I understand what the quick weapon switch option is for, it's not working.

[TerminX]

Fox, on 21 February 2015 - 10:00 AM, said:

If I understand what the quick weapon switch option is for, it's not working.

It works properly, I just forgot to remove it from the PC version.

[Fox]

Nah, I thought it was an option make switching weapons work like in the DOS version. Which would not be a bad idea.

[Micky C]

Has anyone noticed that the engine seems to overestimate the clipping of floors with relatively large slopes? Like if it's sloped upwards, you'd be positioned higher then you should be at the peak of the slope? Is that normal?

[Fox]

I believe that's because the engine calculates the clipping height based on the sprite center, not the highest point of the sloped sector.

[Jblade]

Just a quick question, can I use a sector's .alignto function with relative impunity (as the wiki says it serves no purpose) or is there a limitation to it?

[Helixhorned]

Jblade, on 26 February 2015 - 03:28 AM, said:

Just a quick question, can I use a sector's .alignto function with relative impunity (as the wiki says it serves no purpose) or is there a limitation to it?

Since r4415, that member is used to override a sector's fog pal in the GL renderers.

[Jblade]

Well the TC's built for classic mode so that's not a big problem then, thanks!

[Hendricks266]

I would discourage overloading members of the main game struct. I urge you to use a gamearray of size MAXSECTORS (or numsectors, if you resize after map load) instead.

[Steve 64]

MrRumbleRoses told me think yesterday EDuke32 now has Demo Recording, That awesome news make it easier to record videos now I should update my eduke32

[Helixhorned]

Micky C, on 23 February 2015 - 03:19 AM, said:

Has anyone noticed that the engine seems to overestimate the clipping of floors with relatively large slopes? Like if it's sloped upwards, you'd be positioned higher then you should be at the peak of the slope?

Yes, can confirm that by experiment. See the attached ZIP file which contains a map and a CON file for a small ball that moves back and fowrard across a sloped elevation.

Doing some investigation, one finds that the reason is twofold: (1) the particular way the getzrange engine function handles nearby sectors and (2) the fact that the game calls it with a fixed walldist value for all actors (127, from A_GetZLimits() in gameexec.c) regardless of their actual size.

Attached File(s)

•  getzrange_slope_test.zip (1.48K)
  Number of downloads: 533

[Nukey]

So I was perusing PLAYER.C's processinput() function

came across the code in the first image

seems to still exist in eduke32 (as of Rev 5016 anyway)

what is the purpose of the block highlighted in red?

a short-circuited "klabs(actor[p->i].floorz-actor[p->i].ceilingz) < (48<<8)"

versus an "else if (klabs(fz-cz) < (32<<8) && etc"

second image (seems to) indicate the two klabs() are comparing the same stuff

if that's true, the "else if" could never possibly be executed

i'm not much for reading code; it's completely possible that i am missing something obvious here

sort me out please thanks and strawberries

Attached thumbnail(s)

• 
• 

[Fox]

From what I can understand...

"klabs(actor[p->i].floorz-actor[p->i].ceilingz) < (48<<8)"

If the difference beetween the floor and ceiling heights of the current sector are less than 12288 units.

if (klabs(fz-cz) < (32<<8) && isanunderoperator(sector[p->cursectnum].lotag))

If the difference beetween the floor and ceiling heights of the sector called by processinput is less than 8192 and the the current player sector lotag is that of an operator.

[Nukey]

that's the weird part

if floor and ceiling difference is < 8192

it's guaranteed to be < 12288

i can't imagine how it could ever reach the "else if" block

(given the second image, anyway)

i.e. the block highlighted in red looks like dead code that could never be executed

[Fox]

I assume the hittype floorz/ceilingz may be different from fz/cz. But I am having a hard time understanding it.

[Nukey]

looks pretty much the same in the original source:

Quote

hittype[pi].floorz = fz;
hittype[pi].ceilingz = cz;

i see no assignments, comparisons, or function calls on the 'hittype' stuff (until the block of code in question)

lots of comparisons on fz and cz, but only one assignment operation:

(image - eduke32 source again)

dunno what hz is... maybe this is correcting for slopes or 'true-centering' or something

anyway, i don't think they're different, but i can't say for sure yet

Attached thumbnail(s)

• 

[Hendricks266]

Nukey, on 01 March 2015 - 08:17 PM, said:

second image (seems to) indicate the two klabs() are comparing the same stuff

if that's true, the "else if" could never possibly be executed

Given the second image at the top of P_ProcessInput(), that looks to be the case.

Nukey, on 01 March 2015 - 09:50 PM, said:

lots of comparisons on fz and cz, but only one assignment operation:

The assignment is

getzrange((vec3_t *)p,p->cursectnum,&cz,&hz,&fz,&lz,163L,CLIPMASK0);

A pointer to these variables is passed into getzrange, which dereferences it in order to modify them.

[Nukey]

Hendricks266, on 01 March 2015 - 10:06 PM, said:

Given the second image at the top of P_ProcessInput(), that looks to be the case.


The assignment is

getzrange((vec3_t *)p,p->cursectnum,&cz,&hz,&fz,&lz,163L,CLIPMASK0);

A pointer to these variables is passed into getzrange, which dereferences it in order to modify them.

ya sorry, i was ignoring that one because it's the initial assignment for those variables

i should have said "modified" to be clearer, only cz gets (potentially) modified on the way to the block of code in question

at least that's all i saw on my quick skim through

[Jblade]

Is there any way to make the automap more useful in room over room constructions? Right now it's always just shown the top most sector which can be a nuisance in certain circumstances. I imagine there's probably a good reason why it can't be improved of course, but even just having your current sector take priority over any other in the same space would be a useful change in itself.

[Fox]

Even if it could be improved, I think it's better to stay true to the original in this case. No?

Speaking of the automap, some times it goes black. It seems to happen when you are entering new sectors or palfrom is not zero.

[Jblade]

Quote

Even if it could be improved, I think it's better to stay true to the original in this case. No?

No, because it's useless in maps which use TROR or even just basic ROR that normal Duke supported. Have a client side variable or something if you think it would take from the experience.

[Jblade]

Anyway to disable the UNLOCKED quote when using SE19? I'm not sure how I'd go about doing that in CON code due to the hard-coded nature of the effect.

[Hendricks266]

Jblade, on 15 March 2015 - 02:31 AM, said:

Anyway to disable the UNLOCKED quote when using SE19? I'm not sure how I'd go about doing that in CON code due to the hard-coded nature of the effect.

You can blank out the quote in the CONs, which will turn any function call to display it into a no-op that doesn't affect the currently displayed quote or print a blank line to the log.

[Jblade]

I meant on an individual basis as it's useful for some levels but having it display when SE19 is triggered is a bit annoying. I can manually deactivate it just for that level by checking for that quote and changing it though if we're on a certain level so it's no big deal. Cheers.

[Hendricks266]

I looked in the code and the best I could do is add EVENT_QUOTE, which might be overkill. Instead, you may be able to save the current player[].ftq and fta in EVENT_PREGAME and restore them in EVENT_GAME if the unlocked quote displays when you don't want.

[Fox]

gamevar fta 0 1
gamevar ftq 0 1

onevent EVENT_DISPLAYSBAR
  ifvarg player[THISACTOR].fta 0
  ifvare player[THISACTOR].ftq 8
  {
    setplayer[THISACTOR].fta fta
    setplayer[THISACTOR].ftq ftq
  }
  getplayer[THISACTOR].fta fta
  getplayer[THISACTOR].ftq ftq
endevent

[Hendricks266]

You should make those variables per-player. Also, does EVENT_DISPLAYSBAR run even when "screen size" is maxed out (== no HUD)?

[TheDragonLiner]

A solution for displaying ROR on automap could be the addition of some sort of 3D map display but that would be too far from the original game, besides I wonder if the Build Engine can actualy support something like that ...

[Fox]

Hendricks266, on 16 March 2015 - 10:45 AM, said:

You should make those variables per-player.

Oops.

Hendricks266, on 16 March 2015 - 10:45 AM, said:

Also, does EVENT_DISPLAYSBAR run even when "screen size" is maxed out (== no HUD)?

Yes.