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

[Mblackwell]

Tea Monster, on 07 April 2014 - 11:23 PM, said:

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

It would be much more work than optimizing Polymer, and probably not be good for this use case.

[Hendricks266]

Tea Monster, on 07 April 2014 - 11:23 PM, said:

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

I thought this kind of question had been asked and answered already.

One does not simply "swap in renderers". A renderer for an game engine is designed specifically to use the data types of that game engine. In BUILD's case, that would be sectors, walls, and sprites (with other stuff on top like lights).

Porting another renderer is like putting 9V batteries in your car's gas tank. The work involved in such a thing would basically be writing a new renderer.

[Tea Monster]

Ok, so are there any plans *in the near future* to optimize polymer?

[Helixhorned]

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

any closer to getting blend support into rotatesprite?

I think I have come up with a solution that will make everyone happy. Alpha support is now availible directly in the engine. The only thing you as a user have to do is to generate a PALETTE.DAT with alpha blending tables at blend numbers from 1 to numalphatables (which must be a power of two) and specify log₂(numalphatables) when saving it. When the engine sees that number, it will translate alpha values to blend indices and set translucency bits accordingly. This works in rotatesprite() as well as for spriteext[].alpha.

Additionally, since there's no need to provide both alpha and blend by the user, we can now resolve the negate vs. shift-by-8 issue in favor of the first option. See the commit messages of revs. 4426-4428 for more details.

As for the reverse case, additive translucency support for the GL modes, that could be done... OpenGL provides means of setting blending modes, after all. One could probably implement something similar -- make PALETTE.DAT specify the (start/)end blend number for the additive tables, and have .blend + translucency bits translated to the additive blending factor.

[Hendricks266]

This is a brilliant solution. You want alpha in 8-bit? Provide the data yourself.

Helixhorned, on 09 April 2014 - 11:04 AM, said:

As for the reverse case, additive translucency support for the GL modes, that could be done... OpenGL provides means of setting blending modes, after all. One could probably implement something similar -- make PALETTE.DAT specify the (start/)end blend number for the additive tables, and have .blend + translucency bits translated to the additive blending factor.

I'm not 100% how OpenGL makes such modes available, but alpha still has 24 bits available to us for a bitfield, enumerated constants, or a combination of both. We would just have to reserve [31:8] == all 1s as a signal that the lowest 8 bits are a blend value rather than an alpha value (due to 2's complement negation).

[Jblade]

Sounds cool, forgive my ignorance but can the tables I made previously still work alright? Or won't this affect them? (By tables I mean the ones I made using the LUA commands you posted back when you first added blending and stuff)

[Helixhorned]

Fox, on 07 April 2014 - 02:26 AM, said:

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 GROW_WEAPON
  ifvarg WEAPON11_SELECTSOUND 0
    soundvar WEAPON11_SELECTSOUND

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

Yeah, that's what you get when you expose an array as separate variables with numbered suffixes. Of course, the author of this is hardly to blame... back then, there were no system gamearrays, and that semi-solution worked for their use case.

On the C side, the WEAPONx_* variables conceptually form an array of arrays: per-player, per-weapon. In the Lunatic build, this is also what's concretely there:

#ifdef LUNATIC
  [weapondata_t is a struct type]
weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS];
#else
  [You don't really want to see this, but for the next argument's sake...]
// pointers to weapon gamevar data
intptr_t *aplWeaponClip[MAX_WEAPONS];       // number of items in magazine
intptr_t *aplWeaponReload[MAX_WEAPONS];     // delay to reload (include fire)
  [...]
#endif

If we want to expose these as array to CON, one possible solution in LunaCON is to expose g_playerWeapon[0] -- that is, the weapon settings for the first player -- as a system gamearray of size MAX_WEAPONS. For C-CON, the aplWeapon* declarations are a bit harder to understand: they're arrays that store, for each weapon data member and each weapon index, a pointer to an array of size MAXPLAYERS (i.e. a per-player gamevar, which is what the WEAPONx_* gamevars are!). So it's structured totally inside-out from what you'd naturally write, and reinterpreting that as a player-by-weapon array is hopeless.

So, since a hypothetic weapondata[] system gamearray would only be a LunaCON-only thing, there's probably no point at all -- Lunatic (i.e. the Lua interface) already supports access to g_playerWeapon[][] in a fashion that I find pretty pleasing: player[].weapon gets you a reference to that player's weapon data, and you can index that with either weapon name strings or weapon indices! Look, from test.lua:

local WEAPON = gv.WEAPON

(...)

gameevent{ "JUMP", flags = actor.FLAGS.chain_beg,
    function(actori, playeri, dist)
        local ps = player[playeri]
(...)
        local pistol = ps.weapon.PISTOL
        if (pistol.shoots ~= D.RPG) then
            pistol.shoots = D.RPG
        else
            pistol.shoots = D.SHOTSPARK1
        end
        ps.weapon[WEAPON.PISTOL].firesound = D.LIGHTNING_SLAP
(...)
    end
}

NOTE: this interface is not yet documented, but I think that I will keep it.

[Helixhorned]

Hendricks266, on 09 April 2014 - 11:26 AM, said:

I'm not 100% how OpenGL makes such modes available

Additive blending can be achieved by setting the blending function to an appropriate value. (The blending equation would stay the default GL_FUNC_ADD).

Quote

but alpha still has 24 bits available to us for a bitfield, enumerated constants, or a combination of both. We would just have to reserve [31:8] == all 1s as a signal that the lowest 8 bits are a blend value rather than an alpha value (due to 2's complement negation).

Yyyes... I find that a little to much cramming of functionality into that one poor argument. We used 'alpha' now just because we were reluctant to add another command (rotatespriteab?), after all. Going the analogous route for additive-modes-in-GL would keep user's the freedom of using as many blending tables as desired for a particular kind of blending, and make it work in both renderer classes with minimal additional effort.

James, on 09 April 2014 - 11:27 AM, said:

Sounds cool, forgive my ignorance but can the tables I made previously still work alright? Or won't this affect them?

Yes, you can use the previously generated tables. No, the new features won't affect them.

[Jblade]

Well that's cool since it looks like the new function doesn't work with my old tables (setting the alpha value in rotatespritea to anything else just makes it invisible - I've only tested this with stuff in displayweapon though) but that's what I get for rushing and adding it in everywhere.

[Hendricks266]

Helixhorned, on 09 April 2014 - 11:51 AM, said:

Going the analogous route for additive-modes-in-GL would keep user's the freedom of using as many blending tables as desired for a particular kind of blending, and make it work in both renderer classes with minimal additional effort.

I don't think we would want to specifically implement additive translucency. If we directly exposed glBlendEquationSeparate and glBlendFuncSeparate as enums, that would use 2*3 + 4*4 = 22 bits, and effectively expose every possible OpenGL blending possibility. (Though I don't know how the source/destination stuff would work... perhaps each sprite would only need half that, as defined for itself only.)

[Fox]

Helixhorned, on 09 April 2014 - 11:38 AM, said:

So it's structured totally inside-out from what you'd naturally write, and reinterpreting that as a player-by-weapon array is hopeless.

What I can think of is that .gotweapon or .ammo_amount are already existing C-CON "player-by-weapon" arrays. So theorically it should be possible, you can have either player[].weapon_workslike # or weapon[].workslike #, if adding new per-player structure members is not too much of a burden.

[Helixhorned]

James, on 09 April 2014 - 11:56 AM, said:

Well that's cool since it looks like the new function doesn't work with my old tables (setting the alpha value in rotatespritea to anything else just makes it invisible - I've only tested this with stuff in displayweapon though) but that's what I get for rushing and adding it in everywhere.

Well, yes, the old tables won't give you the "magic" alpha functionality since for that, that one descriptive byte is needed. If you have set up the alpha blending tables at indices 1 to N, and N is a power of two, all you need to do is to append one byte, having the value log₂(N), to the old table. That's all what the PALETTE.DAT change is about.

----

Thinking about more OpenGL blending modes, my previous idea isn't that great. If we went that route, then it would be better to do it really analogous instead of "reverse analogous". That is, have some bit-subset of (say) spriteext[].flags specify the blending mode, and do the same alpha -> blend+translucency bits translation for classic, only changing the index of the first blending table for a particular mode.

Hendricks266, on 09 April 2014 - 12:03 PM, said:

I don't think we would want to specifically implement additive translucency. If we directly exposed glBlendEquationSeparate and glBlendFuncSeparate as enums, that would use 2*3 + 4*4 = 22 bits, and effectively expose every possible OpenGL blending possibility. (Though I don't know how the source/destination stuff would work... perhaps each sprite would only need half that, as defined for itself only.)

I like the overall idea. Needs to be thought about.

Fox, on 09 April 2014 - 12:07 PM, said:

What I can think of is that .gotweapon or .ammo_amount are already existing C-CON "player-by-weapon" arrays. So theorically it should be possible, you can have either player[].weapon_workslike # or weapon[].workslike #, if adding new per-player structure members is not too much of a burden.

Maybe, but I'm not interested in implementing such a change.

[Jblade]

Quote

Well, yes, the old tables won't give you the "magic" alpha functionality since for that, that one descriptive byte is needed. If you have set up the alpha blending tables at indices 1 to N, and N is a power of two, all you need to do is to append one byte, having the value log2(N), to the old table. That's all what the PALETTE.DAT change is about.

Ok, so how do I do that? With a hex editor? I have no idea what the hell I'm doing because I'm not a programmer, sorry.

EDIT: I've tried to do what I can, I added a single byte to the end of PALETTE.DAT like you said and the game gives me this:

ERROR: invalid lognumalphatabs value, must be in [1 .. 7]

I've tried lots of different combinations and nothing works.

[Fox]

Helixhorned, on 09 April 2014 - 12:21 PM, said:

Maybe, but I'm not interested in implementing such a change.

[Hendricks266]

Fox, on 09 April 2014 - 12:07 PM, said:

C-CON

CON is a language. C-CON and LunaCON are two different "compilers"/"interpreters" for CON.

Helix, do you have a name for the EDuke32 scripts written in Lua that run under Lunatic?

[Fox]

Would it be too much to ask for the full status bar to be the default one in Eduke32 as it was originally?

[Jblade]

Ok so when you say 'add a byte', I opened up PALETTE.DAT with an editor and see this at the very end:

07 12 1F 85 8A 8F 86 8B 8F 65 6C 7E 55 5A 5D 00

So I do change those last 2 digits to what is needed? I added a number at first and it said this:

ERROR: invalid lognumalphatabs value, must be in [1 .. 7]

So I tried changing the last number to 7 and the game then loads up, all the ingame additive stuff still works but anything with rotatespritea is completely invisible no matter what value alpha is set to. Bear in mind the only thing I want is the additive value which is stored at blend 255 (which is what the original additive/alpha LUA code gave me when I ran it back when it was first added) rotatespritea doesn't show up even with the last digits left as they were before I modified it.

[Micky C]

Here's a simple thing that could save some mapping time; what if when you're editing a number, such as hitag, pal, x-vel whatever, the scroll wheel can increment that number up or down without you having to delete and retype stuff? If it's possible to add it, IMO it would be a useful addition and fit in naturally as an intuitive feature.

[Helixhorned]

Hendricks266, on 09 April 2014 - 02:11 PM, said:

Helix, do you have a name for the EDuke32 scripts written in Lua that run under Lunatic?

I can only come up with cheesy ones like "lunabits" or "pieces of moon" ("rocks" is already taken by a package management system for Lua). But is there a need? Calling them Lua scripts seems fine to me.

James, on 09 April 2014 - 09:56 PM, said:

Ok so when you say 'add a byte', I opened up PALETTE.DAT with an editor and see this at the very end:

07 12 1F 85 8A 8F 86 8B 8F 65 6C 7E 55 5A 5D 00

So I do change those last 2 digits to what is needed?

No, I said "append", meaning to add a new byte at the end.

Quote

I added a number at first and it said this:

ERROR: invalid lognumalphatabs value, must be in [1 .. 7]

The numeric value of that byte is interpreted as log₂(number of alpha tables), where the alpha tables are assumed to start at 1, hence this range. The value 0 is reserved in case more stuff gets added later to mean "no alpha tables" instead of "one alpha table".

Quote

So I tried changing the last number to 7 and the game then loads up, all the ingame additive stuff still works but anything with rotatespritea is completely invisible no matter what value alpha is set to. Bear in mind the only thing I want is the additive value which is stored at blend 255 (which is what the original additive/alpha LUA code gave me when I ran it back when it was first added) rotatespritea doesn't show up even with the last digits left as they were before I modified it.

Are you using the table generated by the command I once posted? The one with an additive blending table at index 255? Then the alpha stuff doesn't apply at all. What you want is passing -255 to the 'alpha' argument in all rotatespritea calls whenever additive blending is desired. The table could have been left as is. (I guess my reply was confusing because it quoted your blend-for-rotatesprite question, but was mainly about the lognumalphatables extension of PALETTE.DAT.)

Edit: I don't really understand why you all are reluctant to just run Lunatic Mapster32 and re-generate the table if necessary. Did I say that a convenient menu interface was added?

Edit 2: that something is rendered totally transparent sounds like a bug, even though claiming that 128 alpha tables are loaded when there are none is an error on your side. Total transparency (i.e. non-drawing) should be achieved only when the alpha value is 255.