|
|
|
|
| Welcome, Guest | Home | Search | Login | Register | |
| Author | Attempt to add color to MvM running on MacOS 7/8/9 PPC (Read 168221 times) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
lauland
512 MB  Posts: 674 Symtes 7 Mewconer! 
|
on: December 17, 2024, 16:00
@Jatoba I was going to stick with GM 3.5.0 MPW, but your mention of MvM being "visually-glitchy, and overall glitchy" and following the Gryphel instructions, has changed my mind. It WOULD be best if we all use the exact same MPW. I could try and reproduce your steps but it'd be a LOT easier if you could make an archive of your MPW and upload it to MG page http://macintoshgarden.org/apps/mini-vmac-source-code if possible? (.sit .dmg or even, heaven forbid, .zip, etc, is fine). ---- Ok, I've determined the code in OSGLUMAC.c is using classic and NOT Color QuickDraw calls (using a BitMap, and not PixMap for CopyBits() is a sure sign) so without changing that, color is completely impossible. Fixing that will be the first step. Ironically, once we've done this, we won't "just get color", and the resulting app will be visually indistinguishable from the existing one! But doing it cleanly (not just hacking randomly) is key. ---- The next obvious step is changing UseColorMode, ColorModeWorks, and vMacScreenDepth. From looking at the code, I believe we'll need to look at the platforms that do support color to get further. ScrnMapr_SrcDepth and ScrnMapr_DstDepth are constants, which does NOT seem right. I think some new code to handle that will be needed, and not just a simple patch to OSGLUMAC.c. ---- I can create a github page, we can upload (and then update etc) our patched source to MG, host it here at System7Today, and/or just toss what we are working on back and forth between ourselves via email, etc. The source archive will be mercifully tiny. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Last Edit: December 17, 2024, 19:04 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #1 on: December 17, 2024, 20:42
|
Quote from: lauland I could try and reproduce your steps but it'd be a LOT easier if you could make an archive of your MPW and upload it to MG page http://macintoshgarden.org/apps/mini-vmac-source-code if possible? (.sit .dmg or even, heaven forbid, .zip, etc, is fine). Absolutely. In fact, back in February 2024 I actually set up a .SIT file of an "untouched", pristine merge of MPW GM + PR + Final Updates, and although that was kept as a clean backup for myself, I'm glad to see it can serve some purpose for others, as well. Gopher download link (Netscape and Classilla work, as do purpose-made Gopher clients like TurboGopher and, for "modern" systems, Gophie, or even Floodgap's Gopher-over-HTTP proxy): (EDIT: Gopher link removed since link for the file is provided further down in another post via HTTP, without breaking the forum page scrolling.) MD5 checksum (data fork only, since it's a SIT file): 3f32f16d1e3b972e4a8b91ff6fd1406f (Unfortunately this long URL will horizontally-extend the post space of this thread, but I cannot hyperlink Gopher links in S7T/M9L.) (This was uploaded via Hotline to M9L/S7T's Hotline server, which was awesomely made accessible via Gopher by @Knez & Co.) This download is essentially the true latest version of MPW as released by Apple, there should be absolutely no modifications made to any file, and should mimic Gryphel Project's MPW build setup. (If it should be uploaded to the Garden, I believe the MPW page would be ideal. It's just that I figured many wouldn't want to "trust" someone else's merge work and wish to do it themselves if so desired, but I could be wrong.) I hope the Gopher (or Hotline) link is fine enough for you, @lauland / @MTT / anyone else chiming in? -------------------- About source control, I'm fine with anything, as well. Perhaps putting a .SIT of the source inside the "Uploads" folder in M9L/S7T's Hotline server like I did with MPW would possibly even be ideal for us to casually share this in a cool old-school fashion? I believe if we want to use "diff" tools and the like to quickly detect changes, we can do so without relying on Git and the like, although such repos (be it of Git, CVS or whatever) are fine by me, as well. Anything you guys prefer! -------------------- As soon as I can, I will see if I can also compile Mini vMac on CW Pro 8. It'd be cool if MPW could compile 3.5.8 properly like CWPro8 can, and like MPW can with 3.4.1. I'm feeling greedy about this, but perhaps we can diff 3.4.1 and 3.5.8 and see what changes likely caused this discrepancy? About the actual main interesting topic, which is Color for Mac II guest in Mac OS hosts (PPC and 68k), I will try poking/inspecting OSGLUMAC.c (and others) ASAP and see if I can provide any insight-- as unlikely as it is to help, but the more pairs of eyes, the merrier the coding, so I will try anyway.
Last Edit: December 20, 2024, 21:12 by Jatoba
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #2 on: December 18, 2024, 18:44
|
Should we start a thread on os9lives? I only realize now that a LOT of my posts have been about MacOS 9 (not System 7) and probably belonged there (and might get more people interested). ---- @Jatoba Muchos gracias for the MPW! You should post it at MG, as it may lower the barrier (not only for this project!) and be very useful. I know exactly what you mean about "trust", but, I think, in the 2020's, anything we can do to enable more people is a gift to the world. You get what I'm saying, there are some, I'm sure, where downloading a single package may make all the difference... (Heck, putting the parts together irritated ME enough to not want to bother, and I should know better!) ---- Let me know more about what you've seen with CWPro8. Using it, so we can leverage its excellent debugger will be very helpful. I have a strong feeling we'll be inspecting structures on a running copy of MvM at some point... I'm open to doing Carbon too (with same code base, just #ifdef's), so we could use XCode's even better debugger. This'd be a mutant Carbonization, separate from the existing MacOS X support...again, not really "useful" for anyone, except for hacking on the source. (I can absolutely Carbonize the event loop, etc etc) ---- And, did you have trouble with 3.4.1 vs 3.5.8 (or vice versa?). We'll definitely look at both versions. I use BBEdit/TextWrangler's "Find Differences" to compare source trees all the time, and will take a look.
Last Edit: December 18, 2024, 18:47 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #3 on: December 20, 2024, 18:39
|
Color Mini vMac is also applicable to System 7, so I think discussing things here works out well, although Classilla indeed is more in the Mac OS 9 territory. Since each forum has a different audience with a different "collective personality", I think taking these discussions to both places can make sense. Sometimes I'd create a thread over something in S7T, M9L and also the Garden! And one could always include more to the mix for max reach: TinkerDifferent, 68kmla, VintageApple Reddit, MacRumors PPC subforum etc.... Anyway, I think System 7 Today is fine for all this! There's a lot of OS 9 / System 7 overlap, and often you discuss even porting OS 9 apps to System 7 or even 68k, so I think you are in the right place eitherway.  ---- I followed your advice on MPW and directly uploaded it to MPW page in the Garden (first, topmost download). I also cleaned the page up a bit as a whole, and made things easier to spot for the general visitor. ---- By adding the flag & value "-e mw8", then using "Import Project" from within a fully-updated CodeWarrior Pro 8.3 to import the generated .mcp.xml file for Mini vMac, and saving the newly-created .mcp file to where the .mcp.xml file also was, I was able to simply click on "Make" and get Mini vMac to compile. Like @MTT pointed out, the instability and inaccuracies I would get with 3.5.8 + MPW were simply no more (well done, @MTT!). One thing to note, though, is that earlier I misremembered and thus mispoke about the exact issues I had with Mini vMac 3.5.8 compared to 3.4.1. The exact breakdown of the situation is as follows, when combined with this System 6 disk image (currently download #3) for testing: - Mini vMac 3.4.1 + MPW + non-Mac-II guest = All good - Mini vMac 3.5.8 + MPW + non-Mac-II guest = Unstable and inaccurate, the "eyes" widget lacks the pupils, and after using it for a while, the system hangs - Mini vMac 3.5.8 + CWPro8 + non-Mac-II guest = All good (!) - Mini vMac 3.4.1 + MPW + Mac II guest = Lack of color aside, the screen's black & white colors are inverted, such as the included Shanghai II's title screen - Mini vMac 3.5.8 + MPW + Mac II guest = Lack of color aside, the screen's black & white colors are inverted, such as the included Shanghai II's title screen - Mini vMac 3.5.8 + CWPro8 + Mac II guest = Lack of color aside, the screen's black & white colors are inverted, such as the included Shanghai II's title screen So even in black and white, Mac II emulation is off when displaying visuals, whether we use MPW or CWPro8. So it might be another thing to look into. Are bits flipped compared to what they should be in the source for the part that corresponds to the original Mac OS / QuickDraw? I don't know. ---- By the way, it's great to know that BBEdit (and TextWrangler, for that matter) have a "Find Differences" function! Great to know we have native Mac tooling for that!---- With regards to debugging, seeking to leverage CW's debugger sounds like a great idea, we certainly can try that now. I did not even consider that considering how little I worked with C (and C++) so far... As for XCode's + non-OS-X-Carbonization, that's a pretty interesting plan, too, if well-attainable. Weekend is coming now, just maybe I get to poke at the source this time, although admittedly when I briefly peeked at OSGLUMAC.c earlier, it looked pretty big and intimidating to my untrained eyes. But I know there ain't no goblins anywhere, just have to sit down, get used to it, and try to trace and break bits and pieces down.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #4 on: December 21, 2024, 00:40
|
system7today.com vs other places: Agreed. I love system7today's minimal easy-on-the-eyes design. I put a "little note" about classilla over at os9lives.com, hopefully I won't attract any griefers or "I'm creating a new browser!" folk, but hey, there MIGHT be people out there who might actually DO something, and who am I to hold that back from the world? ---- MPW: Awesome! That is a gift to the world! And people like me who are lazier than they should be. ---- Well...dang...I did INDEED see the 3.5.8 problems you describe...but assumed it was either due to my crazy changes or the fact I was running MvM inside an Intel copy of SheepShaver on my Apple Silicon Mac! That'll teach me a lesson to not have too many variables at once. What I didn't see was the "inverted" colors, but I'll take a another, closer, look (I never launched Shanghai, for example). Will be trying out building in CodeWarrior next thing. Add do diff/compare of 3.4.1 and 3.5.8 and see if anything "obvious" stands out that might be causing the instabilities. Also see why 3.4.1 doesn't like CodeWarrior (did the older source generator just not support it?) ---- Regarding debugging, I'm thinking exactly of something like I was doing in this screenshot: https://revontulet.org/2024/01/05/859cc0dcff8542f0b493c42081e3bb36.png Right there you can see the source and destination GrafPorts and associated rectangles that are about to be copied by CopyBits(), and follow the trail right up to that call. Putting a breakpoint on MvM's CopyBits() will be EXTREMELY informative. That was XCode, CodeWarrior is...good also, but not quite up to gdb's level, for "reasons" due mostly to MacOS 9...but we'll deal with that. Yeah, don't be intimidated, frankly, OSGLUMAC.c is a bit of a mess, with EVERYTHING Mac related all jammed together in no logical order in one file. Do a Find on "BitMap" or "CopyBits" or some of the other variables I mentioned earlier to look JUST at the drawing code. There's a LOT in there we won't ever need to even touch.
Last Edit: December 21, 2024, 00:52 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #5 on: December 21, 2024, 09:34
|
D'oh, I somehow completely forgot to mention it in my previous post: the "inverted colors" black & white issue I get with Mac II with the actual Mac OS as a host does not manifest all the time. It generally looks fine, but some things have the two colors inverted. And the easiest way to notice this is to just try running that Shanghai II game included with that System 6 image: you will be greeted with a horrible-looking inverted colors mess. I guess I was way too tired and drained when I wrote my previous post, and that slipped away. About building 3.4.1 with CWPro8, actually, I thought we could! But I just tested it for the first time to confirm: indeed we can't! And we get different errors depending on whether or not we specify Mac II (-m II) or don't specify anything. I'm assuming whatever was done to the source code to get CWPro8 to compile it is also what likely caused MPW to compile it wrongly by the point it reached 3.5.8, but who knows, we would have to check to be sure. And, OK, you made it clear how awesome it would be to have GDB onboard with us, nothing beats having a quality debugger to tell us wth is going on at any given time. Never thought much of employing the likes of XCode or other non-real-Mac-OS programs and their respective OSes to develop FOR the actual Mac OS, but you made it clear I shouldn't be that hard-headed about it. (Although I gotta say, I don't think I have what it takes to carbonize the relevant parts at present.)
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #6 on: December 21, 2024, 13:35
|
Inverted colors: I'm not entirely convinced this is an MvM bug and not just poor coding in Shanghai...Running it in MvM Mac II on MacOS X (taking MacOS 9 out of the equation) shows very poor display (the same inversion maybe?) if you switch Monitors to "Black and White". This is exactly what you see if a program uses a lot of color on a Black and White display if the programmer didn't bother to detect the screen depth, and use specific black and white art (and doesn't bother to dither it ie poor quantization). In other words, it isn't "inverted" but instead every single color is brain-dead mapped to either black or white. Let me know if you see the problem anywhere other than Shanghai... ---- I generated source trees for many of the variants, 3.4.1 vs 3.5.8, mpw vs cw8, and mppc vs mach, and then used BBEdit's "Find Differences..." (on MacOS X) to compare different combinations and see what is actually different about them. I found...many interesting things... 3.5.8 mpw vs 3.5.8 cw8: Very very few differences, dealing mostly just with compiler specifics (pragmas, include files, qd globals and similar). Did not see any hint to instability. (I could relatively easily "backport" changes to 3.4.1. Will look into that time permitting. See below.) 3.4.1 mpw vs 3.5.8 mpw: A lot of differences, as expected, including file additions or renames. But concentrating on OSGLUMAC.c none are ground breaking or "significant" (a lot of type names and other things were changed, but overall structure is almost identical). 3.4.1 mppc vs 3.4.1 mach (didn't look at 3.5.8 mach): Surprise! At least THAT MacOS X version is already Carbon! (I was expecting some Cocoa which would've been VERY different). This would normally be a really good thing because we might be able to "un-carbonize" it and backport color support...but they used Core Graphics (aka Quartz) for display, and NOT Color QuickDraw. In other words, it is Carbon, but MacOS X specific. The two OSGLUMAC.c's have a LOT in common, but extreme differences. The display code functions have radically different names and structure, even if the file itself is "similar". ---- Color inversion: If you can get it happening consistently outside Shanghai, let me know. 3.4.1 cw8 idea: The code changes are trivial, but it will need a new project file. There are enough file additions and name changes that we can't just reuse the 3.5.8 one directly, but it would be "relatively easy" to put one together or hack it. 3.5.8 instabilities: One difference in the CW8 version (vs MPW) was a flag that might impact optimization. Otherwise, my best guess is maybe compiler bugs? It's possible that by the time 3.5.8 came out, the author had switched to CodeWarrior and didn't bother to test on MPW? Carbon for debugging in XCode: So there are two approaches...(1) Take the mppc code and "Carbonize" it, might be able to use parts of the mach version, especially event handling, but since OSGLUMAC.c is such a mess, it might be easier to do this "from scratch". (2) Take the mach code and replace Core Graphics with Color QuickDraw, again, it is a MESS, and this would involve 90% of the same kind (but different) work as our original goal: Color on MacOS 9. So (1) is far more likely and that is what I'd look into, if the cost of the work is worth the benefit of using XCode. CodeWarrior's debugger may just be "good enough" for us! ---- Something "smells fishy" to me... The fact that the MacOS 9 version didn't use Color QuickDraw, and the MacOS X version used CoreGraphics is...a little weird...strange and very unusual when you look at the source for different Mac projects out there. Ok, the original author just didn't bother to use Color QuickDraw...a DIFFERENT author did the MacOS X version but why did they use CoreGraphics? Color QuickDraw would've just been (relatively easy) changes (the very ones we are contemplating ourselves!) and not a LOT of brand new code. Maybe they were learning it and just wanted to use it? Especially since there aren't terribly significant differences using Color QuickDraw between MacOS 9 and Carbon. (Mostly just type casting, opaque structures and resource formats). Comparing OSGLUMAC.c, it's obvious the mach version was based on the mppc one. Why did they "fork" it and not just fix it up, ie add Color QuickDraw and Carbonize it? One possibility is the fact that Carbon doesn't support the "classic" (ie B&W) QuickDraw calls, but only Color QuickDraw. The mach author tried to "just compile" the mppc version in XCode, saw it wouldn't compile, and threw the drawing code (but Carbonized the rest) out the window and decided to use CoreGraphics because "it's better". Another very strange thing is there is a LOT of "modern" (aka late age) MacOS 9 code in the mppc OSGLUMAC.c...things like supporting Appearance, and good use of MacOS 8.5+ APIs. Why did someone bother to do THAT, but not add Color QuickDraw?!? One answer, of course, is laziness...the fact that there aren't a lot of Mac programmers, they all have egos, and just do what they want/can with the limited time they have... But I've looked at a lot of Mac code and can confidently say, this code is WEIRD. I'm sorry that if you haven't looked at much, that this might be the first you take a deep dive into. It is NOT a good first Mac project for learning. A good analogy is if your first pet is a dog from the pound that has chronic health issues, behavioral problems, poops everywhere and is very ugly. The code has not been well looked after, so what we're setting out to do is a bit more of a challenge than it should be... Like that dog, it'll need a lot of love.
Last Edit: December 21, 2024, 14:12 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #7 on: December 21, 2024, 15:07
|
I just had a realization, it may or may not be worth a try, but among the "developer options" there's a flag called -api, and I don't know how far it was implemented fully in 3.5.8 (or 3.4.1), but we can use "-t mppc -m II -e mw8 -api sdl" to use SDL 1.2.x instead of what is the default of the target platform. Curiously there's both Carbon AND Cocoa there for OS X, too, so not only the code was carbonized (although with Quartz instead of Color QuickDraw), it was also... rewritten in Cocoa? I stumbled upon the option when trying to see if there was a flag for choosing the drawing API (there isn't), and this is the closest thing I found, so I thought it was worth a quick mention here. I did try compiling 3.5.8 like that with CWPro8, but there are some errors, among them being that I have to move SDL-related files to... somewhere. Maybe to my CWPro8 folder? I remember doing something similar, but with putting OpenGL files inside MPW folders that MPW itself told me where they go (unlike CW) in order to compile SDL 1.2.15 (and 1.2.13) on Mac OS 9. Do you think this is worth a look, before we try swapping up QuickDraw with Color QuickDraw calls? Side-note: We can also specify "-t mppc -m II -e xcd" to use XCode to compile the mppc (rather than mach) version of Mini vMac. I'm not sure if this can help us with anything though, since the effort of carbozining would still be required to leverage GDB (if I understood it right), and instead just using CW's debugger might be good enough for us, from what you mentioned. (By the way, there's also a flag to specify the exact XCode version in case it helps, e.g. XCode 2.4.1 would require an additional "-ev 2410".)
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #8 on: December 21, 2024, 18:29
|
Sproing-boing! (Sound of eyeballs shooting out, and back into, head). Cowabunga! If we can build a version the uses SDL (thanking the maker 1.x and not SDL2) for MacOS 9 PPC then we're done, have found the holy grail! I just generated source trees (both 3.4.1 and 3.5.  using those flags you suggested and am going to look at them and will be trying compiles later today. (Going to visit fam, but bringing laptop w/ SheepShaver).FYI It looks like when I was talking about 3.4.1 and cw previously, I had the flags wrong and had something like "-emw8" (no space). No no backport needed.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #9 on: December 22, 2024, 01:25
|
Progress building after a lot of wrangling with SDL and CodeWarrior. Will go into details soon, but you can probably guess (and reproduce most of them). I tried both the 1.2.13 SDL and your 1.2.15. On launch I get: The application "minivmac" could not be opened because "InterfaceLib--FSResolveAliasFileWithMountFlags" could not be found. Very strange. Will look into soon...
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #10 on: December 22, 2024, 23:26
|
Bingo! I have the MacII SDL 3.5.8 version running in SheepShaver on MacOS 9.0.0 in color! (Was able to play Shanghai). Will test on real hardware soon and see how fast it is. ---- The error I saw was because CW8's MSL requires 9.1 or higher. CW8 itself "requires 9.1", but I got it to run by upgrading the CarbonLib for my 9.0.0... Still, the apps it produces, if they use MSL, will require 9.1! The call the error references IS implemented in Carbon, which is why using a new enough CarbonLib allows you to run CW8. ---- Imported the mcp.xml file into CW7, added needed SDL parts (including .rsrc), MSL, and a few Universal libs (like TextCommon and Unicode), did a few other project tweaks, and was able to build. Renamed "include" inside SDL to "SDL" so include "SDL/SDL.h" works. FYI Had to increase memory in Get Info for built MVM, default was WAY too low. FYI Dropping disk image on the app, does NOT work. Instead I renamed the test "System6.img" file to "disk1.dsk", so it would mount automatically.
Last Edit: December 24, 2024, 03:15 by lauland
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #11 on: December 24, 2024, 21:29
|
Now that is what I call a true Christmas gift. So awesome you figured that out! You made the dream into reality!I really am itching to try out your various code patches to that SDL codebase to get it running here, as well. I assume you are patching the resulting SDL codebase directly, but I'm sure we can apply most, if not all, of the steps to the "general" Mini vMac source, so that it generates the correct code each time we specify "-api SDL". This would allow us to i.e. switch resolution etc. without having to redo the steps each time. Looking forward to the final result! Maybe I should kick myself to see how far I can get too? It's a lot more reassuring when we know there is a light at the end of the SDL tunnel. I was concerned the SDL portion was simply unimplemented! (By the way, there's also an SDL2 option, but that is, currently, of no concern to us users of the actual Mac OS.) Now, once that is straightened out, I have to admit, I feel a bit "restless" at the thought of just leaving things there: SDL 1.2 is limited to PowerPC Macs, unlike Color QuickDraw. So not only 68k Macs get left out of the fun, Mini vMac II with color inside another Mini vMac II instance with color won't be possible! (I mean, questionable utility aside... who wouldn't smirk at the thought of running that!) A big mystery to me is whether or not I can actually contribute to anything to that cause: once I got started, I got completely side-tracked with other Mac-y activities, such as straightening out the Garden pages for MacPython 2.x, MacCVS and so on... And now I see myself oogling Panorama 4 and V archival... *sigh* Why oh why, me?! "I will just do this real quick and jump back to the code", but it's never quick and takes the entire day.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #12 on: December 24, 2024, 22:17
|
Actually...it was FAR easier than expected. There aren't any "patches" required at all! All the work was just wrangling the SDL parts, and setting up the CW project. Compared to other projects I've dealt with it was practically painless. I just used the "-api SDL" flag as is. I used the cw8 flag, but was able to import the mcp.xml into cw7 (so I could use 9.0 with SS) with no problem at all. NOTE: The generated CW project using "-api SDL", even for cw8, is incomplete, missing all but the basic mac libs, and includes the Mac (not SDL) .r file, which is wrong. I've uploaded a screenshot of the open project, and a shot of it running Shanghai2 to MG... http://macintoshgarden.org/sites/macintoshgarden.org/files/screenshots/Screen_Shot_2024-12-24_at_3.04.53_PM.png http://macintoshgarden.org/sites/macintoshgarden.org/files/screenshots/Screen_Shot_2024-12-23_at_2.09.45_PM.png Switching resolution, as in "Monitors" in the running MvM's Control Panel works...of course running it in "Black & White" is NOT the same as running the non-Mac II version of MvM. The Mac II version still has Color QuickDraw, even in Black & White, which is why I think you saw Shanghai distorted. BTW you absolutely contributed already! I wouldn't have even thought of trying a CodeWarrior SDL version for MacOS 9, and was too lazy to read the MvM docs to look up all the possible flags!
|
Jatoba
|
256 MB Posts: 270 System 9 Newcomer!
Reply #13 on: December 25, 2024, 08:12
|
Nice, thanks for the screenshot! That helps a lot.Quote from: lauland Switching resolution, as in "Monitors" in the running MvM's Control Panel I meant compiler options to set the resolution: Mini vMac doesn't allow resolution switching at all once compiled (you either use defaults, or -vres -hres compiler flags), which is extremely inconvenient, although, like the original author says, it does keep Mini vMac extra lightweight. So "Monitors" should be listing only the resolution it is compiled for and nothing else. But, with your screenshot, it's not that big a deal to adjust the source each time. I'm still surprised at how Mac II in black & white is just "supposed to look like that", and that 1-bit color depth Mac II inherently looks and is different from 1-bit color depth in pre-Mac-II Macs. But I guess it makes sense.
|
lauland
|
512 MB Posts: 674 Symtes 7 Mewconer!
Reply #14 on: December 26, 2024, 04:53
|
Oh derp! I should read what you actually say...for some reason I conflated "screen size" with "screen depth". I guess because normally those are tied together. Hmm...if it is a limitation that the hres/vres is hard coded into the MvM build, nothing we can do about that...or are you saying on some platforms it isn't? ---- So there are two things still missing from the MacOS 9 build: The ability to drop a disk image either on the app icon or the running window, and the being able to use the "Control Mode" (ie hold down the control and c key). Both are pretty obviously event related (the drag and drop is done, usually, via an apple event on MacOS 7+). The missing Control Mode is weirder... ...hold the phone: It turns out ALL keypresses aren't working...I hadn't tested that and just assumed they were since mouse events obviously were working. Could be it IS getting the key events but not translating them to the right mac codes, so they get ignored... (Very strange that mouse works, keys don't!) Either way, I'm going to either try breakpoints or debug printfs in the event handling code in OSGLUSDL.c and see what is happening (or not as the case may be). ---- I think we are of the same mind: "Run all the code...on ALL the platforms!". Obviously we'd both dearly love to see SDL2 for MacOS 9 PPC...and even just SDL 1.x for m68k. Either way, both would open up the possibility of porting a LOT of great software to our beloved old OS. I know you did some good looking into (and, more importantly, actually building!) SDL 1.x, and think I saw a comment of yours that the code was "very powerpc". I'll take a look myself and see just how bad it is. There's a port of SDL for m68k Amigas (and even an ancient limited one to PalmOS), so it isn't a CPU thing. I'll get you my (somewhat?) educated opinion on how much work a port would take. As far as SDL2 MacOS 9 PPC, that is likely more difficult, but could take some actual closer looking into also. I don't know the scope or difficultly of taking the modern SDL2 codebase, and attempting to "port" the MacOS 9 SDL 1.x bits into it, which sounds like a sane idea to try... Both of the above could be a huge amount of work, or could be just another case of nobody bothering to put real effort into it...due to lack of interest or just laziness. ---- I think the two things that made the Mac II in B&W look so bad running shanghai are that, first, Shanghai probably just doesn't detect the screen depth well (or doesn't care), and that it was System 6, which was an early version of Color QuickDraw. I suspect if you run the Mac II version in B&W with System 7.5 and tried other games, it will likely look much more like you expect. ---- Python, CVS, Panorama, etc: You do what you gotta do, and when your brain tells you to do something, it can be very hard to not follow whatever path it takes you. I won't lie and say I wasn't slightly disappointed that you didn't whip out the compilers and follow, but, hey, you were still making the Mac world (MG) a better place, so I can't fault you one tiny bit. (And in fact, think quite highly of you!) If you'd instead spent your time going off drinking and hunting endangered species, that'd be a whole different story. (I shouldn't judge anyone on how they spend their own time, but if anyone is making the world better, even in tiny ways, they're absolutely good in my book).
Last Edit: December 26, 2024, 08:18 by lauland
|
|
Pages: [1] 2 3 4
|
| |||||||||||||||
|
© 2021 System7Today.com. |
