Doomsday's default definitions already have material glow's for lava (and water and nukage). As far as I am aware, Doomsday doesn't support textures or anything for material glows, so I personally can't think of much that can be added to the mentioned defaults.
Doomsday's default definitions already have material glow's for lava (and water and nukage). As far as I am aware, Doomsday doesn't support textures or anything for material glows, so I personally can't think of much that can be added to the mentioned defaults.
I wasn't sure but I figured they might, however if the texture image is changed? the lighting effect might to as well. this of course also depends on the layer effect needed from that point. eg - the effect will need to match up with the defuse texture.
~ unless DE uses a composite/inverted color of the primary image for the effect on its own?
Despite what the documentation implies, glows are currently only rendered with flats; textures and such currently do not give off glows (they are only rendered full bright), but will do in future.
Hmm, yeah I see it may only have to do with the base texture, in this case lava or slime flat.
Although I was thinking of (tech4 engine materials again) where I'd have control over a brightmap kind of effect.
At the moment though, in DE it seems the effect only has to do with lightmap or glow in this case. ~ I don't plan on hacking a way in to the effect like I did with ?spcwall4? with a shinymap acting as a brightmap heh.
So there's not much I can do with that, that DE doesn't already do! ~ at least at this time.
Darn it! I was thinking brightmaps again!!! :P
Yes, and yes.
I know gzdoom supports brightmaps, I made a map a few years ago, never released however (a small project we were working on at teamhellspawn) that had many brightmaps. ~ they can look pretty neat if used right!
Yeah, Danij let me know a couple of weeks ago that DE is to have support for them in the near future!
I just spaced it heh, and was thinking of tech4 materials again.
Thanks Vermil for the quick reply!
@KuriKai, have you thought about the bubble idea in the lava and maybe slime flats? ~ I'd understand if it would be a pain because of animation.
Oh btw, Gary brought up an interesting question as if the hi-res version of the flat animation might have more frames? I'm wondering about this too.. Do hi-res versions allow for more frames than the original 4 frames? ~ going by only observation, DE takes the original 4 frames and adds a couple extra frames for fadin/out for a smoother animation. Does hi-res allow this also?
I remember a command and a pack that allowed for the liquids to use smooth animation. I used it back in the days of 1.8.6. Clearly it was possible back then but if I recall correctly was broken with the 1.9 series. Funny that an old game like Doom 64 could make the water smooth but Doomsday now can't, not to mention cloud scrolling. At least Doomsday can make it glow when Doom 64 couldn't.
well dday dose not need that one wad anymore as it can have up to 12 frames of animation for flats tho that number is a bug you should be able to have any number of animations.
Woah! there has to be some, limit, maybe?
At least 256 frames maybe?
~ script stages? or frame limit?
This of course just my opinion, but anymore frames than that would tend to get a bit redundant?
I can understand more frames or stage effects maybe needed in case of some random specific effect, but more than 200 frames etc? depending would seem to be quite a lot of frames(images) to push out for some random effect. This.. is just imo of course.
~ however I can also understand that "hey, why not?", "I'd surely like to see it!"
I suppose it doesn't matter much in a set block of memory for some huge amount of 128x images.. ~ but say the images were 512x?
Although I suppose, that isn't bad now days if it's only around 1mb memory.. if it (was only 256 frames), and 512x images?
~ In this case, a 512x image being around 4kb X 256 frames = 1024?
~ although (in such cases) a translucent background/alpha mask which would no doubt increase file size possibly x2 also.
Anyways, what I'm getting at is.. unlimited?.. there just has to be some sort of marked limit.
I'm not sure how it works in this case, I'm guessing currently DE could play a 7 hour movie though if wanted? :P
~ or would it say, "hey! this script is using too much memory!" ?
speaking of resolution, I think the hi res textures should be higher res than what already exists. Also with modern computers, it shouldn't be an issue, yet you talk about resolution and frame rate budgets as if this is the 1990s. Yep, once Doomsday software is up to date, this won't be an issue. Also 1mb (or maybe you mean MB) of memory is nothing. It wouldn't be bad nowadays if it was 1000 times that (1GB). In an age of the average desktop having 16GB of system RAM and 4GB of video card RAM, your concern seems unnecessary.
@Gordon: There is no such limit to the number stages (frames) an animated material (flat) can use.
I will need to test but all the testing thus far has had the frames end at 12 no matter if there were more in the sequence thus for now until it's fixed it's a bug at 12 but like i said i need to do more testing with the current unstable builds.
Edit: My mistake it only goes up to 9 now if you think this should not be then please enlighten us as to the proper way to have more then 9 frames as i would like to know so i can fix jhonxfluids even tho it's not doom looking it would be nice to have an alternate.
Gary you totally miss the point, and totally misunderstood what I was saying, sorry..
Unless of course you were in reply to someone else? ~ which wouldn't make sense either.
The question has to do with frame animation (and how many), via material script. If it's indeed unlimited, as said, it wouldn't bother me. The point is, there usually is a limit. ~ As in my example I was talking about a theoretical value with a 256 limit. ~ using a typical 512x texture size. And in most cases (just so you'll know), a texture doesn't need to be any larger than that. ~ unless of course the artist wants them to be.
To help, In the previous post, Gordon is having trouble trying to find an actual frame amount as well.
@Gordon: Sorry but I've no idea what you are referring to. The only fixed limit on the number of material stages is so large that it's irrelevant. What bug?
However, that doesn't mean its a good idea to try and use it for video because it would be massively sub optimal. The assumption is that the mod author uses their best judgement to settle on a practical balance between fidelity and performance.
That tells me nothing. Can you upload the mod in question, describe what you are trying to do and what isn't working as you expect. As I said earlier, there is no fixed limit in effect here. So either there really is a bug that is causing that to happen, or there is a problem in your mod.
The way flat animations are defined in id Tech 1 mods is using a linear range of flats/textures. The first and last frame of animation is defined by the game, say, BLOOD1...BLOOD3. This means that all lumps which appear between these two "bookends" according to their position in the lump index, will form the final animation.
So, if the animation is BLOOD1...BLOOD3 and you want to add extra frames into that sequence (lets go with 12 in total), the WAD should look something like:
Note how BLOOD1 and BLOOD3 are always first and last respectively, with the new frames added inbetween. In JohnXfluids.pk3 the BLOOD3 lump is nine places away from BLOOD1, therefore the animation consists of only nine frames.
Most likely this mod was made many, many years ago, back when Doomsday was using a logic for defining such animations that was incompatible with vanilla's method. This was changed for compatibility reasons as there are far more mods using the vanilla logic which we must be compatible with.
ah thank you that make more sense but that needs to be somewhere so that people can read it as i did not know the texture animations had changed.
Edit: so i fixed my test blood and now it sorta works well no it dose not work how you stated it should. it goes in order of frames 1,2,3,4,6,7,8,9,12 so i need to do some testing.
I believe it was indeed documented in the change log at the time (I'm thinking 1.9.0-beta4 but I may be wrong).
Its not something that crops up very often because frankly, there are very few mods that relied on the old logic. In modern Doomsday you don't need to rely on that mechanism at all, as all such animations can be completely redefined using the Material system.
Edit: You'll need to reorder and rename the lumps and also rename the hires patches accordingly. Simply moving them around won't fix it.
You no longer need a ded def at all for extending or reducing the number of frames in the Vanilla animations (obviously if you make an all new animation or modify the amount of time each frame takes, then you would need to write a ded def or similar).
In your Pwad, just make sure the first and last frames/lumps of your animation are named FWATER1 and FWATER4 respectively and then run the Pwad by itself (i.e without the ded def).
If converting to the new mechanism, I would abandon the vanilla method of "injecting" lumps between the bookends in the lump index because this can be problematic for various reasons. Instead, I'd add the new lumps outside the range defined by the bookends and then use a Material definition to move them into place and set up the timing.
Gary you totally miss the point, and totally misunderstood what I was saying, sorry..
Unless of course you were in reply to someone else? ~ which wouldn't make sense either.
The question has to do with frame animation (and how many), via material script. If it's indeed unlimited, as said, it wouldn't bother me. The point is, there usually is a limit. ~ As in my example I was talking about a theoretical value with a 256 limit.
Well, it seemed like you were concerned about memory usage and resolution. You said it wouldn't be a problem if it was just 1Mb as if 1Mb is a lot. It is so tiny.
Maybe part of what I said was a rant to the fact that the engine still can't take full advantage of modern hardware, but on the other hand, it is good it is changing and Doomsday is evolving a lot in the past 2 years.
If converting to the new mechanism, I would abandon the vanilla method of "injecting" lumps between the bookends in the lump index because this can be problematic for various reasons. Instead, I'd add the new lumps outside the range defined by the bookends and then use a Material definition to move them into place and set up the timing.
You'll notice that its more work doing it this way but there are quite a few advantages.
I can see that but i think the pay off is worth it. Having something that works and shows off this new method is what needs to be done so i will start work on converting it all tomorrow and post a link so people can download it.
Edit: is DoomsDay suppose to crash if the text you posted is in a DED as mine dose. strange.
Comments
~ unless DE uses a composite/inverted color of the primary image for the effect on its own?
http://dengine.net/dew/?title=Ded_material
Despite what the documentation implies, glows are currently only rendered with flats; textures and such currently do not give off glows (they are only rendered full bright), but will do in future.
Although I was thinking of (tech4 engine materials again) where I'd have control over a brightmap kind of effect.
At the moment though, in DE it seems the effect only has to do with lightmap or glow in this case. ~ I don't plan on hacking a way in to the effect like I did with ?spcwall4? with a shinymap acting as a brightmap heh.
So there's not much I can do with that, that DE doesn't already do! ~ at least at this time.
Darn it! I was thinking brightmaps again!!! :P
Thanks
Dday does plan to support brightmaps, as DaniJ has mentioned here viewtopic.php?f=3&t=875&p=11689#p11689
Yes, and yes.
I know gzdoom supports brightmaps, I made a map a few years ago, never released however (a small project we were working on at teamhellspawn) that had many brightmaps. ~ they can look pretty neat if used right!
Yeah, Danij let me know a couple of weeks ago that DE is to have support for them in the near future!
I just spaced it heh, and was thinking of tech4 materials again.
Thanks Vermil for the quick reply!
@KuriKai, have you thought about the bubble idea in the lava and maybe slime flats? ~ I'd understand if it would be a pain because of animation.
Oh btw, Gary brought up an interesting question as if the hi-res version of the flat animation might have more frames? I'm wondering about this too.. Do hi-res versions allow for more frames than the original 4 frames? ~ going by only observation, DE takes the original 4 frames and adds a couple extra frames for fadin/out for a smoother animation. Does hi-res allow this also?
Thanks
http://www.dengine.net/dew/index.php?title=Group
I hope that changes one day
At least 256 frames maybe?
~ script stages? or frame limit?
This of course just my opinion, but anymore frames than that would tend to get a bit redundant?
I can understand more frames or stage effects maybe needed in case of some random specific effect, but more than 200 frames etc? depending would seem to be quite a lot of frames(images) to push out for some random effect. This.. is just imo of course.
~ however I can also understand that "hey, why not?", "I'd surely like to see it!"
I suppose it doesn't matter much in a set block of memory for some huge amount of 128x images.. ~ but say the images were 512x?
Although I suppose, that isn't bad now days if it's only around 1mb memory.. if it (was only 256 frames), and 512x images?
~ In this case, a 512x image being around 4kb X 256 frames = 1024?
~ although (in such cases) a translucent background/alpha mask which would no doubt increase file size possibly x2 also.
Anyways, what I'm getting at is.. unlimited?.. there just has to be some sort of marked limit.
I'm not sure how it works in this case, I'm guessing currently DE could play a 7 hour movie though if wanted? :P
~ or would it say, "hey! this script is using too much memory!" ?
Edit: My mistake it only goes up to 9 now if you think this should not be then please enlighten us as to the proper way to have more then 9 frames as i would like to know so i can fix jhonxfluids even tho it's not doom looking it would be nice to have an alternate.
Unless of course you were in reply to someone else? ~ which wouldn't make sense either.
The question has to do with frame animation (and how many), via material script. If it's indeed unlimited, as said, it wouldn't bother me. The point is, there usually is a limit. ~ As in my example I was talking about a theoretical value with a 256 limit. ~ using a typical 512x texture size. And in most cases (just so you'll know), a texture doesn't need to be any larger than that. ~ unless of course the artist wants them to be.
To help, In the previous post, Gordon is having trouble trying to find an actual frame amount as well.
However, that doesn't mean its a good idea to try and use it for video because it would be massively sub optimal. The assumption is that the mod author uses their best judgement to settle on a practical balance between fidelity and performance.
The way flat animations are defined in id Tech 1 mods is using a linear range of flats/textures. The first and last frame of animation is defined by the game, say, BLOOD1...BLOOD3. This means that all lumps which appear between these two "bookends" according to their position in the lump index, will form the final animation.
So, if the animation is BLOOD1...BLOOD3 and you want to add extra frames into that sequence (lets go with 12 in total), the WAD should look something like:
F_START
BLOOD1
BLOOD1A
BLOOD1B
BLOOD1C
BLOOD1D
BLOOD2
BLOOD2A
BLOOD2B
BLOOD2C
BLOOD2D
BLOOD2E
BLOOD3
F_END
Note how BLOOD1 and BLOOD3 are always first and last respectively, with the new frames added inbetween. In JohnXfluids.pk3 the BLOOD3 lump is nine places away from BLOOD1, therefore the animation consists of only nine frames.
Most likely this mod was made many, many years ago, back when Doomsday was using a logic for defining such animations that was incompatible with vanilla's method. This was changed for compatibility reasons as there are far more mods using the vanilla logic which we must be compatible with.
That mod will need to be updated accordingly.
Edit: so i fixed my test blood and now it sorta works well no it dose not work how you stated it should. it goes in order of frames 1,2,3,4,6,7,8,9,12 so i need to do some testing.
Its not something that crops up very often because frankly, there are very few mods that relied on the old logic. In modern Doomsday you don't need to rely on that mechanism at all, as all such animations can be completely redefined using the Material system.
Edit: You'll need to reorder and rename the lumps and also rename the hires patches accordingly. Simply moving them around won't fix it.
what would you suggest to make it easier to convert this into the new format?
In your Pwad, just make sure the first and last frames/lumps of your animation are named FWATER1 and FWATER4 respectively and then run the Pwad by itself (i.e without the ded def).
Heres how to do that with the NUKAGE animations: You'll notice that its more work doing it this way but there are quite a few advantages.
Maybe part of what I said was a rant to the fact that the engine still can't take full advantage of modern hardware, but on the other hand, it is good it is changing and Doomsday is evolving a lot in the past 2 years.
Edit: is DoomsDay suppose to crash if the text you posted is in a DED as mine dose. strange.