Go Back   Project64 Forums > General Discussion > Open Discussion

Reply
 
Thread Tools Display Modes
  #1001  
Old 9th July 2014, 06:26 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

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.
Reply With Quote
  #1002  
Old 9th July 2014, 06:56 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

Quote:
Originally Posted by HatCat View Post
You could use 2 or 2,000,000 CRT functions; it won't matter. If you're statically linking the CRT, it will be the same file size added.

In fact if anything, using CRT functions allows for SMALLER file size than using the Win API functions, since you have to do less pushes/pops given a smaller amount of function arguments to work with. I sometimes do forced-noinline functions for this purpose, like that DisplayError NOINLINE function. It's designed to end up calling win32 MessageBoxA anyway, but to only accept 1 argument, not 4. So it's smaller file size in exchange for insignificant performance sacrifices when there is an error to show. Actually if anything it's faster performance because it's smaller code, at least enough to outweigh such a trivial performance "sacrifice".

dem txt files I asked you for in that PM or it didn't happen!!
Actually, at least with MSVC it does matter how many CRT functions you use. I believe it only links the stuff you need. I remember in my older GUI projects where I statically linked CRT, I decreased my exe by a few KB, just by replacing sprintf with my own string to int conversion function. I'll have to check up on that NOINLINE method. I never thought of calling a function that calls winapi functions lol.

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
gl_ext.txt
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:
Originally Posted by V1del View Post
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
Lol ikr? I do know that my drivers are outdated. HatCat wants me to wait until he fixes the problems though 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 ;/ .
Reply With Quote
  #1003  
Old 9th July 2014, 07:28 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Yeah v1del, GCC is good, but MinGW won't remove the Microsoft CRT dependency from the win dll.

Quote:
Originally Posted by RPGMaster View Post
Actually, at least with MSVC it does matter how many CRT functions you use. I believe it only links the stuff you need.
You're sure? Then why does any EXE I've ever built with MSVC version XXX, grow an extra 100/200 KB in file size, when statically linking MSVCR?

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:
Originally Posted by RPGMaster View Post
Anyway, here's some info.
GL_VERSION, 2.1.0 - Build 8.15.10.2622
GL_VENDOR, Intel
GL_RENDERER, Intel(R) HD Graphics
What's up with the version?
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
You should get different results if you tell Windows to run Project64 in 256-colors mode. You should get a GL_VERSION of 1.1.0 and a vendor of "GDI Generic" or something like that. Also make sure GPU-accelerated scaling is off. Now with 256 colors mode, do you still get a black screen in pj64 1.6?

Quote:
Originally Posted by RPGMaster View Post
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
You have the exact same output as I do except for what I highlighted in red in your paste.

Instead mine are:

Code:
cAlphaBits
	00
cAlphaShift
	00
cAccumBits
	40
cAccumRedBits
	10
cAccumGreenBits
	10
cAccumBlueBits
	10
cAccumAlphaBits
	10

cAuxBuffers
	04
But everything else in your gl_pfd.txt, matches mine.
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:
Originally Posted by RPGMaster View Post
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.
Smoke weed every day.
Reply With Quote
  #1004  
Old 9th July 2014, 07:51 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.
Reply With Quote
  #1005  
Old 9th July 2014, 08:05 PM
V1del V1del is offline
Project Supporter
Senior Member
 
Join Date: Feb 2012
Posts: 442
Default

Quote:
Originally Posted by RPGMaster View Post
GL_VERSION, 2.1.0 - Build 8.15.10.2622
GL_VENDOR, Intel
GL_RENDERER, Intel(R) HD Graphics
Well that explains quite some things (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.
Reply With Quote
  #1006  
Old 9th July 2014, 08:23 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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
I really should get used to gcc. Maybe I'll learn how to use it this week.
Reply With Quote
  #1007  
Old 9th July 2014, 08:48 PM
zuzma zuzma is offline
Junior Member
 
Join Date: Jan 2013
Posts: 28
Default

I guess I can't post links? Anyway if you type mxe daily builds bitbucket into google the first link should be binaries of mupen64plus with the plugins.
Reply With Quote
  #1008  
Old 9th July 2014, 08:56 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

Quote:
Originally Posted by RPGMaster View Post
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.
But what's the title of the window that says "Problem scaling the frame drawing"? I don't care about results with GPU-accelerated scaling; keep that option disabled constantly for now. Was it GL_INVALID_OPERATION?

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:
Originally Posted by RPGMaster View Post
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 hear ya, I just haven't run out of options yet...but who knows, maybe you upgrading your drivers is the only way

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:
Originally Posted by RPGMaster View Post
Edit: LOL. I just clicked the test button in Mupen and got this error. "No suitable pixel format detected on this system.".
That's absurd. You didn't get any warning message pop-ups BEFORE it threw you that error?

If not, then look where it says this:
Code:
    formats = DescribePixelFormat(
        device_context,
        pixel_format_enum,
        sizeof(PIXELFORMATDESCRIPTOR),
        &test);
... try adding before that statement, this
Code:
    test = pixel_format;

Last edited by HatCat; 9th July 2014 at 09:04 PM.
Reply With Quote
  #1009  
Old 9th July 2014, 09:19 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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);
That should take care of your "Problem scaling the frame drawing." error when GPU-accelerated scaling is not turned on. I find it weird that you get that error when running in 256 colors mode, because I don't...you must have a different GDI driver than I do. Again, please post GL_VERSION/VENDOR/etc when running in 256 colors mode this time.
Reply With Quote
  #1010  
Old 9th July 2014, 09:31 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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:
Originally Posted by zuzma View Post
I guess I can't post links? Anyway if you type mxe daily builds bitbucket into google the first link should be binaries of mupen64plus with the plugins.
You need more posts to be able to post links. Thanks for the quick answer though .
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 09:09 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.