[Helixhorned]

Yup, it's accessible from CON using {get,set}actor[].alpha or the sprite[].alpha inline array syntax even if it's not a member of either the internal actor[] or sprite[] arrays, but of the spriteext[] array. The values are on a 0-255 scale. Full alpha control for rotatesprite etc. is a thing for the future.

[Fox]

It's Polymer only. =S

[blizzart]

I just want to ask what´s the max numbers of pals I can define in a .def file.
For Brute Force I want to use different pals for model skins, so we can vary skin colors and clothes of enemies and NPCs.

Also I want to define new fogpals, too.

[Mark]

I took a quick look at the HRP defs and saw a few tiles that used 16 pals. No idea about the max allowed.

[Mblackwell]

Wasn't it 0-255?

[TerminX]

Yes, but a few of the higher values are reserved.

[blizzart]

Mblackwell, on 23 February 2013 - 06:12 PM, said:

Wasn't it 0-255?

TerminX, on 23 February 2013 - 06:43 PM, said:

Yes, but a few of the higher values are reserved.

Thank you both Mblackwell and TerminX,
that are enough for sure. I just wanted to know, if I can have more than 64 palettes.


But another question: can I define a normal map to a texture only once or can I have a normal map for every pal I use?

[Fox]

Just a small request, is it possible to return the badguy check from the source code in CON? Thanks.

[Mblackwell]

blizzart, on 24 February 2013 - 12:40 AM, said:

Thank you both Mblackwell and TerminX,
that are enough for sure. I just wanted to know, if I can have more than 64 palettes.


But another question: can I define a normal map to a texture only once or can I have a normal map for every pal I use?

Once.

[blizzart]

Mblackwell, on 24 February 2013 - 06:02 AM, said:

Once.

That´s sad. This would have give us the opportunity to use skins with many differences like beards, hair or no hair and much more.

Anyway, it´s not that big problem, so we will stay to different skin colors and clothes.

[Mark]

Use the skins with beard and hats like regular. When making the alt pal skins, leave the beard or hat area transparent. It should work fine when applied to the model.

[Mblackwell]

But the normal would still affect it (I think... ?). But since it's an attached prop you could probably get away with a separate model that follows the animations of your actor and just lock it to the actor's position.

[Micky C]

Is there any way of having both a fogpal and a regular pal on a sector? Maybe some way through con code? Or perhaps in the future with the new map format?

[Kyanos]

The Big Cheese, on 01 March 2013 - 03:21 AM, said:

Is there any way of having both a fogpal and a regular pal on a sector? Maybe some way through con code? Or perhaps in the future with the new map format?

What are you trying to do here? I bet that whatever the results are you're looking for, they will be possible using some con code.

[Micky C]

Well for example have an entire area blue (using pal 1 everywhere), however have a non-black fogpal.

I realized since making that post that I can get an effect very similar to what I wanted by using pal for fogpal, and the con effect to create an underwater global pal (as long as you've hooked up highpalookup to the underwater pals )
So in the mean time it's all good, however if I or anyone else in the wants to use other colours then they're in trouble.

[Kyanos]

There are more game palettes than just water, and more pals to choose from than you can shake a stick at. I'm curious now what might happen if I define a fogpal and highpal to the same pal number, will both be applied, or one or the other?

Hmmm... possibilities here, too much to talk about, no time, here's a pic. Everything is pal 26 a gray fogpal, I also defined it as a highpallookup, the pal 4 all black... 8-bit art stays normal while hightiles and models change.

[Micky C]

Hmm that's a good solution, defining both, however it would need to work for 8 bit art as well, not just high res textures and models. Don't worry about it though, I'm satisfied with my original solution (still provided that you've hooked up the underwater highpal, I haven't updated lately).

[Steveeeie]

I'm not sure if this has been mentioned before, or if its something other have noticed.

Models with alpha maps in the hrp have a bit of a problem.

If polys have an alpha map applied to them, the become transparent(expected) but polys sitting behind also become transparent, is there a way around this?

I will follow this up with a screen shortly.

[Micky C]

We know what you're talking about. It can be fixed eventually, but there are higher priorities.

[Steveeeie]

The Big Cheese, on 02 March 2013 - 04:41 AM, said:

We know what you're talking about. It can be fixed eventually, but there are higher priorities.

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

[Micky C]

Steveeeie, on 02 March 2013 - 04:46 AM, said:

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

I'm not a dev, just a mapper who spends a shameful amount of time on these forums, and utters jargon that I occasionally read about here without understanding
I'm on my phone right now haha.
But IIRC I don't think there is at the moment, but it will probably be added in the future.

Just to be on the safe side, wait and see what Plagman has to say about it.

[Mark]

I'm not up on the tech speak either, but if it means anything I think "backface culling" might be enabled in the engine. Would that be your problem?

Other will know for sure.

[Gambini]

Steveeeie, on 02 March 2013 - 04:46 AM, said:

Thanks

Do you know if there is support for two sided textures ? I'm currently getting around it by flipping duplicated polys atm, but its a bit of a waste of resources
.

In the meantime, duplicating the desired polygons and inverting their normal to simulate "nocull" is technically less expensive (at least in other engines for which I do models from time to time). And you dont need all polys to be double sided anyway.

[Plagman]

Yeah, that's the way to go. The problem with translucency is a general thing that I need to tackle, but as a general rule of thumb make sure translucent parts of your model are in their own surface, and if there is specific disjoint parts make sure they're on separate surfaces as well, so that the engine can sort them roughly.

[Kyanos]

Plagman, on 02 March 2013 - 09:30 AM, said:

Yeah, that's the way to go. The problem with translucency is a general thing that I need to tackle, but as a general rule of thumb make sure translucent parts of your model are in their own surface, and if there is specific disjoint parts make sure they're on separate surfaces as well, so that the engine can sort them roughly.

It's nice to have rules like this! Any other tidbits you'd like to share. I have many models with transparency and have learned parts of this rule the hard way. However it's news to me to that it's a well known general rule, it's not always easy learning these quirks.

[Plagman]

It's not really a rule for today, though it can help some. What I meant if that if you did that, it would make it easier for me to improve the situation later when I get to it.

What the engine does now is determine which models to draw, then go through them in a rough closer-first order and draw all their surfaces, in order. That means that if the part of your model that's fully opaque ends up behind the part that's translucent from the angle you're looking at it but everything is in surface 0, your translucent stuff might not be drawn in the right order and you might not see through it. If you move the translucent part to surface 1, you're guaranteed that it's at least going to be drawn after all the opaque parts of the same model.

Now, what I want to do eventually is have a "translucent" DEF token that tells the engine "this surface is translucent", because it would be a huge pain in the ass to try to examine the models at runtime to figure out which parts are translucent or not. This way the engine could draw all the surfaces of all the models that are opaque just fine, then walk through the translucent surfaces only and try to figure out how to alleviate any artifacts (by trying to sort them, or any other approximation that would yield better results than today). This way even if the method to make it look OK is expensive, it would only apply to a small portion of the scene.

Intersecting translucent planes are never really going to work right, however. It's not wonder than modern games avoid translucency like the plague and always use alpha-testing for world stuff. The only translucent stuff you see are particles, which are easy to sort since they're conveniently aligned.. Even things like glass panes are generally rough approximations, like additive blending.

[Mblackwell]

Couldn't you have users flag them so they are both drawn fully and blended?

[Plagman]

Which part are you referring to exactly? You can't render intersecting translucent planes without breaking them up into more polygons and carefully sorting them, which is very expensive.

[Mblackwell]

That part. I'm saying skip proper sorting and blend them if a flag is set by the modder. This would look terrible if any part wasn't alpha, and could produce visual artifacts, but for many instances it would be as good as anything.

[MusicallyInspired]

MusicallyInspired, on 09 February 2013 - 08:38 PM, said:

Got a problem with polymer on my laptop. My laptop is a decent build with a NVidia GeForce GT 550M 2GB video device. Polymer works fine and smoothly except for spotlights. In Mapster and ingame the spotlights don't show up at all. If I do 'restartvid' in the console the spotlight will appear for a split-second before disappearing again (also, I've noticed that it does not cast a shadow). I'm not sure if this was ever a problem before or not as I don't remember if I ever saw an ingame spotlight on my laptop or not. I guess I just assumed it would work. I'm already running the latest driver so that's not the problem. Any suggestions? I've tried the latest snapshot as well as the 64-bit build that was posted a little while back. No change. I'm not sure why it's not working as it's a decent NVidia card and NVidia is supposed to the best compatible device for polymer, right?

The eduke32.log file displays these lines of messages every time I typed in 'restartvid' if it means anything:

Can I bump this one more time? Also, I notice when playing e1l1 the spotlight in the street flickers on and off, and still no shadows.