[TerminX]

Nukey, on 12 February 2014 - 09:05 AM, said:

Separating mapster32 at all was a bad idea.

My original intention was to separate out all of the sample data that 99.999% of users never use... I don't necessarily think separating out mapster32.exe itself was a good idea either.

[Nukey]

The original intention makes sense, but I think having them in a separate sample folder was good enough.

[MetHy]

The one thing that got everybody to make maps for Duke3D back in the days was that the level editor was in the folder of the game...

[Nukey]

Exactly

[Hendricks266]

The samples folder 7-zipped is 55.9 KB. With my next SVN push, eduke32-sdk packages will be gone and reintegrated into the main download. The net download size for someone who wants both will be smaller because 7-zip will compress out the redundant engine and libraries (SDL, FLAC, etc).

If the lack of a package containing only eduke32.exe actually bothers any users in practice, we can see about making that available too. Really though, if file size is a concern, it's not that hard to set up your own synthesis.

Packages will still be separated based on architecture (32-bit/64-bit) and release/debug. That will keep the file size mostly down.

[The Commander]

"simple" people just want a download with eduke and mapster in one zip, they are not going to go to the lengths of learning how to compile it themselves just for that.

[Nukey]

I think most people in general prefer it that way. When I have a hundred things to do and upgrading a program is one of them, the last thing I want to do is track down two separate halves of it.

[Helixhorned]

Hendricks266, on 11 February 2014 - 11:43 AM, said:

Or not, because I still intend to implement .alpha in classic as an analog of the OpenGL alpha.

Well, then you'd either have to
* calculate the 128 blending tables at startup, which takes a couple of seconds even in the release build (it's 2²³ engine.nearcolor() calls, after all), or
* package the extended PALETTE.DAT as part of EDuke32.

Both options have their problems. The central one I see with hard-coding the functionality is that you take away resources from modders. With blending tables 0 + 1..128 taken, there are only 127 more left. What if a mod author wishes to implement 255 levels of blending, but using a different formula than the usual alpha translucency? Keeping the core functionality availble but giving modders its full potential seems to be most in line with the modding spirit of EDuke32.
Besides, when using .alpha, you already commit yourself to having custom scripting code. In that setting, having the few lines of additional code for the alpha -> blend+cstat translation is a non-issue.

Micky C, on 12 February 2014 - 03:51 AM, said:

You're right, there is no mapster32.

Oops, riiiiiight. I omitted it from the Lunatic package earlier since I didn't want anyone creating map-text maps yet. Starting with r4330, the synthesis package contains Lunatic Mapster32, but without the ability to save TROR maps.

[Hendricks266]

Helixhorned, on 12 February 2014 - 02:34 PM, said:

Well, then you'd either have to
* calculate the 128 blending tables at startup, which takes a couple of seconds even in the release build (it's 2²³ engine.nearcolor() calls, after all), or
* package the extended PALETTE.DAT as part of EDuke32.

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.

The how of it is undecided. I generally use the Wii as my worst-case scenario. 256 colors * 256 colors * 128 degrees of translucence = 8 MiB! That's not acceptable.

Since palettes only use 0-63 anyway, we could limit alpha to intervals of 4. 2 MiB isn't as bad, but it still requires more investigation.

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

[Micky C]

If eduke32 is going to calculate the tables at startup, maybe the player can be given the choice as to whether they want the improved translucency or classic? Then if a modder wants to use them, they can then just include it with the mod since it'll probably be a fraction of the mod's size anyway.

But can I request that the last day or two of posts in this thread be moved to the eduke32 thread? This thread has been seriously off-topic lately.

[Fox]

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.

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