SDL2 for PPC MacOS 9 efforts...



Welcome, Guest \| Home \| Search \| Login \| Register


Author	SDL2 for PPC MacOS 9 efforts... (Read 66221 times)
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	on: January 09, 2025, 16:08 For the record, I'm using CW7 and not even going to try an m68k version, because I'm not TOTALLY crazy. I need to get back into Hotline and will be uploading what I've got to the S7T one. You guys can help. See if you can find a simple open source SDL2 game, that does NOT use OpenGL, for a test case, that you'd like to see ported. Although I'm going to include OpenGL, I'm going to get 2D rendering going first. One that isn't visually over the top and simple as possible would be great. I think SDL-Ball might be good? If you guys have heard of anyone else in the wider world, that has made a similar attempt at SDL2 for MacOS 9, or may be interested, feel free to point them in my direction.. But don't get their hopes too high! ---- I'm using the software renderer for now, although acceleration should possible at some point. I've used OpenGL personally for 2D drawing in other projects, and that way you'd get acceleration "for free", if the MacOS 9 OpenGL does it that is... It turns out the dummy video driver doesn't register itself as a "real driver", so the video tests won't run with it, and to get further I wrote a skeleton "macosclassic" driver. I took the QNX driver, since it was the smallest, commented out all the QNX stuff and changed the name. It doesn't actually do ANYTHING right now, but is a legit video driver. It looks like some parts of SDL1 did make it into the SDL2 codebase...either that or someone sometime did at least did try using CW, as I've found a couple __MWERKS__ #ifdef's in the code. I've had to add several others... ---- Here's the output of testrendercopyex with all the verbose flags turned on. I haven't added any QuickDraw code, so you can see it is not detecting any screen size, etc. I'm not even opening a window yet... INFO: Built-in video drivers: macosclassic INFO: Video driver: macosclassic INFO: Number of displays: 1 INFO: Display 0: 0 INFO: Bounds: 0x0 at 0,0 INFO: Usable bounds: 0x0 at 0,0 INFO: DPI: 0.000000x0.000000 INFO: Current mode: 0x0@0Hz, 0 bits-per-pixel (SDL_PIXELFORMAT_UNKNOWN) INFO: No available fullscreen video modes INFO: Built-in render drivers: INFO: Renderer software: INFO: Flags: 0x0000000D (Software \| PresentVSync \| TargetTexturesSupported) INFO: Texture formats (: ARGB8888, ABGR8888, RGBA8888, BGRA8888, RGB888, BGR888, RGB565, RGB555 INFO: Current renderer: INFO: Renderer software: INFO: Flags: 0x0000000D (Software \| PresentVSync \| TargetTexturesSupported) INFO: Texture formats (: ARGB8888, ABGR8888, RGBA8888, BGRA8888, RGB888, BGR888, RGB565, RGB555 ERROR: Couldn't load icon.bmp: Parameter 'src' is invalid ERROR: Couldn't load sample.bmp: Parameter 'src' is invalid ---- The "src" error is referring to a "rwops" function array, that should hold pointers to all the file io functions, so it is not able to open the bmp files. I don't know why this is happening, it looks like if you have HAVE_STDIO_H defined, it should use defaults, but likely I need to specify that our platform supports basic standard C file io. I'm still going to get it to the point where it is loading the bitmaps and setting up surfaces before I start actually adding QuickDraw calls to the "macosclassic" video driver. I want to be cautious because I still am not completely sure this project is viable, although it is looking good so far. I believe it is working, but am not positive. If I do get the bitmaps loading, I'll flesh out the video driver. Then will need a "macosclassic" input driver. At that point, some of the trivial video tests may actually run. ---- If THAT happens I'll pull back and get more folks out in the world on board...if there are any. Or port a simple game, either way I need a "proof of concept" to show SDL2 could actually exist for MacOS Classic. I'm hesitant to make "an announcement" at MG or MacOS9Lives or MacRumors until I have something legitimately running. I REALLY hate when people announce "I'm building a new browser", or some other nonsense, before they actually have ANYTHING or have a single line of code...
Last Edit: January 09, 2025, 16:20 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #1 on: January 09, 2025, 19:42 I can't wait to be done with SDL1 and move on to this, and help in whichever way I can. I agree with you not to "announce anything too loudly" just yet for the reasons you stated. I'm kinda really excited about this, and would love to help give this continuity, be it in coding, testing, trying to port a simple SDL2 app or otherwise.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #2 on: January 09, 2025, 22:58 Let me know if you find a good candidate for a simple SDL2 app to try porting. I've found a bunch of simpler games that might be good, once I get further...but like a lot of SDL1 games, they need SDL_image, SDL_mixer, etc and I haven't even started looking at those.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #3 on: January 12, 2025, 19:14 I've gotten to the point where "I know that I don't know enough", or "I know just enough to know I don't understand what is going on" to go much farther. As in, I'm not really familiar with SDL2...ITSELF to know what I am doing. I know SDL 1.2 very well, but SDL2 is much more complex. There's lots of moving parts, with "devices", "displays", "display modes", "windows", and "renderers"...and I'm having a hard time understanding the guts of them all... I think I'm probably at the point to call in help, and see if anyone else out there is interested...I've done a lot of the initial heavy lifting, and have something of a "proof of concept". I'm going to try and upload what I have to HotLine... ---- I tried taking the SDL1 mac driver and adding into the tree...but, as I said before, the "plumbing" is completely different, with constants and structs et al, radically changed or missing between SDL1 and SDL2. A shim or compatibility layer might be an idea, but starting over from scratch is probably more logical. So I started sketching out a Classic MacOS "video" driver, using QuickDraw and the Event Manager. I actually copied the Mac parts I'd written for another project, since I'd kept them as clean, simple, and understandable as possible, and knew they worked. So, real (working?) code is in there, the tests don't crash, and seem to be running...but nothing is being drawn. This is because I have a window frame buffer that I just malloc'd the right size, but I also have an offscreen GWorld for the real Mac window...those two should be the same thing, but are separate because I don't know if it is safe to let the software renderer write willy nilly to the GWorld's pixels. It might not hurt to try... ---- Here's the stderr output of testrendercopyex...it opens a window, and goes into the event loop...all drawing is offscreen still...but the fact that it is creating and destroying textures, and at least thinks it is moving pixels, is actually a lot... The lines that start with "macosclassic" are the video driver. The "INFO" lines are from the SDL "test harness". The rest are debug printf's to show where in testrendercopyex it is... macosclassic videoInit... macosclassic Going to NewCWindow... macosclassic (Window done) macosclassic sdlvdisp is 95e1fb08 INFO: Video driver: macosclassic INFO: Number of displays: 1 INFO: Display 0: 0 INFO: Bounds: 640x480 at 0,0 INFO: Usable bounds: 640x480 at 0,0 INFO: DPI: 0.000000x0.000000 INFO: Current mode: 640x480@60Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888) INFO: Red Mask = 0x00ff0000 INFO: Green Mask = 0x0000ff00 INFO: Blue Mask = 0x000000ff INFO: Fullscreen video modes: INFO: Mode 0: 640x480@60Hz, 32 bits-per-pixel (SDL_PIXELFORMAT_RGB888) INFO: Red Mask = 0x00ff0000 INFO: Green Mask = 0x0000ff00 INFO: Blue Mask = 0x000000ff INFO: Built-in render drivers: INFO: Renderer software: INFO: Flags: 0x0000000D (Software \| PresentVSync \| TargetTexturesSupported) INFO: Texture formats (: ARGB8888, ABGR8888, RGBA8888, BGRA8888, RGB888, BGR888, RGB565, RGB555 macosclassic createWindow... macosclassic showWindow... macosclassic createWindowFramebuffer... macosclassic new gworld at a26e1c0 INFO: Current renderer: INFO: Renderer software: INFO: Flags: 0x0000000D (Software \| PresentVSync \| TargetTexturesSupported) INFO: Texture formats (: ARGB8888, ABGR8888, RGBA8888, BGRA8888, RGB888, BGR888, RGB565, RGB555 After SDLTest_CommonInit... loop... Going to SDL_PollEvent... macosclassic pumpEvents... macosclassic mac event.what=8 skipped! Going to SDLTest_CommonEvent... INFO: SDL EVENT: Window 1 shown Going to Draw... Going to SDL_RenderGetViewport... Going to SDL_CreateTexture... Going to SDL_SetRenderTarget1... Going to SDL_RenderCopy1... Going to SDL_RenderCopyEx... Going to SDL_SetRenderTarget2... Going to SDL_RenderCopy2... Going to SDL_DestroyTexture... Going to SDL_RenderPresent... macosclassic updateWindowFramebuffer... Draw done. loop done ... repeat ... loop... Going to SDL_PollEvent... macosclassic pumpEvents... macosclassic mac event.what=6 skipped! Going to Draw... Going to SDL_RenderGetViewport... Going to SDL_CreateTexture... Going to SDL_SetRenderTarget1... Going to SDL_RenderCopy1... Going to SDL_RenderCopyEx... Going to SDL_SetRenderTarget2... Going to SDL_RenderCopy2... Going to SDL_DestroyTexture... Going to SDL_RenderPresent... macosclassic updateWindowFramebuffer... Draw done. loop done loop... Going to SDL_PollEvent... macosclassic pumpEvents... macosclassic mac menu 'q' mchoice=2097217545 macosclassic Command-Q...quiting...
Last Edit: January 12, 2025, 19:29 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #4 on: January 12, 2025, 20:06 @lauland About your SDL 1.2 -> SDL 2.0 knowledge transfer, I suspect it might be mighty useful to check out the source of sdl12-compat. Supposedly, it maps SDL 1.2 calls to the corresponding SDL 2.0 ones, allowing an existing SDL 2.0 library to run SDL 1.2 software. Like you said, a compatibility shim, just like that one, might help, and I mean this in both that it can teach you about corresponding SDL2 functionality via the SDL 1.2 API, and in perhaps us coming up ourselves with an "sdl12-compat-2" to get SDL 2 apps running via an SDL 1.2 library. I think they also have official migration guides from 1.2 to 2, somewhere, so ironically that can also educate us a bit on how to achieve the reverse? Of course, these are just a thought.
Last Edit: January 12, 2025, 20:16 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #5 on: January 15, 2025, 18:42 Don't want to get anyone too excited...but... http://revontulet.org/2025/01/15/8b717fa8942d458c939c6c0f03cc2425.png http://revontulet.org/2025/01/15/c10aa8118e6a4101ae8431cbe3d4d1ff.png

Bolkonskij Administrator 1024 MB Posts: 2023	Reply #6 on: January 16, 2025, 07:57 I have to say, porting SDL2 to Mac OS 9 seems like an intimidating task to me - so kudos for getting THAT far already. thumbs up

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #7 on: January 16, 2025, 16:18 Here's the REALLY goofy and maddening thing: It's a bit subtle too...so...it is building, so we "have a MacOS 9 SDL2"...technically! But...it is practically entirely useless, because there are no Classic Mac drivers! So, all the code is there and compiling, but it can't/doesn't do anything. In theory someone COULD take this, and the source for an SDL2 game, and compile it. They'd get an application, but when you open it, blank screen (or now, distorted nonsense). ---- I thought of a really good analogy for what I'm doing...at least I think it's good... What we want is a motorcycle that runs on, let's say, electric power. (motorcycle=SDL2, electric power=MacOS 9). We have a kit, all the parts, and the instructions for building a normal motorcycle, that uses a gas engine. (This is the SDL2 code, the gas engine is the drivers for MacOS X, Windows, Linux, etc). Now, let's say I have very good knowledge about electric powered bicycles/mopeds/etc. (Those represent SDL1 on MacOS 9). But I don't know much about motorcycles. My existing knowledge of the smaller vehicles is usable, and I know how to make an electric engine...but taking my knowledge and extending it to the much more complex motorcycles is ok in concept, but a bit of stretch...and I may not know enough enough to build a large enough electric engine for one. I can't use any engines I already have, they're too small. Further extending the analogy...the REAL SDL2 programmers out there are happily zooming around on their gas powered motorcycles (Linux, Windows, MacOS X). They may appreciate our efforts, but have extremely little interest in electric bicycles/mopeds (MacOS 7/8/9). Anyway, I hope that made things clearer and not even more confusing.
Last Edit: January 16, 2025, 17:53 by lauland
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #8 on: January 16, 2025, 18:38 http://revontulet.org/2025/01/16/692cacd244a7436d945813e89cb8469d.png Better? Well...yes and no. The bit depth is now right, with 32 bit color pixels. But the garbage that the top is now making me think I'm doing something fundamentally wrong... It is only displaying anything by accident...

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #9 on: January 25, 2025, 11:28 These may be baby steps, but give it time, and those steps can take you across Earth eventually! Once we "wrap up the bag" with SDL 1.2, SDL2 would be my next aim... no matter the challenge up ahead. But... first things first.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #10 on: January 25, 2025, 19:39 Well...did very stupid thing...lost a week's work. No new functionality, but had been cleaning it up to be nice and readable. Had dummy OpenGL at least in place. And broke out the blit into a separate function to work on. But...was working on three different machines, and somehow overwrote the last version I'd worked on with older one...sigh. So I'm going to get it at least clean enough for the public and upload it to MG...that way there'll be a copy I can't easily accidentally erase. @Knezzen just witnessed me panicking about this live on HotLine...

cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #11 on: January 26, 2025, 05:37 Oh no! a week’s work! yikes! I’ve done some of those, and it really bites whenever we mess up like that I always tell myself I’ll improve my goofs further on the next attempt, and often times, the mind has a way of doing just that, keep your chin up!

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #12 on: January 26, 2025, 08:41 @lauland Can relate, hate it when that happens. From my experience, I can say that, generally, in the pursuit to rewrite what was lost, most of the time we make it better than it originally was, and we also get there faster than we did the 1st time around, so don't get too discouraged.

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #13 on: January 26, 2025, 19:14 Thanks guys, and @Jatoba is right. In my past experience when similar things happened, when I went back and was forced to recreate previous efforts, I found I HAD learned a lot, and the results DID end up "better" than what was lost. It's funny, I had just read on the MG "Equestria Girls" page about something very similar happening to its developer, losing QUITE a lot of work, just throwing up their hands in frustration, not wanting to have to redo so much, and they might never do it. Luckily I didn't lose quite as much, and re-writing just code is far less of a pain than dealing with Flash. Although I don't share interests with Liggliluff, I sure do feel for them! http://macintoshgarden.org/games/equestria-girls-dress I've created an MG page for my work, and feel a lot better today, after the shock has worn off...I was just getting ready to add "sdl12-compat" which would allow programs written for SDL1 to run on SDL2 (somehow?!?). This would let me use SDL1 programs, where I actually understand what they are doing, to be tests for the new "macosclassic" drver. http://macintoshgarden.org/apps/sdl2-macos-9-rough-draft
Last Edit: January 26, 2025, 19:20 by lauland
cballero 1024 MB Posts: 1176 System 7, today and forever	Reply #14 on: January 27, 2025, 03:05 If only your setup would have allowed to program in emulation and have had Time Machine backing up snapshots of your disk once you shut down the emulator but thankfully, you can now use the MG as your backup space for this and likely other future projects! I’m excited as I follow, as best as I can, your exciting programming exploits!

	Pages: [1] 2 3

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.