[Helixhorned]

LeoD, on 01 December 2014 - 10:51 AM, said:

Build on Debian is broken as of r4783:
r4783-debian.log

Fixed that. The menu errors are better left to Hendricks.

This warning is much more interersting though. TX: maybe we ought to compile with pre-C++11?

Quote

build/src/a-c.c: In function 'void vlineasm4(int32_t, char*)':
build/src/a-c.c:262:32: warning: narrowing conversion of 'vince[0]' from 'int32_t {aka int}' to 'unsigned int' inside { } is ill-formed in C++11 [-Wnarrowing]
     uint32_vec4 vinc = {vince[0], vince[1], vince[2], vince[3]};
                                ^

[Hendricks266]

Helixhorned, on 01 December 2014 - 11:23 AM, said:

The menu errors are better left to Hendricks.

Thanks, I'll handle these.

Helixhorned, on 01 December 2014 - 11:23 AM, said:

This warning is much more interersting though. TX: maybe we ought to compile with pre-C++11?

These are exposed since I removed -Wno-narrowing. They should be fixable by adding a (redundant) cast to each member.

[Helixhorned]

Hendricks266, on 01 December 2014 - 11:29 AM, said:

These are exposed since I removed -Wno-narrowing. They should be fixable by adding a (redundant) cast to each member.

You're right, let's keep it at C++11. They're not "redundant" then, though.

[MetHy]

There seems to be an issue with flickering lights in 4777, for instance this light here (first room of the first map of Duke Hard) would never get THAT dark, I just checked again in an older version to make sure

http://i101.photobuc...zps21af45b7.png

[Hendricks266]

Fox, on 29 November 2014 - 07:16 AM, said:

But I would also make it slide when you open/close the menu in-game for the sake of consistency.

Fox, on 01 December 2014 - 04:07 AM, said:

Nitpicking: shouldn't the menu slide when you confirm to quit to the title?

The menu transitions are not intended to slide to or from nothing. Would the skill menu slide out when you start a new game? It doesn't make sense to me.

LeoD, on 01 December 2014 - 10:51 AM, said:

make OPENGL=0 is broken again as of r4779:
r4779-OPENGL=0-mingw64.log

Fixed.

[Fox]

Now an important issue, it seems to be impossible to properly define when the menu should slide or not. It's not possible to get the necessary information using EVENT_DISPLAYMENU and current_menus, specifically if the game started a "new menu" or is just a continuation of a previsous one. It gets worse because it appears current_menu stores information of the last displayed menu.

[Micky C]

With recent mapster32's I've noticed a lot of maps I'm working on suddenly have a few level 2 errors that weren't there before. Corruptcheck tryfix doesn't do anything, and looking at each error I can't see anything wrong with it. A false alarm?

[Roma Loom]

Is it just me or loading a savegame doesn't load maphacked polymer light sources?

[LeoD]

make utils fails, even more with RELEASE=0 :
 r4792-utils.log (19.49K)
Number of downloads: 665

Roma Loom, on 02 December 2014 - 11:38 PM, said:

Is it just me or loading a savegame doesn't load maphacked polymer light sources?

Can't confirm that, but your issue may be caused by the fact that
autoload is broken as of r4658.

[Helixhorned]

Micky C, on 02 December 2014 - 08:49 PM, said:

With recent mapster32's I've noticed a lot of maps I'm working on suddenly have a few level 2 errors that weren't there before. Corruptcheck tryfix doesn't do anything, and looking at each error I can't see anything wrong with it. A false alarm?

Yes, in cases that occur with sliding doors, for example.

r4569 said:

Mapster32: prototypical checker for wall loops, enabled partially.

Inspired by
http://forums.duke4....post__p__199151
the corruption checker now checks for certain conditions of the loops of each sector. Recall that CW loops are outer and CCW loops are inner.

- If a sector has no or more than one outer loop, count that as corruption (level 4 and 3, respectively).
- (Disabled) For sectors with exactly one outer loop, check that all inner ones are inside it. This is currently not compiled due to an asymmetry of loopinside() for degenerate cases, similar to pre-r3898 inside().

r4580 said:

Mapster32: demote wall check "corruptions" introduced in r4569 to level 2.

The winding of a loop -- with clockdir() -- is determined by examining the two line segments spanned between the points following a leftmost point of the loop. If the loop contains a leftmost point that belongs to the "right" side (as can happen with sliding door constructions), there's a chance that an outer loop is misclassified.

[Micky C]

They don't involve sliding doors though, as far as I can tell they're completely random vertices that have nothing wrong with them and behave normally.

Btw Hendrick's flipvert mapster32 script is giving me an error in newer builds. Mapster told me to email Helixhorned but I think posting it here will suffice

--- Compiling: flipvert.m32 (3906 bytes)
flipvert.m32: In state `flipvert':
flipvert.m32:131: error: symbol `tilesizy' is neither an array name nor one of `(t)sprite', `sector', `wall' or `light'.
            set k tilesizy[k]
            |------------->* 
 
--- Found 1 errors.

[Helixhorned]

Jblade, on 07 June 2014 - 11:35 AM, said:

Would it be possible to determine if a player has line of sight with any part of a sector?

Internally, classic and Polymost use a bit-array gotsector[] during which stores whether a particular sector has been collected for rendering so far. We could devise some API to query it at an appropriate point, for example in EVENT_DISPLAYROOMS (returning the value of the last render, not the pending one). There's also gotpic[], but that seems to be cleared once at map entry and then have bits only set, almost never cleared.

Jblade, on 22 June 2014 - 06:15 AM, said:

How does the base game's AI work? is there an article or something somewhere?

If you feel comfortable reading EDuke32 source code, you could follow references to AC_MOVFLAGS and variables derived from it, such as 'movflags'.

Fox, on 23 June 2014 - 01:31 AM, said:

So, has anyone looked over this?

Won't be "fixed". Why should a wall-aligned sprite care about its neighbors in such a manner? It would introduce unnecessary complexity.

Jblade, on 27 June 2014 - 04:04 AM, said:

Is it possible for you guys to add a showview command that only updates it's view by a specified tick count, if such a thing is possible?

That's an interesting idea, and also one I had contemplated in another context, namely having IVF videos play in-game. For showview-generated frames, they'd have to be kept in some auxiliary buffer during frames where there is no real update, so again some scaffolding and API needs to be devised.

Fox, on 27 June 2014 - 01:18 PM, said:

Would it be feasible to insert new sector/walls via CON? I can't think of why not, at least in a premap state.

I'm planning to comment on this, also in light of Lezing's in-game map editor.

[Fox]

Helixhorned, on 06 December 2014 - 06:36 AM, said:

Won't be "fixed". Why should a wall-aligned sprite care about its neighbors in such a manner? It would introduce unnecessary complexity.

I am talking merely about the texture filter repeating the borders of flat sprites.

If even the original maps occasionally use sprite to build 3D structures, it seems weird for it to have a different filter of walls/floors. While it may not work so well with some textures – the same applies to some textures used in walls or floors. So I believe it would be consistent to use the repeat the borders for the linear filter in both cases.

[Helixhorned]

Fox, on 06 September 2014 - 09:02 PM, said:

I was wondering, would it be possible to change the size of an array when a map is loaded?

Fox, on 06 September 2014 - 10:26 PM, said:

Edit: It seems to not be working for the current map.

This works as expected for me, both in C-CON and LunaCON:

gamevar tmp 0 0
gamearray tmpar 4096

onevent EVENT_ENTERLEVEL
    resizearray tmpar NUMSECTORS
    setvarvar tmp NUMSECTORS
    setarray tmpar[tmp] 0  // error
endevent

MetHy, on 24 September 2014 - 10:59 AM, said:

I've been playing some Duke3D in Dosbox lately, and I keep having the feeling that in some situations the player can switch weapons faster in EDuke32 than he could in the original game.

This seems like a serious departure from original Duke3D, indeed. This instant-switching gives you an advantage especially for weapons with a long cycle, such as the shotgun. (E.g. shoot, then switch to RPG.)
I propose to make switching policy configurable per-player, say player[].weapswitchflags. In a multiplayer game, the owner could decide whether to allow different values of .weapswitchflags across peers.

MetHy, on 30 September 2014 - 09:06 AM, said:

I just reinstalled v1.3 in DOSBox, and I really didn't remember that you can't kick slimers trying to eat you in v1.3. I actually kind of like that, it makes them more dangerous and annoying enemies rather than how useless they are in 1.4.

That's really pretty neat, and I vaguely remember it now, too. But as far as these micro-options go, I'm rather for making them available via scripting mutators. Btw, can you or someone else who feels "responsible" for this subject create a new thread, maybe in the Bug reports section? I think that these issues deserve to be discussed, and I slowly have a hard time keeping all of them in my head.

Hendricks266, on 25 September 2014 - 08:02 AM, said:

The mousewheel behavior should probably be a cvar anyway... it might help the original demos run in sync.

No, syncing to the original demos is hopeless. Too many accumulated changes that affect the game state evolution. Keyword "butterfly effect".

Fox, on 06 December 2014 - 09:55 AM, said:

I am talking merely about the texture filter repeating the borders of flat sprites.

Ah, I see. You're right, disambiguating textures by whether they can be seamlessly placed side-by-side and setting the GL texture mode accordingly might be a worthy endeavour. But where would this bit of information come from?

[brullov]

Hey guys, I've just updated my EDuke32 and now I've got this with my dear voxels:

[Fox]

Helixhorned, on 06 December 2014 - 10:34 AM, said:

This works as expected for me, both in C-CON and LunaCON:

Yeah, it seems to be working now.

Helixhorned, on 06 December 2014 - 10:34 AM, said:

Ah, I see. You're right, disambiguating textures by whether they can be seamlessly placed side-by-side and setting the GL texture mode accordingly might be a worthy endeavour. But where would this bit of information come from?

It would work for all wall-aligned and floor-aligned sprites.

[Helixhorned]

Stabs, on 16 October 2014 - 02:23 AM, said:

So weirdest thing happened today, i was playing e1l1 and was enetering the cinema through the whole in the wall at the ticket booth, and iam not sure what happened, i must of hit and angle just right near the crack in the wall and it teleported me into the secret room above in SoS

Er, but that upper secret area overlaps with the right-hand portion of the area with the cardboard-like wall:



Do you want to say that you somehow managed to get into there by squeezing yourself at the left-hand side so that the x/y coordinates were also changed?

Fox, on 22 October 2014 - 07:19 PM, said:

This is purely hypothetical, but I have been wondering if it would be a possibility to have a table for negative shade values? Aka a light table.

In principle, yes, the shade table could be extended "downwards". What would be a killer use case? I can currently only think of something bloom-like, but is that worth the trouble?

Artem Nevinchany, on 06 December 2014 - 10:45 AM, said:

Hey guys, I've just updated my EDuke32 and now I've got this with my dear voxels:

Confirmed.

Fox, on 06 December 2014 - 10:51 AM, said:

It would work for all wall-aligned and floor-aligned sprites.

That's too unspecific. Here's one example of a wall-aligned sprite that should not have repeated texture mode.

[Fox]

Helixhorned, on 06 December 2014 - 11:05 AM, said:

Er, but that upper secret area overlaps with the right-hand portion of the area with the cardboard-like wall:

duke0003.png

Do you want to say that you somehow managed to get into there by squeezing yourself at the left-hand side so that the x/y coordinates were also changed?

Eduke32 has been having some warping glitches for quite some time. It happened to me a lot in Lunatic Fringe.

Helixhorned, on 06 December 2014 - 11:05 AM, said:

In principle, yes, the shade table could be extended "downwards". What would be a killer use case? I can currently only think of something bloom-like, but is that worth the trouble?

No specific case for it.

Helixhorned, on 06 December 2014 - 11:05 AM, said:

That's too unspecific. Here's one example of a wall-aligned sprite that should not have repeated texture mode.

capt0023.png

Yes, but the game already use some masked walls that doesn't look good with repeat:

[Helixhorned]

Fox, on 06 December 2014 - 12:45 PM, said:

Eduke32 has been having some warping glitches for quite some time. It happened to me a lot in Lunatic Fringe.

Sure, these warping "bugs" are there since Duke3D -- there was even a French Dukematch team in honor of them -- but I was specifically asking whether Stabs "bug-teleported" from the left hand side of that area to the upper secret area overlapping with the right-hand side, which would seem a novelty. Usually, you'd get warped to a different sector with the same x/y location (updated at most by player velocity).

Quote

Yes, but the game already use some masked walls that doesn't look good with repeat:

Those stray lines you're seeing in classic mode have a different cause, namely a precision issue. Your suggestion is about the GL modes though, as far as I can see.

Artem Nevinchany, on 06 December 2014 - 10:45 AM, said:

Hey guys, I've just updated my EDuke32 and now I've got this with my dear voxels:

Should be all right with r4800 again!

[Fox]

Helixhorned, on 06 December 2014 - 01:09 PM, said:

Those stray lines you're seeing in classic mode have a different cause, namely a precision issue. Your suggestion is about the GL modes though, as far as I can see

I was just pointing out an use of masked wall that wouldn't look good with linear filter. Maybe I should have taken a screenshot in OpenGL mode to begin with:

[Helixhorned]

Fox, on 06 December 2014 - 01:20 PM, said:

I was just pointing out an use of masked wall that wouldn't look good with linear filter. Maybe I should have taken a screenshot in OpenGL mode to begin with:

Well yes, isn't that the same example as my ship's wheel? That's the reason why for sprites, it's clamping texture mode by default. We agree, then, but aren't you supposed to provide arguments in favor of your proposal (that is, to make repeating the default mode for wall/floor-aligned sprites)? I'm confused.

[Fox]

I am just saying it would be consistent, there are many cases where it doesn't look good with walls or masked walls too. Ideally it should be defined manually via def...

[TerminX]

Being able to switch weapons after firing but before the weapon has finished cycling is a bug, not by design... I've just tracked it down to something being commented out for testing ~4 years ago and accidentally committed in a large commit with the message "global thermonuclear code rape". Oops.

All this time when people were complaining about weapon switching speed, I thought they were talking about a separate intended change, which lets you switch weapons when in the middle of another weapon switch. That change isn't going anywhere (and no option to disable it and make the mousewheel useless will be accepted) but I will definitely fix being able to do stuff like switch weapons in the middle of cocking the shotgun, etc. I will probably revert it back to requiring p->kickback_pic == 0 again. Any objections?

[Fox]

TerminX, on 06 December 2014 - 02:57 PM, said:

All this time when people were complaining about weapon switching speed, I thought they were talking about a separate intended change, which lets you switch weapons when in the middle of another weapon switch.

It's also because the weapon disappear if you switch while it is being raised:

[Hendricks266]

Fox, on 06 December 2014 - 03:43 PM, said:

It's also because the weapon disappear if you switch while it is being raised:

I can look into fixing that after TX commits his fix.

[Fox]

On that, currently if you switch weapon while weapon_pos is greater than zero, it is set to 10. Instead it should multiply the value of weapon_pos by -1 if it is smaller than 10.

[Jblade]

Just a quick question/request - at the moment I modify the player's horiz to simulate screen shaking when weapons are fired, but of course this means that the player's shots are off-target when firing a fast firing weapon. Is there a way to change the player's apparent viewing horizon without actually effecting it physically?

[Fox]

Camerahoriz.

[Jblade]

oh yeah, I forgot about that. cheers.

[Lunick]

This doesn't contribute to the thread but, I love Fox.