EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#4951 Posted 02 December 2014 - 08:49 PM
#4952 Posted 02 December 2014 - 11:38 PM
#4953 Posted 03 December 2014 - 09:05 AM
r4792-utils.log (19.49K)
Number of downloads: 543
Roma Loom, on 02 December 2014 - 11:38 PM, said:
autoload is broken as of r4658.
#4954 Posted 03 December 2014 - 12:58 PM
Micky C, on 02 December 2014 - 08:49 PM, said:
Yes, in cases that occur with sliding doors, for example.
r4569 said:
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:
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.
#4955 Posted 03 December 2014 - 05:23 PM
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.
#4956 Posted 06 December 2014 - 06:36 AM
Jblade, on 07 June 2014 - 11:35 AM, said:
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:
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:
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:
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:
I'm planning to comment on this, also in light of Lezing's in-game map editor.
#4957 Posted 06 December 2014 - 09:55 AM
Helixhorned, on 06 December 2014 - 06:36 AM, said:
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.
#4958 Posted 06 December 2014 - 10:34 AM
Fox, on 06 September 2014 - 09:02 PM, said:
Fox, on 06 September 2014 - 10:26 PM, said:
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:
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:
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:
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:
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?
#4959 Posted 06 December 2014 - 10:45 AM
#4960 Posted 06 December 2014 - 10:51 AM
Helixhorned, on 06 December 2014 - 10:34 AM, said:
Yeah, it seems to be working now.
Helixhorned, on 06 December 2014 - 10:34 AM, said:
It would work for all wall-aligned and floor-aligned sprites.
This post has been edited by Fox: 06 December 2014 - 10:55 AM
#4961 Posted 06 December 2014 - 11:05 AM
Stabs, on 16 October 2014 - 02:23 AM, said:
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:
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:
Confirmed.
Fox, on 06 December 2014 - 10:51 AM, said:
That's too unspecific. Here's one example of a wall-aligned sprite that should not have repeated texture mode.
#4962 Posted 06 December 2014 - 12:45 PM
Helixhorned, on 06 December 2014 - 11:05 AM, said:
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:
No specific case for it.
Helixhorned, on 06 December 2014 - 11:05 AM, said:
capt0023.png
Yes, but the game already use some masked walls that doesn't look good with repeat:
#4963 Posted 06 December 2014 - 01:09 PM
Fox, on 06 December 2014 - 12:45 PM, said:
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
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:
Should be all right with r4800 again!
#4964 Posted 06 December 2014 - 01:20 PM
Helixhorned, on 06 December 2014 - 01:09 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:
#4965 Posted 06 December 2014 - 01:29 PM
Fox, on 06 December 2014 - 01:20 PM, said:
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.
#4966 Posted 06 December 2014 - 01:46 PM
This post has been edited by Fox: 06 December 2014 - 01:47 PM
#4967 Posted 06 December 2014 - 02:57 PM
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?
#4968 Posted 06 December 2014 - 03:43 PM
TerminX, on 06 December 2014 - 02:57 PM, said:
It's also because the weapon disappear if you switch while it is being raised:
This post has been edited by Fox: 06 December 2014 - 03:44 PM
#4969 Posted 06 December 2014 - 04:13 PM
Fox, on 06 December 2014 - 03:43 PM, said:
I can look into fixing that after TX commits his fix.
#4970 Posted 06 December 2014 - 04:25 PM
This post has been edited by Fox: 06 December 2014 - 04:25 PM
#4971 Posted 07 December 2014 - 12:49 AM
#4975 Posted 07 December 2014 - 01:25 PM
Now, here are some news about a side project I have temporarily resumed... That's the city thing I posted some time ago with building.
Thanks to some help I found here to know how to implement 3d models, the screenshot highlights my very first ones...
Edit: and... the "attach file" button doesn't work. So the features doesn't work anymore you won't see anything :/
This post has been edited by David B.: 07 December 2014 - 01:30 PM
#4976 Posted 08 December 2014 - 02:48 AM
Also, you can add me on Steam if you'd like. I'll accept if you're cool.