DRD Team

The new version is out!

The main reason is the corrupted sprites that showed up when using the goggles. Aside from that there are several other bug fixes and most importantly, the HIRESTEX lump is finally functional.

Its syntax is very simple:

To replace an original texture, sprite or graphic use:
And to define a new hires texture use:

UPDATE: Due to an annoying rendering bug I decided to re-upload it right now. Please get 0.9.11 right now if you downloaded 0.9.10!

Seeing as how HieRes will require OpenGL and I have had no problems whatsoever with 0.9.9 well I am not gonna upgrade to 0.0.10. There just is no major need for me to do so.

If you don't use OpenGL you don't need to upgrade any further. Because that's the only thing I am going to work on in the next few weeks or months.)

Next thing on my list is model support.

Haven't had too much time with it tonight, but a couple of reasonably long games were problem free and the light-amp effect is looking great. Thanks Graf. (BTW, I like the quicker ducking speed too.)

Ooh, I'm definitely gonna try this out and report on how well it works. And I really can't wait for models. I might have to get back into 3D modelling then

Edit: Initial results prove positive
Only problem I have is the fact that the textures can't be between TX_START and TX_END, and thus aren't seen by Doom Builder. But hey, since most of my textures were already there, it's not much of a problem.

Graf Zahl wrote:If you don't use OpenGL you don't need to upgrade any further. Because that's the only thing I am going to work on in the next few weeks or months.)

Next thing on my list is model support.

Have you decided what format will these models be?

Since the only models I have to test right now are the JDRP it has to be MD2 and DMD. If I get decent specs for other formats later I might add them as well. I have designed the code in a way that the engine itself doesn't know anything at all about the models' internals so adding new formats gets easier.

The biggest problem right now is the definition format. I was hoping that I could write a parser that could read the included .DED files but that is not possible. Doomsday gives every single state a name and the models reference this name. ZDoom's states are just indices into the object's state table so I am probably forced to do something not so nice and user friendly as I hoped.

No matter what I do, it means that it is impossible to use the JDRP without extensive restucturing and that makes the whole exercise a little pointless.

New Gzdoom! Message edited.

Heh, have fun trying to get the models working Graf.

I know the amount of work you'll have to do to support ALL of Doomsdays model options (including world-time animation in Zdoom's state method).

The jDRP has always been meant as a cross-port resource pack but since the other ports arn't interested in supporting models to the same degree as Doomsday - it has slowly become more and more Doomsday dependant. For example, jDRP 1.1 won't work in Risen3D without severe butchering.

I'd be quite happy to make changes here and there in order to get it working in GZdoom too.

However, jDRP 1.1 WILL be released this Christmas (dozens and dozens of completely new models ) and I don't feel inclined to do any extensive work untill its released. Also 1.1 makes extensive use of ALL of Doomsday's features (including model particles, the particle system, shiny textures, decor lights etc etc) and will be shipped as a Snowberry addon.

I don't really expect to support all the features right away. This will be a huge task and I don't have that much time and what's worse only minimal experience with models (the only thing I ever did was to hack some code together so I could display the few (shitty) models in Silent Steel.)

For the first step I'll be glad to get some animated objects to show at all without interpolation or fancy lighting effects.

One question though: I noticed that the jDRP uses lots of .pk3's within .pk3's. Are there any restrictions regarding compression? Reading a .pk3 that is stored uncompressed within the outer .pk3 is easy but is there the possibility that the inner .pk3 may be compressed as a whole again? (I'd really prefer not to handle this case.)

The only restriction with the Doomsday PK3/ZIP handling is that if you use compression - you MUST use the NORMAL mode (as described in WinZip) (purely because the others haven't been implemented (yet)). Any number of files, depth or compression method can be used in any combination.

For jDRP 1.01 (the last offical, full release) it was set up like that for maximum flexibility (a user could disable the individual "modules" by commenting out lines in the accompanying jDRP.DED) but it will also work in many other install scenarios. I spent a fair bit of time evaluating Doomsday's virtual and physical file structures/systems to allow it to be used as either and all-in-one pack, "installed" (first depth, unpacked) to data/auto (can't be disabled unless moved out of /auto) or to data/jDoom (where the whole thing can be turned on/off depending on whether jDRP.DED is loaded).

The most likely scenario with Doomsday mods is that the inner PK3s will be compressed and not outer. It is much more flexible this way.

For jDRP 1.1 the structure has been completely redesigned to make the most of the changes made to Doomsday since then. The biggest of which is Snowberry and with it the advent of the new .addon and .box formats. The problem is that means even more work for you to do (to support fully) as each addon module has meta data which allows you to configure the addon via the Snowberry GUI.

If you don't plan on supporting the ZIP format extensively then it might be wiser to just forget the problem and require that users unpack jDRP.PK3 into it's component PK3s and create a .bat or something to load them all (last count with 1.1 was 80+).

Hmm, it doesn't look like you're using the "force32bit" value... The reason I had added that is to force specific textures to use the GL_RGBA8 format so they'd keep the full 8-bit alpha channel if you need it (ie: gradient mask or something) when using 16 bit texture formats (like GL_RGB5_A1).

No, I don't. So far I haven't had any need to. If it becomes necessary I'll add the support though.