[Fox]

Edit 2: Okay, I was right about it. The game fails to return the player id with setplayer[THISACTOR] or setvar during EVENT_GAME if the player in question is dead, and instead will look for the closest player alive.

For example, this won't work properly in multiplayer:

gamevar MYVAR 0 1

onevent EVENT_GAME
  ifactor APLAYER
  {
    setplayer[THISACTOR].structure 1
    setvar MYVAR 1
  }
endevent

While this will:

gamevar MYVAR 0 1
gamevar TEMP 0 2

onevent EVENT_GAME
  ifactor APLAYER
  {
    getactor[THISACTOR].yvel TEMP
    setplayer[TEMP].structure 1
    setplayervar[TEMP].MYVAR 1
  }
endevent

[Gambini]

Entering the range of an ambience (looped) sound will play it at full volume for a short and choppy period. If the sound engine needs that short period to check what volume the sound has to be played. I suggest then playing all ambience sounds with a low volume until the calculations regarding distance and offset are performed. That´d remove the "scratched disk" effect Duke´s soundscape currently has.

[Fox]

I got some problems with the status bar. In order to make screen_size 8 display the entire screen, I must remove tile 2462 (BOTTOMSTATUSBAR). However not everything is working right...

Spoiler

Unfortunately changing tile 2462 seems to relocate the level stats to the bottom of the screen.



I suppose that in order to fix that problem, and for the sake of consistency, it could work in the same way of the automap episode / level display. Basically adding an offset of 32 pixels whenever screen_size does not equal zero.

Spoiler

Apparently the screen size is not calculated, but simply subtract some pre-defined values from the resolution. As a result, an smaller status bar at the bottom gives a narrow aspect to the screen.



It would be better if there was some actual calculation behind this, though it may have some small effects on the original game. Another solution is to allow the editing of windowx1 / windowy1 / windowx2 / windowy2.

[Player Lin]

Is possible made the level stats shows on other area because in some mods(like DN:WoA), when the mod changed the status bar textures, and that level stat will covered the custom status bar textures/items in that position and just a little annoying...

[fgsfds]

Gambini, on 23 March 2013 - 10:57 PM, said:

Entering the range of an ambience (looped) sound will play it at full volume for a short and choppy period. If the sound engine needs that short period to check what volume the sound has to be played. I suggest then playing all ambience sounds with a low volume until the calculations regarding distance and offset are performed. That´d remove the "scratched disk" effect Duke´s soundscape currently has.

Because of a lack of ambient sounds in original Duke, it's not too obvious. Look what happens on the maps with a lot of sounds

It's an ultimate ear rape.

[Hendricks266]

Fox, on 24 March 2013 - 10:44 PM, said:

Unfortunately changing tile 2462 seems to relocate the level stats to the bottom of the screen.

I suppose that in order to fix that problem, and for the sake of consistency, it could work in the same way of the automap episode / level display. Basically adding an offset of 32 pixels whenever screen_size does not equal zero.

Ideally we could let the modder decide where to position it, but I can't think of any way other than a new event ().

The automap level and episode do this:

            if (ud.overhead_on == 2)
            {
                const int32_t a = (ud.screen_size > 0) ? 147 : 179;
                minitext(5,a+6,EpisodeNames[ud.volume_number],0,2+8+16+256);
                minitext(5,a+6+6,MapInfo[ud.volume_number*MAXLEVELS + ud.level_number].name,0,2+8+16+256);
            }

The level stats do this:

        const DukePlayer_t *myps = g_player[myconnectindex].ps;

        if (ud.screen_size == 4)
            i = sbarsc(ud.althud?tilesizy[BIGALPHANUM]+10:tilesizy[INVENTORYBOX]+2);

        else if (ud.screen_size > 2)
            i = sbarsc(tilesizy[BOTTOMSTATUSBAR]+1);
        else
            i = 2;

        j = scale(2,ud.config.ScreenWidth,320);


        Bsprintf(tempbuf,"T:^15%d:%02d.%02d",
                 (myps->player_par/(REALGAMETICSPERSEC*60)),
                 (myps->player_par/REALGAMETICSPERSEC)%60,
                 ((myps->player_par%REALGAMETICSPERSEC)*33)/10
                );
        G_PrintGameText(8+4+1,STARTALPHANUM, j,scale(200-i,ud.config.ScreenHeight,200)-textsc(21),
                        tempbuf,0,10,26,0, 0, xdim-1, ydim-1, 65536);

// there is more for the rest of the lines but you get the idea

I would almost suggest that the modder disable it and replicate it from CON. However, given that it uses some internal values (and given its propensity to change over the years) this is not a viable option.

I don't know what to do.

off-topic: Since 2 is now valid for screen_size, I would like to investigate implementing the classic and modern mini-HUDs both selectable using -/+. (A menu option could disable either or leave both.)

Fox, on 24 March 2013 - 10:44 PM, said:

Apparently the screen size is not calculated, but simply subtract some pre-defined values from the resolution. As a result, an smaller status bar at the bottom gives a narrow aspect to the screen.

It would be better if there was some actual calculation behind this, though it may have some small effects on the original game. Another solution is to allow the editing of windowx1 / windowy1 / windowx2 / windowy2.

The viewport throws a wrench into everything. You can see the effect just by modifying "Status bar size" in Game Setup. I think this is more than a paper cut.

[Fox]

Hendricks266, on 25 March 2013 - 11:10 AM, said:

Ideally we could let the modder decide where to position it, but I can't think of any way other than a new event ().

Can't it just use some variable or userdef option to determine the position? I.e. default value x = 0 and y = 168.

Hendricks266, on 25 March 2013 - 11:10 AM, said:

I would almost suggest that the modder disable it and replicate it from CON. However, given that it uses some internal values (and given its propensity to change over the years) this is not a viable option.

I don't know what to do.

For now I would just give the level stats the same position as the automapepisode and level (32px offset if screen_size > 0) for the sake of consistensy.

(Also it seems you don't have a good way to disable the level stats right now)

Hendricks266, on 25 March 2013 - 11:10 AM, said:

The viewport throws a wrench into everything. You can see the effect just by modifying "Status bar size" in Game Setup. I think this is more than a paper cut.

It seems that the status bar size option wasn't avaiable in the original Duke 3D. So I guess it can't be helped to give it some new code.

And since we are here, shouldn't the status bar left and right side display that border normally seen when you shrink the screen? It's a bit weird to see the background touching the viewport.

Spoiler

Hendricks266, on 25 March 2013 - 11:10 AM, said:

off-topic: Since 2 is now valid for screen_size, I would like to investigate implementing the classic and modern mini-HUDs both selectable using -/+. (A menu option could disable either or leave both.)

I requested that before, and TerminX said it could conflict with some old mod. But to tell the truth, I don't really see the purpose of having a built-in HUD now that we have CON mutators. It would be better to have it in a CON file, which would also be editable.

By the way, what's the purpose of this status bar option? The default status bar wasn't supposed to cover the screen.

Spoiler

[Hendricks266]

Fox, on 25 March 2013 - 12:13 PM, said:

Can't it just use some variable or userdef option to determine the position? I.e. default value x = 0 and y = 168.

Hackish, and a waste of two int32_t. And:

Fox, on 25 March 2013 - 12:13 PM, said:

For now I would just give the level stats the same position as the automapepisode and level (32px offset if screen_size > 0) for the sake of consistensy.

That's a simple hack workaround, but what if your custom HUD is taller than that? Then both level stats and automap ep/lev are problematic.

Fox, on 25 March 2013 - 12:13 PM, said:

(Also it seems you don't have a good way to disable the level stats right now)

ud.levelstats

Fox, on 25 March 2013 - 12:13 PM, said:

And since we are here, shouldn't the status bar left and right side display that border normally seen when you shrink the screen? It's a bit weird to see the background touching the viewport.

That's a limitation of the software viewport. In OpenGL the background is not there. "Setting RETURN to a non-zero value in EVENT_DISPLAYSBAR will prevent the status bar from being rendered. The area where the big status bar would normally appear remains, however, and will contain visual glitches." "The status bar is not drawn each frame, it is only patched when the ammo counter is updated."

Fox, on 25 March 2013 - 12:13 PM, said:

I requested that before, and TerminX said it could conflict with some old mod. But to tell the truth, I don't really see the purpose of having a built-in HUD now that we have CON mutators. It would be better to have it in a CON file, which would also be editable.

If anything, the statusbar will transition to built-in or included Lua. (Perhaps if not part of the exe, included as an eduke32.pk3 (zip renamed).)

Fox, on 25 March 2013 - 12:13 PM, said:

By the way, what's the purpose of this status bar option? The default status bar wasn't supposed to cover the screen.

More options, so it doesn't cut off the top of the screen. I like the options.

==/==/==

Here is my idea, which needs approval from Helixhorned.

Normally events use the variable RETURN for some hardcoded values. However, we have the following collection of hardcoded, non-pointer, writable gamevars that we can put to use (as revealed by DNDEBUG x2):

gamevar RETURN 0 2048 // (system)
gamevar ZRANGE 154255552 GAMEVAR_PERPLAYER // (system)
gamevar ANGRANGE 154255624 GAMEVAR_PERPLAYER // (system)
gamevar AUTOAIMANGLE 154255696 GAMEVAR_PERPLAYER // (system)
gamevar LOTAG 0 2048 // (system)
gamevar HITAG 0 2048 // (system)
gamevar TEXTURE 0 2048 // (system)

EVENT_GETSHOTRANGE already uses ZRANGE and ANGRANGE.

I propose that LOTAG and HITAG be used for the x and y coordinates of the level stats and episode ep/lev in EVENT_DISPLAYSBAR. (You can tell which is being displayed by ud.overhead_on.) One of the variables could be used for the height of your intended status bar and the game will handle the rest.

(I had an idea for another application of LOTAG, HITAG, and TEXTURE here.)

[Gambini]

Quote

It's an ultimate ear rape.

I think the sound engine should be conscienciously revised. There are a couple of things that work noticeably worse than with the original game. Having 96 voices or more doesn´t seem to help.

[LeoD]

Fox, on 25 March 2013 - 12:13 PM, said:

By the way, what's the purpose of this status bar option? The default status bar wasn't supposed to cover the screen.

That has become my usual setting.

[Fox]

Hendricks266, on 25 March 2013 - 02:20 PM, said:

That's a simple hack workaround, but what if your custom HUD is taller than that? Then both level stats and automap ep/lev are problematic.

True. But at least it makes sense for the two to work in the same way.

Hendricks266, on 25 March 2013 - 02:20 PM, said:

That's a limitation of the software viewport. In OpenGL the background is not there. "Setting RETURN to a non-zero value in EVENT_DISPLAYSBAR will prevent the status bar from being rendered. The area where the big status bar would normally appear remains, however, and will contain visual glitches." "The status bar is not drawn each frame, it is only patched when the ammo counter is updated."

I checked it, it doesn't seems to apply to the blank spaces on the left and right sides of the HUD.

Spoiler

Hendricks266, on 25 March 2013 - 02:20 PM, said:

ud.levelstats

That's related to the option in the menu. If I change that it turns into a fight against the menu.

Hendricks266, on 25 March 2013 - 02:20 PM, said:

More options, so it doesn't cut off the top of the screen. I like the options.

But there is the problem that there is no way to check via CON if that is being displayed or not, or to disable it (in case it is not necessary).

[TerminX]

It's so you can scale the full HUD down and use it as a small HUD if you want.

[LeoD]

TerminX, on 25 March 2013 - 03:00 PM, said:

It's so you can scale the full HUD down and use it as a small HUD if you want.

Can the metallic frame be made transparent? Simply replacing it with transparency via GIMP (attempt attached) doesn't work.

Attached thumbnail(s)

• 

[OpenMaw]

Gambini, on 25 March 2013 - 02:50 PM, said:

I think the sound engine should be conscienciously revised. There are a couple of things that work noticeably worse than with the original game. Having 96 voices or more doesn´t seem to help.

Yeah, that's pretty bad. Paper cuts for the ear drums.

[Diaz]

The CRACK sprites are always fullbright with the Polymer renderer (haven't tested other renderers). This is annoying because they're more visible than I wanted to, and makes some secrets in my maps way too easy to find.

As far as I know this was not the standard behavior in the original game - I remember I used a shade value together with translucency to make them less visible back when I made Fusion TC.

[Micky C]

Has that always been the case? In my experience they always looked normal in polymer. Perhaps show a picture of one of these fullbright crack sprites.

[Fox]

I remember reading somewhere in the source code that cracks are meant to glow in the dark.

[Diaz]

Here:

Attached thumbnail(s)

• 

[Gambini]

I also think that´s standard behaviour. The problem is that different engines deal with translucency differently. So it wasn´t that noticeable as it is now. You don´t want all maps in the world affected by such change at this point.

[Diaz]

Well, but I guess the default behaviour could be left untouched while introducing some way to change it. Or is it possible to actually activate a sectoreffector from CON? Because if it is, I might just code my own cracks. I just think cracks that glow in the dark are plain nasty.

[Mblackwell]

Diaz, on 26 March 2013 - 03:14 PM, said:

Well, but I guess the default behaviour could be left untouched while introducing some way to change it. Or is it possible to actually activate a sectoreffector from CON? Because if it is, I might just code my own cracks. I just think cracks that glow in the dark are plain nasty.

Yes it is possible at least indirectly using operateactivators (for example). You can also operatesector, or operatemasterswitch. Then there's just coding the entire effect from scratch.

Though, you should be able to manually set the shade of the crack in CON code.

[Gambini]

I remember a way to use any no actor sprite as a crack by simply hitagging it with the same value than a hidden crack or something. I´m not sure though.

[High Treason]

If you take the CON route, you needn't code your own cracks, just force the shade as MBlackwell says. I think this should work, though I haven't tested;

gamevar PA_SHADE 0 2

eventloadactor CRACK1   // You would have to do this for each crack type
cstator 2048   // Makes sure it doesn't use the sector's shade, line might not be necessary
getactor[THISACTOR].shade PA_SHADE   // Get's the shade you set the crack to in Mapster to this var
enda

onevent EVENT_GAME
ifactor CRACK1 { setactor[THISACTOR].shade PA_SHADE }   // Again, you need to do this for all four crack types
endevent

Not sure what you know about CON coding, so my example might be pointlss. ifactor combined with event game gives great flexibility over hardcoded actors.

[Fox]

No, that won't work. Looking at the source code, the tsprshade is set to 16 during animatesprites.

[Mblackwell]

So just set it during EVENT_ANIMATESPRITES.

[Fox]

Fox, on 08 March 2013 - 02:01 PM, said:

Some of the animations displayed on the screen are too fast depending of the framerate, for example the moving arms after being hit by the Shrinker. In the GIF above it is faster than it should be in the vanilla game, despite it still being slowed down by the recording software.

Since this has been fixed, was the Ripper, Shrinker and Freezethrower firing animation also fixed?

[TerminX]

I only fixed the shrunk hands, but Hendricks might have fixed the thing with the Ripper... I'll check out the other problems though.

[Hendricks266]

I didn't touch the Ripper's actual animation, I just made the middle muzzleflash not animate if the player is frozen.

(I think weapons.con.sample would need to be updated for all four animation cases (hands and weapons).)

[Hendricks266]

TerminX, on 26 March 2013 - 10:12 PM, said:

I only fixed the shrunk hands

Fox, on 08 March 2013 - 02:01 PM, said:

Some of the animations displayed on the screen are too fast depending of the framerate,

I think the key is that the animation depends on the framerate when it should instead be based on totalclock or similar. Fox?

[Fox]

Like I mentioned in my early post, what I can think of is it being based on totalclock divided by 4.

The hack I use with CON to display custom weapons is to check whenever totalclock is different compared to the last time (the display event was running), and if the value for totalclock is a multiple of 4. It works, but is is not perfect (it seems to result in some glitches when it sync with the framerate or something).