wrote:I'm thinking there are only 2 (TWO!) probs left.......Sunglare & bleeding hurting FPS, and black squares around the wings & tail surfaces!!
😁:D:D
Aparently you count sunglare/bleeding as one.
S! All,
tried the various antiliasing settings on my GeForce3. Best results were the NONE but even with NONE I would get some black wing surfaces but not as much as before.
Agree that time of day may play a part I have been testing only in campaign mode so no constant times for evaulations.
Also for what it is worth I reinstalled+updated for other reasons my Santa Cruz drivers that changed the fps by +10 to 15 😀
Going tonight reinstall the M$ FF2 stick I have been using notice that this maybe issue too.
Will report anything of value later regarding these things.
Have Fun!
Thor
Sorry, can't do any more work on the wrapper, I'm too busy playing the game. 😀
Did nobody warn ya? It's infectious. 😀 😀 😀
Ah, another satisfied (corrupted!) customer!
😁
😁
😁
wrote:Aparently you count sunglare/bleeding as one.
They act the same, and the result is the same. The only difference is that the bleeding fades in and out.
😀
I've fixed a few more problems. Check out the Glidos web site.
THANK YOU THANK YOU THANK YOU!!!!!!!!!!!!!
This is amazing... I mean REALLY amazing! Just took RB for a spin with the new wrapper files and it is looking quite fantastic... I do believe it looks a bit better than what I get on my dedicated RB PC with a VooDoo 5500.
The $10.00 registration fee is the best investment I've yet made in RB3D!
wrote:I've fixed a few more problems. Check out the Glidos web site.
Your timing couldn't have been more perfect........I'm soon to release ROTJ II, which has extra, never before seen, aircraft slots.
The possibilities are 256 *EXTRA* aircraft!
😁
I already have 3 slots "rock solid" stable, and working on a 4th.
RB's longevity has just went through the roof.
😁
S! All,
sys = P4 1.3, Geforce3 DDR, 768 ram, Santa Cruz using a 17" E770s monitor
Got the updated drivers for the GeForce3 30.82 and Santa Cruz running and the updated Glidos files (BTW outstanding sir) 😎
No more grey popups for cockpit and mostly all the black squaring or trims gone, but they are still intermittent.
I took out sunglare and am running WinMe on vid card at High Color 16 bit, Resolutions for both are 800x600. Only consistent prob is the radial engines of the E3 and the occasional squares of black on some aircraft - really depends on season and time of day in campaign mode.
Using Western Front Patch and only other mod is some of the Weasel sounds in simpatch of WFP. Will try some other SWWiSA patches like Italian front just as experiment.
I am very grateful to all of the Vogons and especially to you sir Glidos best ten bucks I ever spent on this game.😀
Hope now we can get the last pieces of the puzzle complete and let me know if ya need another contribution. I may not have much but you are so close I want to keep you involved here sir.
😁
Thor
Noticed that the version number didn't get updated on the RB page. The page lists it as 0.06b10, but the current version is 0.06b11 Just thought i'd mention that so no one gets confused.
THANKS for all the great work on this for us, i'm really looking forward to my new computer/graphics card someday. I've been seeing a few postings of new people looking to pick up RB3D since word on this wrapper has started getting out. Saw the original up to $40.00 on ebay!
I'm glad you found Baron.exe also! 😁
So the installer on that aftermarket version was messed up? Glad you knew what you were doing! Where did that one come from?
wrote:S! All,
Using Western Front Patch and only other mod is some of the Weasel sounds in simpatch of WFP. Will try some other SWWiSA patches like Italian front just as experiment.
😁
http://benchmarksims.com/ROTJ/index.htm
😁:D:D
The new version of the wrapper is AWESOME! I've been flying all evening with a big grin on my face. Fantastic work, Paul!
I still have a few trasparency related issues, the easiest to reproduce being the dark grey polygon around the guns in the F2 view. Paul, if you haven't already, you may want to check out Baron von Helton's ROTJ patch and fly the Dr.I in "Fly Now". The gun trasparency problem shows up there for me.
BvH, great work on activating the new slots! I'm eagerly awaiting ROTJ II.
Now, all we need is the Promised Land patch...
S! Gentlemen, on a job well-done. Oh, BTW, the exasperated sigh you hear in the background is my wife waiting for her turn on the computer. "Are you STILL playing Red Baron???" 😁
🤣!
GliDos Logo:
"The DOS Glide emulator to exasperate flight simmer Wives everywhere!"
You meant slogan, right? (He meant slogan. Really.)
Yes, it’s my fault.
Aaaaaargh! Always these pop-ups. 😉
Hmmm, I think I can change the Glidos spinning logo to read "exasperated wives".
About my broken copy of RB: I got it from sold out. They usually know what they are doing so I'd like to think it was just a one-off bad CD. Certainly it would be nice to be able tell people they need only pay £5, not $40 for RB. Oh, and the CD was just about readable under W98 (before it crashed my computer), so the info was on the CD (more evidence that it was just a dodgey CD).
The transparencies. I'm getting somewhere with that. Lots of problems are due to RB making frequent use of palette changes. The sunglare and bleeding is done by changing the palette (and the fog colour). That's awkward for OpenGL, and requires all the OpenGL-side textures to be regenerated. So what I've done for now is ignore palette changes so textures stick with the first palette they are assigned. That has fixed the speed hit for bleeding.
The transparency problem is also connected with palette changes. It seems that some of the plane textures contain areas that require different palettes (or maybe it is just that there are textures that have some areas where black means transparent, and other areas where black means black). Either way, in effect, a single texture gets used with different palettes. I can handle that, but only with the palette change code turned on, in which case we get the slow down when bleeding.
There are long-term ways to fix this I think, but they are a bit complicated, and might take a while. I wonder though, whether the problems might be fixed by altering the models.
Thanks for pointing out the version error on the web site.
wrote:................................................................................................ The transparencies. I'm gettin […]
................................................................................................
The transparencies. I'm getting somewhere with that. Lots of problems are due to RB making frequent use of palette changes. The sunglare and bleeding is done by changing the palette (and the fog colour). That's awkward for OpenGL, and requires all the OpenGL-side textures to be regenerated. So what I've done for now is ignore palette changes so textures stick with the first palette they are assigned. That has fixed the speed hit for bleeding.The transparency problem is also connected with palette changes. It seems that some of the plane textures contain areas that require different palettes (or maybe it is just that there are textures that have some areas where black means transparent, and other areas where black means black). Either way, in effect, a single texture gets used with different palettes. I can handle that, but only with the palette change code turned on, in which case we get the slow down when bleeding.
There are long-term ways to fix this I think, but they are a bit complicated, and might take a while. I wonder though, whether the problems might be fixed by altering the models.
...................................................................................
Hmmmmmmmmmmmmmm!
I just made some experiments! Most modders set the fuselage texture to smooth (but not transparent) in the dml-file. (material list). In some cases I could solve my transparency problem by setting the fuse texture to transparent as well, i.e., applying the same settings as the wings, elevator and rudder have.
Another observation, which might be related to your findings. Use of terrain patches, which use special palettes and not the stock glide palettes ends up in lower framerates and more graphics corruption. Less probs with stock palette custom patches sofar.
I will pass the transparency prob on to our modders; I'm just a painter. 😉
Glidos:
You are probably partially aware of this , but here goes 😀
RBII/3D's texture palettes are controlled in shading , sunglare , season color , ect .. by .spl files , which start , in the beginning of the files looking like standard .pal , and have about 180kb of subsequent programing to shift color particular index numbers.
In fact , you can edit a .pal on a .bmp , and it will still display the same in the game , because the .spl overrides based on the index# ... index # 0 is always the transparency , regardless of the color used.
The primary .spl files are in the Data directory , 5 '0000000#.spl" and control all the in game objects .. these controll all the in-game textures for DirectDraw.
Where it get's trickier , is the .spl files for the Glide textures for terrains , sky/clouds and effects , that are accessed from the 3 .vol files in the '3dpatch' folder
I do however , have stock extracted copies of ALL RBII/3D .pal and .spl files
If it will help to have them , please e-mail me at fineline@uia.net
While I'm not 100% sure of what each does completely , or which set of texture class each controls , I've got a pretty good idea and other info that may be of help.
About 1/2 way down this page is a basic definition of RBII/3D's primary in-game palette used on object/planes
Firstly: I've just uploaded a new version that deals with most of the transparency problems, I believe. Its still a hack but not such a bad one.
Thanks for all this info. All new to me and interesting. Moreover it leads me ot believe that careful control of the palettes may give a final solution. What might work is to edit these files that contain large number of palettes, and quantise them: make them stay the same in large sections and jump value only every so often, so that where you have at the moment
0123456789
you change to
0003336669
If you can get it down to say 16 palettes in total that might be workable. Then you can take the current version of the wrapper I've just uploaded and turn off the "IgnorePaletteChange" feature.
No that's wrong: I mean no texture gets used with more than 16 different palettes. The total number doesn't matter.
Having said this, I may eventually be able to fix the whole problem within the wrapper using an OpenGL extension, but that requires some research.
