List of Hades Compatible and non Compatible video cards

This forum is for outdated or irrelevant Modding Information that may or may not be 3 months old.

Moderator: thunderchero

KrazeeXXL
BORG Trouble Maker
BORG Trouble Maker
Posts: 2267
Joined: Sat Jan 03, 2009 3:00 am
Location: the 36th Chamber

Post by KrazeeXXL » Thu Sep 23, 2010 11:56 am

I read this post some time ago and never even thought about to consider it tbh ;)

kill explorer.exe sounded dunno... strange :lol:

in our last mp captaindusk played with hades 2.2 and I tried 1.1. (DIRECT3D)

Both of us use an HD3850 AGP.
For cd the game worked fine but for me it crashed in the second (a big) battle I had.

lol I think I kill the explorer next time just to find out if this really is the problem. I have to see it to believe it! :lol:

goodone
Lieutenant-Junior Grade
Lieutenant-Junior Grade
Posts: 50
Joined: Fri May 29, 2009 2:00 am
Location: Novi Sad, Vojvodina, Serbia, Europe
Contact:

Post by goodone » Sat Sep 25, 2010 5:58 am

must be the one of win7 'features'. :)
iNqUIrY: whO ArE yOU?! Image
Image a cYbErnEtIc LifEfOrm,
LingErIng On hUmAnItY. Image

User avatar
Nucky9
Ensign
Ensign
Posts: 20
Joined: Tue Sep 15, 2009 2:00 am

Post by Nucky9 » Sun Sep 26, 2010 1:11 pm

goodone wrote:i am quite sure udm3 is not compatible with hades. i haven't checked it's textures to be sure, but just by examining other ppl posts and general info about the mod, i guess it simply wasn't made with respect to 256x256 hades limit. bop has the same issue - there are a few textures that require scaling back to 256x256, but nothing that can't be quickly done.
I couldn't find any 512x512 .gifs in UDMIII, although some _c textures are 256x256 (you mention earlier that they should be 128x128, but this doesn't seem as important as the 512x512 limit you talk about).

That said, I know it occasionally crashes in the ship research screen. Would the hades version or settings (software etc.) make any difference there, or do you believe it has to be a texture problem?

Thanks,

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6389
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Sun Sep 26, 2010 1:23 pm

Nucky9 wrote:
goodone wrote:i am quite sure udm3 is not compatible with hades. i haven't checked it's textures to be sure, but just by examining other ppl posts and general info about the mod, i guess it simply wasn't made with respect to 256x256 hades limit. bop has the same issue - there are a few textures that require scaling back to 256x256, but nothing that can't be quickly done.
I couldn't find any 512x512 .gifs in UDMIII, although some _c textures are 256x256 (you mention earlier that they should be 128x128, but this doesn't seem as important as the 512x512 limit you talk about).

That said, I know it occasionally crashes in the ship research screen. Would the hades version or settings (software etc.) make any difference there, or do you believe it has to be a texture problem?

Thanks,
this only applies to vanilla models and he suggested that all (a,b,c gifs) be 256 any way as joker recommended, maybe on different post?

it would also help to keep track of what models crash in research screen and report that info on UDM post with (model that it crashed on, your video card info, what version of hades used, and your 3D setting)

thunderchero

User avatar
Nucky9
Ensign
Ensign
Posts: 20
Joined: Tue Sep 15, 2009 2:00 am

Post by Nucky9 » Sun Sep 26, 2010 1:31 pm

thunderchero wrote:this only applies to vanilla models and he suggested that all (a,b,c gifs) be 256 any way as joker recommended, maybe on different post?
thunderchero
Ok, makes sense. Could the few 128x128 textures be a problem then, or is the 256x256 limit the only consideration?

As for noting the crashes - the usually occur (very sporadically) in MP games, so I haven't really been able to make notes. Plus I thought the problem was a general one, not specific to any models. Now that I know there might be a problem with a specific model, I'll be more diligent.

I have another question actually - which files make up the Hades patch? Is there an easy way to switch between 1.1 and 2.2 manually?

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6389
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Sun Sep 26, 2010 3:13 pm

Nucky9 wrote:Ok, makes sense. Could the few 128x128 textures be a problem then, or is the 256x256 limit the only consideration?
the 128x128 gif that are in UDM are unused. :wink:
Nucky9 wrote:As for noting the crashes - the usually occur (very sporadically) in MP games, so I haven't really been able to make notes. Plus I thought the problem was a general one, not specific to any models. Now that I know there might be a problem with a specific model, I'll be more diligent.


I do not know of any models that are causing problem, but will look into any report of problem.
Nucky9 wrote:I have another question actually - which files make up the Hades patch? Is there an easy way to switch between 1.1 and 2.2 manually?


yes and at this point it may help you, but as you said would have to be done manully.

first download hades stand alone from here.

viewtopic.php?name=Downloads&d_op=viewd ... ls&lid=154

use winrar or winzip to extract files

for hades 2.2 files

create new folder and place hades 2.2 exe inside

extract files with winrar or winzip to that folder (do not run installer).

now you have the raw files from hades 2.2 + installer in that folder.

for manual install you only need only a few files.

place the following files in the install path you want to update.

gen.mpr
gr3dfx.mpr
mprd3d.mpr
mprp2.mpr
sh34w32.dll
mpr97.dll
mpr555.dll
mpr555m.dll
mpr555p.dll
mpr555pm.dll
mpr565.dll
mpr565m.dll
mpr565p.dll
mpr565pm.dll (this file could be copied to a new folder and renamed to mpr565.dll as goodone suggests then copy to install path and overwrite file.)

then open the stbof.ini and set 3D= to "DIRECT3D" but run mpr.exe from install you just added these files if you computer list "Direct3d" devices (like it list above in software area) then and only then it should be set to "DIRECT3D"

or

"3DFX" could be used but run mpr.exe from install you just added these files if you computer list "Glide" devices (like it list above in software area) then and only then it should be set to "3DFX".

or

"P2" could be used but run mpr.exe from install you just added these files if you computer list "permedia 2" devices (like it list above in software area) then and only then it should be set to "P2".

hades 1.1 can be done same as above, But they are only outdated files and all file in 2.2 replaces them. also hades 1.1 only supports direct3d.

NOTE; this would need to be done to each install path (mod or vanilla) you want to update.

hope this helps

thunderchero
Last edited by thunderchero on Thu Nov 11, 2010 11:49 pm, edited 3 times in total.

User avatar
Nucky9
Ensign
Ensign
Posts: 20
Joined: Tue Sep 15, 2009 2:00 am

Post by Nucky9 » Mon Sep 27, 2010 7:25 pm

Thanks, that is very helpful thunderchero!

goodone
Lieutenant-Junior Grade
Lieutenant-Junior Grade
Posts: 50
Joined: Fri May 29, 2009 2:00 am
Location: Novi Sad, Vojvodina, Serbia, Europe
Contact:

Post by goodone » Fri Oct 01, 2010 3:12 pm

Nucky9 wrote:Could the few 128x128 textures be a problem then, or is the 256x256 limit the only consideration?
as far as i know, microprose graphics interface [also known as mpr, or better mpr.dll], has few model renderings states.

the old, original, mpr [version 4.0], used in vanilla, was made to handle three - 512x512, 256x256 and 128x128 - textures. it worked through software rendering using ddraw or gdi, whichever is available, and is rather slow, since it calculates 3d in cpu. this fault shows in large combats.

this wasn't sufficient in later mpr versions, one used in vanilla falcon 4.0 and its later patches, as it was required to draw many more objects on the screen. basicaly, the idea was to transfer the entire rendering on to 3d hardware. in first, it was done through directx, but both 3dfx and 3dlabs proved they can deploy legacy 3d functions, still unsupported or incompatible with current microsoft's directx, so the latest mrp i have ever seen [introduced in hades 2.x patch, coming from falcon 4.0 patch] had included some legacy support for that hardware. that's why we have more than a single 3d= value.

unfortunately, transferring things to directx or 3d hardware had it's limitations. video memory for one, but also speed. that's why 512x512, i suppose, was dropped, since it didn't change much, at least not for falcon 4.0. so, hades has a limit of 256x256 for textures.

now, why different resolutions? it has to do with video memory and speed again. 128x128 was used when the scene is far a way, showing many different objects. 512x512 would be used in close-ups. and u get the picture for 256x256.

now, the research screen uses only a single one of them. it's logical to suppose [i do not have time to test it now, but i am quite sure i'm right] it was made to display the 128x128 texture, or the _c version. since udm doesn't use 128x128, and ppl are reporting research screen crashes in udm, regardless that all of the udm textures do not break the 256x256 limit, i think u have just found ur problem.

in all my mods i tried to respect 128x128, 256x256 & 512x512 texture state:
1. 128x128 for _c files,
2. 256x256 for _b files,
3. 512x512 [in case of vanilla], or 256x256 [in case of hades] for _a files.

that may explain why i see much less crashes than average udm/mod user.

also, this applies to hades, texture/.hob modders & similar. i am sure it's better to respect that limit [ships may look too big to fit to the research screen if u do not follow it - a way of testing - if they show without a crash, that is].

imo, particularly, it's a mistake to create just one texture resolution and use it for all texture file versions, especially misusing .hob files to point just onto one resolution file, which is a common practice for modders, unfortunately.

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6389
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Fri Oct 01, 2010 4:25 pm

goodone wrote:now, the research screen uses only a single one of them. it's logical to suppose [i do not have time to test it now, but i am quite sure i'm right] it was made to display the 128x128 texture, or the _c version. since udm doesn't use 128x128, and ppl are reporting research screen crashes in udm, regardless that all of the udm textures do not break the 256x256 limit, i think u have just found ur problem.
Incorrect research screen uses 256x256 gif (tested)
goodone wrote:in all my mods i tried to respect 128x128, 256x256 & 512x512 texture state:
1. 128x128 for _c files,
2. 256x256 for _b files,
3. 512x512 [in case of vanilla], or 256x256 [in case of hades] for _a files.
I am unclear what files you refer too here? _c files, _b files _a files

If you are talking only about gif files on vanilla models you are correct. But any new model that is a completely different subject :wink:

I am guessing you are talking about the hob files?

if so you are incorrect all three gif sizes/views use the ***_a.hob.

if so have a look at this post

viewtopic.php?name=Forums&file=viewtopic&t=1546
goodone wrote:that may explain why i see much less crashes than average udm/mod user.
You have stated you only play BOP and vanilla, BOP only has 3 new models, while UDM has 105 new models.

I personally have played well over 300 turns in single player with UDM without any crashes. I will admit battles are much slower due to the higher poly count models when the battle has more than 20 ships.

But most crashes are due to use of wrong settings or wrong video driver by the user. and not the fault of the mod.

thunderchero

goodone
Lieutenant-Junior Grade
Lieutenant-Junior Grade
Posts: 50
Joined: Fri May 29, 2009 2:00 am
Location: Novi Sad, Vojvodina, Serbia, Europe
Contact:

Post by goodone » Fri Oct 01, 2010 5:31 pm

thunderchero wrote:
goodone wrote:now, the research screen uses only a single one of them. it's logical to suppose [i do not have time to test it now, but i am quite sure i'm right] it was made to display the 128x128 texture, or the _c version. since udm doesn't use 128x128, and ppl are reporting research screen crashes in udm, regardless that all of the udm textures do not break the 256x256 limit, i think u have just found ur problem.
Incorrect research screen uses 256x256 gif (tested)
u mean _b? anyway, that's important, whichever the case is.
thunderchero wrote:
goodone wrote:in all my mods i tried to respect 128x128, 256x256 & 512x512 texture state:
1. 128x128 for _c files,
2. 256x256 for _b files,
3. 512x512 [in case of vanilla], or 256x256 [in case of hades] for _a files.
I am unclear what files you refer too here? _c files, _b files _a files

If you are talking only about gif files on vanilla models you are correct. But any new model that is a completely different subject :wink:
i am talking about gifs. i was talking about gifs the entire time. hobs got mentioned only at the end of that post.

also, new models don't rly change much in this respect. if i need 256x256 & 128x128, i rescale them.
thunderchero wrote:
goodone wrote:that may explain why i see much less crashes than average udm/mod user.
You have stated you only play BOP and vanilla, BOP only has 3 new models, while UDM has 105 new models.
i play bop on hades. i also rescale all bop's new textures [models] to get all of them according to the upper rule. since hades respects 256x256 and 128x128 rule, and doesn't mess with .hob files, i guess it works better than the average installation.

i only miss adequte _c.hob and _b.hob for new models for bop, but they don't matter much anyways, so i don't care too much. but it would be nice to have adequate .hobs for very small ship and damage.

i also consider that making _b.hob and _c.hob the same as _a.hob only calls for trouble.

User avatar
thunderchero
Site Administrator aka Fleet Admiral
Site  Administrator aka Fleet Admiral
Posts: 6389
Joined: Fri Apr 25, 2008 2:00 am
Location: On a three month training mission, in command of the USS Valiant.
Contact:

Post by thunderchero » Fri Oct 01, 2010 6:35 pm

goodone wrote: u mean _b? anyway, that's important, whichever the case is.
***_b.gif for vanilla correct

For new models All gif('s) for the model are 256x256 (if more than 1 is used than they are different)

You would need to understand new ship models since they are not the same as vanilla models.

As to the rest of your statements, since you are reluctant to try new things and know nothing about new ship models this discussion is at it's end.

thunderchero

goodone
Lieutenant-Junior Grade
Lieutenant-Junior Grade
Posts: 50
Joined: Fri May 29, 2009 2:00 am
Location: Novi Sad, Vojvodina, Serbia, Europe
Contact:

Post by goodone » Sat Oct 02, 2010 4:11 am

thunderchero wrote:For new models All gif('s) for the model are 256x256 (if more than 1 is used than they are different)
they should not be. it's a wrong practice.
thunderchero wrote:You would need to understand new ship models since they are not the same as vanilla models.
that doesn't rly change much.
thunderchero wrote:As to the rest of your statements, since you are reluctant to try new things and know nothing about new ship models this discussion is at it's end.
now, this is more like an insult. i never stated any of that, and i guess u do not possess an ability to read ppl's minds.

but, since i do not have time to deal with ignorant ppl who do not take time to make their points valid, u r right - this discussion should be over, it serves little purpose. and i already made mine.

KrazeeXXL
BORG Trouble Maker
BORG Trouble Maker
Posts: 2267
Joined: Sat Jan 03, 2009 3:00 am
Location: the 36th Chamber

Post by KrazeeXXL » Sat Oct 02, 2010 5:37 am

goodone wrote:i never stated any of that
goodone wrote: but, since i do not have time to deal with ignorant ppl who do not take time to make their points valid
blablablalaberlabersülz

Better sweep around your own backdoor. That's all I got to say to you. Seen such a harsh & arrogant person seldom :!:

:roll:

I really had to say this :!:

User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 2581
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Post by Flocke » Sat Oct 02, 2010 6:11 am

goodone, I really appreciate that you want to help, and you know alot background information (still havn't checked how msvcrt.dll get's loaded).
And your testing on best hades and other dll compatibility is highly appreciated, too.

The problem is, you're also stating alot of incorrect or unhelpful guesses and as far I've understood you've never played udm3. Thunderchero and others had hard work getting these nice ships done, and they look far better than the original ones. There are complicated exporting rules involved I dunno about myself yet either.

It's true that it would be great to have smaller ship versions and textures if used by the game (to get some kind of LOD - nothing new), but that's mostly an issue of speed. The game and tactical combat works well for many people! I doubt you'll get hades or software rendering completely stable on any system, and rendering so much more polygons (bsp increases poly count even more) wouldn't surprise to have an effect. In tactical combat also the combat system might work on the meshes and have an effect, I dunno. But don't expect people to redo and reconvert all the models for lesser polygons. That's not applicable and they havn't modelled those ships to look as ugly as the older botf ones.

However alot care has been taken to make those ships as compatible as possible without looking ugly. E.g. I know Thunderchero already converted alot textures down to 256x256 to make it hades compatible.
And by experience the issues mostly are raised by systems, system configuration, drivers, os and stuff. If it was due to the new models, sometimes there were conversion failures on particular models that had to be fixed, but than there was a direct relation with crashes to ship occurance.

Often there are other issues in combat, especially with many ships involved, that seem to be more related to the combat system. E.g. when using evade command or with 3 or more empires involved or massive fleets and space stations etc etc etc. Many mods try to lengthen the battles and increase supplyable shipcount, no wonder it crashes more often.
However, if system is set up well, normally most people get botf AND all the common mods to work quite well.

Before continuing to state your guesses as recommandation (not that we dislike guesses) please take the time and test yourself if that really makes a difference. Else it's not helpful!

cheers :P

Edit: @Krazee, you're just getting misleaded to spam way too easy, but maybe you're right and it's just not worth arguing :lol:

Hey, we're a friendly community, do we already need another call for civility? think ruthlessferengi has already demanded for civility a doozen times! :roll:

goodone
Lieutenant-Junior Grade
Lieutenant-Junior Grade
Posts: 50
Joined: Fri May 29, 2009 2:00 am
Location: Novi Sad, Vojvodina, Serbia, Europe
Contact:

Post by goodone » Sat Oct 02, 2010 1:16 pm

all of my guesses are quite logical, if one takes time to think about them.

botf/mpr was made to handle three/two texture resolutions, and i simply cannot imagine they did it that way just because they could - there has to be an engine dependent reason.

following this logic and my different experience from what seems common here, i find modders' practice to use only one ship texture resolution a wrong one.. i do not have time to fully test it, i'm not a modder or a modeler, and i'm already taking too much time contributing to this community than i should have afforded myself, but i find it respectful and worth my contribution, if sometimes absurd over some issues [like things i already spoken about, which i thought by ten years of botf someone would have gotten by now], so i simply contribute.

not a single one of my conclusions is simply wrong. if that was the case, nobody would bother replying this much, would they?

also, since i value my time spent writing these things down, i rly find it annoying when someone dismisses them just because he thinks i know nothing about the whole issue. that's not how u combat wrong ideas, if u rly think they r wrong. u combat them by proving with facts, providing examples and statistics. otherwise it's just - well, ignorant.

anyway... i have provided my logic here, everybody have freedom to read it and acknowledge it [if it doesn't get deleted - that is], so i have done what i wanted. hopefully, someone will find it beneficial, if others find it 'blablablalaberlabersülz'.

in conclusion, i find that i have overstepped my behavior patterns over this, so, i'll just leave this topic and that will be the end of worries, both urs and mine.
Last edited by goodone on Sat Oct 02, 2010 1:51 pm, edited 1 time in total.

Post Reply

Return to “Modding Information Archive”

Who is online

Users browsing this forum: No registered users