![](https://forums.duke4.net/public/style_images/cgs/_custom/switch.png)
EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#4916 Posted 22 October 2014 - 07:19 PM
#4917 Posted 26 October 2014 - 02:08 AM
When playing in polymost, sprites that are floor aligned and on the floor seem to flicker a LOT more (it used to happen but very rarely) when the player is in movement and looking at them. For example try map Storage Wars of Duke Hard (DH07.map), and look at the floor where the player starts while moving in polymost. I just compared with an older version (r4394) and that didn't happen.
This post has been edited by MetHy: 26 October 2014 - 02:09 AM
#4918 Posted 26 October 2014 - 03:06 AM
#4919 Posted 26 October 2014 - 03:25 AM
#4920 Posted 28 October 2014 - 08:37 PM
#4921 Posted 28 October 2014 - 08:57 PM
#4922 Posted 28 October 2014 - 09:19 PM
#4923 Posted 29 October 2014 - 03:00 AM
#4924 Posted 10 November 2014 - 01:30 PM
MetHy, on 03 October 2014 - 02:59 AM, said:
Yes, press TAB.
#4925 Posted 13 November 2014 - 08:00 PM
#4926 Posted 13 November 2014 - 09:03 PM
texture 258 {
pal 0 { file "highres/textures/0258.png" }
normal { file "highres/textures/0258_n.png" parallaxbias 0.0 parallaxscale 0.1 }
specular { file "highres/textures/0258_s.png" }
glow { file "highres/textures/0258_g.png" }
}
#4927 Posted 13 November 2014 - 11:21 PM
You can't change them size they're hard coded. If you want to make new ones, you'd have to write some con code to spawn an SE with the light properties that you want.
Or you can just add them to the map itself, but then you can't change them during gameplay.
#4928 Posted 13 November 2014 - 11:40 PM
chuck bronson, on 13 November 2014 - 08:00 PM, said:
From CON, you'll want to spawn the appropriate SE 49 / SE 50. If the light will be moving, you'll want to update its position in EVENT_ANIMATESPRITES so that it does not appear to stutter.
To change hardcoded sprites, first disable the hardcoded ones using the following, then make new ones using the above.
getactor[THISACTOR].htflags temp orvar temp 256 setactor[THISACTOR].htflags temp
#4929 Posted 19 November 2014 - 10:13 AM
#4930 Posted 19 November 2014 - 11:22 AM
Fox, on 19 November 2014 - 10:13 AM, said:
Er, I think you mean to ask something else -- onevent and endevent are just tokens that delimit the code for a single (type of) event, and those can't be nested. However, events may recurse, i.e. active event code may give rise to another event, even of the same type. Can you provide an example of what problem you want to solve? What kind of entity do you want to impose a fixed ordering on?
#4931 Posted 24 November 2014 - 09:35 PM
This post has been edited by Fox: 24 November 2014 - 09:42 PM
#4933 Posted 24 November 2014 - 10:14 PM
Edit: Nevermind the smooth movement. I guess it's better to leave the Newbeast the same way.
This post has been edited by Fox: 24 November 2014 - 11:21 PM
#4934 Posted 28 November 2014 - 10:57 PM
#4936 Posted 29 November 2014 - 01:18 AM
![:)](https://forums.duke4.net/public/style_emoticons/default/wink.gif)
#4937 Posted 29 November 2014 - 01:19 AM
![Posted Image](http://forums.duke4.net/public/style_emoticons/default/dukecigar.gif)
#4938 Posted 29 November 2014 - 01:29 AM
![:)](https://forums.duke4.net/public/style_emoticons/default/wink.gif)
#4939 Posted 29 November 2014 - 05:30 AM
#4940 Posted 29 November 2014 - 05:59 AM
Then again panda antivirus seems to fucking suck and it looks like it counts as "trojant" most .exe it doesn't know. Just saying.
Also, the mouse pointer appears in the menu, however when I click on something, it doesn't select where the pointer is at, but what's between the 2 nuke symbols (selected by the keyboard or the mousewheel)
Also, I was just testing through Duke Hard (to make sure the episode doesn't stop at map7, which is fine now); and now I found something else that's a little weird.
at the start of the secret map (Parking, dhsl.map, slot 17) the player is brought down by several sloped convoyer belt sectors. I never had any problem with these slopes in any other EDuke32 version (neither did I in classic in megaton); but now the player can get stopped (by the ceiling I think) where 2 sectors meet. It's not a big deal because you just need to press forward to keep going, but it breaks the smooth intro of the map.
I have no idea what could have changed that influences this though.
This post has been edited by MetHy: 29 November 2014 - 06:10 AM
#4941 Posted 29 November 2014 - 07:16 AM
About the cursor, I would prefer if it was not transparent since there is a distinction beetween it and the actual crosshair. I wonder if it would look better if it was scaled to the screen resolution? Perhaps it would be a case where it would be better to not correct the aspect ratio for the tile.
Edit: What exactly is the algorithm used for the menu sliding (x coordinate), for custom menu elements? Currently I am using an aproximation with a sin curve (it's also possible I can't sincronize it properly using totalclock).
This post has been edited by Fox: 29 November 2014 - 11:34 AM
#4942 Posted 29 November 2014 - 12:13 PM
MetHy, on 29 November 2014 - 05:59 AM, said:
Because only the cursor is implemented right now. Stay tuned.
Fox, on 29 November 2014 - 07:16 AM, said:
No, that wouldn't look right.
Fox, on 29 November 2014 - 07:16 AM, said:
Intentional.
Fox, on 29 November 2014 - 07:16 AM, said:
You're on the right track. I think you can detect when an animation is taking place by when current_menu changes, but until everything is exposed to scripting, you'll have to hard-code which animation runs where.
typedef struct MenuAnimation_t { int32_t (*func)(void); Menu_t *a; Menu_t *b; int32_t start; int32_t length; } MenuAnimation_t; static MenuAnimation_t m_animation; int32_t M_Anim_SinRight(void) { return sintable[scale(1024, totalclock - m_animation.start, m_animation.length) + 512] + 16384; } int32_t M_Anim_SinLeft(void) { return -sintable[scale(1024, totalclock - m_animation.start, m_animation.length) + 512] + 16384; } void M_ChangeMenuAnimate(int32_t cm, MenuAnimationType_t animtype) { switch (animtype) { case MA_Advance: m_animation.func = M_Anim_SinRight; m_animation.start = totalclock; m_animation.length = 30; m_animation.a = m_currentMenu; M_ChangeMenu(cm); m_animation.b = m_currentMenu; break; case MA_Return: m_animation.func = M_Anim_SinLeft; m_animation.start = totalclock; m_animation.length = 30; m_animation.b = m_currentMenu; M_ChangeMenu(cm); m_animation.a = m_currentMenu; break; default: m_animation.start = 0; m_animation.length = 0; M_ChangeMenu(cm); break; } }
vec2_t origin = { 0, 0 }; if (totalclock < m_animation.start + m_animation.length) { vec2_t previousOrigin = { 0, 0 }; const int32_t screenwidth = scale(240<<16, xdim, ydim); origin.x = scale(screenwidth, m_animation.func(), 32768); previousOrigin.x = origin.x - screenwidth; M_RunMenu(m_animation.a, previousOrigin); M_RunMenu(m_animation.b, origin); } else M_RunMenu(m_currentMenu, origin);
#4943 Posted 01 December 2014 - 04:07 AM
#4944 Posted 01 December 2014 - 10:51 AM
![Attached File](https://forums.duke4.net/public/style_extra/mime_types/txt.gif)
Number of downloads: 365
Build on Debian is broken as of r4783:
![Attached File](https://forums.duke4.net/public/style_extra/mime_types/txt.gif)
Number of downloads: 365
#4945 Posted 01 December 2014 - 11:23 AM
LeoD, on 01 December 2014 - 10:51 AM, said:
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]}; ^