|
|
|
#1001
9th July 2014, 06:26 PM
|
|||
|
|||
I can change stuff around and recompile if necessary (although that would mean I'd have to set up some form of Visual Studio shfdlkjhdkjfs can has gcc plox? :P jk have to dig around in the source a tad anyway now that I have some freetime
 )Gonna check if I can repro RPGMaster's issues in 1.6 EDIT Nope, 1.6 works just fine here, the fuck is wrong with your OGL Master? You do have the drivers from nvidia's site and are running on it instead of any potential integrated intels are you? Weird stuff Last edited by V1del; 9th July 2014 at 06:37 PM. 
|
|
#1002
9th July 2014, 06:56 PM
|
||||
|
||||
|
Quote:
Anyway, here's some info. GL_VERSION, 2.1.0 - Build 8.15.10.2622 GL_VENDOR, Intel GL_RENDERER, Intel(R) HD Graphics gl_pfd.txt Code:
nSize 0028 nVersion 0001 dwFlags 00008024 iPixelType 00 cColorBits 20 cRedBits 08 cRedShift 10 cGreenBits 08 cGreenShift 08 cBlueBits 08 cBlueShift 00 cAlphaBits 08 cAlphaShift 18 cAccumBits 00 cAccumRedBits 00 cAccumGreenBits 00 cAccumBlueBits 00 cAccumAlphaBits 00 cDepthBits 00 cStencilBits 00 cAuxBuffers 00 iLayerType 00 bReserved 00 dwLayerMask 00000000 dwVisibleMask 00000000 dwDamageMask 00000000 Code:
GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_blend_color GL_EXT_abgr GL_EXT_texture3D GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_SGIS_texture_edge_clamp GL_SGIS_generate_mipmap GL_EXT_draw_range_elements GL_SGIS_texture_lod GL_EXT_rescale_normal GL_EXT_packed_pixels GL_EXT_texture_edge_clamp GL_EXT_separate_specular_color GL_ARB_multitexture GL_EXT_texture_env_combine GL_EXT_bgra GL_EXT_blend_func_separate GL_EXT_secondary_color GL_EXT_fog_coord GL_EXT_texture_env_add GL_ARB_texture_cube_map GL_ARB_transpose_matrix GL_ARB_texture_env_add GL_IBM_texture_mirrored_repeat GL_EXT_multi_draw_arrays GL_NV_blend_square GL_ARB_texture_compression GL_3DFX_texture_compression_FXT1 GL_EXT_texture_filter_anisotropic GL_ARB_texture_border_clamp GL_ARB_point_parameters GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_env_crossbar GL_EXT_texture_compression_s3tc GL_ARB_shadow GL_ARB_window_pos GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_ARB_vertex_program GL_EXT_texture_rectangle GL_ARB_fragment_program GL_EXT_stencil_two_side GL_ATI_separate_stencil GL_ARB_vertex_buffer_object GL_EXT_texture_lod_bias GL_ARB_occlusion_query GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_non_power_of_two GL_ARB_vertex_shader GL_NV_texgen_reflection GL_ARB_point_sprite GL_ARB_fragment_program_shadow GL_EXT_blend_equation_separate GL_ARB_depth_texture GL_ARB_texture_rectangle GL_ARB_draw_buffers GL_ARB_color_buffer_float GL_ARB_half_float_pixel GL_ARB_texture_float GL_ARB_pixel_buffer_object GL_EXT_framebuffer_object GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_EXT_draw_buffers2 GL_WIN_swap_hint GL_EXT_texture_sRGB GL_EXT_packed_float GL_EXT_texture_shared_exponent GL_ARB_texture_rg GL_ARB_texture_compression_rgtc GL_NV_conditional_render GL_EXT_texture_swizzle GL_ARB_sync GL_ARB_framebuffer_sRGB GL_EXT_packed_depth_stencil GL_ARB_depth_buffer_float GL_EXT_transform_feedback GL_EXT_framebuffer_blit GL_ARB_framebuffer_object GL_EXT_texture_array GL_ARB_map_buffer_range GL_EXT_texture_snorm GL_INTEL_performance_queries GL_ARB_copy_buffer GL_ARB_sampler_objects GL_NV_primitive_restart GL_ARB_seamless_cube_map GL_ARB_uniform_buffer_object GL_ARB_depth_clamp GL_ARB_vertex_array_bgra GL_ARB_draw_elements_base_vertex GL_EXT_gpu_program_parameters GL_ARB_compatibility GL_ARB_vertex_array_object Quote:
since other people are bound to have my issues. OpenGL does tend to work terribly on my computer. I think a well coded OpenGL plugin isn't as bad though. 1964 Video before they stripped out OpenGL was really fast (still not as fast as their DX version). It was actually faster than Jabo 1.6 so I was impressed. It's a shame no one bothered to fix a lot of the graphical glitches though. What's ironic is the fact that Rice's OpenGL does certain things better than its DX version lol. I get no stack hash errors and SSB64's intro doesn't desync in PJ64 and Apollo when I use OpenGL instead of DX.Pretty much anytime there's a DX equivalent of that plugin or game, DX always wins in performance lol. That's why I'm probably just going to use Dx or Ddraw when I decide to develop/work on a gfx plugin. I hope I can fix these OpenGL issues I'm having ;/ .
|
|
#1003
9th July 2014, 07:28 PM
|
||||
|
||||
|
Yeah v1del, GCC is good, but MinGW won't remove the Microsoft CRT dependency from the win dll.
 Quote:
Those hundreds of KB will come from statically linking the CRT, even if you use a minimal amount of CRT functions as possible. It's insane...don't static link it. You can save hundreds of KB by either removing the dependency on msvcr*.dll, if possible, or just keeping it as an external DLL dependency. Better yet, if you link using MinGW binutils, it's only dependent on MSVCRT.DLL, not MSVCROVER9001.DLL. Quote:
Where'd the " - Build 8.15.10.2622" come from? That doesn't look like conformant output from an OpenGL context. Are you sure that's the exact text that came from GL_VERSION.txt? Great, so your vendor is Intel. Maybe you just have outdated Intel drivers for OpenGL then. Here is what mine says: Code:
GL_VERSION : 2.1.2 GL_VENDOR : NVIDIA Corporation GL_RENDERER: GeForce 6150 LE/integrated/SSE2 Quote:
Instead mine are: Code:
cAlphaBits 00 cAlphaShift 00 cAccumBits 40 cAccumRedBits 10 cAccumGreenBits 10 cAccumBlueBits 10 cAccumAlphaBits 10 cAuxBuffers 04 I wonder if you get different results, when using an emulator that DOESN'T give you a black screen, than what you pasted from one that does? (or the other way around w/e since you used mupen heh) Quote:
__________________
http://theoatmeal.com/comics/cat_vs_internet
|
|
#1004
9th July 2014, 07:51 PM
|
||||
|
||||
|
Oops, I should have checked the txt files generated when using PJ64. Actually I used 1964, since your plugin works best on it. I implemented a test button on it a while back
. I'll go ahead and see if the results are different for Mupen and PJ64 1.4.That's odd about your exe's being > 100KB. They must be big projects or something lol. For instance my old version of that Banjo Tooie save editor gui frontend was like 66KB, back when I statically linked CRT. When I ran PJ64 1.4 Audio Fix Edition with 256 colors, I got this error message, "No accelerated pixel formats detected!". Then I got an infinite loop of "Problem scaling the frame drawing". I had to exit through task manager ;/ . It didn't matter whether or not I had GPU accelerated scaling. For GL version, I double checked and that's what I keep getting. I also got 2.1.0 - Build 8.15.10.2622 , when using PJ64 1.4. I wonder if upgrading my drivers will solve these issues. Let me know when you're fine with me upgrading my drivers . I don't mind waiting if that allows you to fix issues. I just want to know when your done. I like fixing problems on both ends.Lol I didn't mean to say DX is objectively better than OpenGL in performance, but rather how it works on my specific machine .Edit: LOL. I just clicked the test button in Mupen and got this error. "No suitable pixel format detected on this system.". Last edited by RPGMaster; 9th July 2014 at 07:54 PM.
|
|
#1005
9th July 2014, 08:05 PM
|
|||
|
|||
|
Quote:
 (I was always under the assumption you had an nvidia somewhere, I thought I read that somewhere  ) Yeah try to update that from intels site ogl 2.1 looks way to low for any HD graphics (checks wikipedia: maybe not, whats your cpu model?). If those drivers are still from windows update compat, the issues you're having are even less surprising as microsoft butchers the shit out of OGL on their own supplied drivers + OGL on intel on windows has always not been that optimal anyway (e.g. glide64 on an old Mobile 4 series doesn't run and OGL is locked at 1.3 or some shit on windows, no problems on linux and goes up to 2.1) . OGL support is implemented as part of the driver so it plays a huge role of how you perceive its performance. On nvidias you will see OpenGL outperform directX on certain workloads.EDIT FOR MORE PARTICIPATION: That your GL_VERSION string gets printed out with the build version appended can be normal, just the way intel decided to report the version, nothing that suprising about that, afaik Nvidias version string isn't as plain either on the newer drivers Last edited by V1del; 9th July 2014 at 08:12 PM.
|
|
#1006
9th July 2014, 08:23 PM
|
||||
|
||||
|
V1del, thanks for your feedback and advice. After doing some reading, it all makes sense now. I wonder if any of those OGL glitches I see in Rice Video will be fixed if I upgrade drivers.
Do you know where I can get the binary of the latest Mupen64Plus version of rice? All I can find is the source, but I'm too lazy to compile with gcc .Here's my cpu specs Code:
Processors Information ------------------------------------------------------------------------- Processor 1 ID = 0 Number of cores 2 (max 8) Number of threads 4 (max 16) Name Intel Core i5 480M Codename Arrandale Specification Intel(R) Core(TM) i5 CPU M 480 @ 2.67GHz Package (platform ID) Socket 989 rPGA (0x4) CPUID 6.5.5 Extended CPUID 6.25 Core Stepping K0 Technology 32 nm Core Speed 2926.3 MHz Multiplier x Bus Speed 22.0 x 133.0 MHz Rated Bus speed 2394.3 MHz Stock frequency 2666 MHz Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x L1 Data cache 2 x 32 KBytes, 8-way set associative, 64-byte line size L1 Instruction cache 2 x 32 KBytes, 4-way set associative, 64-byte line size L2 cache 2 x 256 KBytes, 8-way set associative, 64-byte line size L3 cache 3 MBytes, 12-way set associative, 64-byte line size FID/VID Control yes Turbo Mode supported, enabled Max turbo frequency 2933 MHz Max non-turbo ratio 20x Max turbo ratio 22x Max efficiency ratio 9x Max bus number 255 Attached device PCI device at bus 255, device 2, function 1
|
|
#1008
9th July 2014, 08:56 PM
|
||||
|
||||
|
Quote:
And can you tell which gl function call generated the error, if you move the error = glGetError(); line in different locations of the draw_screen_soft function with respect to different opengl function calls preceding it? Quote:
I'd rather find that out for sure though than to lose the chance to see if there is any way to fix it on my end. Quote:
If not, then look where it says this: Code:
formats = DescribePixelFormat(
device_context,
pixel_format_enum,
sizeof(PIXELFORMATDESCRIPTOR),
&test);
Code:
test = pixel_format;
__________________
http://theoatmeal.com/comics/cat_vs_internet Last edited by HatCat; 9th July 2014 at 09:04 PM.
|
|
#1009
9th July 2014, 09:19 PM
|
||||
|
||||
|
rpgmaster, when running DllTest feature off mupen64 did you not receive a warning message before that saying --
"Mismatch between run-time and test pixel formats." And did you also run DllTest while the emulation thread was active, rather than before loading rom? also, at vi.c:194 in draw_screen_soft, remove these lines of the statement: Code:
if (error != GL_NO_ERROR)
DisplayGLError("Problem scaling the frame drawing.", error);
__________________
http://theoatmeal.com/comics/cat_vs_internet
|
|
#1010
9th July 2014, 09:31 PM
|
||||
|
||||
|
Sorry I had to go afk
. I'll go ahead and try the changes you suggest, then I'll go ahead and post the results.With Mupen64, if I go straight to the plugin selection menu after starting the emulator and click test, I get an error saying "No current device context. Try initializing the plugin before testing it.". This isn't a problem because I know that Mupen64 does not initialize plugins until you either load a rom or click on the config button. So what I do is open config once, then close it. Then when I click test, i get that begin testing message box, then the error I posted previously. Ohhh haha now I get it. I only clicked test when not running any games. Now test works! I guess I got into the habit of not testing during emulation, from using your rsp plugin .Quote:
.
|
Linear Mode
All times are GMT. The time now is 09:09 AM.