[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: 282

[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.

[Micky C]

 thedrawliner, on 16 March 2015 - 10:48 AM, said:

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 ...

Mapster already has the isometric view, but it's not textured. It'd probably be too complicated to be useful anyway even if it was textured, at least for those maps which are already too complicated for the regular 2D map.

[Nukey]

 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.

I recall that Two-Way Trains have the unique ability to trigger ActivatorLocked sprites without displaying the "unlocked" quote, but I couldn't find a way to get this working with SE 19. I dug through the code a bit and it looks pretty much impossible via "classic" methods. You might find that info useful for other effects though.

[Nukey]

first pic also looks vestigial... came across it in "GAME.C"

and another in the second pic (executes, but looks useless)

and a third! the "else" should never be able to execute

for future reference, are these things worth posting so they can be marked with comments in the source, or should i just be ignoring them?

i will have to dig through the source properly someday, there must be hundreds of lines of code like these.

Attached thumbnail(s)

• 
• 
• 

[Fox]

There is no instance in the original levels which a barrel is squished. But it works for User Maps.

[Nukey]

Ah right, for some reason I had checked GAME.CON for the latter two cases, but forgot about that first one.

[TerminX]

Second example looks like it's just marking it with a tag so that the neartag() function can find it. The third is interesting... if you look directly below the WATERBUBBLE__STATIC case label there's a check for APLAYER, clearly indicating that the APLAYER__STATIC case above once fell through.

[Nukey]

I agree, the first APLAYER block probably fell through at one point, which would nicely explain why that "else" exists.

I am a bit confused on the second part though. Maybe I'm reading it wrong.

It looks like the "if (j >= 0 && sprite[j].picnum == APLAYER)" part doesn't depend on the previous case falling through, since it's checking (what I assume to be) the owner sprite that is spawning the bubble, instead of sp->picnum directly

[Fox]

Indeed. I assume that at some point there was another case which was removed.

[TerminX]

Oh, oops, you're right--I read the j as an i.

[Fox]

Is there an easy way to render a md3 like the ones used by Eduke? For example, if I wanted to create sprites from the Liztroop HRP model from all five angles and for all animation frames.

[Mark]

You could load the model into most modeling programs and take screen caps as you rotate the model. I did that when Teamonster sent me his Duke model for beta testing. Its time consuming but possible. If there is an easy to use all-in-one program solution I am not aware of it.