[fgsfds]

Is someone works on shotgun model? I tried to make new texture for it. Is it ok?

[Roma Loom]

You shouldn't probably touch the shotty since it's scaled down by the depth axis. Now when have the ability to define render FOV for HUD weapons - the shotty should be started from scratch imo.

[NightFright]

Both the new shotgun model and the old one to which the majority decided to roll back to are/were horrible. However, it is one of the most difficult weapons to do apparently due to its limited amount of frames. I still hope someone will come up with a convincing solution for it one day since it remains one of the most frequently used weapons in the game.

[The Commander]

Roma Loom, on Mar 22 2011, 11:17 PM, said:

Now when have the ability to define render FOV for HUD weapons

http://dukeworld.duke4.net/eduke32/synthes...4/ChangeLog.txt
Been there for almost a month now.

[Roma Loom]

Yeah, I've used it for new RPG, Fist and CrackNuckles. I should have written "now when we have".

[Striker]

Roma Loom, on Mar 22 2011, 11:06 AM, said:

Yeah, I've used it for new RPG, Fist and CrackNuckles. I should have written "now when we have".

"Now that we have"

By the way, perhaps there could be a way to contact the maker of this Duke3D Shotgun?
http://www.gamebanana.com/skins/19675

If proper permission is acquired, I can easily convert this into a workable model without hands for you guys to experiment with. Just name the format you want it in, and I'll do it.

[Roma Loom]

It's already used in DukePlus. The problem is not about making model, the shotty is pretty easy do to in comparison with shrinker or freezer. The problem is to animate it without all that jerkness due to the limitations of the current animation system.

[NightFright]

Build #229 committed. Changes:

> Fixes for shotgun ammo and multiswitch by empyrock
> Renames for 249_s, 250_d/s, 746_n/s (letters had been written in capitals)

[fgsfds]

Some models, fixed for work with polymer. Also they are converted to md3, so you can delete original md2.

[Master Fibbles]

There were md2 models in there?

[NightFright]

Changes committed with rev. #230. And yes, there were (I think there are still some left, actually)...

[fgsfds]

There are still about 50 md2 models in hrp. What are the advantages of md3? Is it necessary to convert all md2 how it's written in to-do list?

[Plagman]

Yeah, Polymer lighting won't apply to MD2s. Weird though, I thought Parkar converted all of them at some point in the past.

[fgsfds]

All models are converted to md3. I hope I don't missed something. You can delete all md2s, because there are some models already converted or unified, but md2s still not deleted.
And a question. Why you don't delete textures, that was polymerised and isn't used anymore? For example 0396.png. Instead of it 0396_d.png is used, and 0396 just takes space.
Also, Hendricks266, you can use new orange font (based on new 13d font) in your vacation hrp if you want.

[Master Fibbles]

I think the redundancies have to do with polymer vs polymost.

[LeoD]

Mr.Flibble, on Mar 24 2011, 12:39 AM, said:

I think the redundancies have to do with polymer vs polymost.

There is a general inconsistency in polymerising textures because AFAIK no official policy exists.
Usually xxxx.png/jpg is polymerized by creating xxxx_d.png, xxxx_n.png, xxxx_s.png. Sometimes the old file gets deleted.
But there are quite some cases where xxxx.png gets overwritten by files that should have been named xxxx_d.png.
Sometimes the original stays in place and only xxxx_n.png and xxxx_s.png are added.
There are more cases of orphaned files in the repo, btw.

I think that quite some polymerized versions do not look as good or as close to the ART as their polymost predecessors. Therefore it wouldn't be bad to keep the latter for later comparison and as incentives for improvements. (But since it's the PolyMER repo...)

[Plagman]

There was an official policy, and it was to add diffuse maps as _d without touching the old Polymost texture in order to keep both. The idea behind that was to have a script that would go through the tree and remove all _d, _n and _s maps as well as associated DEFs to automatically generate a Polymost HRP. However NightFright failed to keep a bunch of old Polymost tiles when doing commits, so we would have to comb through the SVN history to correct that. Anyway, more incompatible stuff has been added since then and I don't really care anymore, so let's go ahead and remove all the old, now-orphaned Polymost textures.

LeoD, on Mar 23 2011, 05:23 PM, said:

I think that quite some polymerized versions do not look as good or as close to the ART as their polymost predecessors. Therefore it wouldn't be bad to keep the latter for later comparison and as incentives for improvements. (But since it's the PolyMER repo...)

Are you saying that from comparing the _d and the old texture in an image viewer or looking at the Polymer texture in game with lighting applied? The point of diffuse maps is that they look ugly without lighting, since they don't have lighting baked in them like Polymost textures do.

[LeoD]

Plagman, on Mar 24 2011, 01:49 AM, said:

There was an official policy, and it was to add diffuse maps as _d without touching the old Polymost texture in order to keep both. The idea behind that was to have a script that would go through the tree and remove all _d, _n and _s maps as well as associated DEFs to automatically generate a Polymost HRP. However NightFright failed to keep a bunch of old Polymost tiles when doing commits, so we would have to comb through the SVN history to correct that.

That's not neccessary (anymore). My unofficial Polmost HRP update would be a good start. Especially since the DEFs are created for easy side by side comparison with their Polymer counterparts. Besides the renaming IIRC about 35MB would have to be re-added.

Plagman, on Mar 24 2011, 01:49 AM, said:

Are you saying that from comparing the _d and the old texture in an image viewer or looking at the Polymer texture in game with lighting applied? The point of diffuse maps is that they look ugly without lighting, since they don't have lighting baked in them like Polymost textures do.

I'm aware of that. Of course things get worse once specular and/or normal mapping are turned off for performance reasons. I have attached a few example screenshots, not to call the polymer textures bad work, but to show that I'm not talking complete nonsense.

Attached thumbnail(s)

• 
• 
• 
• 
• 
• 
• 
• 
• 

[Hendricks266]

empyrock, on Mar 23 2011, 06:36 PM, said:

Also, Hendricks266, you can use new orange font (based on new 13d font) in your vacation hrp if you want.

I don't think your 8-bit tiles work with the Duke 3D palette.

SwissCM himself suggested an orange version of his font at some point as well, although I don't know if he was referring to yours or one of his own creation.

[NightFright]

A new full build of the Polymer HRP preview is available. It also contains the md2 to md3 conversions, hopefully everything works.

Maybe keeping builds/SVNs for Polymost and Polymer HRP separated would not have been bad after all. While it seemed to be a good idea to have a unified SVN for everything, it turned out to be confusing, especially with many people committing revisions. The script stuff seemed promising, but apparently the new naming convention for files did not reach everyone back then. To me, it would seem sensible if nothing were deleted now until the material has been saved for Polymost-only HRP builds. Then, cleanup of Polymer repository might commence.

Ah, and everything I had deleted back then was re-added again right afterwards, so nothing was actually lost (at least not in cases where the diffuse map file was named differently compared to the Polymer version). I admit I still made some mistakes in the beginning since I did not get the difference between common Polymost textures and diff maps, but well, errors are human.

[fgsfds]

You forgot to remove 0133_slotdoor.md2

[NightFright]

Well, in the downloadable build it is removed anyway. Will do that with the next commit (or anyone else).

[Plagman]

The Polymost tiles would still be in the revision log, so nothing would actually be lost if we removed them today.

[Plagman]

LeoD, on Mar 23 2011, 07:29 PM, said:

I'm aware of that. Of course things get worse once specular and/or normal mapping are turned off for performance reasons. I have attached a few example screenshots, not to call the polymer textures bad work, but to show that I'm not talking complete nonsense.

Looking at the textures from your examples, the "polymer" versions look overall a lot closer to the original tiles wrt shape and object placement. However, you're right that examples #2 and #3 do look inferior on these shots; that's because there's no light in the vicinity. Eventually all level lighting will come from actual lights and not old sector shading, so this kind of thing won't happen in the future; stuff will either not be in view or lit as intended. I don't see the issue with #1, it looks pretty good to me, other than the big blue light that showed up out of nowhere.

[Micky C]

Plagman, on Mar 25 2011, 03:38 AM, said:

Looking at the textures from your examples, the "polymer" versions look overall a lot closer to the original tiles wrt shape and object placement. However, you're right that examples #2 and #3 do look inferior on these shots; that's because there's no light in the vicinity. Eventually all level lighting will come from actual lights and not old sector shading, so this kind of thing won't happen in the future; stuff will either not be in view or lit as intended. I don't see the issue with #1, it looks pretty good to me, other than the big blue light that showed up out of nowhere.

Do you mean with maphacks like the ones I've been working on or is there going to be some kind of alternate solution? Like light textures actually emit light or something? Because if maphacks are going to be the ultimate light solution for the original levels, a lot of them from episodes 1 and 4 are going to have to be modified as they seem to have been designed as a supplement rather than a replacement.

[Plagman]

Yeah, they'll have additional features to remove the old sector lighting and be easier to edit from mapster, but that's about it. That's how Parkar originally did the E1L1 maphacks, he removed all sector lighting and started over with Polymer lights.

[fgsfds]

Don't know where to ask. Why is sw_hrp contains stuff for deadly kiss? Is it even released?

[Hendricks266]

empyrock, on Mar 27 2011, 06:32 AM, said:

Don't know where to ask. Why is sw_hrp contains stuff for deadly kiss? Is it even released?

Shadow Warrior High Resolution Pack thread

I decided to incorporate all the add-ons into the mainline HRP for SW because 1) there are not any major differences between them like CONs, and 2) the disjointed structure of the add-on HRPs for Duke make setup unfortunately complicated.

Deadly Kiss has not yet been publicly released. A group of 4 people, including myself, are working on polishing it up while waiting for the final OK to release it.

[fgsfds]

Some updated signs, props and remaded steroids pickup to look more similiar to the original sprite.
And about calendar. 3d realms site says that the game "set sometime in the early 21st century", so it can't be 3007's year. It is difficult to see something on the original sprite but it looks like October 2007.

[Master Fibbles]

I think the calendar has been discussed ad nauseam here before. "It shouldn't be 'cucumber' since that isn't a real month" "We don't know what date it is" "Maybe it is the release date of DNF" etc etc etc.