ZDoom

ReX wrote:

Graf Zahl wrote:Should be fixed now.

What is the build number? On the devbuilds.drdteam.org page shows the last build as gad6ce5a, posted on Nov 9.

I checked GitHub, but I don't see where the new build can be downloaded. [Admittedly, I am a GitHub novice, and I may be looking in the wrong place.]

And thanks for fixing this.

I inquired about this, got no answer... had to build it myself yesterday and couldn't get sound to work. >_<

ReX wrote:What is the build number?

There isn't one at the moment.

Graf Zahl wrote:Should be fixed now.

What is the build number? On the devbuilds.drdteam.org page shows the last build as gad6ce5a, posted on Nov 9.

I checked GitHub, but I don't see where the new build can be downloaded. [Admittedly, I am a GitHub novice, and I may be looking in the wrong place.]

And thanks for fixing this.

WTF O_O, that was one of the most waited feature I ever wished :O.
I think I even did a request in the zdoom fórum but it ended with a no ;I .
At least, it's now working

Graf Zahl wrote:Should be fixed now. Please note that the new code cannot check for texture presence anymore. Since the texture manager gets initialized after MAPINFO the only solution was to let MAPINFO store the textures' names and do the actual lookup during precaching itself.

Nice solution, ignore if the texture is missing instead of game crash.

Should be fixed now. Please note that the new code cannot check for texture presence anymore. Since the texture manager gets initialized after MAPINFO the only solution was to let MAPINFO store the textures' names and do the actual lookup during precaching itself.

Ugh...

Looks like MAPINFO does not have access to those textures. This will need to be checked more thoroughly.

I tried the PrecacheTextures feature in MAPINFO, as follows:

PrecacheTextures = "XMETL08", "XMETL09", "XMETL10"

However, I get the following error when GZDooM loads up:

Script Error, "Paranoic.pk3: MAPINFO" Line 90:
Unknown Texture "XMETL08"
Script Error, "Paranoic.pk3: MAPINFO" Line 90:
Unknown Texture "XMETL09"
Script Error, "Paranoic.pk3: MAPINFO" Line 90:
Unknown Texture "XMETL10"

These graphics are in the Textures folder of the pk3.

I also used these graphics as patches to create "XMETL08A", "XMETL08B", etc. in the TEXTURES lump. When I insert these names in the MAPINFO I get the same error.

Is this feature intended only for textures defined in TEXTUREx and not in TEXTURES?

Ral22 wrote:Does this support the cache-ing of Graphic lumps as well, such as for HudMessages? Or does this need testing to verify?

Isn't it all part of the same texture manager? I think it's worth a try.

I know one of my mods gets a small delay when first displaying a high-res scope graphic. Would be neat if that could be avoided.

This is one of the finest things I've ever seen. Thank you kindly, Graf!

Does this support the cache-ing of Graphic lumps as well, such as for HudMessages? Or does this need testing to verify?

Nash wrote:Oh wow this is massive, thanks Graf!

Why massive, this was a 5 minute thing...

Oh wow this is massive, thanks Graf!

added

Projects with true high resolution resources would be greatly benefited by such a feature. The "texture on a wall" thing only works for smaller jobs. I can say for my own high resolution project I have to make this "cutscene intro" just to load the monsters and maps so the game runs normally. It looks fine but I would rather not have to resort to such a construct. Wouldn't push anyone to implement it but it is a great idea.

Nash basically wrote:

Thus why I support this feature suggestion.

Waaaay back in time when my weather system was in its infancy, I used 100 separate textures that go from a clear sky to an overcast sky. The skybox would flip between these textures in real-time as the weather shifted around. This made the game appear really laggy as each texture is loaded for the first time (they were 1024x flats :O).

To work around this, I setup a dummy sector that shows all 100 flats in a single room (cut the sector into 100 strips and texturing them appropriately, and placed a camera far enough so that its initial POV would catch all of the textures) and finally setup a small 32x32 camera texture placed on the HUD but OFF SCREEN so essentially the player is "looking" at all of those 100 textures but you can't see them on the HUD because I placed them far away (had I continued to use this overly convoluted solution, I would eventually find out that my trick will break with multiple-monitor setups). This little camera texture would be drawn on on the screen with HUDMessage everytime the player enters that particular map.

Good thing I scrapped that convoluted shit as I developed more advanced ways to render the sky with cloud particles and eventually a skydome... :P