59 replies to this topic

[ghostdog]

Yeah, I've just reproduced this in 800x600. It never happened to me before since I was mainly testing the UI in bigger resolutions and it doesn't seem to happen in big resolutions. In fact I can see this happening in Mebbeth's Hut only in 800x600. With 1024x768 and 1152x648 it didin't happen.

Nevill, I can see that you have installed it in 800x600 , right ?

Qwinn, what resolution are you using ? Have you noticed this only with the new v2.1 with the bigger window or did it also happened with the older versions ?

[ghostdog]

Ok, this seems to be a widescreen mod problem. I uninstalled my UI and it still happened with only the widescreen mod installed in 800x600 :



I'll tell Bigg about this.

Edited by ghostdog, 19 January 2010 - 03:33 AM.

[Qwinn]

I'm using 1360x768.

Qwinn

[ghostdog]

Heh, it's funny. Of all the resolutions I've tested so far this only happens in 800x600 and in 1360x768. With 1024x768 , 1152x684, 1280x720 1280x800, 1680x1050... the glitch doesn't show. My UI makes it even less visible since by centering the loading screens you don't see them imprinted in the left side, the only thing you may see is a small part of the dialog window. Anyway, I've informed Bigg about this.

Edited by ghostdog, 19 January 2010 - 05:36 AM.

[nevill]

Quote

Nevill, I can see that you have installed it in 800x600 , right?

Yes. I thought it would be a nice compromise between detalisation and usability.

[the bigg]

Can I have a save?

[nevill]

Of course. 'Weidu.log' is included in the archive.
 000000006-Save.rar   109.07K   43 downloads

[the bigg]

Ugly hack FTW.

diff --git a/libsmall/patch_are.tpa b/libsmall/patch_are.tpa
index d7013f4..4fbb448 100755
--- a/libsmall/patch_are.tpa
+++ b/libsmall/patch_are.tpa
@@ -20,7 +20,7 @@ COPY_EXISTING_REGEXP - GLOB ~^.*\.wed$~ ~...~
 				whichMax = i
 			END
 		END
-		PATCH_IF xMaxWed * 64 < x || yMaxWed * 64 < y THEN BEGIN
+		PATCH_IF (xMaxWed - 3) * 64 < x || (yMaxWed - 3) * 64 < y THEN BEGIN
 			INNER_ACTION BEGIN
 				APPEND_OUTER ~widescreen/areas~ ~%SOURCE_RES% %xMaxWed% %yMaxWed%~
 			END
@@ -35,8 +35,8 @@ COPY ~widescreen/areas~ ~widescreen~
 		READ_2DA_ENTRY_FORMER areas_to_fix bfg 1 xMaxWed
 		READ_2DA_ENTRY_FORMER areas_to_fix bfg 2 yMaxWed
 		origArea = xMaxWed * yMaxWed
-		xReq = x / 64
-		yReq = y / 64
+		xReq = x / 64 + 3
+		yReq = y / 64 + 3
 		PATCH_IF xReq < xMaxWed THEN BEGIN
 			xReq = xMaxWed
 		END

[ghostdog]

Naah, it's a thing of beauty in my eyes. So, we're close to a WDM v2.4 ?

[the bigg]

Yes. The fact that the publicly available version cannot uninstall is a great incentive for me to update it ASAP

[taplonaplo]

ghostdog, on 16 January 2010 - 10:03 AM, said:

Yep, this is the flickering I mention in the readme. It can happen when you open a window and something is moving in the visible area. Unavoidable as far as I know unfortunately.

Avoidable by pasuing the game before opening the window, which pauses the game as i remember. So i wonder if "pause" is a function and it would called before popping the window would it prevent it?

Edited by taplonaplo, 20 January 2010 - 04:20 AM.

[Qwinn]

Quote

Avoidable by pasuing the game before opening the window, which pauses the game as i remember. So i wonder if "pause" is a function and it would called before popping the window would it prevent it?

That sounds like an excellent solution.

I'm betting it'd be a case of -moving- the call to the pause function, rather than adding a call. It probably works as a toggle. If you did Pause(), pop window, Pause(), you'd probably wind up unpaused. So switching it from (window then pause) to (pause then window) would probably work great. And it would probably be easy to do that in the engine, cause it shouldn't require any more room than the original order did.

Qwinn

Edited by Qwinn, 20 January 2010 - 04:46 AM.

[Qwinn]

Wow, it's a really good thing thebigg is working on fixing that "vertical stripe on lower left" bug.

In a resolution where you got the bug, try casting Remove Curse while in Vrischika's shop.

Epileptics beware!

Qwinn

[nevill]

Quote

That sounds like an excellent solution.

Will it fix the problem with the action menu (the one that allows you to choose weapons)? It is also flickering from time to time.

[scient]

I know where the code location for opening up all those windows (journal, inventory, spellbook) when I was working on expanding journal entries. When I get home, I'll see what can be done to reorder the pause and if it's safe to do so.

Edited by scient, 20 January 2010 - 07:15 AM.

[ghostdog]

Sounds good, thanks scient.

[Qwinn]

Scient, might want to check out the function StartStore as well.

Qwinn

[scient]

Qwinn, on 20 January 2010 - 08:14 AM, said:

Scient, might want to check out the function StartStore as well.

Qwinn

Is that a place with problem or place where it's working? But I also have store location when I was testing something or other.

[Qwinn]

It has the problem. It's just that it's started via that function being called from dialogues, rather than by a button in the GUI.

Qwinn

[ghostdog]

Qwinn, on 20 January 2010 - 08:37 AM, said:

It has the problem. It's just that it's started via that function being called from dialogues, rather than by a button in the GUI.

Qwinn

Yeah, and that problem has already been toned down by a fix from taplonaplo that enabled a small wait before the store opens. Without that fix the stuttering was severe. Of course if pause can be called instead it would hopefully be much better.