Compiling miniB3D on Ubuntu and Mac
BlitzMax Forums/MiniB3D Module/Compiling miniB3D on Ubuntu and Mac
| ||
| Are there any tutorials? I tried compiling on ubuntu awhile back and had some trouble, windows needs MinGW, does Mac or Ubunutu need anything? thx |
| ||
| mac needs xcode installed ubuntu or linux in general gcc and the corresponding devel packages |
| ||
| Here's a tutorial: Don't bother? ;) I started The King Is Dead on Ubuntu but kept getting segmentation faults like EdzUp. (It doesn't render right under OSX either, mind -- seriously, unless you absolutely have to do otherwise, stick with Windows.) |
| ||
| reallllyyyy?!! that was kind of one of the primary selling points for minib3d, being cross platform compatible... |
| ||
| Well, did anyone actually care to find the source of the error by testing out? it's not like it doesn't work because it doesn't want to :) |
| ||
| that was kind of one of the primary selling points for minib3d, being cross platform compatible... Well let's bear in mind that it doesn't have any selling points because it's gifted to us not sold. I'm not sure cross-compatibility with Linux is a reasonable expectation when you take into account the myriad varieties and the size of the development team (ie Simon), but you mentioned Ubuntu specifically and it's specifically Ubuntu that has caused a couple of us grief. So I'm just letting you know, because I got a little ways into development before the segmentation faults started appearing.Also, when I say "it" doesn't render right on OSX I mean The King Is Dead doesn't render right right. TKID does some avant garde stuff which, while it technically should work identically on OSX, most projects probably won't miss. I don't want to give the impression that MiniB3D is hopelessly broken on OSX because it isn't, but I'd suggest you develop on Windows in the same kinda way that it's sensible to develop a website against Firefox rather than IE. (Rationale: You want to write for a platform that behaves as expected, otherwise your primary code-base becomes a kludge with a shelf-life -- that being the length of time it takes for the platform to get fixed.) Well, did anyone actually care to find the source of the error by testing out? The flippant answer to that would be "not my job" but the truth is I'd merrily hunt down the problem if I had the time and expertise (I have neither!) Until someone comes along who does, the pragmatic thing to do regarding Ubuntu is advise caution. |
| ||
| Are you sure the problem is miniB3D's and not the driver used on Linux? I ask because miniB3D code is plain openGL, doesn't have anything in particular that should be causing issues per se. Also, I know for sure in Ubuntu 8, 9 or 10, the available drivers for ATI cards (at lease here, for my ATI X1300) are poorly made, at best; even 'vanilla' bmax stuff have difficulties to run at full speed. |
| ||
It does work on Ubuntu 8. Just compiled miniB3D in debug mode, and here's the proof: So, try the "mini-fixes" version... if that doesn't help, then check your drivers. As for Mac, I can't do anything about it - I don't have one. |
| ||
| Nice going, SLotman. |
| ||
| It does work on Ubuntu 8. Just compiled miniB3D in debug mode, and here's the proof: Oh I'll email EdzUp and let him know everything is fine and he can press on, then. High fives all round, especially if we're ignoring: I got a little ways into development before the segmentation faults started appearing If you want to be genuinely useful perhaps, while it's fresh in your mind, you could detail the process you went through to identify and install the required dependencies for BLaBZ so he can give it a punt himself? |
| ||
| especially if we're ignoring: I got a little ways into development before the segmentation faults started appearing I just showed that you CAN run miniB3D modules on Linux. I took one screenshot - but also I ran a sample I made implementing a Bloom filter on that same demo - and it ran pretty well, no problems. I don't know what kind of problem you found - but I tested the "right out of the box" miniB3D, to make sure it worked on Linux. If you want to be genuinely useful perhaps... I just had to install the dependencies required so max can build modules. Nothing fancy needed. To learn how to do that, I went here and basicly followed the several tutorials that exists there, asking questions when I was stuck somewhere - more than a year ago. Today I just copied my miniB3d folder from Windows and hit ctrl+D. The flippant answer to that would be "not my job" but the truth is I'd merrily hunt down the problem if I had the time and expertise (I have neither!) Well, if you really wanted problems solved, the bare minimum you could do was to post a bug report, with a small sample reproducing the problem, or at least showing *where* you program crashed. If you don't say a word, you don't post about it, how do you expect anyone to at least try to solve it? If you look at the miniB3D forum, you'll see I had several problems myself, and asked here for help. Some things I got to solve myself - and I'm no genius at 3d programming, others I had help, and this way miniB3D gets better and better. Isn't that what the open source model is all about? What Linux is all about? |
| ||
| I just showed that you CAN run miniB3D modules on Linux. And I already said I did that. You know how it is -- you mention a problem (any problem) with computers and somebody pops up to say how it works perfectly fine for them, which is nice but ultimately not a great deal of use to those for whom things remain squiffy. Well, if you really wanted problems solved, the bare minimum you could do was to post a bug report...If you don't say a word, you don't post about it, how do you expect anyone to at least try to solve it...If you look at the miniB3D forum, you'll see I had several problems myself, and asked here for help And you'll see likewise for me. Not in relation to this, though, because there was already a thread about it that had gone nearly a year without being addressed so, y'know, pragmatism won out. I had a demo competition to lose. Isn't that what the open source model is all about I don't really want to get into it but, the major projects aside? Atypically, surely? |
| ||
I still don't have any problems, as much as I try - for sure I don't have a "big demo" to test it out yet, but even something like this is working fine: This is casting shadows (projected shadows) and it has a bloom filter on top of it. The floor texture is also code-generated. The model is an animated B3D. So I'm pratically using everything that can be done: multiple cameras, viewports, creating meshes by hand (the shadow uses a custom mesh to 'hug' the receiver), copying the buffer to a texture, scaling... the only thing I didn't do is manipulating textures at pixel level. And you'll see likewise for me. Not in relation to this, though, because there was already a thread about it that had gone nearly a year without being addressed so, y'know, pragmatism won out. I had a demo competition to lose. Could you post a link to this thread? So I can take a look at it? |
| ||
| Sorry to side track a little, slotman can you point to where those shadows came from? They look great and ive never had much luck with shadows so always looking for new paths... Somewhat on topic of first post: just backing up first response, on Mac you just need to install Xcode. I've been working with minib3d on Mac (ppc and intel) as well as windows without any serious structural problems. Based on historical threads I would lean towards drivers as being the primary cause of any problem on Linux before anything else (Linux graphics drivers especially have always given me nightmares) |
| ||
| Could you post a link to this thread? So I can take a look at it? I did some pixmap stuff which then got copied to textures but I don't know if you'd class that as manipulating textures at the pixel level. Thing is, I did that first and only got problems once I started to build on it. Anyway, yeah, you're doing pretty much the whole shebang there -- did you say you were on an ATI card? Looking at EdzUp's thread ( http://www.blitzbasic.com/Community/posts.php?topic=83277#939720 ) it does strike me that Intel gfx chipsets are common to our set-ups. :-/ Edit: ima747 there are some B3D towel shadow examples knocking around if you want something to be chewing on with :) |
| ||
| Sorry to side track a little, slotman can you point to where those shadows came from? They look great and ive never had much luck with shadows so always looking for new paths... I just coded it yesterday ;) Still have plenty to test to see if it's really ok - but so far so good :) That shadow is basic a 512x512 texture, where I render using a second camera just the model, all black - then I apply it to a mesh that 'hugs' the receiver mesh. Based on historical threads I would lean towards drivers as being the primary cause of any problem on Linux before anything else (Linux graphics drivers especially have always given me nightmares) That's exactly my point. Took me a lot of time to get even Ubuntu's own 3D screensavers to work properly. But that are other problems that one wouldn't face on Windows: for example, if you use "CreateTexture" on Windows, the created Texture will be zero filled (all black) but on Linux, it can have all sorts of data, so you should zero the texture manually if you want it all black (this dates to the principle that any memory reserved can have any data on it - on windows apparently it comes zeroed) Other problem may arise by not declaring the variables and using int on everything - this can cause very strange problems. But without any sample code, or a hint of what's causing the issue... it's hard to help. |
| ||
| I did some pixmap stuff which then got copied to textures but I don't know if you'd class that as manipulating textures at the pixel level. It's more or less what I have in mind. Note that on Windows you can pretty much write outside the pixmap memory area, and it wouldn't crash specially on XP or older - but on Linux that would be a big no-no (and nothing to do with miniB3d, it's how the memory is managed on each OS) Thing is, I did that first and only got problems once I started to build on it. Anyway, yeah, you're doing pretty much the whole shebang there -- did you say you were on an ATI card? Looking at EdzUp's thread ( http://www.blitzbasic.com/Community/posts.php?topic=83277#939720 ) it does strike me that Intel gfx chipsets are common to our set-ups. :-/ See what I mean? He couldn't run any demos on Linux - with MiniB3D 0.52. Besides version 0.53, there has been TONS of fixes, all implemented on the "small fixes" version. And that post - as a bug report - isn't useful for anything. He said all demos crashed, but not even *where* it crashed (on which part of the demo, simple matter of running the demo with debug on) Unfortunately I don't have a Intel based chip to test it - the only one I can test is at work - and it has WinXP installed :/ But back to original question: on Linux nothing extra is necessary to use miniB3D - if you can compile mods, and have OpenGL working with hardware acceleration, then it's just a matter of copying miniB3D folder into the mods folder and hitting ctrl+D on the IDE. |
| ||
| Awesome news! :) So linux is a bit of a toss up due to the fact that it depends on whether or not graphics drivers source is available and if anyone took the initiative to get it to work properly, I assume Macs shouldn't be a problem then :) which is a good thing because chances are, if you're a person who uses linux you probably have access to a windows or mac machine |
| ||
| Based on historical threads I would lean towards drivers as being the primary cause of any problem on Linux I wouldn't disagree (except perhaps to note that I didn't have any other problems with gfx on Linux -- not even with screen-savers!) but whether it's the drivers or the kernel the net result is the same. My perspective is that there are a lot of bog-standard Dells out there (the nearest thing to a standard PC?) and crashing on them is therefore particularly undesirable. But without any sample code, or a hint of what's causing the issue... it's hard to help. I'm not maintaining a Ubuntu partion at the moment so I'm not in a position to isolate the problem unfortunately. I'm pretty much reduced to waving my arms and going "There's a problem! Careful now!" |
| ||
| I have got games to compile perfectly on OSX, I have got linux versions working only in a window its full screen that was chugging out segmentation faults. |
| ||
| Things to look out for when re-compiling on Linux are stuff like trying to set a 32bit screen depth when the card only supports 24bit (nvidia do this on some drivers), trying to run something without having installed the relevant 3d driver, and trying to change the resolution to something other than the desktop size when you are using Twinview monitors. The biggest cause of segfaults i've found porting my games across is inconsistent spelling of file names for external media. Linux is case sensitive, so where trying to load "BiGsTuPidFile.BmP" would work on Win or Mac, in Linux it would fail, as you're really looking for "bigstupidfile.bmp". I've never had any trouble re-compiling on OS X. If anything, things seem to run much more consistently across different hardware setups than Windows. Cheers Charlie |
| ||
| Yeah the case sensitivity is a big problem, but the full screen system is a pain in the butt. |
| ||
| TBH, if you're using a Blide solutionto manage your external media on Windows, then the case sensitivity isn't much of an issue. The fullscreen thing is a pain though, as are inconsistent and flaky drivers. Cheers Charlie |
   |