Topic for those intersted in hardware or software accelerated OpenGL[/b]
Guys, I’m not a programmer (actually, I’m a musician), but I really want to create an OpenGL kit for BeOS or Haiku… I just don’t know where to start, which programming language to use, and whom to contact for it to work out… can anyone help me???
Also, if possible, I’d like to try some parallel port for joystick and gamepads, and (a huge workout) a multitrack audio recording software… but this last is too big, and I’m still thinking about recruiting some friends to help me on it…
Waiting for answers,
Diogo Baeder
CPUs are getting rediculously powerful, but would a software-rendering openGL engine be any good? What would it be used for?
Well, first, you should probably learn exactly how OpenGL works, and how people use it…
http://fly.cc.fer.hr/~unreal/theredbook/
This is a very detailed reference that would get you started at writing programs for current OpenGL systems. Once you understand how it works and everything, then I would say keep googling for documentation on how its actually implimented (either using video card hardware or software or whatever). Keep in mind, I know nothing about opengl programming =).
Also, as an avid gamer, I would like to point out that although OpenGL is extremely fast, it isn’t widely used any more in recent games. They are all using Direct3D now for some reason. I know some of the games have an option to switch to opengl mode, but it’s like the “if your computer sucks” button.
Hope this helps.
Edit: Oh yea, most Haiku development, for better or worse, is done in C++. I’m not a huge fan of the language, but it appears to get the job done =P.
While it’s true that DirectX is the common API for games nowadays, all alternative OS’ are more inclined to opengl. Mainly because it has more open source resources with regards to software implementations, hardware programming code, and OS interface mechanisms. DirectX is based on COM which is just nasty. It would probably be the case that a wrapper is used to convert DX calls to Opengl calls. Additionaly V3D developed a beos native library that compiles D3D code into opengl. (note this is at compile time!). One could always write a native D3D driver if you wished. I wouldn’t!
Hm, kinda makes you wonder how alike the structures are between the two protocols. But ya, all quake 3 based games (there’s > 50) are multi-platform and D3D based, at least the newer ones, although some have opengl options in them (ex: call of duty). And (shh) World of Warcraft also has Direct3D as its default engine, but you can change a config file and have it use opengl instead (also a multi-platform game, and a damn big one). I really don’t know much about it, but I have 3 C.S. electives left before I get my degree, maybe I’ll take a course in 3D engines or something.
I know absolutely nothing about these things, but the number of platforms modern games are released for (Windows, PS2, Gamecube, etc) suggests that either they all use D3D or that it is not too hard to port to a different 3D architecture.
Having any 3D support hardware accelerated would be fantastic, and OpenGL is widely used and understood. Mac OSX uses OpenGL for Quartz IIRC.
This might be interesting:
http://www.begroovy.com/archives/000334.html
Welcome to the realtech VRî DirectX Port î Web site.
http://www.v3x.net/directx/index.html
Source Code is available at Source Forge:
RealTech does not work on the BeOS part anymore as far as I can see on the web page… but the Unix part’s could be port-able?
:roll:
i do not know what people like on DirectCrap! the coding model is more object oriented than gl but due to GLs api native you can better wrap it into a REAL OOP structure. besides DirectCrap is sooooooooooo slow compared to OpenGL. although i code my engine to use both systems i’m really not fond of DX… in my eyes, DX is the ‘your pc is crap’ button, not the OGL one.
about software mode: DO IT, REALLY!!
one reason for software mode are incompatibilities. it’s not the first time a 3d acceleration driver bugged on a certain configuration or you are on a laptop without a 3d accel chip (or rather call it, a good chip). software mode allows you to write your game or whatever needs 3d to use the extensions and effects you want even if you are on a machine not having a 3d card offering those features (and most of them are for benchmark hippies and you do not need to throw money out of the window for that). ogl should in fact provide acceleration if present but should not deny working just because it’s absent.
EDIT: and one more thing… try to seriously debug with DX and you will find yourself restarting your locked up pc more often than you can say ‘fuck m$’.
The issue with OpenGL is pretty simple. Software rendering is WAY too slow to be useful. Even on a fast machine. Hardware accelerated rendering is the only useful way to go. But the video card makers have to be willing. They are not willing to release their APIs or source code. That is why the Linux modules are binary only.
Having said that, the best way to get HWOGL is to finish R1 and R2 and attract a ton of users. Who are occasional gamers. When they can do 90% of what they want and have to reboot to Windows only to play games, they will complain to the people who can make a difference - ATI and nVidia. This is exactly what happened with Linux. And it should happen for us, too.
All Linux HW accelerated OpenGL implementations (except the NVidia one) are based on DRI (Direct Rendering Interface). DRI is designed to be independent of X - there is for instance fbdev implementation of DRI : http://www.mesa3d.org/fbdev-dri.html
There are open-source DRI drivers for older ATI, Matrox, 3DLabs, 3Dfx and SIS cards.
So IMO the first step to bringing accelerated OpenGL to Haiku would be porting DRI and the open-source drivers. When the infrastructure is in place it would be much easier for IHVs to port their Linux DRI-based OpenGL drivers to Haiku.
Some insight from the Kernel team on this would be great. Launching a “direct rendering” initiative would have to be tightly knit to the kernel guys. Are the hooks for something like this in place/planned ? Porting Mesa would be nice, but it’s software only…
Mesa version 5.0.1
Philippe Houdoin - Did a port of Mesa back in 2003. This one should be usable in Haiku as well? That should cover software rendring in first place. No?
Then porting DRI and old Open Source drivers seem like a good idea.
An Idea:
How impossible is it to make something that is binary compatible with the Linux Drivers?
Linuxant made something called Driver Loader wich let’s Linux users use Windows Network drivers. (http://www.linuxant.com/company/press_dldr.php) and Vitaliy Timchishin has created WIN32PRN (http://www.gtech-ua.com/vit/en/win32prn.jsp) for OS/2. This one makes Os/2 use Win2k and WinXP printer drivers.
Now I can imagine OpenGL is a bit more “rocket science” than NDIS network drivers and Printer drivers. Not an easy task to do the same for OGL drivers! But impossible?
Harald wrote:
How impossible is it to make something that is binary compatible with the Linux Drivers? ....Not an easy task to do the same for OGL drivers! But impossible?
These drivers are tied to X, so you should port X as well. There are no DRI-only ATI drivers for instance.
I remember back in the time when there were no NVidia FreeBSD drivers there was an effort to port the NVidia kernel module to FreeBSD and build the drivers from the linux object files (nvidia_drv.o) :
http://sourceforge.net/projects/nv-bsd
They had some success running the 2D part but NVidia released official FreeBSD drivers before they could get the 3D working.
Still you’ll need XFree86 so I think this is not an option for Haiku.
BTW, R. Jason Sams (the Be OpenGL guru) now works for NVidia
Quote:
These drivers are tied to X, so you should port X as well.Still you’ll need XFree86 so I think this is not an option for Haiku.
Porting X to get OpenGL to work in Haiku does not seem like the best solution…
But porting X in general and implement it like in OS X where you can launch an X application as if it was a “normal” application would be a great feature. X exist for BeOS today and running it in full screen in one Workspace works, but the way OS X does this is just very nice! 
Well… R2 features… The future… 8)
Harald wrote:
Quote:These drivers are tied to X, so you should port X as well.Still you’ll need XFree86 so I think this is not an option for Haiku.
Porting X to get OpenGL to work in Haiku does not seem like the best solution…
But porting X in general and implement it like in OS X where you can launch an X application as if it was a “normal” application would be a great feature. X exist for BeOS today and running it in full screen in one Workspace works, but the way OS X does this is just very nice!
Well… R2 features… The future… 8)
I would hope that X never comes to haiku… having a working x server just encourages porting shitty unix programs instead of developing native ones that run faster, look better, act like normal apps etc.
Suppafly wrote:
I would hope that X never comes to haiku… having a working x server just encourages porting shitty unix programs instead of developing native ones that run faster, look better, act like normal apps etc.
Every OS has a load of “shitty” applications. One can not say that ALL X applications are “shitty”. I agree there is a lot of bad applications but there is also a lot of good applications written for X. Take the Evolution E-Mail client that support MS Exchange Server mail and calendar as an example.
Edit:
Do not missunderstand, Native apps done the BeOS way would be to prefer! But some X applications are not bad, and being able to run them in a window togher with all other BeOS apps and have full copy/paste and drag and drop functionality btw. BeOS and X apps would indeed be good!
Harald wrote:
Suppafly wrote:I would hope that X never comes to haiku… having a working x server just encourages porting shitty unix programs instead of developing native ones that run faster, look better, act like normal apps etc.
Every OS has a load of “shitty” applications. One can not say that ALL X applications are “shitty”. I agree there is a lot of bad applications but there is also a lot of good applications written for X. Take the Evolution E-Mail client that support MS Exchange Server mail and calendar as an example.
Edit:
Do not missunderstand, Native apps done the BeOS way would be to prefer! But some X applications are not bad, and being able to run them in a window togher with all other BeOS apps and have full copy/paste and drag and drop functionality btw. BeOS and X apps would indeed be good!
Being able to run X applications on Haiku will simply make Haiku play better with other operating systems - it will bring a HUGE load of applications to Haiku just by porting X - it will be done whether people think it should or not. It should be embraced as a compatibility layer for applications where a full native re-write is just not worth it.
Question: Would you rather wait 1 day for someone to port an application you need to use now, or would you rather wait 30+ days for someone to write it from scratch? - if it’s something you plan to use OFTEN, then you’d probably rather it was re-written, and I’m sure if there’s enough interest, it would be… but if it’s just an app to get a one-time job done - maybe once a week, then why bother re-writing it natively…
If we don’t have X, what the heck am I running RDC on?
xbeos -ac
And clunky it may be, but it also means I never have to run Windows on my own machine again. (It stopped booting anyway because I dared to change all my hardware at once.)
Kev
Kev wrote:
If we don't have X, what the heck am I running RDC on?xbeos -ac
And clunky it may be, but it also means I never have to run Windows on my own machine again. (It stopped booting anyway because I dared to change all my hardware at once.)
Kev
Yes, of course BeOS has X now 
- but I suspect it will be “re-ported” for Haiku - in fact, porting *nix software to Haiku will probably be better, as it seems the POSIX compatibility may end up being more thorough than Be ever bothered… eventually.