Jump to content
The Dark Mod Forums
Sign in to follow this  
greebo

DarkRadiant 2.0.1 pre-release test

Recommended Posts

Found another bug -

 

If you click on a model based light entity and then press L for the light inspector, I am not able to open up the list of light textures which Im sure I could under 181.

Share this post


Link to post
Share on other sites

fails to build on Gentoo currently

 

make[3]: Entering directory '/home/prinzenrique/Programs/source/DarkRadiant/plugins/eventmanager'
 CXX	  Accelerator.lo
 CXX	  Modifiers.lo
 CXX	  Statement.lo
 CXX	  EventManager.lo
 CXX	  MouseEvents.lo
 CXX	  Toggle.lo
 CXX	  WidgetToggle.lo
 CXXLD	eventmgr.la
.libs/EventManager.o: In function `EventManager::initialiseModule(ApplicationContext const&)':
/home/prinzenrique/Programs/source/DarkRadiant/plugins/eventmanager/EventManager.cpp:65: undefined reference to `ui::GlobalKeyEventFilter::GlobalKeyEventFilter(EventManager&)'
collect2: error: ld returned 1 exit status

Share this post


Link to post
Share on other sites

creating a particle when there are no other particles (in BFG there are no particles available) allowed me to give it a new name, save it in the file, as per usual, but then the whole particle editor window stayed "inactive" and no new particle was created, in the modfolder/particles folder DR hadn't created any new file, the only thing I could do is close the particle editor window, after that I couldn't open the particle editor no more until I closed DR and re opened it.


Biel Bestué de Luna - Github

Share this post


Link to post
Share on other sites

Found another minor bug -

  • Cant type the _ symbol when trying to filter textures.

post-496-0-95994000-1415633701_thumb.png

 

And a MAJOR bug -

  • Selecting the entity list in 201 is considerably slower than 181, and 181 wasnt fast to begine with! I it took over 2-3 mins to bring up the Entity list.
  • And related to the above, I can no longer select an entry in the Entity list and start typing to filter said list (looks like the same can't type bug above)

When I found the entity I was looking for (the origin of which was causing a leak) I selected said entity and DR froze, closing the Entity list window stop the freezing etc. What ever is wrong is the same thing thats happening in 181, but worse.

Share this post


Link to post
Share on other sites
Under 181 its a few faster still, would it be possible future version to get the speed back to 181 levels..?

Maybe. At the moment I try to focus on the functional issues, performance improvements can be looked at later - don't have the nerve for this right now, this usually involves more time.

 

I never needed to know, because I could always access the light colour from the light inspector in 181, would it be possible to add this back in a later version of DR..?

If it's just the string representation (#CD3333) that's lacking, I can probably do something about it. But I definitely can't change the dialog itself, it's the one provided by the WIndows common controls.

 

grand, Ill go have a look at the def file on the SVN. In the meantime can you unhide that arg in DR so its always shown by default?

I can't unhide the spawnarg because it's not there. The "light" entityDef doesn't define this spawnarg so the colour will default to white.

 

Layers window scroll bug -

Wow, that's weird. I finally managed to get the behaviour here as well - one has to hide the Layers window, then show it again and then toggle some layer - the scrollbar will jump around. It doesnt' happen if the Layers dialog itself is the active window (e.g. if you click on its title bar).

 

Cant drag-scroll bug -

Have you tried moving to the edge of the window a bit slowlier? It seems to me in the video that the mouse cursor is leaving the xy view. DR needs to receive mouse move events that are located very close to the window's border, so maybe you're moving too fast?

 

Do you think you'll manage to put the prefabs custome path feature in for this version..?

Probably not, too much of a change. I'd like to get 2.0.1 out of the door soon, since it's an improvement already - 2.0.1 won't be the last release.

Share this post


Link to post
Share on other sites

If you click on a model based light entit and then press L for the light inspector, I am not able to open up the list of light textures which Im sure I could under 181.

Can you double-check? Which entity are we talking about specifically

 

Cant type the _ symbol when trying to filter textures.

That was something I could fix. It's been caused by the shortcut handling changes - this kind of regression is to be expected after such a global change.

 

Selecting the entity list in 201 is considerably slower than 181, and 181 wasnt fast to begine with! I it took over 2-3 mins to bring up the Entity list.

I'll see whether there's something I can do for a quick win. The Entity List has always been problematic in large maps, and the one you're working on are in the range of 30k map objects, which is a lot.

 

When I found the entity I was looking for (the origin of which was causing a leak) I selected said entity and DR froze, closing the Entity list window stop the freezing etc. What ever is wrong is the same thing thats happening in 181, but worse.

See above, maybe DR will overload itself in processing code after the click.

Share this post


Link to post
Share on other sites

fails to build on Gentoo currently

I think this is fixed now, OrbWeaver has committed a new makefile.in batch.

 

creating a particle when there are no other particles (in BFG there are no particles available) allowed me to give it a new name, save it in the file, as per usual, but then the whole particle editor window stayed "inactive" and no new particle was created, in the modfolder/particles folder DR hadn't created any new file, the only thing I could do is close the particle editor window, after that I couldn't open the particle editor no more until I closed DR and re opened it.

Is this something new in 2.0.x or has this happened before in the 1.8.x versions? If it's not something new, then please put it on the tracker.

Share this post


Link to post
Share on other sites

the particle editor worked perfectly (albeit it repeated the particle effects twice)

 

the strange geometry is new, it worked fine before

 

Could you please provide video or screenshots explaining what's going on ?

Share this post


Link to post
Share on other sites

I provided the screen-shots on the strange geometry above, the particles stuff wasn't big deal then, and now it's no more because there is a bigger problem now, that I already explained also above.


Biel Bestué de Luna - Github

Share this post


Link to post
Share on other sites
  1. Maybe. At the moment I try to focus on the functional issues, performance improvements can be looked at later - don't have the nerve for this right now, this usually involves more time.
  2. If it's just the string representation (#CD3333) that's lacking, I can probably do something about it. But I definitely can't change the dialog itself, it's the one provided by the WIndows common controls.
  3. I can't unhide the spawnarg because it's not there. The "light" entityDef doesn't define this spawnarg so the colour will default to white.
  4. Wow, that's weird. I finally managed to get the behaviour here as well - one has to hide the Layers window, then show it again and then toggle some layer - the scrollbar will jump around. It doesnt' happen if the Layers dialog itself is the active window (e.g. if you click on its title bar).
  5. Have you tried moving to the edge of the window a bit slowlier? It seems to me in the video that the mouse cursor is leaving the xy view. DR needs to receive mouse move events that are located very close to the window's border, so maybe you're moving too fast?
  6. Probably not, too much of a change. I'd like to get 2.0.1 out of the door soon, since it's an improvement already - 2.0.1 won't be the last release.
  7. Can you double-check? Which entity are we talking about specifically
  8. That was something I could fix. It's been caused by the shortcut handling changes - this kind of regression is to be expected after such a global change.
  9. I'll see whether there's something I can do for a quick win. The Entity List has always been problematic in large maps, and the one you're working on are in the range of 30k map objects, which is a lot. And maybe DR will overload itself in processing code after the click.

  1. Its appreciated.
  2. Hmm, thats a pain in the arse then, what about grabing the core from an open source paint application for windows such as "Paint.net", see screenshot of the colour window below.
  3. Its there but hidden by default for model based light entities.
  4. Cool.
  5. Makes no difference, once the object I am dragging reaching the edge of the orthoview windows it stops while the mouse cursor carries on moving.
  6. Fair enough, just means I will have to stick with 181 untill that is sorted.
  7. When I select a model based entity, I can't change or even click on a sader in the r/h pane - see screenshot below.
  8. Grand.
  9. Anything you can do would be appreciated.

post-496-0-20364600-1415659417_thumb.jpg

 

post-496-0-70981400-1415659428_thumb.jpg

 

Found another bug - tried to copy shadername and nothing get copied to the clipboard.

 

post-496-0-36690400-1415661724_thumb.png

Share this post


Link to post
Share on other sites
Hmm, thats a pain in the arse then, what about grabing the core from an open source paint application for windows such as "Paint.net", see screenshot of the colour window below.

No, that wouldn't work at all. I can't just copy stuff from C# to C++.

 

Makes no difference, once the object I am dragging reaching the edge of the orthoview windows it stops while the mouse cursor carries on moving.

That's definitely different on my end then. Hm.

 

When I select a model based entity, I can't change or even click on a sader in the r/h pane - see screenshot below.

You couldn't do that in 1.8.x neither. It's because the atdm:lamp_oil_wall_lit is basically a func_static model, it only has a light source def_attached. DR can't deal with that.

 

Found another bug - tried to copy shadername and nothing get copied to the clipboard.

It works here: textures/common/collision

Share this post


Link to post
Share on other sites
  • No, that wouldn't work at all. I can't just copy stuff from C# to C++.
  • That's definitely different on my end then. Hm.
  • You couldn't do that in 1.8.x neither. It's because the atdm:lamp_oil_wall_lit is basically a func_static model, it only has a light source def_attached. DR can't deal with that.
  • It works here: textures/common/collision <== I copied that a second ago.

  • ah ok, just an idea.
  • Ok, nuked the prefs and drag-scrolling sorta works, but its very flakey - see attached video
  • Ah yes, sorry. Because the dialogue window layout had changed so it look more it did for simple lights in 181 I got confused.
  • nuking the prefs fixed this.

http://youtu.be/nHEQPQ5JDNE

Share this post


Link to post
Share on other sites
Ok, nuked the prefs and drag-scrolling sorta works, but its very flakey - see attached video

The scrolling may be a bit stuttering depending on how much stuff is to be drawn in the scene, but I'd have to investigate more deeply to be sure.

Share this post


Link to post
Share on other sites

Thanks Greebo and while your hear found another bug -

 

On the surface inspector window, a few times when i have clicked texture rotate too quickly - the texture on the surface I was working on went into a continuous spin. The only way I've got it to stop is repeatedly hit the opposite arrow button etc.

Share this post


Link to post
Share on other sites

I thought I saw someone mention that a problem with ESC was fixed, however ESC is not working to deselect objects for me. Do I need to rebind the key shortcut or something?

 

There's also this assertion which occurs after creating a light and switching to the Entity Inspector tab:

 

#0  0x00007ffff405520b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00007ffff5d84c78 in wxGUIAppTraits::ShowAssertDialog(wxString const&) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#2  0x00007ffff56e865a in ?? () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#3  0x00007ffff56e8ced in wxAppConsoleBase::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#4  0x00007ffff5d5e780 in wxApp::OnAssertFailure(wchar_t const*, int, wchar_t const*, wchar_t const*, wchar_t const*) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#5  0x00007ffff56e9081 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#6  0x00007ffff56e4d90 in wxOnAssert(char const*, int, char const*, char const*, wchar_t const*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#7  0x00007ffff5d616d2 in wxBitmap::GetPixbuf() const () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0
#8  0x00007ffff641abe0 in wxDataViewBitmapRenderer::SetValue(wxVariant const&) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0
#9  0x00007ffff6422c53 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_adv-3.0.so.0
#10 0x00007ffff2c3c212 in gtk_tree_view_column_cell_set_cell_data () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
...

 

The assertion output to the console is:

 

../src/gtk/bitmap.cpp(1328): assert "IsOk()" failed in GetPixbuf(): invalid bitmap

 

Strangely however if I click Continue repeatedly the icons do display correctly in the list of entity spawnargs, so I'm not sure what bitmaps it is complaining are invalid.

 

UPDATE: Looks like it is the Help icons column that is the problem. Changing lines like this:

 

row[_columns.helpIcon] = hasDescription ? wxVariant(_helpBitmap) : wxVariant(wxNullBitmap);

 

to this:

 

row[_columns.helpIcon] = wxVariant(_helpBitmap);

 

makes the assertion go away (but now the help icons show for properties that don't offer any tooltip help, so it isn't a very useful fix). I guess the problem is that the GTK tree cell renderer doesn't like being invoked with a wxNullBitmap.

 

UPDATE1: Now fixed in Git. However the fix will need testing on Windows because I don't know if the XPM-based wxBitmap constructor is cross-platform (although nothing in the docs indicates it is restricted). The help icons still don't show any tooltip text but I don't know if I am using them wrong.

Share this post


Link to post
Share on other sites

I think this will be the last pre-release build. I'd like to push it out to be able to continue working on other things like my mousetool branch, and maybe some performance improvements. I'll upload pre9 in a few minutes, watch out for it in the first post.

Share this post


Link to post
Share on other sites

I think this will be the last pre-release build. I'd like to push it out to be able to continue working on other things like my mousetool branch, and maybe some performance improvements. I'll upload pre9 in a few minutes, watch out for it in the first post.

 

Thanks!

 

Btw, any idea why sliding planes issue is back again? I thought it was fixed in 1.8.1.

Share this post


Link to post
Share on other sites

Nothing in that code has changed since months or even years, at least not since the last time somebody has attempted to change something in that part of the codebase. It's very very unlikely that the wxWidgets has anything to do with the floating point inaccuracies, isn't it?

Share this post


Link to post
Share on other sites

Nothing in that code has changed since months or even years, at least not since the last time somebody has attempted to change something in that part of the codebase. It's very very unlikely that the wxWidgets has anything to do with the floating point inaccuracies, isn't it?

 

Definitely not. I am just wondering if it was actually ever fixed. I got in touch with ex-Human Head tools developer, who was responsible for Preditor in Prey 2, and he could potentially fix this precision issue by going with doubles vs floats. If there is an interest, we could raise some funds, as I would rather not pay for this fix alone.

Share this post


Link to post
Share on other sites

I already changed DR back from float to double in July 2012. Before that (I think it was 2011) I migrated to floats since using single precision resulted in more than 20% faster rendering. When people were discussing the precision stuff in 2012 (again), I changed it back to double and this is where we are now.

 

I have never looked into the shifting planes stuff myself thoroughly, so I won't do any more changes without properly researching it first.

Share this post


Link to post
Share on other sites

I already changed DR back from float to double in July 2012. Before that (I think it was 2011) I migrated to floats since using single precision resulted in more than 20% faster rendering. When people were discussing the precision stuff in 2012 (again), I changed it back to double and this is where we are now.

 

I have never looked into the shifting planes stuff myself thoroughly, so I won't do any more changes without properly researching it first.

 

It's not about rendering. OpenGL doesn't support doubles (actually I think OGL 4.x does). The double precision is only needed for coordinates and data storage (whether in RAM or on disk).

Share this post


Link to post
Share on other sites

Well, DR is using doubles for everything. And it sounds like the problem is still there, so I'm not sure the issue is about precision only.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...