EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#5131 Posted 27 January 2015 - 07:52 PM
It shouldn't break any existing mod, since .screen_size would remain the same and what would change is .althud (the menu option being removed).
This post has been edited by Fox: 27 January 2015 - 07:53 PM
#5132 Posted 30 January 2015 - 05:12 PM
#5133 Posted 02 February 2015 - 01:45 AM
#5134 Posted 02 February 2015 - 06:15 AM
DavoX, on 30 January 2015 - 05:12 PM, said:
It's the OS playing the sound, right? It's probably an SDL2 issue. I'll see if there's anything I can do.
Jblade, on 02 February 2015 - 01:45 AM, said:
Sure, that will be no trouble.
#5135 Posted 04 February 2015 - 01:34 PM
#5136 Posted 04 February 2015 - 03:13 PM
Jblade, on 04 February 2015 - 01:34 PM, said:
It should be.
#5137 Posted 05 February 2015 - 02:32 AM
#5139 Posted 05 February 2015 - 08:44 AM
Fox, on 15 November 2013 - 01:55 PM, said:
if (dasectnum < 0 || ((actor[spritenum].actorstayput >= 0 && actor[spritenum].actorstayput != dasectnum) || (spr->picnum == BOSS2 && spr->pal == 0 && sector[dasectnum].lotag != ST_3) || ((spr->picnum == BOSS1 || spr->picnum == BOSS2) && sector[dasectnum].lotag == ST_1_ABOVE_WATER) // || (sector[dasectnum].lotag == ST_1_ABOVE_WATER && (spr->picnum == LIZMAN || (spr->picnum == LIZTROOP && spr->zvel == 0))) )
What's the reason for that line being commented out? That's what is causing the issue with Troopers and Enforcers walking in water sectors.
That was not the reason for enforcers wrongly walking on water. First, note that the condition effectively checks whether an actor should stay put in its sector in the second line; the following ones are just special cases (Cycloid Emperor not leaving arena, other bosses not walking into water sectors). This has nothing to do with "dipping" into water or not. The line was commented out because otherwise, lizmen and z-stationary liztroops are prevented from leaving an ST1 sector by A_MoveSpriteClipdist().
The reason for the enforcers -- and maybe other actors -- wrongly walking on water was that there was that the z position of a sprite was updated in at least two locations, and in an inconsistent manner. First, in MV_Fall(), there is a check for whether an actor should dip into water: this is only the case if
- it's allowed to do that (more on that below),
- has jumptoplayer_only (bit 512) movflag clear, and
- currently has a zero vertical velocity.
Second, there was z updating in VM_Move(), but without handling the dipping special case.
The recent revisions check whether an actor may dip into water in VM_Move(), too, fixing the above-mentioned issue. While this is yet another departure from original behavior, having things consistent seems to outweigh this concern. I have also added a new spriteflag, SFLAG_NOWATERDIP, doing what it sounds like.
I'd be curious to hear whether it fixes any (or preferably, all) real problems.
#5140 Posted 05 February 2015 - 04:00 PM
Jblade, on 17 January 2015 - 01:22 AM, said:
onevent EVENT_ANALYZESPRITES (...) for i drawnsprites { set j tsprite[i].owner switch sprite[j].picnum case 1404 // FAKE PLAYER ife sprite[j].extra 0 set tsprite[j].picnum 5245 // James // Helix: NOTE THIS LINE (...) endswitch } endevent
You want to write
tsprite[i],
not
tsprite[j].
I haven't been able to reproduce the L5 corruption, though, which would clearly be a Mapster32 bug.
#5141 Posted 05 February 2015 - 09:12 PM
Line 252, rotatespritea: invalid coordinates: -21430272, 3145728
What are the limits?
#5142 Posted 06 February 2015 - 02:46 PM
Micky C, on 05 February 2015 - 02:32 AM, said:
Hendricks266, on 05 February 2015 - 06:03 AM, said:
Example? What I'm trying to do is change the visibility of sectors under a sky.
#5143 Posted 06 February 2015 - 02:54 PM
ifand .cstat 16 <do whatever>
I want to test if sector #k has a parallax sky.
ifand sector[k].ceilingstat 1 <do whatever>
#5144 Posted 06 February 2015 - 11:04 PM
I took a look at the source. If I understand it, the issue would be solved by replacing this:
if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_CHECKATRELOAD) { if (PWEAPON(snum, p->curr_weapon, WorksLike) == TRIPBOMB_WEAPON) { if ((*kb) >= PWEAPON(snum, p->curr_weapon, TotalTime)) { (*kb) = 0; P_CheckWeapon(p); p->weapon_pos = WEAPON_POS_LOWER; } } else if (*kb >= PWEAPON(snum, p->curr_weapon, Reload)) P_CheckWeapon(p); } else if (PWEAPON(snum, p->curr_weapon, WorksLike)!=KNEE_WEAPON && *kb >= PWEAPON(snum, p->curr_weapon, FireDelay)) P_CheckWeapon(p);
With this:
if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_CHECKATRELOAD && PWEAPON(snum, p->curr_weapon, WorksLike) == TRIPBOMB_WEAPON) { if ((*kb) >= PWEAPON(snum, p->curr_weapon, TotalTime)) { (*kb) = 0; P_CheckWeapon(p); p->weapon_pos = WEAPON_POS_LOWER; } } else if (PWEAPON(snum, p->curr_weapon, Flags) & WEAPON_RELOAD_TIMING && *kb >= PWEAPON(snum, p->curr_weapon, Reload)) P_CheckWeapon(p); else if (PWEAPON(snum, p->curr_weapon, WorksLike)!=KNEE_WEAPON && *kb >= PWEAPON(snum, p->curr_weapon, FireDelay)) P_CheckWeapon(p);
This post has been edited by Fox: 06 February 2015 - 11:18 PM
#5145 Posted 07 February 2015 - 10:25 AM
Fox, on 10 January 2015 - 09:22 AM, said:
Correct, but incomplete. The other command that's technically redundant is globalsound. Contrary to what its name suggests, it doesn't start playing a special kind of sound, but rather a normal 3D sound from the position of the current player's sprite, provided that the current player is the one whose scene is currently displayed on the screen, or there's a coop game in progress:
case CON_GLOBALSOUND: // (checking omitted...) // (#ifdef SPLITSCREEN_MOD_HACKS omitted...) if (vm.g_p == screenpeek || (GametypeFlags[ud.coop]&GAMETYPE_COOPSOUND)) A_PlaySound(*insptr, g_player[screenpeek].ps->i);
#5146 Posted 07 February 2015 - 10:36 AM
Fox, on 16 January 2015 - 10:36 AM, said:
The globalsound command does not act differently depending on the current actor. (It does depending on current player, as explained in my preceding post.)
Maybe it would be helpful to phrase your request as what feature you're trying to achieve directly, not how. See XY problem.
#5147 Posted 07 February 2015 - 10:58 AM
Practical example:
onevent EVENT_SOUND ifvare RETURN BOS1_RECOG ifactor BOSS1 ifspritepal 0 setvar RETURN BOS1_SPEECH endevent
This is not possible because BOS1_RECOG is a "globalsound". Since the primary purpose of EVENT_SOUND is to manipulate hard-coded sounds, this would make sense in my opinion.
This post has been edited by Fox: 07 February 2015 - 11:06 AM
#5148 Posted 07 February 2015 - 11:19 AM
#5149 Posted 08 February 2015 - 12:01 AM
Fox, on 25 January 2015 - 05:23 AM, said:
Fixed.
Jblade, on 02 February 2015 - 01:45 AM, said:
I've added a "musictoggle" member of the userdef structure.
Jblade, on 04 February 2015 - 01:34 PM, said:
It looks like this is already set up in the source. Have you tested it and found it to not work?
#5150 Posted 08 February 2015 - 09:25 AM
#5151 Posted 08 February 2015 - 10:57 AM
#5152 Posted 08 February 2015 - 11:16 AM
EDIT: also just a thing, thanks for making this change - the translucent background covered up the menu display code I did which caused ugly clashes with colours which is now fixed in the latest snapshot:
Quote
This post has been edited by Jblade: 08 February 2015 - 11:23 AM
#5153 Posted 08 February 2015 - 11:46 AM
Jblade, on 04 February 2015 - 01:34 PM, said:
Yeah, SPREXT_NOTMD will disable rendering a sprite as a voxel. Unfortunately it can only be set from maphacks or from CON. Is the following good enough for you?
gamevar tmp 0 0 onevent EVENT_SPAWN getactor[THISACTOR].cstat tmp andvar tmp 48 ifvare tmp 32 // if it's floor-aligned { getactor[THISACTOR].mdflags tmp orvar tmp 1 // SPREXT_NOTMD setactor[THISACTOR].mdflags tmp } endevent
Otherwise, I agree that it would be better for floor-aligned voxels to "just work", but I'm not sure about rendering them as non-voxels by default then.
#5154 Posted 08 February 2015 - 11:56 AM
Fox, on 07 February 2015 - 10:58 AM, said:
Agreed, that would be preferred.
Quote
onevent EVENT_SOUND ifvare RETURN BOS1_RECOG ifactor BOSS1 ifspritepal 0 setvar RETURN BOS1_SPEECH endevent
This is not possible because BOS1_RECOG is a "globalsound". Since the primary purpose of EVENT_SOUND is to manipulate hard-coded sounds, this would make sense in my opinion.
In this particular case, I think a workaround would do fine. With a vanilla setup, BOS1_RECOG is only ever played when recognizing that boss, so the "ifactor BOSS1" check is redundant. Then, you could just search for a non-sleeping BOSS1 sprite in the map and assume that that one has just awoken. The assumption here is that no pal-0 boss is active at the same time as a colored one.
#5155 Posted 09 February 2015 - 04:52 AM
Jblade, on 04 February 2015 - 01:34 PM, said:
Hendricks266, on 08 February 2015 - 12:01 AM, said:
Jblade, on 08 February 2015 - 09:25 AM, said:
Jblade, on 08 February 2015 - 09:25 AM, said:
Helixhorned, on 08 February 2015 - 11:46 AM, said:
#5156 Posted 09 February 2015 - 06:24 AM
#5157 Posted 10 February 2015 - 11:46 AM
What I was referring to earlier was with any shadows present and i'm mentioning this now because it seems to pinpoint one of the biggest catalysts for the frame rate issues for future reference, just incase it isn't as widely known. I know i'm repeating myself here, but the above information I think is an integral reminder that, while an engine issue might be existent, right now there would be decently large fps gain if a light/shadow removal or fade off point was established like in common games today.
This post has been edited by Jason S.: 10 February 2015 - 11:48 AM
#5158 Posted 10 February 2015 - 12:13 PM
LeoD, on 09 February 2015 - 04:52 AM, said:
red4-model-wall.jpg red4-model-floor.jpg
I was suggesting to render floor-aligned voxels as voxels, but lying flat on the ground. Hence "just work". Drawing them completely flat by default would not be very friendly IMO. In the screenshot, do you object to the small but noticeable gap between the dipswitch model and the surrounding wall-aligned sprites? That's a bug of the model, it doesn't align perfectly.
On a related note: in r4952, I introduced a serious bug at exit when models were used. Please don't use revisions r4952--r4979 and update to r4980 instead. Sorry!
#5159 Posted 10 February 2015 - 12:34 PM
Helixhorned, on 10 February 2015 - 12:13 PM, said:
I am in favor of this as well. In fact, this may be an opportunity to implement pitch and roll for voxels. In Polymost this would be as simple as applying the transformation to the generated model, but for Classic I believe it could work as transforming the vectors along which the squares are drawn.
Sidenote: With voxmodel now a separate file, and with VoidSW on the horizon, I really need to get voxels working in Polymer.
Sidenote: Have we established a defined order of application of angoff, pitch, roll, and md[xyz]off?
#5160 Posted 11 February 2015 - 02:25 AM
Quote
Damn, that would be absolutely fantastic if you could - there's quite a few things that would really benefit from this in the TC. I had always just assumed it would be too expensive to perform or something so didn't ask.
Also just saw the new ability to add custom ANM cutscenes anywhere - I imagine Zaxtor will get a ton of use out of this
On a different note, we get sporadic crashes with rotscrnang after a while of gameplay - it seems to be some kind of conflict with horiz but it's fairly random (but normally after a specific amount of time) I'm going to try and narrow down when it occurs to give more information (although I'm pretty tight on time at the minute)
EDIT: after looking at it in a bit more detail, I think rotscrnang doesn't like using 1024 (which is 180 upside down) since there's a graphical glich in the center of the screen when this value is used. It's not a problem to work around it on my part but it might be worth looking into anyways.
This post has been edited by Jblade: 11 February 2015 - 02:47 AM