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

[Jblade]

I tried to re-gen the table, I just wasn't sure what I was doing exactly. Anyway:

Quote

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

Yeah I know, but it gave me the error I posted so I thought I was mistaken at first.

Quote

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

That is what I've been trying to do/say, giving the rotatespritea any value just makes it invisible ingame in classic, wherether it's minus or positive.

[Helixhorned]

James, on 10 April 2014 - 09:36 AM, said:

That is what I've been trying to do/say, giving the rotatespritea any value just makes it invisible ingame in classic, wherether it's minus or positive.

Hhm, that's strange. Can you try the following with the attached ZIP? Rename the contained PALETTE_1-32-alpha_101-132-addtv.dat to PALETTE.DAT and run each of the CON mutators, screentext.con and sprite_access.con -- using the -mx switch, that is. The first one should display a variety of on-screen text part of which should smoothly fade in and out, one half-cycle with alpha and the other with additive blending. The second one should smoothly fade the LIZTROOP actor.

Attached File(s)

•  PALETTE_alpha_test.zip (1.19MB)
  Number of downloads: 341

[Jblade]

Sorry for all of the hassle I've caused, I got it working by generating a new table via the LUA menu you added which was very very handy (and I didn't know about till you mentioned that) Still need to do some tweaking on my side but it's working now, I appreciate your work and patience with me (I hope at least ) The above example worked fine, I mistyped some commands last night since I had done a really long shift at work so I wasn't proof-reading my stuff before bitching about it, so I apologise for saying it didn't work.

[Helixhorned]

Hehe, no problem. Glad it works!

[Jblade]

Sorry for another question, the remapping feature in the LUA-script is really handy but I can't see how to save my results, since saving both the new palette.dat and the lookup.dat doesn't save what I made with the 'create c.index remapping' function, unless there is something obvious I'm probably missing.

(for what it's worth, I've used the rotatespritea a bunch already so all of this stuff I've requested/asked for I am actually using heh )

[Helixhorned]

James, on 11 April 2014 - 12:32 AM, said:

Sorry for another question, the remapping feature in the LUA-script is really handy but I can't see how to save my results, since saving both the new palette.dat and the lookup.dat doesn't save what I made with the 'create c.index remapping' function, unless there is something obvious I'm probably missing.

Yeah, it previously only saved the default ones. With r4438, there's a query for a range of lookups besides the main 1-25, too.

[Fox]

There is a problem with .fogpal, pitch black textures (shade > 31) are unaffected by the fog.

Off-topic (sorta): What music formats Megaton supports? Only .mid?

[Jblade]

Quote

What music formats Megaton supports? Only .mid?

Actually it only uses OGG files.

[Fox]

Oh, so I guess it's gonna be okay for PSX mod.

[Helixhorned]

Fox, on 17 April 2014 - 04:49 PM, said:

There is a problem with .fogpal, pitch black textures (shade > 31) are unaffected by the fog.

Can't reproduce. They behave the same as if they were given a corresponding "normal" fog pal number here. As usual, posting a screenshot comparing the two (all else being equal) with cl_showcoords 2 may point out the issue.

[Danukem]

Sometimes the framerate drops to 0 but things keep happening in the game. For example, the player often ends up facing the opposite direction by the time the game unfreezes, because the game continues to accept input while frozen. For me, this is an issue when my mods use the CON save command (to save the game in the middle of gameplay), or when new textures are being loaded.

Is it possible to make the game pause while it is frozen? It's a source of player death and frustration.