68kMLA Classic Interface
This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.
| Click here to select a new forum. | | nilSDL2 | Posted by: nil on 2026-09-18 12:53:41
The SDL2 library for 68k System 6
No OpenGL.
Test application attached.
View attachment Screen Recording 2026-09-19 at 5.52.07 am.mov | Posted by: adespoton on 2026-09-18 13:03:11
@lauland1 -- for your perusal. I have to say; I wasn't expecting ANY of SDL2 implemented for System 6. Then again, at one point, I thought it was a stretch to implement SDL 1.2 for System 7, and here we are 🙂 | Posted by: nil on 2026-09-18 13:37:07
Where ever you go, there you are.
First ever SDL2 game for a Macintosh Plus!
View attachment Screen Recording 2026-09-19 at 6.33.18 am.mov | Posted by: adespoton on 2026-09-18 14:01:29
Where ever you go, there you are.
First ever SDL2 game for a Macintosh Plus!
View attachment 104045 What are the memory requirements like? | Posted by: nil on 2026-09-18 14:50:57
What are the memory requirements like? 259KB
256KB if you don't need sound | Posted by: lauland1 on 2026-09-18 16:28:39
Dang, but not dang. You beat me to it! I'd been planning on getting my video driver to support b&w, and squeeze everything onto 4m plus...but you beat me to it! Good on ya! This looks awesome!
FYI I have opengl working in b&w, but it requires color quickdraw, to dither the bitmaps for the screen, so only works that way on se/30 and b&w powerbooks. I am working on pure 68000 opengl. This will NOT run acceptably on standard hardware, but is targeting mac pistorm...for now.
Feel free to "steal" my opengl code, both the stack and the SDL2 part. The new "offscreen" opengl driver doesn't require AGL. Mesa 2.4.1 would be the stack to look at. TinyGL requires truecolor...for now...but it would be a better fit for this I'm sure. | Posted by: lauland1 on 2026-09-18 16:49:45
BTW, here: https://github.com/laulandn/PETSCIIRobotsMac/blob/main/mysdl2.cpp
Is what I may call a "mini-SDL2". It mostly works, but only if the surfaces match the screen. It is an alternate I'd spin off for low end machines...but I may not have to now... | Posted by: nil on 2026-09-18 16:55:10
@lauland1 you're amazing. i hope you're living the dream! i'll get a git repo up later today to try to merge our work. cheers | Posted by: lauland1 on 2026-09-18 18:57:06
Not amazing. Just very hard headed and persistent. | Posted by: lauland1 on 2026-09-19 07:48:10
So I'm trying to get TinyGL to work with indexed color, 256 at first, but the eventual goal is B&W.
Right now, the demos all use SDL2, as does my hacked Apple compatible AGL.
Since "my SDL2" doesn't work well (or at all?) in less than thousands or millions of colors, I'm stuck!
I'm either going to need to get a quickdraw AGL working with TinyGL (the Mesa 2.4.1 one works well, but is tied to that only version of the Mesa device driver api, so would tons of work for TinyGL), or I need to get my SDL2 to work with less than thousands of colors.
This COULD be a case where your SDL2 would do the trick. The AGL and demos would build, but I probably still need to tweak TinyGL to work with non-truecolor (aka indexed). (I won't even be able to tell if I need that work without SDL2 working!)
So, other than making sure TinyGL handles indexed, it might be an excellent fit for nilSDL2 to get OpenGL...in the near future...
In theory, if you target AGL for OpenGL, in general, you'd be able to just slot the TinyGL stack in as a replacement for Apple's. I have this working pretty well, but only in truecolor. | Posted by: nil on 2026-09-20 05:27:32
attached is the latest merge of sdl2macos9 and nilSDL2
indexed window surfaces on the Color QD driver, with TinyGL presenting through SDL_GetWindowSurface instead of SDL_Renderer.
macvideo.c refuses anything that isn’t 16 or 32 bpp:
myDepth=(**gdpm).pixelSize;
if(myDepth!=16 && myDepth!=32) {
return SDL_SetError("Unsupported Classic display depth: %d",myDepth);
DrawSprocket, the PixMap (RGBDirect), and advertised SDL modes are the same 16/32 path. On a 256-color Mac II / LC, VideoInit dies before a window exists. That matches “doesn’t work in less than thousands or millions of colors.”
The TinyGL/OSMesa backend (macosgl.c, SDL_MACOSCLASSIC_OSGL + TINYGL) is already wired as an AGL stand-in, but it still assumes truecolor:
• ostgl_create_context(w, h, tDepth) with 32 forced down to 16
• present via SDL_CreateRenderer + SDL_CreateTexture + RGB565 / ARGB8888
• osglDescribePixelFormat always reports AGL_RGBA = 1
So even if TinyGL could emit indexed pixels, this swap path would still try to upload a 16/32 texture.
1. INDEX8 window framebuffer when GetMainDevice is 8-bit (indexed PixMap / GWorld, pmTable, not RGBDirect). Advertise SDL_PIXELFORMAT_INDEX8. Same for 1-bit later (INDEX1MSB).
2. TinyGL present without SDL_Renderer. osglSwapBuffers should SDL_BlitSurface TinyGL’s buffer onto SDL_GetWindowSurface and SDL_UpdateWindowSurface. That is the SYS6 idea, on a color Mac.
3. Stop lying in AGL. aglChoosePixelFormat / osglDescribePixelFormat should not force AGL_RGBA when the drawable is indexed. Report AGL_PIXEL_SIZE 8 or 1. Demos that request RGBA still get the existing 16/32 path.
4. TinyGL color itself is separate. Fabrice’s TinyGL is an RGB565-class software GL. Indexed/B&W is either (a) dither/quantize on present into INDEX8/INDEX1, or (b) a TinyGL framebuffer format. He cannot tell which until SDL2 will create an 8-bit or 1-bit window. (a) is enough to see a GL cube on a 256-color or Plus screen; (b) is the later “TinyGL handles indexed” work. | Posted by: nil on 2026-09-20 08:50:32
snowemu
View attachment Screen Recording 2026-09-21 at 1.48.18 am.mov
Mini vMac All out speed
View attachment Screen Recording 2026-09-21 at 1.53.05 am.mov | Posted by: nil on 2026-09-20 09:05:17
nilSDL2 is now merged into sdl2macos9. tinygl is fun but slow(understandably)
View attachment Screen Recording 2026-09-21 at 1.57.30 am.mov
View attachment Screen Recording 2026-09-21 at 1.59.42 am.mov | Posted by: lauland1 on 2026-09-20 09:33:55
Zam! This is turning out even better than I hoped! Great work! Truly impressive!
Yeah, I did some work to torture the existing driver to do indexed. Removing that check worked to a point, 2d is fine, but opengl is assuming truecolor, which color quickdraw can handle even on B&W machines.
INFO: I did NOT add that check, nor would I have since I target lowend.
----
The history of classic mac SDL2, up to your work, is this:
1. I did 2d and got everything basically working, including a lot of work on threads.
2. I did not do audio, nor opengl, no sprocket use, didn't finish events, I skipped indexed color to a point, solely because I didn't want to deal with palettes.
3. Nobody used it so I paused. Time passes.
4. drshay/srp took "my SDL2" and added on and/or fixed what was missing, and used it for his MacOS 9 Half-life port.
(The use of a non-human was made, the code is very good, but a bit of a mess, which is fine, mine was already)
5. I took his additions, and made sprockets and opengl optional.
6. I fixed things that were now broken on m68k and pre-MacOS 9 ppc.
7. I got Mesa 2.4.1's AGL to look enough like Apples so SDL2 could use it for OpenGL as an alt to the real thing.
8. Got this working on m68k and worked further on it.
9. Started work on TinyGL as alt OpenGL stack.
10. Created offscreen SDL2 opengl driver to use TinyGL, and also newer versions of Mesa (in progress).
(The offscreen stuff is a real mess and actively in progress)
11. My goal is, some day, some sort of accelerated m68k 3d, so continued work.
12. nilSDL2 is born. Rejoicing ensues.
----
Obviously everything will be extremely slow without some serious attempts at optimization, or this theoretical acceleration appears.
Your code is very very nice, I will build it and test ASAP. I'm fine for whatever you like for the future, two separate ports, or merged. Two separate might make more sense, as in "high end" and "low end".
----
My current goal is to get opengl rendering on pure 68000, to have something for the mac pistorm guys to test. Pure 68000 is needed because, although their pistorm can do 020 and higher instructions, they are using a rom that does not have color quickdraw. (So truecolor pixmaps aren't downsampled or differed).
They are seeing "fast cpu" execution, which may make speeds...reasonable...?
So a new fast downsampler/ditherer that does not require color quickdraw is needed, and will do the trick, as far as I see it. This would be part of AGL, so OpenGL stack agnostic, ie either TinyGL or Mesa.
Getting pistorm to run an SE/30 rom would be a project in and of itself, but would get them color quickdraw (no downsampler/ditherer needed as it could do it).
----
FYI I renamed macosgl.c to macglos.c because I kept getting confused seeing "macos" there. My github SDL2 repo may or may not be behind my MG "code drop", maybe see it for some some new work.
See "macos8addons" for fake Sprockets that "work" on m68k, these allow me to use the Sprockets path, but are minimal or stubs. (ie they "fail correctly") If someone wanted, they could be expanded on to be made as functional as they liked.
PS I'm looking into other non-mac platforms, but abandoning my Amiga work (there are far better ports out there). I've already got some things compiling, but may or may not work further, so have kept it on the down low. This line is a clue. | Posted by: nil on 2026-09-21 17:37:19
thanks for the writeup.
most of the work on this is by bots as well. "i'd prefer to use a 3d printer to make something rather than a scalpel and a block of wood."
i told it to consolidate the work you've done on MG with the stuff i have and PR to your github.
if you want to create a markdown file at the root of the project, so bots can know the intentions of the projects and directions to take it.
cheers again for all your hard work. this sort of stuff means more to me than it should lol | Posted by: nil on 2026-09-21 18:30:40
i never explain myself very well and then realise later.
don't merge the PR. it's for reference only.
thanks | Posted by: lauland1 on 2026-09-22 08:31:57
No prob. And bot coding is reality these days, they may not always produce "great" code, but they are empowering people to do things they may not otherwise be able to, or, more likely, don't have the time. We're seeing some lovely new stuff thanks to them.
I will not merge your changes without your express explicit permission.
It looks very good, although there is a line or two (only) that I may need to change. There was a YieldToThread() removed, etc.
I have tested, and will use, a private merge, but will not release until I hear from you. | Posted by: nil on 2026-09-23 00:09:07
yep, sweet. i had the audit bot run over it. it looks fine to it and me. release it when you want. | Posted by: lauland1 on 2026-09-23 07:50:06
Good deal. I will merge your new code into my "master" SDL2. Because of threads, I needed some very minor changes to your timing code. These will be #ifdef'd so won't bother System 6 or non-threaded System 7, etc. I will be the first to admit I don't know everything I need to know, but we need as many yields as possible when doing threads.
I'll let you know when I've tested, and updated the repo. | Posted by: lauland1 on 2026-09-27 18:17:01
Merged, tweaked.
Also TinyGL custom 1 bit blit added to its AGL. Very ugly, but works as full OpenGL stack for SDL2.
Some last min testing and will update my repo. | | 1 > |
|