EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#5852 Posted 12 April 2018 - 12:19 AM
#5853 Posted 12 April 2018 - 03:35 AM
#5854 Posted 22 April 2018 - 02:31 PM
But apparently, hitting an enemy with shotgun negates the shotgun spread. I'm sure this is nothing new.
This post has been edited by Trooper Dan: 22 April 2018 - 02:42 PM
#5855 Posted 27 April 2018 - 01:17 AM
EDIT: whilst I'm here, is there a way to lock out skill levels too?
This post has been edited by Jblade: 27 April 2018 - 01:18 AM
#5856 Posted 27 April 2018 - 12:22 PM
#5857 Posted 28 April 2018 - 06:45 AM
#5858 Posted 23 May 2018 - 05:40 AM
I was wondering if these changes have been ported to vanilla eduke, or each engine will be on its own branch.
#5859 Posted 23 May 2018 - 08:48 AM
Mike Norvak, on 23 May 2018 - 05:40 AM, said:
I was wondering if these changes have been ported to vanilla eduke, or each engine will be on its own branch.
They were in EDuke32 first.
#5860 Posted 23 May 2018 - 08:51 AM
This post has been edited by Phredreeke: 23 May 2018 - 08:51 AM
#5861 Posted 24 May 2018 - 04:16 AM
#5862 Posted 24 May 2018 - 10:30 AM
Micky C, on 24 May 2018 - 04:16 AM, said:
We've also been making improvements to the scripting system behind the scenes, which will improve performance for any EDuke32 content that suffers from the same slowdowns, in all renderers.
#5863 Posted 30 May 2018 - 08:53 PM
Is there any command to debug clipshape? maybe something that renders a visible clipshape model?
#5864 Posted 31 May 2018 - 05:03 AM
Load the 0_clipshape.map into Mapster. Then you can type into the console r_pr_wireframe. IIRC it requires being in the Polymer mode.
You can try turning off models from the menu and you will see the black 2D sprite with the model's dummytile dimensions. It should be about the same size as the model if its set up right in the defs.
This post has been edited by Mark.: 31 May 2018 - 05:09 AM
#5865 Posted 31 May 2018 - 03:03 PM
I have my doubts about the precision clipshapes have, and what happens when the model moves, etc. I thought there would be a way to make visible the collision model, just like in other engines, like Source.
#5866 Posted 31 May 2018 - 03:22 PM
Gambini, on 31 May 2018 - 03:03 PM, said:
I have my doubts about the precision clipshapes have, and what happens when the model moves, etc. I thought there would be a way to make visible the collision model, just like in other engines, like Source.
The first thing that comes to mind would be making a "wind tunnel" room with some coded projectiles. Projectiles would fire at the model from all directions and angles, and each hit would leave a small indicator sprite on the point of impact. Over a few seconds, the impact points would accumulate and show the outline of the clipshape.
EDIT: It would be more like a car wash, with shooter sprites set up in many places around the model. Then the shooters would spray it. This could be made pretty easily.
This post has been edited by Trooper Dan: 31 May 2018 - 03:31 PM
#5867 Posted 31 May 2018 - 05:26 PM
#5868 Posted 31 May 2018 - 05:34 PM
Gambini, on 31 May 2018 - 05:26 PM, said:
In many cases, clipshaped actors won't move at all: https://forums.duke4...aps-and-actors/
It may depend on how it is coded and the specific clipshape used.
#5869 Posted 31 May 2018 - 08:01 PM
Still, i am worried my initial question washes away, it´s mainly focused on knowing if there is such thing, or is it even posible to feature in the near future? I believe collision detection and render engine have a close relationship, and may feed from similar inputs. Drawing what the clipshape is like on wireframe should be relatively easy and very functional for testing.
#5870 Posted 01 June 2018 - 03:04 AM
I have the feeling that there’s simply no mechanism in place that can be adapted to drawing equivalent models of the clipmaps. The 2D engine can’t spawn sector geometry for a spite that’s floating in the air or crossing multiple sectors. It can’t really be made of individual spites since those sprites would have to be sloped and of arbitrary, dynamically-generated shape, other than some kind of particle-based system not unlike what Trooper Dan suggested but spawned directly by the model on a per-frame basis.
Model support itself is also pretty limited. TX or someone has said that the engine doesn’t really know what a model is, simply that the renderer is told to show a certain asset. After all, the whole reason that Helixhorned implemented clipshape was because that the engine doesn’t intrinsically know model geometry in the first place. As such, it’s unlikely that the reverse process is going to be a thing. Yes, the engine does know the clipping going on in this case, but again there’s no good mechanism to draw it.
It doesn’t help that Helixhorned, who did the original implementation, is no longer around.
This post has been edited by Micky C: 01 June 2018 - 03:05 AM
#5871 Posted 01 June 2018 - 06:04 AM
This post has been edited by Mark.: 01 June 2018 - 06:06 AM
#5872 Posted 03 June 2018 - 02:25 PM
Anyways, I thought to try EVENT_DISPLAYCAMERAOSD, which of course isn't documented. RETURN is 0 and setting it to -1 does nothing. Next I noticed that THISACTOR in that event has a value, so I thought maybe it was the value of the dummy player sprite. So I thought what the fuck let's just set the picnum of that sprite to Bombshell's picnum and see what happens. Fucking hilarious! Turns out it is the ID of the camera being viewed from, so doing that turned the camera into a Bombshell actor which started running around and shooting monsters. But, since it was still the ID of the active camera, you could see from her eyes through the viewscreen if you took a step back from it.
#5873 Posted 03 June 2018 - 02:44 PM
If you want to get the result you were originally after, ask James. He has like 38 characters in his AMC TC and is able to get cameras to show the proper actor.
#5874 Posted 03 June 2018 - 03:04 PM
Forge, on 03 June 2018 - 02:44 PM, said:
If you want to get the result you were originally after, ask James. He has like 38 characters in his AMC TC and is able to get cameras to show the proper actor.
I have a solution now; I'll check with James later to see if we're doing it the same way.
#5875 Posted 03 June 2018 - 08:23 PM
#5876 Posted 06 June 2018 - 05:37 PM
This post has been edited by PsychoGoatee: 06 June 2018 - 05:39 PM
#5877 Posted 06 June 2018 - 05:43 PM
Trooper Dan, on 03 June 2018 - 02:25 PM, said:
It's used to display CAMCORNER and CAMLIGHT when viewing through a security camera.
#5878 Posted 11 June 2018 - 09:13 AM
Flickering of wall sprites under polymer. When a sprite is placed on a wall, Mapster offsets it a tiny little bit away from the wall when looking at it in 2D mode. That makes it a 50/50 chance that it will flicker in game using Polymer. My solution has been to turn off grid locking and manually drag the sprite a tiny bit further from the wall. Flickering problem solved. But seeing as how I have had to do this many 100's, maybe more than a 1,000 times over the years in all my projects it sure would be nice to have Mapster automatically place new sprites further away.
My suggestion is double the number that is used in that calculation right now. My pic shows the default placement on the left and where I manually drag it to on the right. Just that tiny bit of placement makes the problem go away. For reference in the pic, mapster is set for the smallest grid square.
This post has been edited by Mark.: 11 June 2018 - 09:16 AM
#5879 Posted 13 June 2018 - 10:47 AM
#5880 Posted 13 June 2018 - 12:59 PM
Mark., on 13 June 2018 - 10:47 AM, said:
I'm pretty sure they don't want to make mapster changes based on Polymer glitches. But you could strengthen your case if you could show that the old default distance used in the original maps was larger and did not cause the issue.
Also, I don't have time to do this right now, but one could make a mapster script that would adjust the distances for the entire map all at once so you wouldn't have to do it manually.