Is this a problem of TR1 visible on a real pc, too? If so, then there
won't be any fix for this (think it'd not be possible as it is a bug in the
3d [software] rendering algorithms then). If not, then try the different
cores, especially the normal core for testing.

>Is this a problem of TR1 visible on a real pc, too?

no, a no-emulator install ends up with Lara having her shadow

>If so, then there won't be any fix for this (think it'd not be possible as it is a bug in the 3d [software] rendering algorithms then)

don't know how, but anyways Paul Gardiner & dege have both come up with some hack for this

>If not, then try the different cores, especially the normal core for testing

so I did, but no core switching makes any difference.
I didn't mention I'm using v. 0.72 with ykhwong's 09/03/2007 cvs build for glide support.

If on a real machine the shadow is correctly shown, why do they need a hack?

>If on a real machine the shadow is correctly shown, why do they need a hack?

you're telling me. But I can't tell.
If they didn't need it, why did they add respectively a "shadow hack"
and a "Fix TR1's shadow-problem" button ?
Maybe because they noticed that otherwise their emulators were losing Ms. Croft's shadow somewhere.

Which takes me back to the point :
a "real pc" TR1 game shows her shadow,
TR1 via Glidos & dgVoodoo does too, but so it is thanks to a specific option of theirs, and Dosbox doesn't.
Does anyone has a clue why ?

you're telling me. But I can't tell

No, you're telling me, i don't have a clue what shadow thing
would be wrong, looks quite nice to me.

If they didn't need it, why did they add respectively a "shadow hack"

Dunno, ask them.

I didn't mention I'm using v. 0.72 with ykhwong's 09/03/2007 cvs build for glide support.

Well then ask on his board.

I guess you are running ykhwong's DOSBox in Glide mode?

Glide is not supported by the official DOSBox and will only support Tomb Raiders basic DOS era looks (only a shadow blob on the ground and basic texture shading on surfaces).

Best to submit this feature-request on ykhwong's forum.

Erik.

I've added glide feature from gulikoza for a while, and I do not support it at all.

ErikGG wrote:

I guess you are running ykhwong's DOSBox in Glide mode? […]
Show full quote

I guess you are running ykhwong's DOSBox in Glide mode?

Glide is not supported by the official DOSBox and will only support Tomb Raiders basic DOS era looks (only a shadow blob on the ground and basic texture shading on surfaces).

Best to submit this feature-request on ykhwong's forum.

Erik.

Thx Erik for your response.
Yes, I'm running precisely ykhwong's DOSBox in Glide mode
and I fully understand it isn't supported by official DosBox.
Still, I also understood, just like subsequently ykhwong himself pointed out, there's no support for that glide feature anyhow and that's the only reason I tried and posted a message here, mainly to get possible feedback from other users who compare Dosbox to Glidos etc.
Thanks anyway.

DOSBox glide uses a straight approach - everything is forwarded to the wrapper as it is. I don't know what hacks dgVoodoo and Glidos use, so I can't implement them unless the details of what is needed are released.

gulikoza wrote:

DOSBox glide uses a straight approach - everything is forwarded to the wrapper as it is.

A strange thing I noticed about this shadow thing is

either a straightforward TR1 & TR UB install or the use of "mainstream" Dosbox (e.g. v. 0.72 without Glide) for it will produce the effect

Glidos and dgVoodoo follow suit, even if their glidey shadow is different (larger, lighter and nicer) than the original basic rendering,
this hack of theirs appears to be only necessary for TR1 (Unfinished Business doesn't mind if the option is unchecked and will have the shadowy speck anyway), now I thought the engines of TR1 and UB were equal, but apparently some engines are more equal than others

finally, Dosbox with Glide support lacks the effect, but, baffling enough and contrary to the previous observation, unbiasedly does it much the same with both TR1 and UB !
In this case, the 2 programs are sure to behave well (or bad) in step like two homozygotes twins.

Isn't it a bit odd ?

to gulikoza :

please check your inbox
as I sent you a PM on this.

now I thought the engines of TR1 and UB were equal, but apparently some engines are more equal than others

You can be sure that even if two games are using the "same" engine that the newer one has a more advanced version of the engine (examples are Ultima 7 - The Black Gate and Ultima 7 - Serpent Isle, Ultima 8 and Crusader - No Reegret/Remorse, Ultima 6 and Worlds of Ultima - Savage Empire/Martian Dreams (I'm giving Ultima examples since I'm 100% sure of these 😀))

Admittedly that was a cheap chance to an Orwellian quotation 😉

EDIT

TR 1 Unfinished Business is actually some 18 months younger than TR 1.
It was out well after TR 2, building of course on TR 1 set

See (if links are still viable) these interesting "historical" resumés :

http://web.archive.org/web/20000831233949/www … lipCampbell.htm

http://web.archive.org/web/20001013121902/www … /news0154a.html

I saw the light among the shades ! Fear no more for Lara's shadow ! 🙄

In practice, thanks to Paul Gardiner who as frank and helpful as he always is was quickly responsive, and thanks to gulikoza's actively assisting me with debugging hints and moral support,
I was able to tweak the glide patch code a bit in glide.cpp so as to make sure Lara's shadow will show, and will correctly do, in dosbox.

grConstantColorValue() function is where the patching applies.

I plan to start a new thread on this, maybe not here in games/apps, but in the development section where it probably belongs,
so that anyone interested may intervene and hopefully improve the hack 😀

..hmm, before I start any new brilliant thread in development :

I noticed that in TR Unfinished Business the hack doesn't hack a thing 😵
there's still no shadow there !
Talk about TR1 & UB being different engines. Here's a brand new demonstration they are 😒

Anyway, could I resist the challenge ?
Besides, I don't know why, but I always loved those pretty UB four levels very, very much 😀

So, in the end I had to discover that this time the thing doesn't involve grConstantColorValue(GrColor_t color) anymore,
but as I saw, it had to be
grConstantColorValue4(float a, float r, float g, float b)
a function that's not even documented in the glide programmer's guide 😒 so it took some more research.
Anyway what's more, grConstantColorValue4() implied a different tweak, a dreadful (to me) tryst with float maths & pointers, with glide.cpp always as the battlefield.

The result I am happy to say is working fine and happily didn't break the original TR 1 trick of mine.
Like I said, sometimes it's a good thing they changed their way, so TR1 calls one routine, while TR UB calls another, and the 2 hacks may well thrive together.

Did I ever tell you I plan to start a new thread on this, maybe not here in games/apps, but in the development section where it probably belongs ?

but in the development section where it probably belongs ?

New dimensions of postings! ...not

A little update :
I modified my tweaks after seeing they could break the display of the health bars in Tomb Raider, you know the brown health bar and the blue air supply bar, resp. in upper left & right corners of the screen when Lara draws weapon, or is hurt, or else is swimming.

Well, they could become black and non responsive to game status, apparently because locking right away and for each and every subsequent call the constant color value might entail failure of drawing "the flat-shaded texturing using constant color(grConstantColorValue) as the shading value" to quote the glide reference manual, hence the frozen black bars.
Not a treat in gameplay when you need to be aware of your health and air supply anytime.

Besides, I already didn't enjoy the hack being so general, so "public" as it tweaks grConstantColorValue() from its first occurrence. I always wanted to have more nested a call to the function(s) involved.

So I worked it out this way : moved the 2 tricks with respectively grConstantColorValue() for TR 1 and grConstantColorValue4() for TR UB, instead (this is the point) I call them (each one according to the case) from within a later function (later, that means the debug log shows it's called further in time in the game session) :
now either in guColorCombineFunction() or grAlphaBlendFunction() it's the same (I chose the latter in the end), before executing the local function you call grConstantColorValue() there to set the constant color on the spot.

I extensively rechecked it out with TR 1 and TR UB, with new games and load savegames, and after some ironing efforts I was content this way not only the shadow is OK, but at the same time you get the right colors in the bars back, and dynamically active in gameplay as they must be.

Well, here is how dgVoodoo handles TR1-problems:

Missing shadow: When I first tried to get TR1 to work with the wrapper, I figured out that TR1 engine mostly drives the wrapper through the utility-function set, so that through the guXXX functions. All of the pixel-pipeline settings are done via guColorCombineFunction, etc. I noticed that the black background of texts at the opening menu-screen was drawn once because it flashed for a moment, but not anymore. I guessed TR1 must use a simple constantcolor-pixelpipeline configuration to draw it, after all it's the simpliest way. So I tracked down where TR1 set black color and (about) half alpha via grConstantColorValue at the beginning (0x7F000000). I was manage to catch that point, and also found that it used guColorCombineFunction(GR_COLORCOMBINE_CCRGB) to config the pipeline. guColorCombineFunction with GR_COLORCOMBINE_CCRGB was kept called after, but grConstantColorValue(0x7F000000) wasn't for some reason. Also, the point is, GR_COLORCOMBINE_CCRGB is only used to draw the shadow AFAIR. Different mode is used for all other untextured polygons (because they are lightened, e.g. Lara's arms and legs, etc.).
So, all that dgVoodoo does is calls grConstantColorValue(0x7f000000) from guColorCombineFunction (GR_COLORCOMBINE_CCRGB).

Here is the code snip:

void EXPORT guColorCombineFunction( GrColorCombineFnc_t func ) {

DEBUG_BEGINSCOPE("guColorCombineFunction", DebugRenderThreadId);

LOG(0,"\nguColorCombineFunction(func=%s)",colorcombinefunc_t[func]);
astate.flags &= ~STATE_DELTA0;
switch(func) {
.
.
.
case GR_COLORCOMBINE_CCRGB: /* konstans */
grColorCombine(GR_COMBINE_FUNCTION_LOCAL,
GR_COMBINE_FACTOR_NONE,
GR_COMBINE_LOCAL_CONSTANT,
GR_COMBINE_OTHER_NONE, FXFALSE);
if ( (platform != PLATFORM_WINDOWS) && (config.Flags & CFG_TOMBRAIDER) ) grConstantColorValue(0x7f000000);
break;
.
.
.
}

DEBUG_ENDSCOPE(DebugRenderThreadId);
}

The other thing is related to TRUB, it uses the delta0 ligthing mode. It isn't mentioned in Glide 2.43 SDK, must be obselete there. Delta0 means that a contant color is used (can be set with grConstantColorValue4) in place of iterated vertex colors. This is corresponding to the flat shading in DirectX, but the constant color comes from the first vertex of a triangle there.

There's no giving thx enough for this communication, dege.

/* gulikoza, can you believe this ? I hit the jackpot with conjuring up that 7f000000h value . Talk about the usual, unfair beginner's luck ! Fully rewarding though for the long hours spent feeling the ultimate human wreck, a situation that when I was a boy my old man would have christened : praying the saints who don't want to do no miracles.
I wiped these lines from the draft, something tells me you remember 🤣 ,

1#if LOG_GLIDE
2	LOG_MSG("\n Initial global constant color value is 0x7f000000\n");
3	LOG_MSG(" Overridden constant color value as in param[1] would now be %d\n", param[1]);
4#endif

I might well use them instead à la Montaigne, who had those Herodotus quotations carved on his library ceiling 😜 */

dege,
searching for any piece of info I could, I fetched this authentic greater than life Faustian "prologue in heaven" in a discussion between you and Paul Gardiner in 2003 (you knew what you do in vogons echoes in eternity didn't you) and if VOGONS allows a VOPONT (very old post onto new thread) here's an excerpt :
"(Paul) Dege, BTW, I'm sure you are right about the TR1 shadow. I had exactly the same problem, and had to put a strange hack into Glidos to make it work. I found the hack didn't break any other games, so its hard wired. Actually, for a while I hard wired it into OpenGLide, which was a bit naughty.
(dege) Yes Paul, it really seems that the error is in TR1 itself. However I can't imagine that [there was] no shadow on a real Voodoo card. Painfully, I've never seen it, never had a Voodoo card. Once I thought I should buy a real one just because of TR
(Paul) I think there may have been bugs in early versions of Glide that TR1 then relied on. Something like the alpha unit having its own cache of the constant color value that doesn't get updated if the alpha unit is off... or something completely different 😀"

So when I started fiddling with glide.cpp (from gulikoza's glide patch source) browsing stdout.txt for all the debugging log messages I poured in I saw in a normal TR1 testing session guColorCombineFunction() is called some 35,000 times, while e.g. guAlphaSource() is called 3 times only, grAlphaBlendFunction(), grConstantColorValue() and grColorCombine() about 1,500 times each. Not a single call to grAlphaCombine(), though. Why ?

Then I looked up the constant color value, that's 0x7f000000, but after 2 initial calls to guAlphaSource(), the latter seemed to be forgotten, and the constant color value started changing in series like ab ab ab then cde cde cde and so on, but always in a range 0 to 0xffffff so they must be all 24 bit rgb numbers, I guessed.
So I thought, why not try ORing them all along with the first constant color value, a 127 alpha channel, sorta, plus the RGB figures ?
That was the 1st time I saw a shadow stand-in appear in dosbox w/glide, but it was anything but a normal shadow. More on this in a moment, for this will be the whole point of my questioning to you.

In the end, I concluded I was better off with no OR, but just locking constant color to that 7fh (decimal 127) in most significant byte.
In TR Unfinished Business I saw (but only now that you explained I can see why) it changes, but eventually boils down to the same business via a call to grConstantColorValue4() taking four float's instead of an int.

To fix the health bars corruption, I figured it was a bit premature to lock the constant color to begin with, Minority Report-style, before you stick your nose out you're already frozen, not fair.
Moved the tweak to either guColorCombineFunction() or grAlphaBlendFunction() it worked with both, although I put it in the latter in the end, for no special reason (maybe 'cos I like the sound of the word blend).

This is a little snippet to put it more clearly
---------------

1    case _grAlphaBlendFunction16:
2	// void grAlphaBlendFunction(GrAlphaBlendFnc_t rgb_sf, GrAlphaBlendFnc_t rgb_df,
3	//		GrAlphaBlendFnc_t alpha_sf, GrAlphaBlendFnc_t alpha_df)
4
5
6	if(tomb == 1)	// gulikoza's check for TR 1 so it won't break whatever else you're doing with dosbox
7	{
8	    if(FP.grFunction1i = (pfunc1i)fn_pt[_grConstantColorValue4-GLIDE_START])
9		FP.grFunction1i(0x7f000000);
10	}
11	else if(tomb == 2)	// ditto for TR UB
12	{
13	    param[5] = 0x42fe0000;
14	    param[6] = 0;	// thx gulikoza for array maintenance ;)
15	    if(FP.grFunction4f = (pfunc4f)fn_pt[_grConstantColorValue416-GLIDE_START])
16		FP.grFunction4f(F(param[5]), F(param[6]), F(param[6]), F(param[6]));
17	}
18	FP.grFunction4i = (pfunc4i)fn_pt[i];
19	FP.grFunction4i(param[1], param[2], param[3], param[4]); // grAlphaBlendFunction16() at last
20	break;

------------------

Now for the reason of this post :

I came to grips with guColorCombineFunction(), I guess gulikoza has some aching recollections of my frustration about it, I expected him to tell me to drop dead the next time I PM'd him., but could never make much of it, I broke the video output countless times over it, but GR_COLORCOMBINE_CCRGB, along with the GR_COLORCOMBINE_TEXTURE_TIMES_CCRGB choice was a no go.
In Glide refence manual (I browsed v. 2.2, 2.4 & 3) I found 14 valid choices as an argument to use with guColorCombineFunction( GrColorCombineFunction_t func ), I tried 14 of them, no avail, the two I just mentioned were the only ones that made for a shy, incorrect shadowing effect.

I now see I was probably missing a feature like your

LOG(0,"\nguColorCombineFunction(func=%s)",colorcombinefunc_t[func]);
...
switch(func) {
...
case GR_COLORCOMBINE_CCRGB: /* konstans */

Was that the case in your opinion ?

Hm.. silly me, three times silly. Of course it must have been. As I was slowly writing and reflecting with an eye or three on your lines, I now come to a perception of the stiffness of my approach to guColorCombineFunction, a hack is not Jack the Ripper meets Psycho meets the Texas chainsaw massacre weirdo. Well I came to at last. Thanks heaven the move to grAlphaBlendFunction local space finally made the trick for me anyway.
It seems I sort of made an uneducated guess as to where it (the constant color tweaking) was expected to settle down.

One last (I promise) issue anyway is lingering :
you wrote, I can't imagine that [there was] no shadow on a real Voodoo card. Paul added, there may have been bugs in early versions of Glide that TR1 then relied on. Something like the alpha unit having its own cache of the constant color value that doesn't get updated if the alpha unit is off.

Well, I said when I intercepted the 7f000000h value I thought I'd be so smart to OR it with the subsequent instances of the constant color value, which were always 24 bit ones.
grConstantColorValue(7f000000h | param[1]);
that's how it was.

Why did the shadow started to appear then, but only a bad one ? I tried ORing with a number of values for the left constant value side, from (0 | param[1]) (no shadow, fancy that) through the "standard" 7f000000h to (ff000000h | param[1]), never ever I saw a sane shadow showed up. No OR was good.
If "alpha" (most significant byte) is 7fh, a grey spot, if it's ffh (see screenshot : ORed with ff000000h.jpg) a... negative shadow, it's a white hole ! Put my name down for next year's Nobel Prize in Astrophysics for that !

The transparency is gone awry. I had many ideas on it, but yours matter not mine. Is this sorta proving the alpha cache monkey business Paul had imagined ? Or else what do you make of it (aside of making fun) ?
The shade is drawn as is and that's all there is to it ?

Thx a lot for your and anybody's attention and possible responses.

----------------------------------

We can forgive those who bother us, but we can never forgive those whom we bother (M. de la Rochefoucauld)