[Tea Monster]

I'm thinking that there should be two seperate packs.

Currently, the HRP with both packs is pushing a Gig. This is only going to get worse, as more next-gen assets get added. Polymer versions of critters look like they will be pushing 20Mb with skins. Once a few of those go in, along with extra normal and spec skins for other items (especially at higher res than before), things are going to get really bad.

Those who want a Polymost pack are going to be downloading hundreds of Mb of stuff they don't need.

As I have said before, the aims of the two packs, and how they are executed, means that they should share no, or at least very few, assets. Currently, we have to share assets as not everything is complete, but if all the packs were complete, then all the Polymer diffuse skins would be rendered differently than the Polymost skins, due to how the renderer handles lighting.

Ideally, if those who wanted to preserve the Polymost pack wanted to improve it, they could bake on lighting from a 3D program like Max or Blender. Roma Loom showed how this could be done. Ironically, to make the best use of this way of doing things, you need to make a Polymer version first and then bake it down to a polymost file

[Plagman]

The end-goal is to have packages automagically built from SVN, with only the polymost or the polymer stuff, so that people can just pick whichever. SVN download size shouldn't really matter here as you're already pulling a lot more stuff if going that route.

Trooper Tom, on 07 April 2012 - 11:28 PM, said:

After that I wanted to make some optimization with no visible quality loss (Not all files were optimized and believe me it DOES influence the performance greatly).

Are you talking about PNG optimization? That doesn't affect ingame performance at all, the textures aren't PNG anymore in the on-disk cache and DXT compression has a fixed cost. The only thing PNG compression would be able to _slightly_ affect is loading times without the cache enabled, and it's not clear whether it would improve it or make it worse (depends if the bottleneck is pulling the files from disk or decoding them).

Please make sure you don't try to optimize normal / height maps, are most PNG "optimization" software just destroy them.

[Plagman]

Some actual data: as of right now the pack is 660M including the Polymost stuff and 640M with only the Polymer data.

[Spiker]

I never play with cache enabled so I can easily see that larger textures cause longer loading times and even pauses while playing. You say the full Polymer pack is 640mb? I think I could easily beat it under 500mb. The mere deletion of unnecessary alt palletes makes it close to that number. Having the packs separate should not only be considered on the end-user end but the developers as well. If the packs were separate they would be much easier to manage and introducing changes to one pack would not break the other. If you say the size does not matter then we should do it. This would also be a good occasion for some cleanup and proper renaming of files like adding relating suffixes etc. This would make stuff so much better organised.

[Hendricks266]

Regardless of how much easier it makes it for us as pack producers and artists, as long as the pack is separated by renderer there will be massive headaches for the end user, and a noob storm by people complaining why the Polymer HRP looks wrong in Polymost. Therefore, they must remain together. It is not really that much of a burden.

[Spiker]

You're partialy right but typical users won't and probably should not download SVN packs. They should download proper packs that would be posted every month or so when the update is justified. SVN is more of web development folder isn't it?

[MusicallyInspired]

I use the SVN because I don't want to download huge ZIPs all the time. It's just easier to update. I also like to get the updates as they're released and not have to wait for an update ZIP pack. Using the SVN for updates also makes it easier to implement. Everything is already coded properly, you just copy it over to your HRP folder instead of changing around definitions yourself.

That said, I don't mind if polymost and polymer HRPs are combined for the time being. Once Polymer is (more) complete it could be its own deal then. I'll never use polymost again at this point so I can live without it. But as I said, for now it's fine.

As for the shotgun, I've tried it and the animation looks funky like the older "new" shotgun we had for a while before we reverted. Not as bad, though. But still....odd. How come the older shotgun model works so well animation-wise and these new ones don't?

[Spiker]

You did not get my point. I never said you shouldn't use SVN, I said it's not for typical users/noobs. You're experienced enough to know how to use it. Most people don't update their HRP often. Hell, most of them will never instal any SVN client and they will just download the packs from the HRP site as any new user would probably do.

[Hendricks266]

SVN is no longer difficult thanks to my SVN Auto-Downloading Script Set which has been around for some time. Its SVN client is self-contained, and you simply download the 7z, extract, and run one batch file to download, and you can re-run it again later to update. It is also extensible; it self-documents how to make your own parameter scripts for your own SVNs and projects.

[Spiker]

That's really cool! However you should try to think about it not as an experienced user but a complete newbie. I bet 95% would still prefer to download typical zip packs. You see these days even a slightest bit of effort is dicouraging people. They just want to download and play and not to learn new stuff, even if it's simple. Only after they are hooked they may be interested in a more efficient way.

[Hendricks266]

You are right about preference for zip packs. Once Plagman gets around to writing an SVN commit hook to generate zips on demand or after every commit, I envision an HRP download page where, for the main HRP at least, instead of a wall of text we have two columns. On the left it says "Quick & Simple Installation" with a link to a zip file and relevant instructions, and on the right it says "Easy & Efficient Updating" with svn_checkout.7z and relevant instructions.

[NightFright]

We would also eventually need a different layout/design for the HRP homepage. As you can see, the current downloads section has become pretty crowded with stuff. I am trying my best to keep some order there at least, but the list is getting longer and longer, requiring you to scroll a lot. There has to be a way to make it look more compact.

Other than that, I also think that eventually we should end up with different (but simultaneous!) Polymer/Polymost releases. However, with all this rearrangement being done, it shouldn't be forgotten that there are still textures and models left to do. I am writing the same again and again ofc, but while having remakes like the new shotgun is great, large parts of episode 4 are still full of sprites and lowres tiles. Hopefully some guys with lots of time and motivation pop up outta nowhere all of a sudden and do some miracle work. (OK, I am living in a dream world. Don't wake me up though, please...) xD

[Spiker]

Some fuckery is going on here in the header: http://hrp.duke4.net...ext_hrp_release

[Spiker]

NightFright, on 08 April 2012 - 03:35 PM, said:

Hopefully some guys with lots of time and motivation pop up outta nowhere all of a sudden and do some miracle work. (OK, I am living in a dream world. Don't wake me up though, please...) xD

From time to time someone new appears but usually it doesn't last too long. One or two guys can't do everything. Well, at least not in a short period of time. Hire new guys or search for some tutorials yourself and then the process will speed up. Don't worry everything will be remade - eventually. Unless I'm dead

[Mark]

I was cruising thru the HRP and noticed some names and tiles have been accidently switched around. Tile 0395 and 0396 along with their normals, specs and details tiles need to be straightened out.

[Spiker]

I see nothing wrong with these tiles. I even compared them to their 8bit counterparts and they match them perfectly.

[Mark]

I don't have the pics in front of me right now but,

395 has 2 horizontal bars across the door. Its normal and spec maps have more. They match up to 396 instead. Stuff like that.

ADDED: Here we go.

Attached thumbnail(s)

• 

[Spiker]

It's good that you want to help but in this case you're clearly wrong. Everything is fine with these files. There is no just 2 horizontal bars, there's more. The two just have this pattern and this is well reflected in the normal and specular map.

[Mia Max]

I hope this can explain it.
The tile 0395 is only used for polymost.

Here is the def part for polymer:
texture 395 {
pal 0 { file "highres/textures/0395_d.png" xscale 2.0 yscale 2.0 specpower 1 specfactor 0.3 }
normal { file "highres/textures/0395_n.png" parallaxbias 0.015 parallaxscale 0.025 }
specular { file "highres/textures/0395_s.png" }
detail { file "highres/detail/rust.png" xscale 0.15 yscale 0.15 }
}

0395_d matches the spec and normal map.

Attached thumbnail(s)

• 

[Mark]

never mind, deleted

[Striker]

Guys, myself and one of my clanmates mustered up the cash to buy the original source material for the Duke 3D Explosion, so it can be used in the HRP: http://www.mediafire...vl0q9ey6vjolp73

It's in MOV format, and will need to be split up into frames. It unfortunately is cut off a bit, so, some photoshopping skills will be necessary.

Enjoy. I pray that you guys can make use of this, as we shelled out quite a bit for this...

[MusicallyInspired]

I wonder, would it be beneficial to add some kind of system (via DEF or whatever) where you could add extra frames to an animation? Like program a single regular animation tile with up to 3 or 4 extra frames or something (with a specific define in a DEF file for those texture tiles) and have EDuke32 take those into account when animating something. Take the explosion, for instance. It would look incredible with more frames of animation. It would keep the same animation "speed" but have more frames showing (up to 3 or 4 each) in place of one frame in one frame's time. This would do wonders for fire, teleporting, water, toxic, and lava animations. Similar to how the model system in EDuke32 blends model animation frames together for models that replace sprites.

[Diaz]

Isn't the fire animation defined in CON code? FIRE_FRAMES or something like that.
You could just change it and point it to a different set of tiles with more animation frames... as for water, you can just create new water tiles, same for lava (though in that case you would have add code so it damages the player and other actors)

[MusicallyInspired]

Manipulating CON doesn't really preserve vanilla Duke for the HRP, though really. Though, I suppose it changes about as much as a DEF would anyway I guess?

[Hendricks266]

It can be done with the -mx command line (CON module) switch but the problem is that currently there is no good way to load that into the game. I'm working on it.

[Master Fibbles]

MusicallyInspired, on 17 April 2012 - 07:30 AM, said:

I wonder, would it be beneficial to add some kind of system (via DEF or whatever) where you could add extra frames to an animation?

This would solve way more problems than just explosions or fire. The shotgun animation, various characters, etc.

Wasn't there going to be a new animation system? Or did I miss its release?

[Danukem]

I guess you guys are talking about the game creating new frames of sprite animation on the fly, which somehow interpolate between two existing tiles to make a third tile that is half-way between them, then display that new tile at the right times.

Dream on. That is totally different from the model animation smoothing that Plagman added a few years back and will never happen.

[MusicallyInspired]

But why? I'm not saying it's a standard feature in EDuke32 right now of course, but why couldn't it be? I'm well aware it would be something that would have to take place on the programming level. I also know that thinking up an idea is much different than actually implementing it. Why is it so seemingly impossible, though?

[Helixhorned]

The count and rate of frames of a non-actor tile (like one specified with animtilerange) is a property of the first tile in the sequence, so adding extra frames by itself is possible unless the needed tilenums following the last frame are taken. This issue could be remedied by providing a more general means of defining frames, like mapping each frame index to a distinct tilenum. But besides these technical obstacles, I'm not convinced that a simple linear interpolation blending will achieve results that are pretty to look at, so either more frames would need to be gotten out of the source material (which may be lost as in the case of HRP water?), or some kind of structural interpolation would be necessary.

[Danukem]

Helixhorned, on 18 April 2012 - 01:37 PM, said:

But besides these technical obstacles, I'm not convinced that a simple linear interpolation blending will achieve results that are pretty to look at, so either more frames would need to be gotten out of the source material (which may be lost as in the case of HRP water?), or some kind of structural interpolation would be necessary.

I think that's an understatement. Linear interpolation will only provide a morphing effect, but morphing is not acceptable animation in the vast majority of cases. If it were, then coming up with, say, weapon animations for the HUD would be very easy, because all we would need is a point A and a point B, and we could use a program to generate the rest. For certain things like the dissipation of smoke, linear interpolation might be fine, but in most other cases it would probably look terrible. As for creating new animation with structural interpolation: obviously there is a large amount of intelligence and analysis that has to go into making that happen. I would think if someone had the know-how to make that effect, they could put it to much better use than adding it for free to EDuke32.

Also, if the technology were available, it would seem more sensible to run the process on the tiles outside of EDuke32 and then make a mod that uses the results. Otherwise, there would be a lot of processing time and memory used within EDuke32 to create and maintain the tiles each time.