Grimrock

John,

I have tried to find patterns, so far I've found this:

With a clear desktop, do the following

1. Start the game, in the menu go to the editor and open a dungeon, then click the play button.
2. Open the model toolkit and open a random file.
3. Close the editor, start the game and load a dungeon.
4. Close the game and go back to the desktop. Now the window in the model editor should be "blank" or contain your desktop.
5. Now open another file. This should spawn errors.

edit: It seems this isn't 100% reproducable, but it's the closest I've gotten.
And to answer your question, yes I've always had the editor and/or the game running while experiencing the toolkit errors.

edit 2: I consider this to be a major bug as it can actually make the OS unresponsive. It has happened 1 time only though (so far...), the mouse started lagging like crazy and there were low noise sounds emitting from the speakers. Had to do a hard-reset, ctrl+alt+delete didn't even work. This is what triggered the bugcheck code 117 in Windows. My suggestion is to pull back the release from your website and put a note up, until you can fix it!

edit 3: The process also sticks at 100% cpu for one core. Since I am on a quad-core, it means 25% cpu is used all the time without using the toolkit, simply by having it open.

In any case, thank you for a great tool. It's truly appreciated!

I had a lock up as well, but only once and I'm not 100% sure it's related to the toolkit. I had the editor (in play mode), the toolkit, my modeling program and my internet browser opened when it happened. Thought it was some kind of overload issue. Never happened again, though to be safe I don't play the game with the toolkit open and I always close at least one graphic app (my modeling program or the editor) before opening the toolkit.

The rendering in the toolkit is completely messed up now by the way, it looks like the models used to look in the editor or game before you fixed the code. Funny thing is that in game (and in the editor) everything looks fine now. Not a big issue since I don't need the render window of the toolkit, but I thought I'd mention it in case I'm a special case and you didn't notice there is a problem yet.

Just a quick update from this evening's preliminary work... I'm pretty sure the errors are related to DirectX being shared between Grimrock and the GMT. I have been using a rather crude method of recovering when GMT loses DirectX to another app (like LoG).

I ran FRAPS with the GMT accidentally earlier - it was rendering at 5,000 FPS. I read you can't easily VSync DX9 in windowed mode, but a quick parameter change and its now running at 60fps - which has to be a good thing .

I'll post a preliminary version tomorrow and then get to doing a few things 'properly' instead of taking the shortcuts I took to develop what we have in the time I've had available! Thanks for the detailed bug reports - very useful. It's like you guys have had recent experience beta testing software or something! :p

Edit: I'm sure there was a reply from Neikun a second ago! Unless I am imagining things! But yes, will hopefully be less stressful on the old CPU in tomorrow's build!

Thanks for the update, John. Looking forward to the updated version.

JohnWordsworth wrote:
Edit: I'm sure there was a reply from Neikun a second ago! Unless I am imagining things! But yes, will hopefully be less stressful on the old CPU in tomorrow's build!

No imagining there, I just figured I said something stupid.
In response to the 5000fps, "Does this mean it'll stop making my fan make weird noises"

Release Notification: Grimrock Model Toolkit 0.2.2.1
GMT Homepage | Direct Download

The latest release of the GMT is mostly a refactoring and internal code improvement release. There is still some work to do in order to get DirectX to play ball properly when alt-tabbing between GMT and Legend of Grimrock (when Grimrock is fullscreen), but I believe this is 85% of the way there now. The rest should just be code tidying issues more than anything. Changes...

• Rendering is now driven by a timer instead of 'as fast as I can', which means that GMT should use much less CPU. There might be a framerate impact on slower computers though, so please let me know how it performs.
• Tidied up a bunch of the DirectX methods now that I've got my head around some of the oddities of DirectX. As such, Alt-tabbing between DirectX and Grimrock when Grimrock is full screen should be much more stable.
• Added confirmation dialogue boxes when you hit calculate normals or tangents if data already exists (as this will destroy the existing data).

Please let me know how you guys get on with the latest build. I hope to move on to more features for my next development cycle (so I have a fancy new screenshot to post with the release notice! ).

Edit 1: I've just noticed that there are some renderer oddities if you open a number of models in a row / open a file after calculating normals / tangents (random triangles rendering incorrectly). Restarting GMT seems to fix this (and the same models load OK). I'll take a look into this tomorrow - hopefully it's nothing too serious.

Edit 2: Okay, I couldn't go to bed and leave it in that state, so I found the bug that was causing the rendering issues. It should all render ok now . Please make sure you update to version 0.2.2.1 (have edited this post).

I see a grid. I like grids owo
Also my fan no longer whistles haha

I LIKE IT. I don't understand half of it, but I like it, haha

Thanks John, installed and testing. I'll get back to you.

JohnWordsworth wrote: Edit 1: I've just noticed that there are some renderer oddities if you open a number of models in a row / open a file after calculating normals / tangents (random triangles rendering incorrectly).

John, this happens to me whole time on my Ati card (does not matter if I open 1st or 20th model), and some times on my nVidia/intel 4500HD. I hope that new renderer will remove this bug - I will test updated version tonight.

Hi Leki & Xaurus, I look forward to hearing whether the latest build fixes the issues you have been having! Thanks for your patience while we refine the technology.