Can we use 512x512 textures again?
Moderator: thunderchero
- thunderchero
- Site Administrator aka Fleet Admiral
- Posts: 7849
- Joined: Fri Apr 25, 2008 2:00 am
- Location: On a three month training mission, in command of the USS Valiant.
Can we use 512x512 textures again?
Hi Everyone,
Even before the resent post in hades thread I was looking at all the hades files...
First, What are the hades files
hades 1.1 (DIRECT3D)
we are using the original Falcon 4.0 files below
mpr97.dll (replacement file but different from botf version)
mpr555.dll (replacement file but different from botf version)
mpr565.dll (replacement file but different from botf version)
mprd3d.mpr (new file to botf)
stbof.ini 3D setting uses DIRECT3D instead of SOFTWARE
hades 2.2 (3DFX)
we are using the original Falcon 4.0 (1.0.8 patch) files below
gen.mpr (replacement file but different from botf version)
mpr97.dll (replacement file but different from botf version)
mpr555.dll (replacement file but different from botf version)
mpr555m.dll (replacement file but different from botf version)
mpr555p.dll (replacement file but different from botf version)
mpr555pm.dll (replacement file but different from botf version)
mpr565.dll (replacement file but different from botf version)
mpr565m.dll (replacement file but different from botf version)
mpr565p.dll (replacement file but different from botf version)
mpr565pm.dll (replacement file but different from botf version)
mprd3d.mpr (new file to botf)
mprp2.mpr (new file to botf)
sh34w32.DLL (new file to botf)
gr3dfx.mpr (new file to botf)
stbof.ini 3D setting uses 3DFX instead of SOFTWARE
Both versions above require 256x256 gifs. Everyone would prefer to use 512x512 for better quality of textures for models
Tonight I tested each file in a vanilla CD install ("multi installer" using software has same files but 256x256 gifs)
Here was my results;
mpr97.dll 512x512 not effected both versions
mpr555.dll 512x512 not effected both versions
gen.mpr 512x512 not effected
mpr555m.dll 512x512 not effected
mpr555p.dll 512x512 not effected
mpr555pm.dll 512x512 not effected
mpr565m.dll 512x512 not effected
mpr565p.dll 512x512 not effected
mpr565pm.dll 512x512 not effected
mprp2.mpr 512x512 not effected
gr3dfx.mpr 512x512 not effected
sh34w32.DLL 512x512 not effected
mprd3d.mpr freezes game with 512x512 (Error:222 C:\mpr\ddk\eng\State.c Mar 3 1999)
mpr565.dll major 512x512 effect both versions (bad/mixed up texture)
I also looked at trek.exe in a Disassembler and found more 3D setting that are available for use.
SOFTWARE
SOFTWARE1
3DFX
P2
DIRECT3D
So my thought is a new Hades 3.0 using all files from 2.2 but exclude "mprd3d.mpr and mpr565.dll". This would allow 512x512 gifs again and any 3D settings above could be used.
But before anything is done there are still a few questions.
1. Can "mpr565.dll" from hades 2.2 be fixed/edited to allow 512x512 gifs?
2. What is the "mprd3d.mpr" file for? This file is used by DIRECT3D in mpr test and effects 3d battles (freezes).
3. If "mpr565.dll" can be edited would it allow use of "mprd3d.mpr"?
4. How will this work with other users since not every system has the same video drivers I do?
5. Can palette limit be raised to improve quality of textures even more?
thunderchero
Even before the resent post in hades thread I was looking at all the hades files...
First, What are the hades files
hades 1.1 (DIRECT3D)
we are using the original Falcon 4.0 files below
mpr97.dll (replacement file but different from botf version)
mpr555.dll (replacement file but different from botf version)
mpr565.dll (replacement file but different from botf version)
mprd3d.mpr (new file to botf)
stbof.ini 3D setting uses DIRECT3D instead of SOFTWARE
hades 2.2 (3DFX)
we are using the original Falcon 4.0 (1.0.8 patch) files below
gen.mpr (replacement file but different from botf version)
mpr97.dll (replacement file but different from botf version)
mpr555.dll (replacement file but different from botf version)
mpr555m.dll (replacement file but different from botf version)
mpr555p.dll (replacement file but different from botf version)
mpr555pm.dll (replacement file but different from botf version)
mpr565.dll (replacement file but different from botf version)
mpr565m.dll (replacement file but different from botf version)
mpr565p.dll (replacement file but different from botf version)
mpr565pm.dll (replacement file but different from botf version)
mprd3d.mpr (new file to botf)
mprp2.mpr (new file to botf)
sh34w32.DLL (new file to botf)
gr3dfx.mpr (new file to botf)
stbof.ini 3D setting uses 3DFX instead of SOFTWARE
Both versions above require 256x256 gifs. Everyone would prefer to use 512x512 for better quality of textures for models
Tonight I tested each file in a vanilla CD install ("multi installer" using software has same files but 256x256 gifs)
Here was my results;
mpr97.dll 512x512 not effected both versions
mpr555.dll 512x512 not effected both versions
gen.mpr 512x512 not effected
mpr555m.dll 512x512 not effected
mpr555p.dll 512x512 not effected
mpr555pm.dll 512x512 not effected
mpr565m.dll 512x512 not effected
mpr565p.dll 512x512 not effected
mpr565pm.dll 512x512 not effected
mprp2.mpr 512x512 not effected
gr3dfx.mpr 512x512 not effected
sh34w32.DLL 512x512 not effected
mprd3d.mpr freezes game with 512x512 (Error:222 C:\mpr\ddk\eng\State.c Mar 3 1999)
mpr565.dll major 512x512 effect both versions (bad/mixed up texture)
I also looked at trek.exe in a Disassembler and found more 3D setting that are available for use.
SOFTWARE
SOFTWARE1
3DFX
P2
DIRECT3D
So my thought is a new Hades 3.0 using all files from 2.2 but exclude "mprd3d.mpr and mpr565.dll". This would allow 512x512 gifs again and any 3D settings above could be used.
But before anything is done there are still a few questions.
1. Can "mpr565.dll" from hades 2.2 be fixed/edited to allow 512x512 gifs?
2. What is the "mprd3d.mpr" file for? This file is used by DIRECT3D in mpr test and effects 3d battles (freezes).
3. If "mpr565.dll" can be edited would it allow use of "mprd3d.mpr"?
4. How will this work with other users since not every system has the same video drivers I do?
5. Can palette limit be raised to improve quality of textures even more?
thunderchero
-
- Lieutenant-Junior Grade
- Posts: 50
- Joined: Fri May 29, 2009 2:00 am
- Location: Novi Sad, Vojvodina, Serbia, Europe
- Contact:
i do not think it will work just by dismissing some files. it will simply fall back to SOFTWARE [if it starts at all], and most of the times, hades 2.2 SOFTWARE support is troubled also.
there are many things we should know, before we start discussing this topic. i do not have too much time, but i will pour all my infos here, and i will try to follow and add to the discussion these days also.
vannila botf has just two render settings:
1. 15bit,
2. 16bit.
it also has few cpus support - for mmx, p pro or pII functions.
so it's a gdi/ddraw emulation [depending upon gpu]. thus, SOFTWARE/SOFTWARE1 has support for 512x512, it's a only a bit buggy with them [only a few crashes once a while], but is quite slow in combat with many ships [rendering algorithm is software based, thus unoptimized].
hades 1.1 adds only one single thing:
DIRECT3D - directx 3d api calls, mprd3d.mpr file. it updates other files, but to what extent, who knows.
this limits graphics to only 256x256 [since falcon was made so], but makes big battles work better [gpu handles rendering]. it also completely kills crashes, and DIRECT3D, imo, disregards bit setting completely. but compatibility is flacky, and while it works on some gpus, on others it doesn't.
hades 2.2 adds quite many new things:
new graphic support [glide api, legacy permediaII, directx 3d].
unfortunately, cpu support doesn't really count imo, since botf/mpr wasn't made to differentiate between cpus [or at least not efficiently]. so, only mpr565.dll gets used [if set at 16bit], but both mpr565m.dll and mpr565pm.dll should be faster/more compatible.
on the other hand gpu change is working properly, but there are a few issues: 256x256 is the limit & 3d support can be flacky on some cards. but it surely kills combat slowness, crashes and even gets rendering a bit better [subjective], if it works properly, ofc.
also, a few things regarding different 3D= settings here:
1. 3DFX support was created for 3dfx cards [voodoo, banshee - glide api]. i am quite sure it was made to support some of the special glide calls, and that this calls are more or less buggy in present 3d market environment. also, imo, it was made to fall back to DIRECT3D if it detects that user is not using a 3dfx compatible card [this will explain why thunderchero is getting errors from mprd3d.mpr while he's using 3DFX setting, and not from gr3dfx.mpr]. still, 3DFX is a true 3d function - not a ddraw/gdi software emulation, so rendering goes fast.
2. DIRECT3D setting is a generic directx 3d api support, most probably for directx6, maybe 7 [falcon used dx6, but i might be mistaken]. it is a true 3d, but quite old, thus some gpu will work better, other won't work, but when it works it works flawlessly.
3. P2 setting is used for legacy 3DLabs Permedia II graphic card - an opengl card. unfortunately, i know little about this support, but i imagine it is also limited to 256x256 [should be checked]. it might use opengl api instead of ddraw/gdi, and it might also be more stable for many of todays gpus, but with increased speed in combat and stability [some should test this, i am spending all my free time writing this down; i also use direct3d with no issues, so i have no real motive to seek for more time on this at the present time]. unfortunately, i am quite sure botf does some testing to detect if there is a p2 hardware, and if not, it falls back to SOFTWARE. this may explain why i see SOFTWARE-like behavior when i try P2.
so, imo, hades is not only better choice, it is the most advanced rendering type we can use. and we should use it, since vanilla botf render support is really awful [for present 3d market state at least]. i do advocate using 3d api instead of emulation, mostly for combat speed and stability across various cpu/gpu platforms [software is too slow on old hardware].
what combinations should be tested, imo:
1. 16/15 bit, pentium/ppro/mmx/pII support, direct3d/p2/glide [3dfx] - all possible combinations,
2. files should be renamed, instead of using .ini settings [this will ensure api calls are tested, not some exe bugs/fallbacks]: use software and gen.mpr/mpr565.dll,
3. files should be renamed especially when testing cpu combos [i am quite sure botf doesn't recognize cpus as it should; also, pII support should be the most advanced, but i suggest checking them all - so mpr56xxx.dll should be renamed to mpr565.dll on every test phase].
i have some best candidates:
1. hades 2.2, pII, direct3d, 16bit: mpr565pm.dll, mprd3d.mpr,
2. hades 2.2, pII, p2, 16bit: mpr565pm.dll, mprp2.mpr [useful if it uses opengl],
3. hades 2.2, ppro, direct3d, 16bit: mpr565p.dll, mprd3d.mpr,
4. hades 2.2, mmx, direct3d, 16bit: mpr565m.dll, mprd3d.mpr,
and also:
5. hades 2.2, ppro, p2, 16bit: mpr565p.dll, mprp2.mpr,
6. hades 2.2, mmx, p2, 16bit: mpr565m.dll, mprp2.mpr.
u can also try 512x512 on these combos [especially p2], but i doubt it will work. it's a worth of try anyway.
so, before we go any further, we at least own ourselves to test these things as deeply as possible. just dismissing everything and falling back to simple pentium/software combo does little benefit to anyone, since it only makes us go back to vanilla botf hardware support, and we know how slow that can be [or emulate it with new files, which works even worse than vanilla].
there are many things we should know, before we start discussing this topic. i do not have too much time, but i will pour all my infos here, and i will try to follow and add to the discussion these days also.
vannila botf has just two render settings:
1. 15bit,
2. 16bit.
it also has few cpus support - for mmx, p pro or pII functions.
so it's a gdi/ddraw emulation [depending upon gpu]. thus, SOFTWARE/SOFTWARE1 has support for 512x512, it's a only a bit buggy with them [only a few crashes once a while], but is quite slow in combat with many ships [rendering algorithm is software based, thus unoptimized].
hades 1.1 adds only one single thing:
DIRECT3D - directx 3d api calls, mprd3d.mpr file. it updates other files, but to what extent, who knows.
this limits graphics to only 256x256 [since falcon was made so], but makes big battles work better [gpu handles rendering]. it also completely kills crashes, and DIRECT3D, imo, disregards bit setting completely. but compatibility is flacky, and while it works on some gpus, on others it doesn't.
hades 2.2 adds quite many new things:
new graphic support [glide api, legacy permediaII, directx 3d].
unfortunately, cpu support doesn't really count imo, since botf/mpr wasn't made to differentiate between cpus [or at least not efficiently]. so, only mpr565.dll gets used [if set at 16bit], but both mpr565m.dll and mpr565pm.dll should be faster/more compatible.
on the other hand gpu change is working properly, but there are a few issues: 256x256 is the limit & 3d support can be flacky on some cards. but it surely kills combat slowness, crashes and even gets rendering a bit better [subjective], if it works properly, ofc.
also, a few things regarding different 3D= settings here:
1. 3DFX support was created for 3dfx cards [voodoo, banshee - glide api]. i am quite sure it was made to support some of the special glide calls, and that this calls are more or less buggy in present 3d market environment. also, imo, it was made to fall back to DIRECT3D if it detects that user is not using a 3dfx compatible card [this will explain why thunderchero is getting errors from mprd3d.mpr while he's using 3DFX setting, and not from gr3dfx.mpr]. still, 3DFX is a true 3d function - not a ddraw/gdi software emulation, so rendering goes fast.
2. DIRECT3D setting is a generic directx 3d api support, most probably for directx6, maybe 7 [falcon used dx6, but i might be mistaken]. it is a true 3d, but quite old, thus some gpu will work better, other won't work, but when it works it works flawlessly.
3. P2 setting is used for legacy 3DLabs Permedia II graphic card - an opengl card. unfortunately, i know little about this support, but i imagine it is also limited to 256x256 [should be checked]. it might use opengl api instead of ddraw/gdi, and it might also be more stable for many of todays gpus, but with increased speed in combat and stability [some should test this, i am spending all my free time writing this down; i also use direct3d with no issues, so i have no real motive to seek for more time on this at the present time]. unfortunately, i am quite sure botf does some testing to detect if there is a p2 hardware, and if not, it falls back to SOFTWARE. this may explain why i see SOFTWARE-like behavior when i try P2.
so, imo, hades is not only better choice, it is the most advanced rendering type we can use. and we should use it, since vanilla botf render support is really awful [for present 3d market state at least]. i do advocate using 3d api instead of emulation, mostly for combat speed and stability across various cpu/gpu platforms [software is too slow on old hardware].
what combinations should be tested, imo:
1. 16/15 bit, pentium/ppro/mmx/pII support, direct3d/p2/glide [3dfx] - all possible combinations,
2. files should be renamed, instead of using .ini settings [this will ensure api calls are tested, not some exe bugs/fallbacks]: use software and gen.mpr/mpr565.dll,
3. files should be renamed especially when testing cpu combos [i am quite sure botf doesn't recognize cpus as it should; also, pII support should be the most advanced, but i suggest checking them all - so mpr56xxx.dll should be renamed to mpr565.dll on every test phase].
i have some best candidates:
1. hades 2.2, pII, direct3d, 16bit: mpr565pm.dll, mprd3d.mpr,
2. hades 2.2, pII, p2, 16bit: mpr565pm.dll, mprp2.mpr [useful if it uses opengl],
3. hades 2.2, ppro, direct3d, 16bit: mpr565p.dll, mprd3d.mpr,
4. hades 2.2, mmx, direct3d, 16bit: mpr565m.dll, mprd3d.mpr,
and also:
5. hades 2.2, ppro, p2, 16bit: mpr565p.dll, mprp2.mpr,
6. hades 2.2, mmx, p2, 16bit: mpr565m.dll, mprp2.mpr.
u can also try 512x512 on these combos [especially p2], but i doubt it will work. it's a worth of try anyway.
so, before we go any further, we at least own ourselves to test these things as deeply as possible. just dismissing everything and falling back to simple pentium/software combo does little benefit to anyone, since it only makes us go back to vanilla botf hardware support, and we know how slow that can be [or emulate it with new files, which works even worse than vanilla].
Last edited by goodone on Tue Sep 14, 2010 9:16 am, edited 1 time in total.
-
- Lieutenant-Junior Grade
- Posts: 50
- Joined: Fri May 29, 2009 2:00 am
- Location: Novi Sad, Vojvodina, Serbia, Europe
- Contact:
as for the questions:
1. i doubt it is possible: it may just require too many code changes,
2. mpr files [includes mprd3d.mpr] are for graphics api calls; mprd3d.mpr is for DIRECT3D, gen.mpr is for SOFTWARE, gr3dfx.mpr is for 3DFX [glide] and mprp2.mpr is for P2 [permedia II, possibly opengl],
3. imo, 512x512 support was simply not coded in falcon 1.0.8 file versions [probably because those gpu didn't have enough vram to support such big, errr, 'textures'],
4. the entire mpr api would have to be recoded to make it compatible with today's standards,
5. unfortunately, i am quite sure pallete limit was also hardcoded in mpr api, per se.
the one thing we can do is find the best possible combination, since botf doesn't do it right. if i find some free time, i might put myself into such project.
1. i doubt it is possible: it may just require too many code changes,
2. mpr files [includes mprd3d.mpr] are for graphics api calls; mprd3d.mpr is for DIRECT3D, gen.mpr is for SOFTWARE, gr3dfx.mpr is for 3DFX [glide] and mprp2.mpr is for P2 [permedia II, possibly opengl],
3. imo, 512x512 support was simply not coded in falcon 1.0.8 file versions [probably because those gpu didn't have enough vram to support such big, errr, 'textures'],
4. the entire mpr api would have to be recoded to make it compatible with today's standards,
5. unfortunately, i am quite sure pallete limit was also hardcoded in mpr api, per se.
the one thing we can do is find the best possible combination, since botf doesn't do it right. if i find some free time, i might put myself into such project.
- Flocke
- BORG Trouble Maker
- Posts: 3196
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
great post
I can confirm that on my system setting 3DFX in stbof.ini, BotF opens the device in DIRECT3D mode. Using P2 it sadly just falls back to SOFTWARE mode.
Havn't tested the m (for mmx optimisation) and p (for p2 optimization) versions of mpr565, they really might help some little in terms of speed cause every common cpu by now has mmx support and I think also p2 support.
I can confirm that on my system setting 3DFX in stbof.ini, BotF opens the device in DIRECT3D mode. Using P2 it sadly just falls back to SOFTWARE mode.
Havn't tested the m (for mmx optimisation) and p (for p2 optimization) versions of mpr565, they really might help some little in terms of speed cause every common cpu by now has mmx support and I think also p2 support.
-
- Lieutenant-Junior Grade
- Posts: 50
- Joined: Fri May 29, 2009 2:00 am
- Location: Novi Sad, Vojvodina, Serbia, Europe
- Contact:
ok, i was able to find some time to retest my suggestions.
my botf hades config is:
1. version 2.2,
2. 3d=direct3d,
3. pentium II cpu support [by overwriting mpr565.dll with mpr565pm.dll].
it works without flaws, for now. my config is:
Radeon 3450,
Phenom II 550.
i will be playing some mps in next few weeks, so i'll be able to test if cpu optimizations are working as intended [didn't used it before]. my basic assumption was that between available choices [pentium, pentium mmx, pentium pro, pentium II] pentium II should have the most advanced cpu calls support, but pentium mmx may be worth trying too. if anybody has anything to add to this assumption, please do so.
3d=3dfx falls back to direct3d, so that's been tested now, finally too. p2 falls back to software, also.
i never bothered too much before, since my hades 2.2 config was working flawlessly [i just didn't use cpu patch], but when u started this thread, u gave me the idea.
considering that 3d settings affects mainly combat, i expect no changes there. but, i do hope cpu patch will show some benefits on the map view, possibly fixing slow map scrolling response on big, crowded maps in developed games. if so, my time spent here will be well worth the bother.
as for 512x512, they simply don't work with falcon files [they were meant to be 256x256 afterall]. well, at least it's direct3d.
so, it may be a good idea, if cpu patch shows stability, to include a prompt in new hades install about which cpu version it should use [overwriting for user automatically].
as for the idea to go back to vanilla software, for the sake of 512x512, i think it's a bad choice. it wasn't so stable even then [not to mention slow in a large combat]. hades was introduced with concrete reasons, afterall.
my botf hades config is:
1. version 2.2,
2. 3d=direct3d,
3. pentium II cpu support [by overwriting mpr565.dll with mpr565pm.dll].
it works without flaws, for now. my config is:
Radeon 3450,
Phenom II 550.
i will be playing some mps in next few weeks, so i'll be able to test if cpu optimizations are working as intended [didn't used it before]. my basic assumption was that between available choices [pentium, pentium mmx, pentium pro, pentium II] pentium II should have the most advanced cpu calls support, but pentium mmx may be worth trying too. if anybody has anything to add to this assumption, please do so.
3d=3dfx falls back to direct3d, so that's been tested now, finally too. p2 falls back to software, also.
i never bothered too much before, since my hades 2.2 config was working flawlessly [i just didn't use cpu patch], but when u started this thread, u gave me the idea.
considering that 3d settings affects mainly combat, i expect no changes there. but, i do hope cpu patch will show some benefits on the map view, possibly fixing slow map scrolling response on big, crowded maps in developed games. if so, my time spent here will be well worth the bother.
as for 512x512, they simply don't work with falcon files [they were meant to be 256x256 afterall]. well, at least it's direct3d.
so, it may be a good idea, if cpu patch shows stability, to include a prompt in new hades install about which cpu version it should use [overwriting for user automatically].
as for the idea to go back to vanilla software, for the sake of 512x512, i think it's a bad choice. it wasn't so stable even then [not to mention slow in a large combat]. hades was introduced with concrete reasons, afterall.
Last edited by goodone on Tue Sep 14, 2010 3:44 pm, edited 1 time in total.
- thunderchero
- Site Administrator aka Fleet Admiral
- Posts: 7849
- Joined: Fri Apr 25, 2008 2:00 am
- Location: On a three month training mission, in command of the USS Valiant.
Hi goodone,
thanks for all your testing and I will be interested to hear more results
You misunderstand me I do not want to go back to vanilla software. I would like to see 512x512 gifs (or larger) used with direct3d and 3dfx settings.
After some more testing today I understand with current files this is not possible without editing them. I am also looking into other files from microprose games to see what might be compatible with BOTF.
thunderchero
thanks for all your testing and I will be interested to hear more results
goodone wrote:as for the idea to go back to vanilla software, for the sake of 512x512, i think it's a bad choice. it wasn't so stable even then [not to mention slow in a large combat]. hades was introduced with concrete reasons, afterall.
You misunderstand me I do not want to go back to vanilla software. I would like to see 512x512 gifs (or larger) used with direct3d and 3dfx settings.
After some more testing today I understand with current files this is not possible without editing them. I am also looking into other files from microprose games to see what might be compatible with BOTF.
thunderchero
-
- Lieutenant-Junior Grade
- Posts: 50
- Joined: Fri May 29, 2009 2:00 am
- Location: Novi Sad, Vojvodina, Serbia, Europe
- Contact:
it may be that there were no other games released with this kind of mpr engine. microprose was taken by hasbro in 1998 and again by infogrames in 2001, so these games were among the last ones.thunderchero wrote:I am also looking into other files from microprose games to see what might be compatible with BOTF.
afaik, there was no game development after hasbro takeover, and even a few games already scheduled [as botf] were in a troubled state [may explain the bugs, lol].
anyway, as for new hades version, i suggest two things:
1. stop using 3d=3dfx, as it might be a source of some issues [we do not know how well fallback works exactly], and replace it with 3d=direct3d,
2. add cpu patch option for installer [assuming someone doesn't report bugs with in upcoming weeks; i will report back when i get my testing done].
after a few hours of playing, i can say only this: why didn't i thought of cpu patch before?!?!
- Prometheus
- Cadet 4th Year
- Posts: 17
- Joined: Fri May 02, 2008 2:00 am
Yes, I must agree with Goodone, after playing with cpu p2 patch, for a few days now, I must admit the game does look like its working better, more fluent I don't know exactly what it is, it just gives a feeling of better working... Maybe on slower PCs this will be shown even more notably, but also on my faster comp, I got a feeling that game runs more smoothly.goodone wrote:after a few hours of playing, i can say only this: why didn't i thought of cpu patch before?!?!
Ofc, more testing will be done in the near future.
Noo Ani Anquietas Hic Qua Videum - We are the Ancients, this is the place of our legacy.