hi-resolution sprites

[Guest]

Hey has anyone seen hi resolution sprites
used in T.C.'s for zdoom? I'd sure like to
see one. I made a few skins that use the
effect, but don't have a page! :¬(
If anyone knows where I can find a hi-rez
t.c., or want's a skin, mail me at:

jeremystepp2hotmail.com

Thanks

[Enjay]

LilWhiteMouse has done a few, most notably "Chosen". Unfortunately she is having problems with her web site ATM and I don't know if the files can be DL'ed elsewhere.

[boris]

Massmouth 2 uses hires sprites.

[Biff]

LilWhiteMouse has done a few, most notably "Chosen". Unfortunately she is having problems with her web site ATM and I don't know if the files can be DL'ed elsewhere.

Haven't seen Massmouth yet, but Chosen can be had here: http://home.earthlink.net/~mjblakely/data/

The Scarab keys are especially fine, as well as the Isis Warriors and Queen.

[wildweasel]

Hmm...my upcoming project uses high-res almost to excess. But enough hype =P

[Hirogen2]

Randy, what we would need at last would be a PNG reader, since I do not really
like the idea of loading his highres sprites uncompressed :-X

[Mighty Duck X-treme]

Seconded.

1.) The .PNG format is better than .GIF

2.) Doomsday has a unique support for high-res sprites where sprite frames are patches. They can be replaced with external resources just like all other patches. There are some restrictions, though: the dimensions of the external resource do not affect the actual size of the sprite frame. This means the external resources must really be high-resolution versions of the original images. Otherwise the size and/or aspect ratio will not be right for the resource.

For example, in order to replace the Doom medikit (lump name MEDIA0), one would place the file media0.png into the Patches directory.

Color-mapped versions of sprite frames can have external resources, too. To indicate that a resource is color-mapped, its name is formed like this:

• (patchName)-table(classNum)(tableNum).ext

(patchName) is the sprite frame lump name. (classNum) is the number of the color translation class. This number is always zero in jDoom and jHeretic. In jHexen, it's the player's class (0=Fighter, 1=Cleric, 2=Mage). tableNum is the index number of the color translation table. jDoom and jHeretic have 4 tables, jHexen has 8. For example: playa1-table01-ck.png would be the Doom player sprite frame A1 with color table 1. The -ck suffix makes the image color keyed (i.e. special colors indicate transparent pixels).

I do wish ZDoom's high-res sprites will be implemented in a way similar to JDoom's. That would be a kickass feature! ^_~

[randomlag]

If you really used the JDOOM method you'd find a big problem - namely that none of the "hires" texturs show up in an editor - unless you make a special 2nd version just for editing.

On top of that, you lose a great deal of control since you can't control the it anywhere near the same as you can in ZDOOM. In ZDOOM all the standard patch rules are still followed. This means you can reuse the SAME patch and get various resolution images with NO increase (other than the space for defining a texture - a pittance) in PWAD size.

And last but not least, the graphic files (as used for JDOOM) are friggen HUGE, even with compression. Plus it's extremely confusing to use/install with all the various directories, blah blah. Sure it works, but compared to the ZDOOM method it's not easy, not flexible, not user friendly and not editing friendly.

[Mighty Duck X-treme]

Right.

IIRC, you *don't* insert the Hi-Res textures into a wad nor do you use a map editor to edit the textures the way they look.

When the Doom64 TC team used Hi-Res sprites/textures in their TC, the sprites/textures were in two .pk3 files which are considered important data that were needed for full performance in the Doom64 TC.

• Doomsday\Data\doom64\Auto\D64_data.pk3
  Doomsday\Data\doom64\Auto\D64_data2.pk3

Without them, graphic data will result in less resolution as well the pre-rendered floor textures that's extremly important for the TC.

Similar sprites/textures are made and put into the wad.

[randomlag]

Correct - JDOOM graphics are not in the PWAD - one of the "problems" noted. You still use an editor to put the names in the sidedefs and align - the difference is that you can't see them

The TC could have been done just as well with ZDOOM with the textures embedded in the PWAD

Both methods could be done to make everyone happy as in (IIRC) ZDOOMGL.

[Mighty Duck X-treme]

No. There were some features in Doomsday that were not in ZDoomGL. That was why the Doom64 TC crew chose Doomsday as the TC's main source engine.

First of all, the TC was originally meant to use ZDoom. The main reason was that it was most widely used, very flexible, and a favorite. (Which is why we're here, right? :-P)

The TC was going at a snails pace, however, and re-creating the Doom64 experience couldn't be done. The crew realized that Doomsday (which was still new when the project started) evolved into what looks to be the perfect port for the job of the TC. The graphics, models, enviornments, and gameplay was so close to Doom64, the TC has been barreling forward at a brisk pace since the port was changed.

[Xaser]

That's bad, how they switched engines, because my slow-as-molasses (When compared to all the new ones) computer can't run Jdoom worth a crap. Too, bad.

[FUTURE-EDIT] Sadly, this was true. Of course, my fast-as-lightning modern computer still can't run Doomsday because Snowberry is a piece. Word.

[Giomancer]

Hmm, that is sad that they switched engines; they're the only reason I downloaded Doomsday. It is a good TC, though. I had been using Vavoom to get my 3D fix before that. While I like the engine, there really isn't much out for it, which is why my Heretic Project™ (One) will be for Vavoom.

To get back on topic, though, I think a .PNG reader would be great! Not that I ever have anything do with graphics...

[randi]

If all you want is a PNG reader, go to the load game menu.

[Giomancer]

Ummm... Yes Randy. But that's not what I meant and you know it!