well sorry but i dont see any harm i have edited the shader to be completely different and there is no rule against this and how is this hypocritical?
1. It's not "completely different", it's barely different at all internally. 2. It's hypocritical because you're taking Chocapic's code (which allows for you to modify and redistribute it), changing it slightly, then telling others they are not allowed to modify and redistribute it. Chocapic has been gracious enough to allow for that privilege, which you are then not extending to others.
Chocapic, I'm a massive fan of your shaders and I can understand wanting reimbursement for your hard work, but adfocus is the wrong way to do that. I've had only bad experiences with that site, including malicious pop-ups and new tabs being opened onto harmful websites that can't be closed conventionally, and I'm definitely not alone there. Adfly, while annoying, is far better for the end-user experience and poses a much smaller threat, especially for those who aren't so bright.
GLSL is the language the shaders use. Even Mojang coded their default shaders with GLSL. Currently there are no other mods that add these effects to the game (that I know of), and if it does exist, it most likely won't have the same support.
Actually, fun fact, Minecraft doesn't currently use a shaders-based rendering system, but they are planning to for 1.9+
I added a lite version which works faster than v4-lite and as fast as sildurs basic shaders but i'm not 100% sure it works on intel integrated gpus, I think my driver is outdated and I can't update it thanks to toshiba's custom drivers. There's no syntax errors so it should work if your driver is up to date.
I fixed lens flares on moon too (will be added to others version when i'll have the stength to copy pasta 1 line of code and reupload).
I recommand to turn off Oldlighting (shaders settings) and set Smooth lighting level to +-80% with this version. With the others versions set it to +-60%. It "burn" less the textures with the gamma correction.
Any chance we can get the name of the resource pack being used in the screenshots?
ICYMI, Sonic Ether has been working on some new features for this shaderpack... more specifically, volumetric clouds. He's posted some previews here and here.
While the idea of passing the "block type" to a shaderpack is fairly neat in concept, I can guarantee that most mods would not use it which would then nullify any use for it in a legitimate modded instance. I just wish the shaders mod would have a method for getting the string ID of a block rather than it's int ID. Hopefully the 1.8 version will bring support for that since (as far as I know) 1.8 secludes int IDs to the internals only.
I haven't updated, missed the last 2 or 3 driver releases on my 780ti.
I was browsing some different shaderpacks, and came across this a few days back (had to dig to hunt it down) but it jogged my memory:
I'm using the latest beta drivers, so that could be the cause. To be honest though, I haven't gotten that crash in about a month, so it might be fixed.
I've tried several things but after a few minutes, the game crashes all the time.
# # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffeb30b3924, pid=7000, tid=7600 # # JRE version: Java(TM) SE Runtime Environment (8.0_25-b18) (build 1.8.0_25-b18) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [OPENGL32.dll+0xe3924] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #
--------------- T H R E A D ---------------
Current thread (0x00000000031d3800): JavaThread "Client thread" [_thread_in_native, id=7600, stack(0x00000000030d0000,0x00000000031d0000)]
Instructions: (pc=0x00007ffeb30b3924) 0x00007ffeb30b3904: cc cc cc cc cc cc 66 0f 1f 44 00 00 8b 05 f2 d6 0x00007ffeb30b3914: 00 00 83 f8 40 73 0f 65 48 8b 04 c5 80 14 00 00 0x00007ffeb30b3924: ff a0 38 0a 00 00 b8 47 01 00 00 e9 ec d4 ff ff 0x00007ffeb30b3934: cc cc cc cc cc cc 66 0f 1f 44 00 00 8b 05 c2 d6
Register to memory mapping:
RAX=0x0000000000000000 is an unknown value RBX=0x0000000028ba6e90 is an unknown value RCX=0x0000000000000001 is an unknown value RDX=0x0000000028ba6e90 is an unknown value RSP=0x00000000031cb268 is pointing into the stack for thread: 0x00000000031d3800 RBP=0x0000000000000000 is an unknown value RSI=0x0000000000000000 is an unknown value RDI=0x0000000023bd1d10 is an unknown value R8 =0x0000000000000000 is an unknown value R9 =0x00007ffe9c5c0000 is an unknown value R10=0x0000000028bc03e0 is an unknown value R11=0x0000000028bc03e0 is an unknown value R12=0x00000000288553a0 is an unknown value R13=0x0000000028855358 is an unknown value R14=0x0000000028ba62f8 is an unknown value R15=0x000000003ed02600 is an unknown value
VM Mutex/Monitor currently owned by a thread: None
Heap: par new generation total 118016K, used 45214K eden space 104960K, 35% used from space 13056K, 61% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1104837K Metaspace used 78361K, capacity 79089K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K
GC Heap History (10 events): Event: 195.198 GC heap before {Heap before GC invocations=299 (full 39): par new generation total 118016K, used 111240K eden space 104960K, 100% used from space 13056K, 48% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1101376K Metaspace used 78275K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K Event: 195.202 GC heap after Heap after GC invocations=300 (full 39): par new generation total 118016K, used 8058K eden space 104960K, 0% used from space 13056K, 61% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1101376K Metaspace used 78275K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K } Event: 196.781 GC heap before {Heap before GC invocations=300 (full 39): par new generation total 118016K, used 113018K eden space 104960K, 100% used from space 13056K, 61% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1101376K Metaspace used 78302K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K Event: 196.785 GC heap after Heap after GC invocations=301 (full 39): par new generation total 118016K, used 8811K eden space 104960K, 0% used from space 13056K, 67% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1102198K Metaspace used 78302K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K } Event: 198.532 GC heap before {Heap before GC invocations=301 (full 39): par new generation total 118016K, used 113771K eden space 104960K, 100% used from space 13056K, 67% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1102198K Metaspace used 78314K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K Event: 198.536 GC heap after Heap after GC invocations=302 (full 39): par new generation total 118016K, used 8226K eden space 104960K, 0% used from space 13056K, 63% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1103360K Metaspace used 78314K, capacity 79025K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K } Event: 200.863 GC heap before {Heap before GC invocations=302 (full 39): par new generation total 118016K, used 113186K eden space 104960K, 100% used from space 13056K, 63% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1103360K Metaspace used 78339K, capacity 79089K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K Event: 200.867 GC heap after Heap after GC invocations=303 (full 39): par new generation total 118016K, used 7822K eden space 104960K, 0% used from space 13056K, 59% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1104615K Metaspace used 78339K, capacity 79089K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K } Event: 203.286 GC heap before {Heap before GC invocations=303 (full 39): par new generation total 118016K, used 112782K eden space 104960K, 100% used from space 13056K, 59% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1104615K Metaspace used 78353K, capacity 79089K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K Event: 203.290 GC heap after Heap after GC invocations=304 (full 39): par new generation total 118016K, used 8068K eden space 104960K, 0% used from space 13056K, 61% used to space 13056K, 0% used concurrent mark-sweep generation total 2325148K, used 1104837K Metaspace used 78353K, capacity 79089K, committed 79488K, reserved 1118208K class space used 10170K, capacity 10343K, committed 10368K, reserved 1048576K }
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.25-b02) for windows-amd64 JRE (1.8.0_25-b18), built on Oct 7 2014 14:25:37 by "java_re" with MS VC++ 10.0 (VS2010)
Well, if we're all complaining about GUIs here... Seriously though, I really wish you'd texture the sliders for the options menu. It's really odd trying to adjust the render distance and audio without the sliders.
So I'm pretty new to this but I'll just get right to it. I finally got a bulky enough computer to handle this mod (I have a Nvidia Geforce) so I'm pretty familiar with that side of things now, and the render is amazing! but I'm getting these glitches that started happening after I allocated an extra gig to minecraft. I'll post some pics:
It also looks like the spruce logs are wavy instead of the leaves being wavy. Also grass doesn't move. I know how to go into the composite.fsh file and turn on volumetric clouds, do I have to do something similar for the grass and spruce trees?
Most of these are known issues with the 1.8 version of shaders. If you want a stable experience, use the 1.7.10 version.
Hmm, which version of MC are you running? 1.7.10 or 1.8?
How much RAM is in your machine? Which nV card, specifically? Do you know the driver version?
If you have allocated 100% of your RAM, you aren't leaving anything for ShadersMod or Windows. ShadersMod allocates its memory outside of Minecraft, so, if there isn't anything left -- I could see why things might be missing. Plus your machine would lag like mad..
Which shaderpack are you running? Might be SEUS, judging by the clouds, but could be Chocapic/Sildur.. The shadows don't look like SEUS, unless the ShadowRes was turned down..
It's SEUS, he's probably using one of the lower-quality versions.
Thanks for the answer.
On a side note, do you know how to add mod leaves & grass to the waving shader?
Technically... yes... but since the block waving system uses block number IDs (as opposed to string IDs) the blocks will not wave in different worlds. Plus, it does require a small bit of programming knowledge to understand what to do.
0
1. It's not "completely different", it's barely different at all internally. 2. It's hypocritical because you're taking Chocapic's code (which allows for you to modify and redistribute it), changing it slightly, then telling others they are not allowed to modify and redistribute it. Chocapic has been gracious enough to allow for that privilege, which you are then not extending to others.
1
1
Actually, fun fact, Minecraft doesn't currently use a shaders-based rendering system, but they are planning to for 1.9+
0
You're using the SEUS 10.2 preview found here?
0
Any chance we can get the name of the resource pack being used in the screenshots?
0
It's actually just a bug in SEUS, karyonix posted a fix here.
0
0
While the idea of passing the "block type" to a shaderpack is fairly neat in concept, I can guarantee that most mods would not use it which would then nullify any use for it in a legitimate modded instance. I just wish the shaders mod would have a method for getting the string ID of a block rather than it's int ID. Hopefully the 1.8 version will bring support for that since (as far as I know) 1.8 secludes int IDs to the internals only.
0
I'm using the latest beta drivers, so that could be the cause. To be honest though, I haven't gotten that crash in about a month, so it might be fixed.
0
I get that error from time-to-time, try restarting your computer. Usually fixes it for me.
0
1
Most of these are known issues with the 1.8 version of shaders. If you want a stable experience, use the 1.7.10 version.
It's SEUS, he's probably using one of the lower-quality versions.
0
Technically... yes... but since the block waving system uses block number IDs (as opposed to string IDs) the blocks will not wave in different worlds. Plus, it does require a small bit of programming knowledge to understand what to do.
0
Probably not, since Botania uses all sorts of custom rendering techniques, it's bound to have incompatibilities with the GLSL Shaders Mod.
0