Jump to content

Henri Beauchamp

  • Content Count

  • Joined

  • Last visited

Community Reputation

62 Excellent

1 Follower

About Henri Beauchamp

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ditch every modern editor/IDE: keep using Nedit (or XNedit for people using UTF-8) ! 👴 I have been programing with it in all languages (C, C++, Forth, Perl, Tcl/Tk, JavaScript, Java, Python, PHP, bash, etc), for the past 26 years... And yes, I even made syntax highlighting ”recognition patterns” settings for LSL in Nedit... Seeing how much code I produced with this editor (that also can act more or less like an IDE since you can launch complex commands with it, including compilation), I can tell you it certainly does not harm my productivity. 🚅 And yes, the Cool VL Viewer is ent
  2. Adaptive sync is like VSYNC, but at a variable rate: if you use it, you will NEVER get the maximum frame rate from your games, for the driver inserts pauses whenever the frame renders too soon to be displayed in sync with the next monitor frame. You CANNOT get the best performances in frame rates with adaptative sync of VSYNC. The Cool VL Viewer does not try to switch sync modes on/off, unlike some other viewers. As for tearing, I never saw any here while I have no sync scheme set for my driver: simply use triple buffering and you will be tear-free and with the best frame rates. You are f
  3. And this is just now that you reveal you are using ”adaptive sync”... What happens when you turn it off ? Mind you, when in adaptive sync mode, the driver may purposely slow down the frame rate in order to better sync with the monitor... And like I explained, the default field of view in the Cool VL Viewer is NOT the same as in other viewers... You must edit the corresponding debug settings (CameraOffsetDefault for the Cool VL Viewer and CameraOffsetRearView for Firestorm) to get them to match exactly, or you will get a different amount of objects in the FOV, meaning a different load f
  4. Look, I just made another test, in Aditi, in an empty sim so to avoid different surrounding avatars in different viewer sessions, but with some scenery so that it does tax the renderer. The sim is Moonberry Bay, at pos 117,181,21 (on the pier, looking SW towards the shore). All settings to the max (with specific settings in both viewers set so they are the same, i.e. mesh multiplier LoD factor set to 1.0 and Classic clouds off in Cool VL Viewer, Render LOD Factor limited to 3 and terrain details LoD to 2 in Firestorm), 512m draw distance, camera angle set the exact same way (this is super impo
  5. Thing is, you are the only one to get these results... I could post mine here (that are in total contradiction, and on 4 different PCs, ranging from a super old Althon64 + Radeon 9700 to a brand new 9700K + GTX 1070 Ti), but this would be off-topic... Just like this post of yours. I told you on my forum that your system probably had an issue with the frequency or power governor and/or with the BIOS settings for the max package power and/or max socket current...
  6. Dead easy to prove you wrong here. Get the Cool VL Viewer, wait for every texture to load (switching renderers while some load might get them in the wrong texture channel), then switch on/off ”Extended environment shaders” in the graphics settings (not touching anything else), and observe the frame rate...
  7. I strive to stay on par with LL's latest (often not even yet released) changes, and every modification to the EE renderer gets backported in the Cool VL Viewer (and with weekly releases, the changes in LL's git appear only a few days later in the next Cool VL Viewer release); that's why you see different results in the EE renderer of my viewer when compared with other viewers with a slower release rate. This said, as I already wrote in this thread, EEP (P for ”project”, and it will stay as such (i.e. not of actual release quality) for a loooong time, I'm afraid) has been ”released” way to
  8. LOL ! The Cool VL Viewer is probably the fastest viewer around (the main loop is about 50% faster than LL's viewer and 40% faster than Firestorm's)... Singularity may sometimes equal it, but all others are MUCH slower. If it is ”sluggish” for you, it is probably a problem with the settings. You can only compare viewers when using the exact same settings in the exact same conditions... Benchmarking is an art...
  9. I'm afraid such benchmarks are not very significant, unless you know for sure the sims are running on the same hardware (especially with the same CPU power) sharing the same load (number of sims per server, RAM usage to avoid swapping, etc), and (if applicable) using the same virtualization software/hypervisor... Too many unknown variables for us: only LL devels/admins can perform such benchmarks in a proper/deterministic way.
  10. My avatar was already wearing 80+ scripts... Adding more scripts of mine won't change things much, for my scripts are well optimized (especially in the memory usage (most important for sim crossing) and events processing departments) ! 😜 I'd need to add badly scripted stuff to my Aditi inventory... But feel free to use by yourself the same method as the one I described. 💭
  11. Yep, seems working just fine now. Did it flying (avatar fly only) with a ”mildly heavy” avatar (25 attachments, around 80 scripts capped at around 3Mb of RAM): But you should change the permissions of the gift it gives, because I also got: 😜 Here are the region crossing times I got from the viewer log: Personal test: 2020-07-28T15:13:18Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 435.148 ms 2020-07-28T15:13:34Z INFO: LLVOAvatarSelf::updateRegion: Region crossing took 393.159 ms 2020-07-28T15:13:59Z INFO: LLVOAvatarSelf::updateRegion: Region cros
  12. Greetings, I just discovered this new testing ground yesterday and gave it a try. While flying (avatar ”Fly”, i.e. not flying any scripted plane or such), most Blake* regions crossings were flawless (with at worst a split second ”hiccup” at crossing), but I did notice strange things, such as regions visible/active on map and invisible/inactive on mini-map and not accessible via crossing from other regions (while it was possible to TP into some). It was late in the night for me, however, so I did not take any note of time and region names. Today, I gave it another try and stumbled upo
  13. Thing is: we know strictly nothing about Apple's future custom GPUs (since they plan to do away with NVIDIA and AMD and to use their home-made silicon chips)... Open Source is far from being the characteristic of Apple's ecosystem, and nothing can give us a single clue wether their future GPU will have an open (as in at the very least *documented*) API or will need reverse-engineering to add Open Source Vulkan compatibility layers...
  14. It's going to be a close-to-impossible task... Unless Apple finally decides to adopt a Vulkan compatibility layer for their future ”Metal GPU”... LL has recently added a Vulkan detection feature to the statistics sent by the viewer to their server (i.e. the info whether your system got support for Vulkan or not is sent together with the stats the viewer reports to the SL severs). Obviously the preliminary evaluation for the feasibility of a Vulkan port. Transitioning from OpenGL to Vulkan would allow to make the viewer renderer multi-threaded and (at last) benefit from the many-cores
  15. I don't see it ”canned” any time soon (and never in my viewer !)... You are probably confusing the possibility to disable ”basic shaders” (now removed from the EE renderer), but those would only affect pre-v2.1 OpenGL, and the WL renderer already could not render things correctly with basic shaders off. As for deferred rendering (AKA ALM), I personally dislike it a lot and pretty much never use it myself: it makes everything look blurry and gloomy while non-deferred rendering is crisp and vibrant. Not to mention a lowered FPS rate in ALM, which becomes even more critical with the EE rende
  • Create New...