[Helixhorned]

Fox, on 30 March 2014 - 02:34 PM, said:

No, I am saying that .filler shouldn't have been used for custom blending tables in the first place. It makes no distinction beetween floor and ceiling and it's not avaiable for walls in the original map format, so it's an incomplete feature.

Ah, I suck! We don't use sector[].filler at all, it's sprite[].filler that was taken for the new functionality. Sector filler has exactly the problems you mention -- we'd need two members for the ceiling and floor, but we have only one.

Quote

Besides it's a feature that doesn't extend to OpenGL modes, so I don't think it's a feature that should be acessible in the map editor (with old map format).

Well, other features can be specific to one rendering mode, too. It's the mapper's responsibility to make sure that either the map looks as intended anywhere, or state which renderers are suitable in the mapping template.

Quote

Sector .filler should be used for displaying fog independent of pals (...).

Yeah, might be doable... one needs to research a bit whether this member has any use internally, in which case it could be moved somewhere else, or in existing CON code, which would be kind of a blocker for using it for a new purpose.

Quote

Instead .alpha should be extended for floors, ceilings and walls

Alpha isn't a member of the on-disk map structures, but rather of spriteext[], which is only there in the game.

[Plagman]

Well, sorta; spriteext partially lives on disk through .mhk files. These days I guess you could argue a build map file is both a .map and a .mhk.

[Fox]

Anyway, I don't think sprite blending should be extended to the map editor, but the functionality should be added to .alpha.

Edit: I just noticed a small detail, the sprites displayed on the screen when you are checking a security camera need widescreen orientation flags, no?

[Helixhorned]

Plagman, on 31 March 2014 - 01:53 PM, said:

Well, sorta; spriteext partially lives on disk through .mhk files. These days I guess you could argue a build map file is both a .map and a .mhk.

Right. Plus, it's an engine-side structure, so my comment about it existing in the game only was misleading.

Fox, on 31 March 2014 - 06:43 PM, said:

Anyway, I don't think sprite blending should be extended to the map editor, but the functionality should be added to .alpha.

Since sprite[].blend is part of the spritetype structure, it's obviously there in the editor, too. There are simply no "user-friendly" ways of accessing it, you have to use one of the scripting languages.

Quote

Edit: I just noticed a small detail, the sprites displayed on the screen when you are checking a security camera need widescreen orientation flags, no?

In 1680x1050, viewing through a security camera looks fine to me. Can you post a screenshot describing what looks off to you?

[Fox]

Spoiler

[TerminX]

You gave the cameras manual pan and zoom functionality?

[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)