Darkradiant 2.0.1 bugs

[motorsep]

Not sure if you saw this already, but (TAB related):

 

http://goo.gl/zUnzDW

http://msdn.microsoft.com/en-us/library/system.windows.forms.control.keydown%28v=vs.110%29.aspx

[7318]

Greebo now I can compile your branch.

 

but I still get problems with the 3D geometry (the same kind of problems I posted some screen-shots about) I'm using Ubuntu 14.10, and Intel mesa graphics, but the Darkradiant 1.8.1 had correct graphics for me, something has changed in the 3D rendering in-between 1.8.1 and 2.0 that has broken 3D rendering in my system. right now for me the most reliable way to map then is with the wire-frame.

 

also the particle editor is unusable for me, now i can select the particle, but I can't see anything in the 3d view, and the play and stop buttons while active don't seem to activate the time counter in the 3d view.

and also in the particle editor it looks like selecting the particles doesn't update some values right away, like the stages or the actual selected particle in the lists of particle effects, sometimes you have to scroll down and up in order or it to be correctly selected

 

I've received error messages like these but I can't reproduce when and how I received yet:

 

(darkradiant:2896): Gtk-CRITICAL **: IA__gtk_window_resize: assertion 'height > 0' failed

 

** (darkradiant:2981): CRITICAL **: murrine_style_draw_box_gap: assertion 'height >= -1' failed

Edited November 27, 2014 by 7318

[greebo]

but I still get problems with the 3D geometry (the same kind of problems I posted some screen-shots about) I'm using Ubuntu 14.10, and Intel mesa graphics, but the Darkradiant 1.8.1 had correct graphics for me, something has changed in the 3D rendering in-between 1.8.1 and 2.0 that has broken 3D rendering in my system. right now for me the most reliable way to map then is with the wire-frame.

Hm, obviously the pure GTK+/GTKGLExt implementation did something different than the wxGTK implementation on your system, but I'm not an expert in this area. From this wxWidgets page it appears that Mesa even is a requirement if pure openGL is missing, so I don't really know what's going on your end. What I did is set up Ubuntu 14.04 in a VirtualBox environment here, and the wxWidgets GL demo worked fine, even though it was just a virtual machine. DR also rendered ok in my VM, but I haven't checked for a while.

[7318]

I wonder if anyone else is using DR with a Intel "HD graphics 3000" GPU (or newer) either in Linux or Windows so we could see if is an error in my computer or is a systemic error, 3D in other applications, like D3, or OpenArena, do work ok.

[greebo]

Does the DR debug build spit out any GL errors?

[motorsep]

Does the DR debug build spit out any GL errors?

 

Not that I remember.

[7318]

how do I make a debug build?

[AluminumHaste]

I suppose since this is a pre-release then the guide might not apply, but trying to get the Git repo to build on my computer has been painful.

I'm not great at huge projects and get overwhelmed quickly, but I finally got it working today.

 

To start, for some reason I was missing the Boost libraries so I redownloaded those and that got rid of tons of errors.

 

But I was still getting WxWidget errors.

I had to download the latest binaries from their sourceforge site for v120 (using VS2013), and install them to E:\DarkRadiantSRC\DarkRadiant\plugins folder.

I tried using the default which is C:\Windows\SysWOW64, but that didn't allow DR to compile.

I might have had to update the the windows Path variable, but I don't like touching that.

 

Or hell, I might just have needed to reboot, but after all this it finally compiled the debug and release version.

 

There are 833 Warnings, mostly about possible precision loss.

And 1 error which didn't stop the build from compiling:

834    IntelliSense: cannot open source file "wx/intl.h"    e:\DarkRadiantSRC\DarkRadiant\include\i18n.h    10

 

Which is interesting because it's there:

E:\DarkRadiantSRC\DarkRadiant\w32deps\wxWidgets\include\wx\intl.h

 

But not in the w64deps, maybe that's why? Or does it not matter?

[AluminumHaste]

how do I make a debug build?

 

If you are using Visual Studio to compile the project, you select which at the top, either Debug or Release.

[AluminumHaste]

I see you marked bug 0003938 as fixed, have you committed the changes to the Git repo?

[VanishedOne]

I can reproduce that. It seems that the TAB key doesn't produce keydown events in Windows. The OS doesn't send it to the app, so I can't intercept it in the shortcut handler. Can you open a tracker entry for this case, please?

 

Here it is: http://bugs.thedarkmod.com/view.php?id=3940

[greebo]

how do I make a debug build?

You'll have to pass --enable-debug to the ./configure script.

[greebo]

Here it is: http://bugs.thedarkm...iew.php?id=3940

Fixed now, thanks.

[greebo]

I suppose since this is a pre-release then the guide might not apply, but trying to get the Git repo to build on my computer has been painful.

Have you been following the Compilation Guide on the wiki? The folder structure is probably the thing you're missing, otherwise the VC++ projects would find the deps. You don't have to track down any 3rd-party dependencies on your own, that's all included in the w32deps/w64deps packages linked in the Compilation Guide.

 

I see you marked bug 0003938 as fixed, have you committed the changes to the Git repo?

Yes.

[AluminumHaste]

Yes.

 

I tried pulling and it just keeps saying it's up to date.

Checked the guide and I see the git repo was changed (not sure when lol).

I feel pretty stupid, it was git://github.com/orbweaver/DarkRadiant.git I think, changed that to git://github.com/codereader/DarkRadiant.git and now it pulled all the new changes.

 

Really so all this time I've just been checking out the wrong repo, man.

[7318]

compiled with debugging

 

opening and closing DR:

 

biel@Biel-laptop:~$ darkradiant
ApplicationContextImpl: unable to create settings path '/home/biel/.darkradiant/'
XMLRegistry: looking for XML files under /usr/local/share/darkradiant/
[filters] Loaded 15 filters from registry.
[OpenGLRenderSystem] GLSL shading IS available.
[OpenGLRenderSystem] ARB shading IS available.
(darkradiant:9071): Gtk-CRITICAL **: IA__gtk_window_resize: assertion 'height > 0' failed

 

 

if I rescale the window of the texture mapping oiptions (the window that appear when you press "s") i can reproduce the following error:

 

** (darkradiant:9167): CRITICAL **: murrine_style_draw_flat_box: assertion 'height >= -1' failed

 

if I click on the per-pixel rendering button i get the following debug message:

 

^[[renderer] Creating GLSL bump program
[renderer] GLSL program IS valid.
Info:
[renderer] Creating GLSL depthfill program
[renderer] GLSL program IS valid.
Info:

 

I wonder, does darkradiant use a GLSL version superior to 1.3? mesa drivers not superior to mesa 10.3 only have GLSL version 1.3 (i'm currently using mesa 10.5 which should have support for GLSL 3.0 )

[greebo]

I wonder, does darkradiant use a GLSL version superior to 1.3? mesa drivers not superior to mesa 10.3 only have GLSL version 1.3 (i'm currently using mesa 10.5 which should have support for GLSL 3.0 )

I don't know which GLSL version DR's programs are based upon, but since your system supports 3.0 it shouldn't be the problem? I'm afraid I don't have a system with Intel HD3000 around to test, so I can do next to nothing to narrow down the problem for you. I can't really change the way wxWidgets GL is working neither. Does the GL demo of wxWidgets work on your system?

[OrbWeaver]

I feel pretty stupid, it was git://github.com/orbweaver/DarkRadiant.git I think, changed that to git://github.com/codereader/DarkRadiant.git and now it pulled all the new changes.

 

My repo is still active but I'm working mainly on Linux stuff. I do pull changes from greebo periodically but if you want all of his latest Windows fixes then yes, you should definitely pull from his repo directly.

 

I wonder, does darkradiant use a GLSL version superior to 1.3? mesa drivers not superior to mesa 10.3 only have GLSL version 1.3 (i'm currently using mesa 10.5 which should have support for GLSL 3.0 )

 

I think it's using GLSL 1.0, and that informational message indicates that the shaders were compiled successfully, so I don't think GLSL version is the problem here.

[7318]

so GLSL version is out of the question, I might have to check if the wxWidgets GL demo displays the same problems...

[Sotha]

I cannot type anything in S&R editor.

1) Select entity and open S&R.

2) Add a reponse.

3) In the EDIT RESPONSE EFFECT window, try to type something into the argument box (for example TARGET LIGHT for effect "Turn extinguishable light off")

 

All key presses are caught by the DR hotkeys. Trying to type "h" for example hides the chosen entity. Nothing gets into the edit response effect window.

[greebo]

I cannot type anything in S&R editor.

1) Select entity and open S&R.

2) Add a reponse.

3) In the EDIT RESPONSE EFFECT window, try to type something into the argument box (for example TARGET LIGHT for effect "Turn extinguishable light off")

 

All key presses are caught by the DR hotkeys. Trying to type "h" for example hides the chosen entity. Nothing gets into the edit response effect window.

Thanks for reporting, that's already been fixed in source, will be gone as soon as the next build is out there.