[Hendricks266]

NightFright, on Dec 15 2010, 01:48 PM, said:

Hmmm... in general, adding pal 1-x tints for textures should not be needed any more since autotinting works quite well by now. However, if someone can show me where it might be needed, then it might be different. ^^

False. There are only "autotints" for 1, 2, 4, 6, 7, and 8, and these are generally very imprecise and produce dissatisfactory results.

[Fox]

Yes. It's not necessary to have alternative tiles for each pal.

The problem is that the current pal values don't match the original game.


Personally I use these values (I took them from the game colors):

Quote

tint { pal 1 red 72 green 88 blue 140 flags 1 }
tint { pal 2 red 216 green 52 blue 20 flags 1 }
tint { pal 4 red 0 green 0 blue 0 flags 0 }
tint { pal 6 red 132 green 128 blue 80 flags 3 }
tint { pal 7 red 252 green 224 blue 24 flags 1 }
tint { pal 8 red 132 green 128 blue 80 flags 1 }

[Mike Norvak]

Fox, on Dec 15 2010, 06:11 PM, said:

Yes. It's not necessary to have alternative tiles for each pal.

I just said, Tile 3387 needs a properly pick for pal20 as well as other tiles with 12-25 palettes.

Fox, on Dec 15 2010, 06:11 PM, said:

Personally I use these values

Yeah, those tints are more similar to original pals.

[Danukem]

Hmm, you might as well add a tint line for pal 20, with similar values to pal 1. Unless you can think of something in a map that is pal 20 but is not supposed be bluish.

[Hendricks266]

 DeeperThought, on Dec 15 2010, 11:38 PM, said:

Hmm, you might as well add a tint line for pal 20, with similar values to pal 1. Unless you can think of something in a map that is pal 20 but is not supposed be bluish.

No, you can't add any sort of definitions for higher pals unless a more flexible palmap system is implemented. (Like Hunter_rus', but without the problems.)

see: EDukeWiki: Palette (environment)

Compare:

Pal 0 -> Pal 1:

->

Pal 0 -> Pal 20:

->

Quote

Pal20.png
Brown, green, orange and purple [not everything] to blue
Blue to gray

[Danukem]

 Hendricks266, on Dec 16 2010, 08:23 AM, said:

No, you can't add any sort of definitions for higher pals unless a more flexible palmap system is implemented. (Like Hunter_rus', but without the problems.)

see: EDukeWiki: Palette (environment)

Compare:

Pal 0 -> Pal 1:

->

Pal 0 -> Pal 20:

->

I think you are missing my point, and wasting your time on a complicated post in the process. I'm aware that pal 20 does not make everything blue, but in the majority of cases it is used to make things blue, and at any rate defining a tint for it will yield results that are better than nothing. Right now the HRP has nothing for pal 20. If a proper system comes along (which may never happen) the tint can be removed.

[Mike Norvak]

 DeeperThought, on Dec 16 2010, 11:26 AM, said:

I think you are missing my point, and wasting your time on a complicated post in the process. I'm aware that pal 20 does not make everything blue, but in the majority of cases it is used to make things blue, and at any rate defining a tint for it will yield results that are better than nothing. Right now the HRP has nothing for pal 20. If a proper system comes along (which may never happen) the tint can be removed.

But still there're few missing textures for pals like 14,19,24,25,etc....

[Danukem]

Norvak, on Dec 16 2010, 09:30 AM, said:

But still there're few missing textures for pals like 14,19,24,25,etc....

25?

Anyway, there's more than a few, I would wager. And all of those alternate pal textures increase the size of the HRP, and increase load times. There's just no good way of dealing with the problem at this point.

[Mike Norvak]

DeeperThought, on Dec 16 2010, 11:45 AM, said:

25?

DeeperThought, on Dec 16 2010, 11:45 AM, said:

Anyway, there's more than a few, I would wager. And all of those alternate pal textures increase the size of the HRP, and increase load times. There's just no good way of dealing with the problem at this point.

Wherever, that´s true.

[Tea Monster]

Palmaps!

If the old implementation was buggy, couldn't someone re-visit it and get it working?

[Plagman]

It really wasn't any different than having the different palettes stored on disk, and the result was way less flexible.

[Fox]

The problem is that no one care about making a freaking different texture for every single pal...

Not to say that the resulting color for each different texture would not match.


So yeah, I would like to see palmaps.

[Hendricks266]

DeeperThought, on Dec 16 2010, 11:26 AM, said:

I think you are missing my point, and wasting your time on a complicated post in the process. I'm aware that pal 20 does not make everything blue, but in the majority of cases it is used to make things blue, and at any rate defining a tint for it will yield results that are better than nothing. Right now the HRP has nothing for pal 20. If a proper system comes along (which may never happen) the tint can be removed.

I see what you're saying. It makes sense from a practical standpoint, especially since textures (although not models) can have palswaps defined to completely override default tints.

Tea Monster, on Dec 16 2010, 02:09 PM, said:

Palmaps!

If the old implementation was buggy, couldn't someone re-visit it and get it working?

Hendricks266, on Dec 16 2010, 10:23 AM, said:

No, you can't add any sort of definitions for higher pals unless a more flexible palmap system is implemented. (Like Hunter_rus', but without the problems.)

We've been through this before, but Plagman basically summed it up. Here's a more in-depth quote from TX about why Hunter's attempt was removed:

TX said:

Yes, "palmaps" didn't really work very well and I didn't like how they were implemented so I removed them. They resided in the engine side of things, yet were hard coded to only work with Duke3D's palette configuration. This is a no-no. They also used just as much memory when loaded as just having a complete altered copy of the skin, because the overlays were added in at load time rather than multitextured on during rendering. Therefore, due to their implementation, the ONLY purpose they served was to possibly make the filesize of the HRP smaller, in a world where you can get 1000 GB of HD space for $100 USD. So they're gone.

[Tea Monster]

Surely there is some kind of OpenGL command like the photoshop 'multiply' command that overlays one texture on top of another. Then you just tint the overlay in the engine and you can see the original skin underneath, but colourised. Wouldn't it work just like the glowmaps?

[NightFright]

In order to celebrate the new year, I have compiled a self-extracting archive with the following:

> EDuke32 r1749 (Dec 30, 2010) binaries (full release included as zipfile, only eduke32.exe is already extracted which is needed for gameplay)
> Polymer HRP v4.2.174 with latest maphacks
> Roland SC-55 Music Pack v2.0
> Duke Nukem 3D v1.3d shareware data (duke.rts, duke3d.grp)

Extractor will create a "Duke3D" dir on any hard drive you specify. If you own the full game, replace duke3d.grp with the version from the full release (preferrably Atomic Edition) and you are ready to rumble. XXX Pack users can drop the file into the "autoload" dir.

Get it here (605 MB)! BTW, mirrors might come in handy...

[djdori11]

NightFright, on Jan 1 2011, 07:46 AM, said:

In order to celebrate the new year, I have compiled a self-extracting archive with the following:

> EDuke32 r1749 (Dec 30, 2010) binaries (full release included as zipfile, only eduke32.exe is already extracted which is needed for gameplay)
> Polymer HRP v4.2.174 with latest maphacks
> Roland SC-55 Music Pack v2.0
> Duke Nukem 3D v1.3d shareware data (duke.rts, duke3d.grp)

Extractor will create a "Duke3D" dir on any hard drive you specify. If you own the full game, replace duke3d.grp with the version from the full release (preferrably Atomic Edition) and you are ready to rumble. XXX Pack users can drop the file into the "autoload" dir.

Get it here (605 MB)! BTW, mirrors might come in handy...

awesome! and thank you very much for keeping it up! the hrp is from 2006 (?) and today is 2011! 5 fucking years

[SwissCm]

The HRP started early 2004, basically when JonoF implemented hi res texture support.

[NightFright]

Actually, we would have loved to issue HRP v5 instead of a mere repack of existing HRP files, but for this, a milestone should be reached first. A logical and possible one would be to wait for Ep.2/3 completion. Looking at the to-do-list, there is really not much left to do to achieve this.
Ep.2 is missing 8 textures and the Skywalker model (wasn't someone working on that some while ago already, btw?), while Ep.3 is down to 7 textures, 2-3 models (Indy, Fetusjib and a switch) plus a couple of highres number sprites. I believe the community should be able to pull that off well within this year, provided the creative and productive guys find some time to work on it.

Completion of all the episodes which 1.3d version had would certainly be a nice achievement for 2011, wouldn't you guys agree? ^^

[Tetsuo]

Then of course there's those models and textures that need "next gen" (higher resolution models with normal maps, etc.) replacements for but yeah if you mean just having something in there to replace the old then those at the remaining things to be done. But I guess those could be held for a future milestone. Some people are unhappy with the current models in general thinking voxel replacements would be better.

[NightFright]

What I have seen so far indicates that Voxel stuff is a blurry mess which doesn't look anything near highres even. xD But true, the general aim is first to have replacements for the old sprites/textures at all, then efforts to improve them would make more sense. It is obvious that much of the stuff which is now in the HRP is outdated, many models are in there for years without any adjustments. Babes also look more like placeholders, and even the latest HUD shotgun remake didn't really convince as a real improvement over the previous model.
Anyway, changes can only happen if/when contributions are actually made... ^^

[fgsfds]

I made original greyfont / 1.3d menu font in ttf if someone need it. Current greyfont in hrp is terrible. Maybe someone will remake it.

http://dl.dropbox.co...03/GreyFont.ttf

[Tea Monster]

 Tetsuo, on Jan 3 2011, 08:37 PM, said:

... in general thinking voxel replacements would be better.

Are you sure about that?

[Tetsuo]

 Tea Monster, on Jan 4 2011, 08:41 AM, said:

Are you sure about that?

I didn't say I think that just that I see other people say things like that on here. I once spoke out against voxels and I was practically torn to shreds.... also from the latest thread on voxels for duke3D:

 Martin, on Jan 3 2011, 07:57 AM, said:

This intrigues me greatly. I've been thinking about getting Eduke32 or DukePlus running on my rig, but one of the things that bothers me about it is that the 3D monsters just look shit.
*snip*
Voxel models of the old sprites would be great.

I personally think voxels don't look good (a blurry mess like NightFright says) the way they are now but yeah... there are people here who favor them any way.

[NightFright]

Well, if someone feels like investing much time into making voxels, why prevent him/her from doing so if there are people out there who want it? Personally, I would never use it though since voxels can't beat a decent model with a highres skin - and I think concentrating on finishing up undone models might deserve a higher priority. But like I said, nothing wrong with "parallel development" at all. If there actually IS some. ^^

[Tetsuo]

Yeah, to be technical I can't hold a gun to their heads and force them to not make any but I can choose what I personally run.

[Tea Monster]

 Tetsuo, on Jan 4 2011, 09:41 PM, said:

Yeah, to be technical I can't hold a gun to their heads and force them to not make any but I can choose what I personally run.

I don't have any problem with people who love the original sprites. More power to them. Voxels are cool, great stuff. They just don't have the same resolution as a model.

We have the HRP with models, they have a Voxel replacement programme - everyone is happy.

What I can't understand is the people jumping up and down saying that the HRP is "sh*t". These same people then clamour for voxel sprite replacements. They are making the voxel sprite replacements directly from the HRP models.
Wait a minute, didn't they just say that the HRP models are 'sh*t'? So why do they want a lower res, blocky representation of the HRP models, and think that is great? Does anyone see the reality disconnect there?
Its like getting a new, HD, flat-screen TV, looking at it for a few minutes in HD, then saying "You know, that looks like sh*t". Then said person goes over to the TV, pokes around in the back for a minute till the resolution of the TV is now at 128 pixels wide. Person walks back to chair and sits down. On the screen is a barely recognizable lego-brick version of the HD TV signal "Ahhh, now THAT is what I'm talking about!" he says. It dosen't make any sense at all, on any level.

[Radar]

The problem with you guys is that you automatically assume that everyone wants the best looking graphics they can get they're hands on. We all know voxels look like crap, but we want them because of the nice classic look. We want to play Duke as if it had come out with voxels. Even if most of the time they look worse than the original sprites, they are just simply fun and cool to look at.

[bullerbullerseven]

 Radar1013, on Jan 5 2011, 10:02 PM, said:

The problem with you guys is that you automatically assume that everyone wants the best looking graphics they can get they're hands on. We all know voxels look like crap, but we want them because of the nice classic look. We want to play Duke as if it had come out with voxels. Even if most of the time they look worse than the original sprites, they are just simply fun and cool to look at.

I would love to have something better than voxels. But voxel seems to be the only choice for you to make it look like the original game :S

[LeoD]

Hi Roma Loom,
some nitpicking on 1173 : the background structure's colour should tend to be more orange and the edges of the metal structure would be better off if the edges were less sharp so that some light reflects on them (compare the former svn version).
Thanks a lot for keeping up working on the HRP!

[Roma Loom]

Agree. I was just lazy to make the red part of the door as a separate layer to tinker with colors. I always choose speed over quality for duke tiles, otherwise it would take forever.