Crystal Space
Welcome, Guest. Please login or register.
October 20, 2017, 09:00:36 pm

Login with username, password and session length
Search:     Advanced search
9063 Posts in 2051 Topics by 77507 Members
Latest Member: Laidlebonnie483
* Home Help Search Login Register
+  Crystal Space
|-+  Crystal Space Development
| |-+  Support
| | |-+  Odd maximize/restore down window errors Win32
« previous next »
Pages: [1] Print
Author Topic: Odd maximize/restore down window errors Win32  (Read 1612 times)
Posts: 30

View Profile Email
« on: December 09, 2009, 07:41:05 pm »

Version of CS – CS stable 1.2.1
Version of CEL – CEL stable 1.2.1
Version of winlibs package (if on windows) – Corresponding 1.2_002
Operating system – Windows XP Win32
Compiler – MSVC++ 2005
Video card – ATI Radeon X1650 PRO
Driver – Version

1) The first situation occurs immediately after I start up a CS app, like those demos in the CS folder, and appears to happen regardless of whether the entire level is hard coded, like with the Mazing tutorial, or the level is provided in a map file. The app initially starts in the Restore Down window and something is not right with the meshes and their proportions, or the way the camera is looking at them. It almost seems that maybe the camera degree angle is different than its set to be. In any case, when I maximize the window, by pressing the little button, the meshes seem to correct themselves and appear at the right distance/proportion/etc. This problem still occurs when the app is started in Full Screen mode. (As a note, when I do minimize a Full Screen window and restore it, I get numerous graphics errors on the command line and the whole window is screwed up). Further more, every time a new map/world file is loaded, this problem reoccurs and I have to maximize and restore down the window to get the meshes looking right again. This is a problem for me, as I mix 2D and 3D into a single app and the 2D is not affected by this problem, so they become non-uniform. Any ideas? Maybe it's my graphics card, or maybe this problem has been fixed on 1.4.

2) Now this one is just crazy! So apparently, when using iMeshWrapper::HitBeam(...), whether or not csHitBeamResult::hit is true or false DEPENDS ON WHETHER OR NOT YOUR WINDOW IS MAXIMIZED OR RESTORED DOWN. Of course! How could I not see that? I mean, the screen size and whether or not a hit beam made its mark are completely related... CS cracks me up sometimes, in that sneering, wanting to strangle you, kind of laughter. No hard feelings though =).

CS Developer
Full Member
Posts: 206

View Profile Email
« Reply #1 on: December 10, 2009, 12:52:26 pm »

Hmm, problems with resizing are kind-of known and have existed for a while; however, afaik only some people actually try to resize windows and run into that. Hence not resizing is the usual workaround for that Tongue
However, windows _should_ start off with the right size; programmatically there is no resizing or so done. Also, minimizing usually works as well (as that doesn't really change the window dimensions after restoration).

Perhaps give 1.4 a try, possibly the behaviour there is better.
Posts: 30

View Profile Email
« Reply #2 on: December 11, 2009, 06:50:59 am »

Oh, I like that solution: In order to avoid the problem, avoid the situation in which the problem occurs.

Anywho, I narrowed the problem down to a single piece of code: camera->SetFOVAngle(angle, width);

After that function is called, I have to either restore down or maximize the window in order for the meshes to display correctly. Because this happens whenever I start an app, it also suggests that what is initially displayed on the screen is not the default camera degree angle, but a false one, until the, I guess, display calculation is reset by maximizing/restoring down the window.

I can call camera->GetFOVAngle() and output the float angle to screen, and it will give me the number that I set it to, but it won't really display that angle, not until the window is changed.

It's a little disheartening to be not able to change the camera degree angle without problems, but I can live with it for now.
Pages: [1] Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Page created in 6.218 seconds with 17 queries.