Birth of the Federation

Flocke wrote:But with replacement models this is no issue anymore.

so 4500 poly ogre models would just be sweet?



thunderchero

thunderchero wrote:so 4500 poly ogre models would just be sweet?

very sweet!
(but with LOD I hope )

Flocke wrote:(but with LOD I hope )

no but I guess I should

Flocke wrote:
As for your resize bug, that's a new one to me. So you now start in fullscreen and can switch to windowed if fixed aspect isn't set, but as soon fixed aspect is set it crashes? And crashes too when starting in windowed without fixed aspect? What desktop resolution is set in windows?

My desktop resolution is at native 1280x1024 but I tried resizing to 1024x768 and 800x600 and the crash still happened. But changing display=FULLSCREEN enables fullscreen start and I can enter windowed mode back and forth in research screen and I have no problem so that worked (for me) I have encountered no other problems graphic related in UDM or GALM. I have not installed 1024 patch or MPR in any other mod but eventually I will just for testing purposes As for the problems others face I cant pretend to say I am an expert but I was just offereing some suggestions to them to try before commenting it doesn't work right away.

I remember when I would buy PC games frequently in the past, written onthe box system requirements were not an issue to me, but I do remember some (like Homeworld 2 iirc) stated that only certain graphic cards would be compatible with playing the game (due to any number of reasons). Newer graphic cards seem to curb these issues with compatibility with multiple driver updates or the onboard virtual memory that has been increased over the years. Maybe people with newer systems just can't use a new engine in an old game (like BotF) that still supports hob formats for the models? IDK to be honest and hopefully once ogre models are complete and ready to be implemented we will see these issues go the way of the do-do. But only time will tell as phasers are configured into the new models.

xDx wrote:My desktop resolution is at native 1280x1024 but I tried resizing to 1024x768 and 800x600 and the crash still happened. But changing display=FULLSCREEN enables fullscreen start and I can enter windowed mode back and forth in research screen and I have no problem so that worked (for me)

Interesting, native 1280x1024 is greater than botf native 800x600 and greater 1024x768 resolution mods too, so that's not an issue.
Please test if it crashes with to see if FIXEDASPECT or VSYNC make a difference
if not it's probably a driver, ogre, directx or gpu issue.
And have a look if there's an exception last line of ogre.log (there should be one reporting that restoring the display failed or something).
As it's not the first reported crash restoring the display, ruthless reported a similar issue with window resizement during combat, and some onboard gpus don't work at all, I might try to catch the exception and reinitialize whole graphics in a later version. Implementation wise that workaround might not be finest but it should solve window resizement for every system.

Hello Flocke. I have tested all configurations you requested of me in 1024 res (UDM) and 800 res (GALM). The tests were switching between fullscreen and windowed in both a combat and research ship screen (since all other screens caused no issues). These were my results:

Code:
[display]
DISPLAY=VSYNC|FULLSCREEN|FIXEDASPECT

UDM and GALM works flawlessy

Code:
[display]
DISPLAY=FULLSCREEN|FIXEDASPECT

UDM and GALM works flawlessy

Code:
[display]
DISPLAY=VSYNC

UDM worked GALM crashed in same conditions as mentioned above

Code:
[display]
DISPLAY=

UDM worked GALM crashed again under same conditions

Hope this info helps you

edit: The last line of ogre.log for successful tests:

17:25:26: Unregistering ResourceManager for type Material

Interestingly enough I tried going back to reproduce the crashes for the ogre.log and I could not reproduce them. I also tried restoring default INI setting

#DISPLAY=VSYNC|FIXEDASPECT

As was the original problem but again I could not reproduce the crash lol. So as of now I have no problems with any setting in either low res or hi res BotF. Again though I have NOT tested any other mods or vanilla in hi res or just MPR++ so my results are incomplete.

yes, thx, must be a general problem with ogre/dx/hardware
only interesting thing you missed is last line exception of ogre.log when it crashed, there should be one, either failed to restore display or failed to set culling mode, these are the two I've heard of so far.
Graphic recreation workaround on exception should fix this, but looks like I've to compile ogre myself to catch these exceptions, and there's a new ogre version to come soon, so window resize crashes have to wait some.
edit: lol, thx for edit

I edited my last post with ogre.log and interesting results

yeah, interesting, like a ghost this bug, but not in my code at least
also have read from others in ogre forum having experienced problems with window resize and it being hardware related, but maybe there's also a hidden bug in ogre or directx, who knows.
If you encounter it again, have a look at ogre.log if there's an exception last line, unregister is none but normal shutdown or unload.

Here is my video card and specs, Im sure youve been to newegg..

http://www.newegg.com/Product/Product.a ... 6814121395

Hey Flocke, running into an issue with MPR++ in all mods and vanilla. After installation of MPR++ trying to run trek.exe I get this error:

[EDIT] so the fix for this involved simply opening the MPR INI file and adding a # before the FSAA=4 line... all mods work fine now with that. I'm running Windows 7 Home Premium with a standard Intel HD videocard.... hopefully this helps anyone else who finds trouble...



22:00:52: OGRE EXCEPTION(3:RenderingAPIException): Cannot create device! in D3D9Device::createD3D9Device at ../../../../../../RenderSystems/Direct3D9/src/OgreD3D9Device.cpp (line 707)

ZeroChance wrote:[EDIT] so the fix for this involved simply opening the MPR INI file and adding a # before the FSAA=4 line... all mods work fine now with that. I'm running Windows 7 Home Premium with a standard Intel HD videocard.... hopefully this helps anyone else who finds trouble...

Hm, interesting, thanks for report, will have to check the capabilities for FSAA support then.
Sry for, expected every system has FSAA support nowerdays.

could not get udm working on new comp win7 - got the same error as Zerochance - but he suggested i add # to command line in ogre file and it worked! sweet... now if we could solve the lag problem would be nice

Just a quick question Flocke. Does MPR++ still support only 16 bit tga files or is there a way to add png or jpeg files and increase to 24 or 32 bit? I tried adding a new 24 bit dilithium graphic and trek.exe CTD. Is there a way to allow this or are we still limited by trek.exe?

@ruthless your new system does not by poor chance have an intel HD graphic chip like ZeroChance?
Don't be surprised MPR render mode lags on intel graphic chip, that's by far the slowest you can get nowerdays.
3D render mode will probably not lag as long ships don't become too complex and there are no special effects like shadows involved, but needs time to finish that.

@xDx limited by trek.exe, you got it
Dunno if this can be fixed, QuasarDonkey might know more on this with all his wpf research. MPR++ can be adjusted to many formats.