[Micky C]

Is there a mapster32 function or some code that will turn some selected sectors upside down?

[Hendricks266]

I know of no such function but I could write some M32script for you. Would it be enough to:

• y-flip sprites
  
• move sprites to the ceiling ([Ctrl]+[PgUp])
  
• y-flip wall textures
  
• flip all walls' ceiling/floor alignment bits ([O])
  
• adjust the wall's y-panning accordingly
  
• swap floor and ceiling texture attributes
  
• adjust the relative floor and ceiling heights of all selected sectors that are smaller than the maximum z extent of all selected sectors (i.e. flip sector heights without moving the uppermost ceiling and lowermost floor)

I could probably throw in floor door <--> ceiling door for good measure.

Edit: Would you prefer the sectors to be mirrored or to be rotated 180 degrees? The latter would be harder and would likely require the sectors not to have any red lined-walls with unselected sectors.

[Micky C]

That should be useful. Mirrored would be better IMO

Although it won't move all sprites to the ceiling will it? Sprites should be the same distance from the ceiling when flipped as they are to the floor in the original if possible.

[Hendricks266]

Micky C, on 12 February 2014 - 10:27 PM, said:

Sprites should be the same distance from the ceiling when flipped as they are to the floor in the original if possible.

Yes. final sprite z = final sprite [Ctrl]+[PgUp] z - (original sprite z - original sprite [Ctrl]+[PgDn] z).

[Helixhorned]

Hendricks266, on 12 February 2014 - 03:23 PM, said:

It would be completely independent of .blend. That way, users could define those any way they want and have the same range of functionality with 8-bit assets in all the renderers.

It wouldn't be independent. You'd still have to decide on a precedence between .blend and .alpha in case both are non-zero then. I have a hard time understanding what would be gained by implementing 255-level alpha once more when it already can be achieved with a modest amount of hassle. Earlier, you conditionally compiled out the SPLITSCREEN_MOD_HACKS (which I'm fine with), but now you plan to go by the same pattern: hard-coding functionality that is better off being provided by the system in a general fashion.

What's more productive in my opinion is thinking about how to make the application of the alpha -> blend+cstat translation easier on the user. Right now, EVENT_ANIMATESPRITES is run only when spriteext[].flags (known as sprite[].mdflags from CON) has a certain bit set. That's annoying, since it forces one to write game-time code merely to enable a property of an actor tile. So, maybe it would make sense to add another of these SFLAG_* flags for that. In Lunatic, you can pass them directly to gameactor. (In CON, you can set a few of these flags using directives such as spritenopal).
Also, Lunatic has an experimental feature that allows you to define animation callbacks for a particular time separately (another kind of callback is planned, namely for an actor's initialization). It's currently undocumented because implementing it exposed inconsistencies between renderers in the way sprite animations are handled.

Quote

Perhaps the transitions could use some form of RLE...

Any kind of up-front compression would only save memory in case most of the tables are never used at game time, since eventually they have to be decompressed -- at the latest before drawing a translucent object with a particular 'blend'. Think something like the periodically fading liztroop from my example code... Or is your intention to provide smooth alpha fading at the level of the line drawing primitives (tvlineasm* etc)?

[Helixhorned]

Hendricks266, on 06 February 2014 - 11:45 AM, said:

I was already contemplating an optimization pass to cover

1. demoting per-actor and per-player gamevars to global when it can be determined their per-actor/player status is unused

Are you planning to implement a CON code analysis framework? I think you're underestimating the effort a little...

A sufficient condition capturing the notion of "per-actor variable x is used in a temporary sense" is given is by the conjunction of the two following statements; for the purpose of this post I will call blocks like actor, onevent and eventloadactor collectively "procedures".

A. for each procedure, x is accessed at same index i throughout the procedure (but i may take on a different value each invocation of a procedure)
B. for each procedure, x is not live at entry to the procedure

The first point captures the "temporariness" of the usage of x: if x were accessed at different indices throughout the procedure, then it would in practice likely have some purpose besides its temp usage. Again, that's only a "reasonable assumption", not a certainty: e.g. if the only other access of x is a write to x[mod(i+1, MAXSPRITES)] and assuming that B still holds, that would not change its "temporary" character (since that write is useless), but x would get classified as "non-temp" by the analysis.

Point B makes sure that x is never used (i.e. read) in a procedure without having previously been assigned to -- if it were, then it could have been last assigned to in a procedure (a different one or the same), but at a different index!

The general outlook here is that static code analyses can only ever compute over-approximations of the real circumstances. The question when implementing a particular analysis then is whether the resources (run time, memory) gained by exploiting its results warrant the implementation effort (this is not even considering the resource requirements of the analysis itself). Also, if you want to use the results for code transformations, the analysis must be safe: there must be no false positives!

And this is only the conceptual side, not touching the aspect of how such data-flow analyses could sensibly implemented on top of the existing CON parsers.

[LeoD]

r4316 "Replace QuickLZ with LZ4." messes up the HRP.

Spoiler

[Hendricks266]

Helixhorned, on 15 February 2014 - 04:35 AM, said:

Are you planning to implement a CON code analysis framework? I think you're underestimating the effort a little...

I was thinking about it, but I think it would be wasted effort because of Lunatic and because network CON code would need manual changes anyway.

[XxMiltenXx]

LeoD, on 15 February 2014 - 06:04 AM, said:

r4316 "Replace QuickLZ with LZ4." messes up the HRP.

Spoiler

r4316.jpg

Same error on my side. But only with "Texture cache on Disk" set to "compress".
If set to "on" or "off" it works for me.

[Roma Loom]

Is anyone feeling capable of fixing hipals + glowmapping bug? There are tons of textures in HRP defined via pal 0 .. pal XX which can be handled by hipal almost perfectly except for the glowing parts. By now the glowing part is completely ignored by hipal system.

[Cage]

Would it be possible to implement (as an option maybe) display of voxels as cubes? I mean like true cubes - for example, in slab6 you can display the voxels as proper cubes or bound cubes (similar to what Eduke does).

I'm experimenting with using voxels for level geometry and it would be great to make them blend in better. Currently, you can see the limited resolution in close proximity and/or certain angles. If implementing that is complicated or not viable performance-wise, don't worry too much about it.

[Helixhorned]

Fox, on 12 February 2014 - 04:13 PM, said:

Since we are talking about palettes and tables, what about making it possible for a mod author to include their own palettes or lookups without relying on some obsolete PALETTE.DAT editing? Akin to how we use tilefromtexture now instead of EDITART.

The recent round of changes introduces various helpers to create and save lookup tables. Refer to the changes of test/shadexfog.lua and the added documentation.

I don't think that the *.DAT files are "obsolete". They're simple binary formats for which it's easy to write reader or writer programs.
Note that a lookup table is simply a color index remapping, which is then used to set up the whole shade table according to the second example here.

So, having additional blending and lookup tables loadable (the latter was already possible before, but then the fog pals numbers would shift upwards), what's left is
* Loading full shade tables. Currently, it's only possible to register them programmatically with Lunatic's engine.setshadetab().
* Loading additional base palettes. LOOKUP.DAT carries five of them, but allowing any number (up to some limit) would need some code refactoring first.

I'm kind of done with the palette stuff for now, though.

[Stabs]

this is all explained to technically fo me, but from the gist of that one picture does this fog work similar to shadow warriors "heat" pals

really good for hot and underwater settings if it is what iam thinking it is

[Plagman]

Cage, on 16 February 2014 - 04:45 AM, said:

Would it be possible to implement (as an option maybe) display of voxels as cubes? I mean like true cubes - for example, in slab6 you can display the voxels as proper cubes or bound cubes (similar to what Eduke does).

I'm experimenting with using voxels for level geometry and it would be great to make them blend in better. Currently, you can see the limited resolution in close proximity and/or certain angles. If implementing that is complicated or not viable performance-wise, don't worry too much about it.

Do you mean in Classic mode? In Polymost voxels are displayed as true cubes.

[Plagman]

Roma Loom, on 16 February 2014 - 12:25 AM, said:

Is anyone feeling capable of fixing hipals + glowmapping bug? There are tons of textures in HRP defined via pal 0 .. pal XX which can be handled by hipal almost perfectly except for the glowing parts. By now the glowing part is completely ignored by hipal system.

Do you have an example of a tile that does this right now? I can take a look.

[Nukey]

I don't deal with art stuff much, but this has been bothering me for a while, and there seems to be a lot of related discussion going on here, so

Concerning 8 bit mode, how is one supposed to completely "wipe" the art files (all texture/animation definitions) in order to start from scratch?

I can only find two options so far:

undeftexturerange 0 6143

this is for "hightile" only, so does nothing for me, the alternative is

dummytilerange 0 6143 1 1

which works, but leaves two issues which render it almost useless:

1] "dummytilerange" doesn't seem to work with (0,0). I am forced to use (1,1), which leaves a small black square in place of any objects which are not redefined with a new texture (i.e. what if I just want to leave some tiles completely blank?).

2] old animation definitions remain active with the new tiles. There doesn't seem to be a way to wipe old animation info. New textures with new animation definitions work fine, but a newly defined (unanimated) texture that happens to land on an old animated texture number will inherit the same animation properties.

I've gone through the DEF language page on the edukewiki and have found nothing else for doing this. What am I missing here?

[Plagman]

I think the actual ART files are what defines the ART, there isn't a hardcoded tile count that I know of.. so removing the ART files from your GRP and starting over with just one ART file ought to do the right thing. The problem is that a bunch of tiles will have weird behavior based on their number because hardcoded logic in the Duke3D code will assume things based on their ID, so if you really wanted to start from scratch you'd be safer starting at 10000 anyway.

[Nukey]

Oh right, there's the coded tiles to worry about too. Thanks though.

edit: Out of curiousity, are there any plans to implement a DEF language method of wiping animation info and creating truly "blank" tiles? I still think it would be useful.

[Hendricks266]

^def is definitely in need of more undefine commands. Art tiles, skyboxes, tints, highpalookup, sounds, music...

[Roma Loom]

Plagman, on 16 February 2014 - 03:17 PM, said:

Do you have an example of a tile that does this right now? I can take a look.

That would be recently uploaded tile #389. You can toggle r_glowmapping while looking at any paletted version of it too see what happens.

[Cage]

 Plagman, on 16 February 2014 - 03:16 PM, said:

Do you mean in Classic mode? In Polymost voxels are displayed as true cubes.

Yes. Polymost display method is the one I'd like to have, I can't use the 32-bit mode since I'm using custom shading/transparency tables in palette.dat, though.

[Hendricks266]

"r_usetileshades 1" should allow the 8-bit shading tables to work in Polymost. I can't say the same for Helix's .blend--interactions between ART and hightile would be undefined.

[Plagman]

Shade tables are one thing, but custom translucency tables are not going to map to Polymost (or even Polymer with ART mapping) at all.

[Micky C]

Is classic translucency ever going to come to polymer?

Btw I was wondering, in the classic renderer, how would the performance of voxels be compared to 3D spritework in terms of framerate?

[Jblade]

I've noticed a strange glitch with the new blend feature (with the custom pal and all) Whenever an object with a blend of 255 is onscreen (using the additive mode) it seems to apply it to translucent HUD elements as well (or rather things using rotatesprite I guess) It doesn't do it all the time, only if the item is onscreen. I'm guessing it's getting applied to HUD elements as well?

Also related, is there a way to apply it deliberately to rotatesprite stuff? (Like weapon flashes and stuff) Cheers!

[Hendricks266]

I realize now that there is no point in implementing hardcoded .alpha functionality. Since .blend won't work in OpenGL, if you're using .alpha in OpenGL then you probably aren't using .blend for anything and can ship translucency tables.

That said, we could likely leverage rotatespritea's alpha member, or if we want to avoid a mess, create a rotatespriteb command that has .blend instead of .alpha. On the other hand, screentext would need a new command too which would be sad.

Maybe negative inputs for <alpha> use blending tables instead? A new orientation bit?

[Micky C]

Not sure if this behavior is present in the original duke 3d or if it's a bug, I've never seen it mentioned before.

I have some sprites in a (thin) rotating sector, and gradually over time the sprite positions are being offset tangential to the path, which isn't practical for a map of course. Dndebug reveals the sprites have definitely moved from their original position and are outside their original sectors. A test map can be provided if necessary (I'd have to make it from scratch but shouldn't take long).

[Mblackwell]

Is the Relative bit set on the floor?

[Fox]

 Nukey, on 16 February 2014 - 07:56 PM, said:

1] "dummytilerange" doesn't seem to work with (0,0). I am forced to use (1,1), which leaves a small black square in place of any objects which are not redefined with a new texture (i.e. what if I just want to leave some tiles completely blank?).

2] old animation definitions remain active with the new tiles. There doesn't seem to be a way to wipe old animation info. New textures with new animation definitions work fine, but a newly defined (unanimated) texture that happens to land on an old animated texture number will inherit the same animation properties.

dummytile <tile> 65536 65536
animtilerange <tile1> <tile2> 0 0

Hackish, but it does the job...

[Nukey]

Ha! nice. Thanks mate.