[Fox]

What?

Edit: There is a small problem with using the console to spawn sprites, which egs or spawn events fail to detect the palette specified. A basic exemple is using "spawn BOSS1 21" which will spawn a big boss that behaves like a small one.

[Hendricks266]

Better illustrated:

Spoiler

I think it's fine as-is. The camera in the game world isn't going to change according to the viewer's aspect ratio.

[Fox]

I don't think it makes sense that the camera view itself gets bigger but the borders stay in the middle. And it would be a small change to the "game world" compared with moving the position of the player arms.

Edit:



There is no way to distinguish beetween these two modes, since screen_size is set to 4 for both. Is it possible to make the second one return a value of 6?

[Danukem]

Fox, on 01 April 2014 - 11:26 PM, said:

There is no way to distinguish beetween these two modes, since screen_size is set to 4 for both. Is it possible to make the second one return a value of 6?

Unfortunately, mods that have HUD coding that refers to specific sceen_size (I think I have a few of those myself) would need to be updated.

[Micky C]

Is there a way in mapster script to make some changes to a sprite based on its proximity to another sprite (of a certain tile number) in the x-y plane?

[Jenz/Amaka]

Decided to check out Polymer render and only to be greeted with this.

This only happens when using 32bit. 8bit is working just fine.
What did I miss?

[Helixhorned]

Fox, on 01 April 2014 - 11:26 PM, said:

There is no way to distinguish beetween these two modes, since screen_size is set to 4 for both. Is it possible to make the second one return a value of 6?

As TD said, making changes like this would break compatibility and is out of the question. Looking into the code, it looks like userdef[].statusbarmode is what you're looking for. The change occurs at screen_size==8, though. In game.c, G_DrawBackground():

    // draw in the bits to the left and right of the non-fullsize status bar
    if (ud.screen_size >= 8 && ud.statusbarmode == 0)
    {
// (some rotatesprite() calls...)
    }

A cautionary note: do not attempt to modify statusbarmode, as that may throw off setting the "screen size" in the menu.

Micky C, on 04 April 2014 - 01:14 AM, said:

Is there a way in mapster script to make some changes to a sprite based on its proximity to another sprite (of a certain tile number) in the x-y plane?

M32script has the findnearsprite* commands known from CON. They use the current sprite as the one to search from.

MrGlasses, on 04 April 2014 - 01:27 AM, said:

Decided to check out Polymer render and only to be greeted with this.

This only happens when using 32bit. 8bit is working just fine.
What did I miss?

Please post a screenshot with the new "cl_showcoords 2" mode, which displays information some relevant settings for the current rendering mode.
EDIT: cl_showcoords (which is the same as the DNCOORDS cheat) is only available in the game.

Aside: if you change to 8-bit, you're not using Polymer any more, even if you ticked the "Polymer" box in the startup window.

[Fox]

Helixhorned, on 04 April 2014 - 02:57 AM, said:

Looking into the code, it looks like userdef[].statusbarmode is what you're looking for.

Thanks, that's what I was looking for.

Helixhorned, on 04 April 2014 - 02:57 AM, said:

A cautionary note: do not attempt to modify statusbarmode, as that may throw off setting the "screen size" in the menu.

It is working fine for me, or at least as good as userdef can get.

Helixhorned, on 04 April 2014 - 02:57 AM, said:

As TD said, making changes like this would break compatibility and is out of the question.

Frankly, I think the way it is now it's a broken interface. So backward compatible is not that important, since the setuserdef hack has never been fully compatible to begin with. And the setting is controller by different members, the value is set in screen_size and set again in statusbarmode or althud.

Instead statusbarmode or althud should be part of screen_size, and you should have a command to set the desired settings with a bitfield. Or at least something like EVENT_ENLARGESBAR and EVENT_REDUCESBAR.

[Micky C]

Quote

M32script has the findnearsprite* commands known from CON. They use the current sprite as the one to search from.

That sounds like exactly what I want, thanks!. So how would I go about using this as a script?
"do for i allsprites if findnearsprite XXX XXXX set sprite[i].lotag X"?

[Helixhorned]

Fox, on 04 April 2014 - 03:40 AM, said:

It is working fine for me, or at least as good as userdef can get.

Then you're responsible for maintaining the invariant "(screen_size < 8 implies statusbarmode==1) and (screen_size > 8 implies statusbarmode==0)".

Quote

Frankly, I think the way it is now it's a broken interface.

I tend to agree. Before designing new ones though, I'd be interested to hear what your actual goals are. If your plan is to draw a status bar with certain aspects changed, wouldn't you be better off with hiding the hard-coded one and drawing it yourself? I think that Hendricks' port of the HUD display code to CON can be used as a base.

[Helixhorned]

Micky C, on 04 April 2014 - 04:02 AM, said:

So how would I go about using this as a script?
"do for i allsprites if findnearsprite XXX XXXX set sprite[ i ].lotag X"?

Yes, that would pretty much be it. You'd want to make sure that the end result doesn't depend of the interation order of the sprites, which is the case with this example.

EDIT: actually, it should be something like

gamevar i 0 0
gamevar ii 0 0

for i allsprites
{
    findnearsprite TILE MAXDIST ii
    ifvarge ii 0
        set sprite[ii].lotag LOTAG
}

If you were setting "sprite[ i ].lotag", the findnearsprite would be pointless after all. Actually, it may not produce the desired result though -- findnearsprite only returns one (any) sprite that is strictly closer to the current one than MAXDIST, it doesn't iterate over all such sprites. So, you may need to write your own loop using math commands like 'ldist').

EDIT: corrected the code once again. It's probably not very useful anyway, though.

[Jenz/Amaka]

Helixhorned, on 04 April 2014 - 02:57 AM, said:

Please post a screenshot with the new "cl_showcoords 2" mode, which displays information some relevant settings for the current rendering mode.
EDIT: cl_showcoords (which is the same as the DNCOORDS cheat) is only available in the game.

Aside: if you change to 8-bit, you're not using Polymer any more, even if you ticked the "Polymer" box in the startup window.

[Helixhorned]

MrGlasses: I'm somewhat out of ideas. Your original screenshot looked like what you get when there's too extreme parallax mapping going on, however with no hightiles there can be no parallax mapping. The new one shows artifacts at the borders of texels -- dunno what's going on here, really. You can try disabling ART mapping ("r_pr_artmapping 0" followed by "restartvid" in the OSD). Also, posting the output of the "glinfo" command (which will appear in eduke32.log as "OpenGL Information") could provide some insight.

[Jenz/Amaka]

Helixhorned, on 04 April 2014 - 05:35 AM, said:

MrGlasses: I'm somewhat out of ideas. Your original screenshot looked like what you get when there's too extreme parallax mapping going on, however with no hightiles there can be no parallax mapping. The new one shows artifacts at the borders of texels -- dunno what's going on here, really. You can try disabling ART mapping ("r_pr_artmapping 0" followed by "restartvid" in the OSD). Also, posting the output of the "glinfo" command (which will appear in eduke32.log as "OpenGL Information") could provide some insight.

r_pr_artmapping 0 did it, thanks!

Here's glinfo in case ya interested
http://pastebin.com/3e7paVL2

[Fox]

Helixhorned, on 04 April 2014 - 05:02 AM, said:

Then you're responsible for maintaining the invariant "(screen_size < 8 implies statusbarmode==1) and (screen_size > 8 implies statusbarmode==0)".

I am willing to throw it away.

Helixhorned, on 04 April 2014 - 05:02 AM, said:

I tend to agree. Before designing new ones though, I'd be interested to hear what your actual goals are. If your plan is to draw a status bar with certain aspects changed, wouldn't you be better off with hiding the hard-coded one and drawing it yourself? I think that Hendricks' port of the HUD display code to CON can be used as a base.

It's not just about drawing a HUD, but working with the screen size option. Right now the customization requires some ugly hacks. Setting screen_size is not completely effective. For example, if you want to disable a screen_size higher than 8, you will still hear the THUD sound when you press + or 0, besides the option in the menu will look ugly. And if you are not drawing a new status bar, it will make the status bar flick when you use setuserdef. And finally, if you are doing it during EVENT_DISPLAYREST or EVENT_DISPLAYHUD, it won't have effect in the main menu. Well, you got it.

[Helixhorned]

Fox, on 04 April 2014 - 06:05 AM, said:

I am willing to throw it away.

Er, no, what I mean is that you must make sure that the mentioned property holds at all times. Otherwise, glitches like the ones you describe will ensue.

Actually, the full predicate reads:
screen_size >= 0 and screen_size <= 64 and
mod(screen_size, 4) == 0 and
(screen_size < 8 implies statusbarmode==1) and (screen_size > 8 implies statusbarmode==0)

This is simply what the menu/HUD code expects. If you break that, you can't expect anything sensible in return.

Quote

It's not just about drawing a HUD, but working with the screen size option.

I see, it's hooking into changing the screen size what you're after. I'm not against a new EVENT_CHANGESBAR event, but since Hendricks is redesigning the menu code right now, I'll hold it a little for now.

Here's CON code that changes the screen size every half second. It's in EVENT_PROCESSINPUT for the sole reason that this event is run once per tic.

Spoiler

gamevar lastclock 0 0
gamevar sz 0 0
gamevar tmp 0 0
gamevar dir 4 0

onevent EVENT_PROCESSINPUT
    setvarvar tmp lastclock
    addvar tmp 30
    ifvarvarl totalclock tmp
        break
    setvarvar lastclock totalclock

    getuserdef[].screen_size sz
    ifvare sz 64 setvar dir -4
    else ifvare sz 0 setvar dir 4

    ifvare sz 8
    {
        getuserdef[].statusbarmode tmp

        ifvarl dir 0
        {
            ifvarn tmp 1 { setuserdef[].statusbarmode 1 break }
        }
        else
        {
            ifvarn tmp 0 { setuserdef[].statusbarmode 0 break }
        }
    }

    addvarvar sz dir
    setuserdef[].screen_size sz
endevent

[Hendricks266]

Helixhorned, on 04 April 2014 - 12:46 PM, said:

I'm not against a new EVENT_CHANGESBAR event, but since Hendricks is redesigning the menu code right now, I'll hold it a little for now.

I agree that the statusbar needs some customization, but a special event seems like a bandage that would only make things messier when/if something proper is implemented.

There are two separate issues here:
1. The status bar setting in Game Setup.
2. The [+] and [-] keys.

1 is something that my menu code could eventually be expanded to allow Lua to replace with a custom menu entry. Though, an EVENT_CHANGESBAR could fit right into my custom processing functionality without much negative impact.

I would rather see 2 implemented as bits in EVENT_PROCESSINPUT that the user could cancel. I am already planning to add gamefuncs for menu navigation to make life even easier for joystick and Wii users, and eventually I would like to see just about every keystroke the game recognizes made into gamefuncs. On the other hand, that would require additional infrastructure to handle key combinations for the Alt+F* and Shift+F* stuff. Back on the first hand, the input system could benefit from that sort of improvement. SDL2 opens possibilities for controllers, multiple-joystick support is needed if the Wii port will ever support GameCube controllers, splitscreen, etc.

At present, is there not some event that can intercept a screen size change before the HUD has a chance to flicker that also can affect the main menu? EVENT_PROCESSINPUT (as Helix mentioned) seems to be the candidate. Would EVENT_SOUND work to cancel the thuds?

[Fox]

Not really, the sound is used somewhere esle, mostly in the menu. But the + or - are just a shortcut for the menu option, I don't think they should be dealt with separately anyway.

Ideally, you should be able to redefine which options are avaiable for screen_size. It would require you to specify the screen_size value (ID), offset by the status bar height (for screen_size > 7 it equals 34px, etc) and screen shrinking (for screen_size = 12 it equals 4px), plus you need a way to define which screen_size value is set by default when you config a new game.

[Helixhorned]

Fox, on 29 March 2014 - 06:44 PM, said:

Sector filler should totally be used for rendering fog separately from pal

Implemented in r4415. That makes one 'filler' less, which is kind of nice. I'm not 100% content with the yield of that change -- you could already have wall[].pal/sector[].ceilingpal set to arbitrary values and make sector[].floorpal control the GL fog color. So what you gain is the ability to have separate floor (and with it, potentially its sprites) pal and fogpal. The 'fogpal' member is ignored in 8-bit mode, as well as for Polymer with ART mapping.

I looked into the usage of sector[].filler/alignto (now .fogpal) by the CON mods I use to batch-test LunaCON. LNGA2 uses that member to signal some kind of "map initialization". Since EDuke32 never assigns to .fogpal, that's not problematic.

[Micky C]

Does this fogpal change have any benefit to mappers or is it more of an internal change?

[Helixhorned]

Well, you can now decouple the floor pal and the sector fog color from each other in the GL modes (except Polymer with ART mapping). Before, you'd have to define pals for any combination you wanted to use. For example, to have a pal that combines all-red tinting (2) with a green fog (28), you'd have to
- choose a new pal index, say 100
- assuming you're using Polymer + highpal, map pal 100 to use HRP's highpal/pal_02.png (DEF token highpalookup)
- finally, teach EDuke32 about the fog color of pal 100 using the fogpal DEF token

With the new feature, you don't need any resource edits at all: just have a sector's floor pal be 2 and set its .fogpal to 28.

[Stabs]

thats pretty fucking cool, so with map hacks could you write in scripts so the original game uses fogpals?

if you want to put in your maps easily

defstate newfogpal
for i allsectors
{
set sector[i].floorpal 0
set sector[i].ceilingpal 0
set sector[i].fogpal X
}
ends

X is the pal you want to use.

[TerminX]

Email me your Google+ account addresses for Android beta invites.

[Jblade]

any closer to getting blend support into rotatesprite? I remember reading that Helix hooked it up into the code and stuff, but just no access ingame yet (I imagine using rotatespritea would work best, since blend doesn't work in polymost/polymer and alpha doesn't work in classic)

[Helixhorned]

James, on 06 April 2014 - 02:59 PM, said:

any closer to getting blend support into rotatesprite?

At this point it's only a matter of agreeing on the interface. The two major suggestions that don't require a new CON command use rotatespritea's alpha argument:
1) if alpha is negative, interpret this as a blend index (0 is assumed to be the neutral value in both cases)
2) pack the blend index into the high 8 bits of alpha

Version 1) could be slightly easier to write from CON, e.g. "rotatesprite ... -blend" if you only care about blend, but it requires writing conditionals in case you want to use both.
Version 2) lets you pack both into one argument, but needs a couple of lines whenever you want to use blend, e.g. "setvat tmp blend; shiftvarl tmp 8; orvar tmp alpha" ...

[Fox]

Version 2 is good enough.

Helixhorned, on 06 April 2014 - 03:13 PM, said:

2) pack the blend index into the high 8 bits of alpha

And the high 16 bits as a bitfield for blending options in OpenGL. MUST HAVE.

[Jblade]

The second one sounds like a pain, since there is a lot of stuff I'm gonna use it with in the CON files. Why not just use the alpha value without any modification? You can't use alpha in classic and the blend tables don't work in OpenGL so keeping it cross-compatible doesn't seem worth it. Either that or the negative value seems the best.

[Fox]

Because it's better to avoid checking the value of rendmode. Shifting left the value by 8 is relatively easy to use.

Edit: Is it possible to add a mean to read the values from pre-defined gamevars used for weapons, but by specifying the weapon?

For example, if I want to play the select sound of a weapon, I need all this:

  ifvare player[THISACTOR].curr_weapon KNEE_WEAPON
  ifvarg WEAPON0_SELECTSOUND 0
    soundvar WEAPON0_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon PISTOL_WEAPON
  ifvarg WEAPON1_SELECTSOUND 0
    soundvar WEAPON1_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon SHOTGUN_WEAPON
  ifvarg WEAPON2_SELECTSOUND 0
    soundvar WEAPON2_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon CHAINGUN_WEAPON
  ifvarg WEAPON3_SELECTSOUND 0
    soundvar WEAPON3_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon RPG_WEAPON
  ifvarg WEAPON4_SELECTSOUND 0
    soundvar WEAPON4_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon HANDBOMB_WEAPON
  ifvarg WEAPON5_SELECTSOUND 0
    soundvar WEAPON5_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon SHRINKER_WEAPON
  ifvarg WEAPON6_SELECTSOUND 0
    soundvar WEAPON6_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon DEVISTATOR_WEAPON
  ifvarg WEAPON7_SELECTSOUND 0
    soundvar WEAPON7_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon TRIPBOMB_WEAPON
  ifvarg WEAPON8_SELECTSOUND 0
    soundvar WEAPON8_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon FREEZE_WEAPON
  ifvarg WEAPON9_SELECTSOUND 0
    soundvar WEAPON9_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon HANDREMOTE_WEAPON
  ifvarg WEAPON10_SELECTSOUND 0
    soundvar WEAPON10_SELECTSOUND
  ifvare player[THISACTOR].curr_weapon GROW_WEAPON
  ifvarg WEAPON11_SELECTSOUND 0
    soundvar WEAPON11_SELECTSOUND

While it's much shorter in the source code...

[Tea Monster]

Just curious, but is any work being done on optimizing polymer? If not, how easy would it be to swap some thing like the teseract renderer in it's place (just as an example)?

[Micky C]

Yeah I didn't realize how much global illumination added to the coolness and realism of the scene. Would be friggin' sweet to have something like that some day.