Blender and gallium on haiku

I built Neverball on Zeta or BeOS and it worked. Pretty sure it played real slow (2 to 3 fps) but was working. That’s why I wanted you to test with BeOS to double check.

I tested out BeOS Quake 3 on gcc2 Haiku and it works but:

  1. the game wants to connect to the internet and is failing with the same message showing over and over
  2. I only get 2 to 5 fps. Very unplayable; too slow.

Quake 3 does not work with gcc4 Haiku! Complains about missing Mesa (OpenGL) renderer. Requires gcc2 renderer.

In the screenshot sikosis was getting 21 fps in Quake3. Wish I knew his hardware setup and settings.

I also downloaded Quake 3 source, made quick fix and compiled it for gcc2 Haiku. Quake3 (Haiku) starts full screen. Has distorted sound and still trying to connect to the internet. Same thing happens with BeOS version. I haven’t spent any time looking into what is going on.

This was quick so I have to spend more time to test it out if I think it is worth it.

Post above slightly updated.

Quake3 actually does have sound. BeOS & Haiku versions have distorted audio but BeOS one is worse with a buzz to it (annoying).

I enabled fastest settings in graphics and was able to get 9 to 14 fps for game play. Still too slow but better than 2 to 5 I had before.

Maybe someone have sources of Quake 3 for BeOS. It would be very useful in future when we will get 3D acceleration via Gallium3D. I mail to the author of this port but he is no answered.

I ask myself, what indicate this advance, is very interesting, how can this help on and what indicate?
If this game can work on haiku why not blender?

I suposse clutter can be in haiku after the 3d come totally implemented.

Has hardware accelerated graphics on haiku made any progress lately, is it any more stable than it was?

Anywhere that offers binaries of the Quake 3 engine for BeOS should be able to give you the source code because it is licensed under the GNU GPL which requires this.

sources are included in the archive:

"Archive contains:

  1. binary for Haiku GCC2 and GCC2 Hybrid
  2. binary for Haiku GCC4 and GCC4 Hybrid
  3. source code "

then if i understand is not posible compile the nouvveu drivers yet?
DRI2, what about it?

No gallium 3D hardware drivers. No nouveau 3D drivers. Because driver has to be ported to Haiku. Just like how the 2D drivers in Haiku have been ported over.

I am guessing long time before you see accelerated 3D on Haiku. No one is working on it from what I can tell.

I have the will but not full knowledge. if somebody help or teach me maybe i can help in this, i know basic know about c++, from avariables to class and objects…but i dont know the logic of drivers o thats things and sincerilly jus low programing knows…but yes i am very interested.
Help! lets get 3d in haiku!
Maybe just can help and future patchs… but i am really ansius about 3d on haiku because alpha2 being useful for many things now.

So you could squash a bug in SDL, to support 3D games

It’s all about 20 lines of code

Necessary knowledge: BGLView and BDirectWindow classes

[quote=tonestone57]No gallium 3D hardware drivers. No nouveau 3D drivers. Because driver has to be ported to Haiku. Just like how the 2D drivers in Haiku have been ported over.

I am guessing long time before you see accelerated 3D on Haiku. No one is working on it from what I can tell.[/quote]

This is a big problem for Haiku. No hardware 3D. But one that needn’t be insurmountable. The answer to this problem lies in completely circumventing the problem itself. In other words… stop trying to write drivers to access hardware accelerated 3D in the video cards we have in our systems that the video card companies aren’t going to ever give us the specs to…

I’m sure you’re scratching your head, going, “What the… huh? How can that possibly solve our problem?”

The answer is simple… if you can’t figure out how to write hardware accelerated 3D drivers for video cards that other’s make… MAKE YOUR OWN VIDEO CARD!

Now, what I propose may seem insane, but it really isn’t. It’s simply creating a work-around solution that will, in all likelihood, provide what we want (playable 3D gaming), in a way that let’s us define exactly what the card can do and how fast it can do it.

Now, before you start telling me that designing a video card takes millions of dollars and fabs to create the chips and all that stuff, let me tell you that the hardware portion of the answer is likely right where you’re reading this and the initial code to make it function is only a download away.

If I have your interest piqued, do reply and/or Email me. You’re not gonna believe the answer… it’s a very primitive solution, conceptually, but (in theory) it should work faster than the current software solution we’re having to use presently.

I just need someone (or a couple people) willing and able to give it a try…

BUT linux have advantage on this, they have drivers for ATI, intel, sis, S3… Nvidia have opensource 3d drivers too, and in this precisly moment it can have at less the mid speed of the video card they support including 3d obviusly with some of bug, but this can be good to start.
I wanna do anything what i can to help in this camp, but need somebody with most experience who ask the things and help to learn for all this process.
I did´nt understand your solution, can u explain me better that?

I think to combat this / get one up on linux we need to focus ALL of our effort in terms of the graphics server on making the generic graphics driver the best it can be. Add a softpipe to the system, get OpenGL/tinyGL up and running. the key lies in a universal solution for graphics. in its current state the generic VESA driver is massively powerful in haiku why not build on that.

what is the suggestion? how to start this? how to implement it?

In what?

making the generic graphics driver the best it can be
Add a softpipe
get OpenGL/tinyGL

The TinyGL in MorphOS definitely seems better than the original. But how is it better than OpenGL? How would it work better as a general solution? If anyone who knows more about the TinyGL used in MorphOS could share the knowledge, it’d be appreciated.

What is needed to port Tinygl?

Only fix compilation issues…

and bring-to-update the current functions

because TinyGL already have an BGLView implementation :smiley:

but Again, it’s better fix SDL+OpenGL issues… I’m not a coder
but I know that with a little effort, this could be done

The source of ArOs Gallium can be useful for haiku? in wich way?