#21  
Old 27th March 2015, 04:19 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by V1del View Post
@EGL
Afaik you can use it with normal OGL, at least them specs pg 42 suggest so, and also read the announcements of 1.5 couldn't find the specfile for some reason though, and they also mentioned improvements with normal OGL contexts and with Wayland around the corner I'd think they are somewhat interested in having the power of normal OGL available on desktops and stuff
I know that if you're on an AMD card, you can have a native EGL implementation as well as OpenGL ES:
http://developer.amd.com/tools-and-s...opengl-es-sdk/

I tried to get it working and to get ExtremeDude2 (who does have an ATI Radeon) to compile it for me, but I could never test with it on my NVIDIA-only access. NVIDIA, they make OpenGL ES access go through WGL extensions but not through EGL. And I have no idea what Intel is doing, though they mentioned eventually having an implementation of OpenGL ES for Linux.

If we do get a native EGL implementation on Windows I'd really like to check how it is. Maybe I can use it with Mesa3D then or something (which I still need to figure how to compile with the wayland acceleration support in it >.<).

Quote:
Originally Posted by V1del View Post
Dafuq why was my post so late, anyway I can somewhat vouch for Intel OGL drivers being better especially for older cards, my 2007 ass core 2 duo notebook stopped OGL driver support at 1.4 or someshit and on linux it went up to 2.1 and could do z64gl and glide64 easy which both led to a blackscreen on win lol
really lol?

I always just figured they'd rather give a shit about DirectX. I read somewhere actually they're planning to drop support for deprecated OpenGL functions in their Linux drivers (dunno which ones yet or if they really only mean Linux). Other than that though I haven't heard anyone give a shit about the deprecation model in OpenGL 3.0 or removing functions.
Reply With Quote
  #22  
Old 27th March 2015, 08:19 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Default

Quote:
Originally Posted by HatCat View Post
It's not at all important to learning OpenGL itself though.
I didn't even want to learn GLX, but there I was on my Internet-less laptop, with no GLUT, free GLUT, SDL, or any way to install them to my libraries to slack around the context creation problem for me. So I had to learn GLX!

But if you don't have to learn the shit then don't; I'd say just focus on OpenGL.
I just like using low level API's. You're right that I should just focus on OpenGL. If Linux ends up fixing my issues, then WGL certainly isn't that important . I may learn GLX, if it goes well.
Quote:
Originally Posted by HatCat View Post
lol didn't I say all you need to know how to do is drag and drop a slider scale for how much of Windows versus nix is partitioned to your hard disk?

As long as your disk isn't 100% full AND vacated by the same partition, there shouldn't be anything stopping you from having a Linux distro within minutes.
I just have a habit of nitpicking too much sometimes. I just spent a while cleaning up my PC, so I think I'm good to install Linux now. Just need to do research on a few things before I start, like what distro. I also need to figure out what my emulator setup will be. Also I'll need to find a good debugger, since I may end up working on z64gl if my problems are solved .
Quote:
Originally Posted by V1del View Post
Well there's still wine for that windows craving, and emulators being emulators and not often really all that dependent on obscureass windows api, usually work fine.
I'm not too optimistic about wine, but might as well try it.
Quote:
Originally Posted by V1del View Post
And you could also do a dual boot if you have some spare HDD space, best of both worlds
Ya I think I will do a dual boot.
Quote:
Originally Posted by V1del View Post
anyway I can somewhat vouch for Intel OGL drivers being better especially for older cards, my 2007 ass core 2 duo notebook stopped OGL driver support at 1.4 or someshit and on linux it went up to 2.1 and could do z64gl and glide64 easy which both led to a blackscreen on win lol
Thanks for the feedback. That certainly is encouraging . I don't expect the version number to go higher, but just fixing HW specific issues would be nice. Maybe a performance boost too.
Reply With Quote
  #23  
Old 27th March 2015, 03:14 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by RPGMaster View Post
I just like using low level API's. You're right that I should just focus on OpenGL. If Linux ends up fixing my issues, then WGL certainly isn't that important .
Yeah but when writing test applications it just starts to become tedious.

If you're doing like an emulator library or something then low-level APIs make sense to reduce excessive dependencies, but if you're just trying to test OpenGL code under a recognized, conventional context/framework then it's just time-consuming to keep typing it out in WGL every time, especially when nothing about debugging OpenGL is Windows-bound necessarily and could apply to the need to debug it outside of WGL or Windows.

Quote:
Originally Posted by RPGMaster View Post
Just need to do research on a few things before I start, like what distro.
nobody answer that.

linux distro flaming goes on irc not vBulletin

Quote:
Originally Posted by RPGMaster
I also need to figure out what my emulator setup will be.
That's something you would worry about after getting distro to boot.
mupen 0.5 works fine, also if you don't need the plugin environment you can get libretro mupen under retroarch

Last edited by HatCat; 27th March 2015 at 03:18 PM.
Reply With Quote
  #24  
Old 29th March 2015, 08:14 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Default

Quote:
Originally Posted by HatCat View Post
Yeah but when writing test applications it just starts to become tedious.

If you're doing like an emulator library or something then low-level APIs make sense to reduce excessive dependencies, but if you're just trying to test OpenGL code under a recognized, conventional context/framework then it's just time-consuming to keep typing it out in WGL every time, especially when nothing about debugging OpenGL is Windows-bound necessarily and could apply to the need to debug it outside of WGL or Windows.
I generally don't mind using stuff like stdlib when writing test applications or quick tools that are made for the purpose of saving time. Now that I confirmed Linux runs z64gl better on my machine, I don't think I will bother much with OGL development on Windows. I may test things and practice here and there, but it's just too frustrating dealing with the issues I have.
Quote:
Originally Posted by HatCat View Post
mupen 0.5 works fine, also if you don't need the plugin environment you can get libretro mupen under retroarch
I absolutely need the plugin environment ! I'll have to try getting mupen64 0.5 to work. Was not pleased with m64p. Does it show VI/s in mupen64 0.5 in Linux?
Reply With Quote
  #25  
Old 31st March 2015, 02:15 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

Quote:
Originally Posted by RPGMaster View Post
Now that I confirmed Linux runs z64gl better on my machine, I don't think I will bother much with OGL development on Windows. I may test things and practice here and there, but it's just too frustrating dealing with the issues I have.
Linux is home base for GL dawg.

Usually I just do it with WGL on Windows as well anyway just for portability tests.
If it's more likely to be broken on Windows then it interests me in having things to fix.

Quote:
Originally Posted by RPGMaster View Post
I absolutely need the plugin environment ! I'll have to try getting mupen64 0.5 to work. Was not pleased with m64p. Does it show VI/s in mupen64 0.5 in Linux?
I don't remember it showing the speed rates in mupen64 0.5 either, so I guess this was more of an addition to the Windows port of Mupen64 0.5. I never noticed that it was missing so didn't think too much of it, but I suppose it shouldn't be too hard to regularly report back on the VI/s in the console buffer every [few] seconds.
Reply With Quote
  #26  
Old 31st March 2015, 02:47 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,029
Default

Quote:
Originally Posted by HatCat View Post
Usually I just do it with WGL on Windows as well anyway just for portability tests.
If it's more likely to be broken on Windows then it interests me in having things to fix.
I agree with this, but it just sucks when you can't find an ideal solution. I may try investigating z64gl to see why it's bugged for me in Windows.
Quote:
Originally Posted by HatCat View Post
I don't remember it showing the speed rates in mupen64 0.5 either, so I guess this was more of an addition to the Windows port of Mupen64 0.5. I never noticed that it was missing so didn't think too much of it, but I suppose it shouldn't be too hard to regularly report back on the VI/s in the console buffer every [few] seconds.
Aww man . Guess I have no choice but to tweak mupen's source then.
Reply With Quote
  #27  
Old 31st March 2015, 03:37 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

z64gl uses SDL to initialize the OpenGL context I think, at least on nix.

I know I was forced to add SDL code to my angrylion plugin to fix the window message queue issue for sending keystrokes to the controller plugin on Linux, so maybe by enabling the SDL code on Windows when compiling it could give a better 1:1 comparison when checking your Intel driver support on both systems.
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 04:40 AM.


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