High Resolution Pack discussion thread.

[ProAsm]

Question.
How do I know the hrp_update.zip is loading and working, what do I need to look for ?
Its in the Autoload folder together with the Duke3d_hrp.zip

[Hunter_rus]

If you place them together, it should work.
The log should indicate that the "duke3d_hrp.zip" file is loaded before the "hrp_update.zip".

Using group file 'autoload/duke3d_hrp.zip'.
Using group file 'autoload/hrp_update.zip'.

[DeeperThought]

Originally Posted by ProAsm

Question.
How do I know the hrp_update.zip is loading and working, what do I need to look for ?
Its in the Autoload folder together with the Duke3d_hrp.zip

The shrinker blast has a new graphic in the latest update. Before that it had the 8-bit graphic. So just shoot the shrinker and you'll know.

[NightFright]

I will probably bring back modified #2492 with info about HRP Update Pack version number. This way you'll know right on startup that it's working.

[ProAsm]

The log should indicate that the "duke3d_hrp.zip" file is loaded before the "hrp_update.zip".

Using group file 'autoload/duke3d_hrp.zip'.
Using group file 'autoload/hrp_update.zip'.

Using config file 'duke3d.cfg'.
Scanning for GRP files...
Using group file 'duke3d.grp' as main group file.
Using group file 'autoload/duke3d_hrp.zip'.
Using group file 'autoload/duke3d_hrp_update.zip'.

Thank you - I changed the update name for Duke3dw compatibility

The shrinker blast has a new graphic in the latest update. Before that it had the 8-bit graphic. So just shoot the shrinker and you'll know.

Cool, got that, thanks.

I will probably bring back modified #2492 with info about HRP Update Pack version number. This way you'll know right on startup that it's working.

An excellent idea.

[Parkar]

Created a HRP team group for all of us who has contributed to the HRP. Feel free to join if you have done anything for the HRP.

[The Cool One]

wow.. you can actually see the nipples now

[Hunter_rus]

The HRP issues which can be fixed with the latest official EDuke32.

1. Wall-aligned sprites.
   Added "away1"/"away2" maphacks. It's supposed to move a badly wall-aligned sprite away form wall.
   That glitch might happen to a wall-aligned sprite which angle isn't 0, 512, 1024, 1536.
   

   // E1L1.MHK: Security Screen in that room by the "Innocent?" sign
   sprite 588 away1
   
   // E4L5.MHK: "wanted dead" screen
   sprite 78 away1

2. The hanging babes. You still need to change DEFs. Any ceil-aligned model can be fixed now. By the way after you'll have fixed several DEFs,
   you will know how to adjust size for any model.
3. That should be fixed too. It's already fixed for SD_Duke mod(the animation was smooth even during "inittimer 30").

[NightFright]

How can hanging slime babes be fixed EXACTLY? I would really like to know so I can implement this for upcoming HRP Update.

[Hunter_rus]

// "Hanging" babe fixed
model "highres/sprites/characters/0603_hangbabe.md3" {
   scale 9.3 shade 2 zadd -14

Other ceiling-aligned models needs a change too. And don't forget about the accurate size adjusting for models.

[NightFright]

A. Won't this screw up all the other babes hanging from ceiling (i.e. the non-flipped ones)? AFAIK, only a bunch of flipped versions of #603 are concerned (i.e. in E3L1 sprites 591-593, in E3L3 sprites 105/447 and in E3L6 sprite 307). If all the other correct models needed to be changed, this would mean lots of work while it would make more sense the other way round.

B. What do you mean with accurate size adjusting? The light switches that are too big in some levels, for example? Would be great if someone could help me search for them - and how to do it...

[Hunter_rus]

A. It should work fine. There were kinda a math issue in EDuke32 which is fixed now.

B. Look at the map.
Switch between the classic and polymost mode. It fits.
Try changing the scale in DEFs. I'm sure you'll understand it. If not, switch to the classic mode and compare.

[NightFright]

So you mean all the babe models were too small? Hmmm...

[Hunter_rus]

As for size.
The babes are tall in that map for both classic and polymost mode.
You can see that the bottom and the top point are the same for both modes and both positions. If you don't want to you can make it smaller but some flipped models might hung in air instead of lying on the surface(for floor-aligned flipped sprites, it's a rare case though).

As for ceiling-aligned.
New EDuke32 won't break DEFs. It didn't worked properly before the fixing EDuke32 but it can be fixed now at least.

[NightFright]

I see. Seems to work indeed. Too bad OGG music is gone with the new snapshot again, though.

[0815Jack]

one question:

during the play of "Moonbase Accident epsiode" i noticed that it make excessive use of the broken push switch .... its not used in the official maps...is it possible to include this in the HRP?

[NightFright]

Someone would have to do the texture, I guess.

Otherwise, for the babes: I have changed all slime babe scales to 9.3 which seems to do the trick. Sometimes, the crouching babe is minimally floating above ground, but that seems to be an issue with sprite placement. It's hardly noticable, anyway. At least the flipped hanging girl is fixed now, which is an important fix (although the model is only used on three Ep.3 maps this way).

As for OpenAL support: Any chance you are going to modify latest Jan 26 EDuke32 snapshot again so we get back OGG music?

[Radar1013]

Yeah, NightFright is right. We NEED OGG music back.

[Hunter_rus]

As for the OpenAL.
Even though unofficial OpenAL snapshot has my features/fixes, it will be getting obsolete over time.

I think it can wait a week(=I shan't be doing anything until then).
Perhaps I'll be keeping parallel development branch for a while because there are many Vista users with broken DirectSound.

P.S. This isn't a proper thread. OpenAL snapshots have nothing to do with HRP.

[Hunter_rus]

As for model scale.
Flipped floor-aligned sprites should not be floating above the ground. That means that they should be upscaled. Some monsters are even bigger then we thought before. Are you scared?

"Flipped" = "upside-down". Press "F" twice in Mapster32.
"Floor-aligned" = "for instance, monsters who walk, objects which are lying on the ground".

[NightFright]

Well it was kinda common knowledge that the slime babes were too small. What I didn't know was that it would still have an impact on the flipped hanging babe because it looked OK when hanging from the ceiling. So I thought if it was increased in size, the normal version would get messed up.

[Hunter_rus]

This tool isn't for end user but for the HRP team.

There is a tool which will help adjust scale and offset for models("scale","zadd"). Also it will help debug model animation(slowmode).
Adjusting scale and offset: sprite and model should match in both modes(classic,polymost) and both positions(normal, flipped). You can see that Duke and some monsters should be bigger.

Keys(EDuke32 defaults):
E - flips all sprites.
R - switches to the class mode
F - switches to the polymost mode.
RMB - slowmode.

[NightFright]

Maybe someone would be so kind to make a simple map/room with all monsters, babes and the Duke character so comparison can be done faster. THX.

[Hunter_rus]

You can use the "_ZOO.MAP". But it hasn't all the sprites anyway.

[Tea Monster]

I found a bug some time ago in which if you ceiling aligned a sprite, its position on the ceiling would depend on its scale. I don't know if that is what you are running into. I asked to have it fixed about 6 months ago when I had a lot of trouble getting the shower head and the dome light into the game.

Basically, when you change the scale of an item, it shifts the center point off the ceiling.

[Hunter_rus]

@ Tea Monster
There was a bug in EDuke32.
It was fixed in my unofficial snapshots and the latest official snapshot got this fix as well. The shower head and the dome light can be fixed properly now.

EDIT

Originally Posted by NightFright

Sometimes, the crouching babe is minimally floating above ground, but that seems to be an issue with sprite placement.

If you're sure that model definition is correct and some models should be moved, you can move individual models via "pitch", "roll", "mdxoff", "mdxoff", "mdyoff", "mdzoff" maphacks(description/guide).
It's sync safe and they can be moved wherever you want.

Examples:

// move up
sprite 0 pitch 1
sprite 0 mdxoff 200000 // change the value

// move down
sprite 0 pitch 4095
sprite 0 mdxoff 200000 // change the value

[Mr.Fibbles]

The Crouching babe is off the ground in the sprite. It is something the original sprite was made with and to alter that would be to break compatibility between 8 and 32 bit.

[Hunter_rus]

Are you speaking about a specific crouching babe OR crouching babe in general?

1. If specific(the sprite was badly placed in the map): it usually hard to notice in 8-bit mode even if it's badly placed but it's noticeable in polymost. This can fixed in polymost via maphacks(see above). This doesn't break sync and doesn't affect 8-bit mode.
2. If in general(all babes): sprite and model should match in both modes and in both positions. It doesn't matter that this babe isn't floor-aligned when you place it in mapster32.

[NightFright]

Found following models to rescale:

- scaled up: 1334 (crouching babe), 1880 (sentry drone)
- scaled down: 1960 (Pigcop car), 2000 (Pigcop), 2710 (Emperor)

Amazing this was not done earlier. Changes will be included in next HRP Update. The crouching babe indeed is floating in mid-air even as a sprite. Strange, but it's not so bad ingame.

mdx/y/zoff options will require a massive maphacks revision of all Duke maps, checking them for models clipping into walls. Some help doing this would be GREATLY appreciated. You should PM me your findings, however. It would be sensible to do map-wise checks, so full reports on complete maps would come in handy.

[Hunter_rus]

Originally Posted by NightFright

- scaled up: 1334 (crouching babe), 1880 (sentry drone)
- scaled down: 1960 (Pigcop car), 2000 (Pigcop), 2710 (Emperor)

I thought there were more models which should be changed: Duke, trooper, enforcer. Some stuff(supply, armory) in the _ZOO.MAP. I just let you know. I
understand that you have too little time before the next hrp_update.

Originally Posted by NightFright

mdx/y/zoff options will require a massive maphacks revision of all Duke maps, checking them for models clipping into walls. Some help doing this would be GREATLY appreciated. You should PM me your findings, however. It would be sensible to do map-wise checks, so full reports on complete maps would come in handy.

I can't describe completely how to move models because it's the math. If it is difficult for you to calculate proper maphacks, I can do them but I would need to know sprite locations(I'm not going to find them myself).

[Mr.Fibbles]

1334 is floating as a sprite and as a result the sprite is lowered below the ground (to make it look like she is on the ground). Any change to the model to make it otherwise (and the subsequent maphacks to "correct" it) would break user maps and 8 bit to 32 bit compatibility because the maps made with HRP in mind will look very strange in 8-bit mode and vice versa.
I think NightFright knows what I mean by this.

[NightFright]

I will try to fix anything with clipping or floating for next HRP Update release, so you should not encounter any drinking fountains stuck in walls, weapons/trash cans in walls, no babes floating above ground etc. - plus correctly sized models. It might delay release, but it will be an important update.

While we are at it: Do the mdxadd/-yadd/-zadd parameters all have the value 200000 by default or what? And by how much on screen would a model be moved if you change that value by, let's say, 100 units or so?
Plus: Can this stuff be written just behind normal maphacks, e.g. "sprite 382 angoff -384 mdxadd 190000" or so? Or do I have to make a new maphack line even if it's for the same sprite?

[alandog]

thanks NightFright, and hope to see something new, lately there are really slow progresses on the project

[NightFright]

These new commands away1 or mdx/-y-/-zoff don't seem to do anything at all. I tried to move sprite 384 (trashcan) in E1L1 away from the wall but nothing happened. Used "sprite 384 mdxoff 64". Besides, EDuke32 gave me an error message:

Error on line /E1L1.mhk:98: expecting int, got "sprite"

The security screen in E1L1 still appears partially broken when approached, even with the away1 command in the maphacks. So much for this glorious new function of yours! *LOL*

[DeeperThought]

Originally Posted by NightFright

Error on line /E1L1.mhk:98: expecting int, got "sprite"

It looks like it may have been expecting another parameter from the previous command. Are you sure you didn't leave out a number on the line before?

[Hunter_rus]

Maphacks:

sprite 588 away1

sprite 384 mdzoff -600000
sprite 384 pitch 1

Make sure the map wasn't changed.

I run into some problems.

1. When you save a map using the latest mapster32, it rearranges sprites IDs. The September's mapster32 doesn't. Use it if you want to change the player starting point.
   I think the saving route should be changed back completely.
2. "Error on line /E1L1.mhk:98: expecting int, got "sprite" is harmless, ignore it. Many maphacks were added by Hendricks266. But he forgot the "break" statement.

If you still don't understand how these maphacks work, I can do them.

[NightFright]

I will see if I get it working... do I actually have to add "pitch 1", too? Even if it's not needed? And why so high values (600000)?

[Hunter_rus]

Here is a good description.
Here is my explanation.

The main idea is, it's not a movement, it is a rotation. You need "pitch", because it won't going to work without a rotation. Values are big high because the radius tends to infinity.

[IronBallz]

Hey Guys I'm sorry to post here but I don't want to make another thread. I am having problems with the High Resolution Pack since I switched to Vista, it worked in XP; but when I try to run it, I get a message that says "The Program has stopped working correctly", Even without the high res. the colors are messed up. Any ideas? Any help would be greatly appreciated.

[Mr.Fibbles]

Drivers: update them
Log: post it
Rinse, lather, repeat.

EDIT: that was too tech lingo. First, post the file "eduke32.log" or some text document titled "eduke32" in the folder. It should be a log file of what happened. From there we can help you.
First shot in the dark is that you need to update your video drivers.