[Fox]

That's evil.

[Diaz]

Only happens in Mapster32, btw. Not in the actual game.

[Gambini]

Changelog reads:

Quote

Classic rotatesprite: add assertion failing with DNF mod, comment another.

I wonder what that is. Can someone explain me in neanderthal words what that does?

[DavoX]

I don't know if this is the right place for requests but here it goes anyway:

Imagine you're doing some complicated spritework and you never seem to find the tile you need, but there's always that tile that looks so perfect but it has another object in it making it impossible to use, like this one:



The top looks so good to use on corners and such, but the column under it just ruins things. Which brings me to my request...

Could be it possible to add a small editor inside of mapster to add transparency to a tile temporarily? and only for one given map. For example by editing pixel by pixel filling the unneeded parts with that pink color.



Now, I know what everyone's thinking "use bastart, editart" and such... but my point is to make a simple quick tool that let's you make a new tile right out of the bat when you need it, only for transparency, not to make new textures. The special modified tile would be stored inside the map itself without adding new *.art files. I know this would make levels unplayable on previous versions of eduke32 but with TROR the same thing happens....

The uses that you could give to this of course are many like:

1) complicated spritework, sometimes you need a tile to fit exactly on a structure.
2) shading with transparent tiles that have pallette 4. This way you can place the shading tile on the wall and it will cast the shadow you want.
3) Making new types of masked walls, fences and such.
4) The possibity of making structures with sprites instead of walls, saving them for later use. It's really easy to reach the wall limit, the sprite limit not so much.

Let me know what you think....

[Jblade]

Gambini, on 12 May 2013 - 01:04 PM, said:

Changelog reads:



I wonder what that is. Can someone explain me in neanderthal words what that does?

Taking a look at the changelog, I will take a stab in the dark and say helix noticed some latent problems with the rotatesprite's zoom command (most likely related to the Duke bike and how it zooms in and out depending on what you're doing) I don't think it has any kind of effect on the mod itself but it should prevent problems down the line with that command.

Davox; that sounds like a cool idea but I have no idea how feasible it would really be. I think the real issue would be that it'd take alot of time to code.

[xPreatorianx]

NightFright, on 10 May 2013 - 02:01 PM, said:

While we are at the grpinfo topic again:

Besides the other idea to add a "grpdir" parameter to launch groupfiles from specific dirs, it would be great if EDuke32 could parse more than just one grpinfo file. Currently, it seems that more than just one is ignored, it's just loading the first one.
If that was implemented, you could add more groupfiles by just copying them with any custom grpinfo (which could ideally be provided directly with the download), not having to add the new data to your main file all the time.

I am currently compiling a huge ~28 addon pack, and those two features would make things a lot easier (basically, I am only waiting for this xD).

Your pack works with the latest snapshot btw. I tested it out! Thank god for that I greatly appreciate it! I also second this request!

[Plagman]

I suggest you thank the HRP contributors instead, they probably had more to do with it.

[Helixhorned]

Gambini, on 12 May 2013 - 01:04 PM, said:

Changelog reads:

Quote

Classic rotatesprite: add assertion failing with DNF mod, comment another.

I wonder what that is. Can someone explain me in neanderthal words what that does?

This means that I added a guard that terminates the debug build of EDuke32 if a particular code path is taken that would otherwise lead to undefined behavior. One of these was subsequently fixed, but another remains. Classic rotatesprite doesn't handle large zoom values well because pretty much everything is calculated in fixed point. I added some instructions on how to hit the assertion failures, for example the one I fixed reads:

Quote

// Assertion would fail with DNF mod without (uint32_t) below: in mapster32,
// set dt_t 3864 (bike HUD, 700x220)
// set dt_z 16777216
// <Increase yxaspect by pressing [9]> <-- CRASH!
// (It also fails when wrecking the bike in-game by driving into a wall.)

16777216 is zoomed in 256x, but you'll notice that for the bike HUD, incorrect drawing will already start from a zoom value of about 570000 (8.7x).

So in short: The bike mod exposed some badnesses in the classic renderer, and one on those was fixed.

[DavoX]

Great helixhorned!

[TerminX]

Working on a Polymost enhancement:

[Gambini]

So awesome we´re back to the roots!

[NightFright]

Is it just me, or is EDuke32 improving even faster than usually lately?

[Micky C]

TerminX, on 13 May 2013 - 12:36 PM, said:

Working on a Polymost enhancement:

How does that work anyway?

[TerminX]

I committed it. It's still pretty experimental, but you can enable it with r_usetileshades 1. It increases memory usage for Polymost quite a bit because it requires a separate texture be generated and stored corresponding to each shade level that needs to be drawn, but it shouldn't make each .art texture take up any more memory than the average HRP texture.

[Jimmy]

Those burgundys and maroons make him look so much more menacing in the dark. Good work, I say.

[Micky C]

TerminX, on 14 May 2013 - 06:27 PM, said:

I committed it. It's still pretty experimental, but you can enable it with r_usetileshades 1. It increases memory usage for Polymost quite a bit because it requires a separate texture be generated and stored corresponding to each shade level that needs to be drawn, but it shouldn't make each .art texture take up any more memory than the average HRP texture.

Wow, I just tried this out with my WIP DNF map, and the difference is huge! Thanks!
The sky is finally the correct orange, and the rocks have much better colour variety, making them look more interesting.

[supergoofy]

R3768 - Attrition mod crashes


something is wrong with my system. I will do a restart asap and will edit my post


[edit]

it was something on my end

[LeoD]

Quote

Revision: 3759
Author: terminx
Message: Remove md4 library, since we aren't using it anywhere anymore

Oops. On Helixhorned's proposal I chose MD4 as the map identification for the (hopefully upcoming) user map maphack system.

[TerminX]

If anyone ever gets around to doing that, they can add md4 back in (or choose something better) at the time. Or, something like crc32 (which is used everywhere else) could be used instead since it's not really about security against intentional modifications, but simple identification of files. Or, maybe we can just pull in something like md5 and use that for everything everywhere... who knows.

[supergoofy]

md5 is better

[TerminX]

Sometimes speed is more important than being secure against malicious intentions; e.g we don't have much of a reason to care about someone being able to modify a GRP file to be corrupt but still show up as valid in the startup window but we do care if suddenly the GRP scan at startup takes 5 times as long.

[Fox]

Fox, on 01 May 2013 - 07:40 AM, said:

By the way, is it possible to add SoundToggle, FXVolume, MusicToggle and MusicVolume to the avaiable userdef structures?

Any light on this? I don't want to sound like a douche, but since the source code already perform a ud check on this, I think it shouldn't be too hard to implement.

[TerminX]

I would be OK with supporting reading the values, but definitely not with setting them from within CON.

[TerminX]

Another couple of comparison shots from Polymost:

[Plagman]

E1L5 is great for that stuff. I used this one tile both for highpal and artmapping testing since it has so much variance.

[TerminX]

Indeed. On that note, I'm so glad we're able to reproduce the coloring of the original game accurately (for the most part) in all renderers now.

Please test the new mode, guys... I plan on making it the default sometime soon (just like the one in Polymer is default now), assuming major problems with it don't crop up.

[Gambini]

I have been testing it a lot, along with new polymer´s shading system.








They´re both dreamlike. There are some minor problems with each one, but most of those are known problems that have been happening long before.

It´s important to remark that the relevance of these issues in comparision to the improvements is so small that it almost makes no sense to mention them. With the exception of a few polymer specific issues, which should be IMO high priority.

Visibility in polymost may need some minor tweaking:







Here you can see that in both 32bits renderers vertical offset in viewalligned sprites is mirrored:





Some gradient ramps in duke´s palette have poor shadetables transitions, this is more noticeable in Polymost now since the visibility is based on open-gl´s regular shading system, no big deal, just pointing it out (I don´t consider it worth being fixed):




Here you can see how Polymer still has problems when rendering maskwalls that are inside a double-parallaxed sector:

FORGOT TO UPLOAD THOSE SCREENS

Here you can see how both 32bit renderers draw non-square-of-2 textures wrong (old problem anywway):





Here you can see how in Polymer decal sprites still clip their background;



Not pictured problems: Grills fences and other sprites with alhpa parts become thick and blur on a relatively short distance.

[Fox]

TerminX, on 15 May 2013 - 01:42 PM, said:

I would be OK with supporting reading the values, but definitely not with setting them from within CON.

I only intend to read it, but I suppose anyone should use it at their own risk.

By the way, is ud.config.MusicDevice even used in Eduke today?

[Diaz]

Gambini, on 15 May 2013 - 07:57 PM, said:

Not pictured problems: Grills fences and other sprites with alhpa parts become thick and blur on a relatively short distance.

Yeah, to fix this I suggest implementing a way to define tiles as nomipmap, maybe in a separate file that could then be included with EDuke32 (just like tiles.cfg).

The bad thing about the other issues is that fixing them will probably break existing Polymer maps (since they have been done with those deficiencies being present). I guess, however, that fixing thousands of non-polymer usermaps and Duke itself is more important

While I'm at this, now that it seems like the priority is to get all renderers to look like classic as much as possible, may I ask that r_usenewshading value of 1 is never removed. Pretty pretty please, it would break all I've done so far

[Plagman]

I don't think there are any plans of removing any existing functionality such as this, backwards-compatibility is understood to be extremely important. Isn't anisotropic filtering supposed to mitigate things like you describe?