|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | OpenGL on m68k (Mesa) status (Read 14283 times) | ||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
on: January 13, 2025, 04:19
I was able to build it and run several examples. The first three screenshots here are running in BasiliskII: http://macintoshgarden.org/apps/mesa-graphics-library (Also built on PPC and remaining screenshots are from there). There seems to be a bug in the GLUT add-on library which caused some of the examples to fail. I have an idea how to fix it. (It is related to CodeWarrior's PowerPlant, which it uses). I haven't tested on real hardware yet, but expect it to be Pretty Dang Slow(tm). It was passable but slow in Basilisk on a fast host. So don't get any hopes up for games...it is 100% not accelerated, as there is no 3d hardware for m68k that is commonly known (and maybe none was ever made). Because of the amount of pixels needed to be pushed, there is no way around this, other than some sort of insanely fast 68k compatible cpu. But, for what it's worth, it exists, so we have it in our toolbelt, at least. ---- The Mac specific part is called AGL, and it is very close, but not the same as Apple's OpenGL 1.1+ for PPC. It may have been based on version 1.0, I'm guessing. It doesn't replace or conflict with Apple's OpenGL, as the shared library names are different, and it is missing some functions that Apple's has. The M68k version is CFM shared libraries only, I've made a little effort/progress at including it in the nascent m68k SDL I've been working on, but don't know what I'm doing and running into shared library issues. Even if I got it to work, I don't expect it to be useful, due to lack of speed, but am trying "because it's there". |
||||||||||||||||||
Last Edit: January 13, 2025, 04:21 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #1 on: January 13, 2025, 17:34
|
I added some more explanation of the issues I ran into building it to the comments on the MG page. It does NOT build "out of the box" using the version of CodeWarrior the readme tells you to use and the supplied project files, without the tweaks I mention. I tried building with newer versions of CodeWarrior, but immediately ran into PowerPlant problems. It seems many (all?) versions of PowerPlant were supplied as source only, and so you built it along with your application. This was the case when I was building Goliath for m68k. Because it changed with each version of CW, it means you really need to use the EXACT version of CW (or at least PowerPlant) that an application uses, if you have any real hope of success. FYI For Goliath, I actually used a copy of a newer version of PowerPlant, with an older version of CW. This, surprisingly, worked well. So, one possibility for building Mesa using newer versions of CW would be to use the older PowerPlant (the opposite of what I did for Goliath). I might try this. At the same time, if you actually WANTED TO USE Mesa in a project, you just need the headers and the built shared libraries. This is what I'm going to try for m68k SDL. (So Mesa built with CW1, SDL built with CW6). Mesa does not support static libraries for m68k, which means if you want to use it, your app has to be CFM-68k. This complicates things, at least I'm running into goofy problems with SDL. ---- I tried uploading a built copy of Mesa m68k using HotLine, so you guys could see how fast (slow) it runs, but was foolishly running in Basilisk and so predictably crashed. Please ignore the probably partial upload that is there. I'll upload a good copy soon on a real Mac.
Last Edit: January 13, 2025, 17:46 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #2 on: January 13, 2025, 19:18
|
Based on what I saw in SDL (PPC), a shared library on the Mac needs an "*.exp" file so that the compiled shared library can actually be used. Else there's no method exposed at all. A strong indication of this is if you look at the "Link Order" tab for the SDL STUB target in CWPro5 or 6, it ONLY "compiles" the SDL.mcp.exp file. The "release" shared lib target's linking is basically the files for building the static library + other libs + the SDL.mcp.exp file. On project settings, somewhere in the linking options, you have to change some dropdown there from "None" to "Use *.exp file" or similar, else those files get ignored even if they are a part of the target, from what I could tell. Anything beyond that, I do not know. When I tried getting 68k SDL shared lib to compile, I couldn't (so far). And I think shared libs on 68k only exist as CFM-68k? Or was there some other non-CFM type of 68k shared libs in the past? (Or is this why 68k apps had everything in the resource fork and nothing delegated to shared libs? I have no idea.)
Last Edit: January 13, 2025, 19:26 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #3 on: January 13, 2025, 22:02
|
I finally (FINALLY!) figured out my shared library confusion in CW: I kept getting linker errors to the gist of "Can't use non-CFM .lib", when I was trying to link in things like the SDL library. This lead me, wrongly, to assume that SDL had to be a shared library. This is ONLY with CFM-68k, and not PPC or normal m68k. It turns out CodeWarrior has CFM static .lib files...these are STATIC libraries, not shared, and not "stub" libs either, but you have to set a particular button in M68k target when building the .lib. So, I needed to build a separate "CFM-68k" .lib for SDL, and can't use the same .lib file. I don't know what magic is going on behind the scenes, and it may be a goofy CW only thing. The reason it never came up is that PPC is ALWAYS cfm, and usually, m68k is never. I wasted a LOT of time trying to build m68k as a shared lib, and made SOME progress in that direction. We might finish it, or might not. The good news is we don't have to, since it now has a separate target for making a CFM .lib file. FYI Had to ALSO have build SDLmain CFM, so there's a new target for THAT too (ALL .lib files you link with have to be "CFM"). ---- After having done all that, turned on opengl support for M68k. It also wanted to have the real libso, so turned that on and it at least compiles fine. So I'll leave that turned on and "officially" (as much as it gets) supported in m68k SDL. Don't know if it actually works, and not even sure how to test it. Once THAT was done, SDL_macgl.c complained about a few AGL functions that Mesa is missing that Apple's OpenGL has. Apple's supports more than one "context" and Mesa doesn't. Mesa has "AGLPixelFmt" Apple has "AGLPixelFormat" etc. Mesa is missing a bunch of attribute defines, etc. All easy to fix. ---- After fixing all the differences between Apple's OpenGL and Mesa, I got SDL's testgl building as a real CFM-68k app. But when I run it, it tried to "load" the OpenGL library, which it doesn't have to with Mesa, since even though it is a shared lib, it is "loaded" at run time by the OS. That's what all the Mesa demos do. THEN...I run into problems in SDL's GL support wanting to do "GetProcAddress" and dynamically getting function pointers to the OpenGL lib. I think the idea is on some platforms/systems, OpenGL is optional, and it may or may not be present. I may not be explaining or understanding this well... If you don't have the Mesa shared libs, it will complain at LAUNCH time, some part of SDL doesn't need to go looking for it, not while it is actually running. Does that make sense? Anyway, if I let the function pointers be NULL, it complains and won't run...but I'm getting close...
Last Edit: January 13, 2025, 22:06 by lauland
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #4 on: January 14, 2025, 18:14
|
Thought more on it and realized loading OpenGL (whether Apple's or Mesa) dynamically at runtime is a Good Idea(tm). The reason is that if you are running a program that uses a version of SDL with OpenGL support (which I'm trying on m68k), you MUST have OpenGL installed to even launch the app, even if it doesn't use OpenGL. Loading (and/or at least checking for it) at runtime means users don't have to have Mesa if OpenGL is it turned on in m68k SDL for everything. This probably makes sense, and I can just try and adapt the way it loads Apple's OpenGL for PPC...if I'm very lucky, the "function pointers" are just generic and will "just work" the same way. The other choice would be to "distribute" Mesa along with our m68k SDL...but since the GetProcAddress is broken anyway, I might as well try and fix it and try and do it the way it was designed to be. ---- FYI Wanted to test this on real hardware, so copied the built example applications and shared libs to a real mac, but couldn't launch because it needed the "MSL C.CFM68K.DLL" and "MSL MWRuntimeLibCFM68K" files in my Extensions folder. A real pain, but looks like CW builds CFM apps with those shared TOO. Going to copy THOSE and try again...
|
|
Pages: [1]
|
| |||||
|
© 2021 System7Today.com. |
