@dosnostalgic Huh, wonder if they manually recreated the cutscenes or if we included the scripts (unused) with the original. We originally intended to run them ingame, but in the end decided it was safer to prerender them to guarantee audio sync across varying systems.
Well this seems like some pretty f*cking important information that is completely absent from modern documentation. 🙄 (At least I think it explains why Pipe Dream has purple colors where it shouldn't!)
Yep, that was it. Kind of preferred the purple, but I guess that was the "mask out" color. They would set the background color to the "mask out" color, and BitBlt to a monochrome bitmap to create the mask which they then used for transparent blits.
On the plus side this investigation caused me to implement the complete set of GDI ROPs, so that's one fewer dangling thread lurking in the code.
one of the great disappointments with apple’s decline in visual design aesthetics over the past 15 years was the loss of richly textured objects and backgrounds
every month i visit my local Re-Use center, which gives away donated household junk so it can be repurposed. it’s an artist’s paradise.
today’s find was old carpet samples. i love the texture, patterns and interesting weaved colours. feel free to use ‘em for digital art.
@vga256 IMO, Apple's decline in visual design aesthetics started with the introduction of richly textured objects and backgrounds, specifically the brushed metal look of the QuickTime player.
That was the start of them throwing the Human Interface Guidelines (aka The Bible) to the curb in favor of skeuomorphism, and began the trend away from consistent UI toward pretty UI.
This was also about the time I gave up on Apple and moved on.
@dosnostalgic It was always the height of laziness in arcade ports to just use the built-in PC BIOS font instead of the original arcade font. It's a small thing, sure, but it always bugged me even as a kid, and made it feel less "arcade-y" for no good reason.
Well, well, look what turned up today. Think this is the final confirmed, officially-licensed SCUMM game I hadn't managed to lay my hands on. Seems to run fine.
Even though neither Loom nor Indiana Jones and the Last Crusade shipped with Hercules graphics support, the Passport to Adventure demo CD offers a Hercules video option. Which means you can check out both games (along with Secret of Monkey Island, which did support Hercules) in glorious green & black to see what might have been.
(The scaling artifacts on the text are from the original game, not from DREAMM. Guessing they didn't put too much work into cleaning up that stuff for a rather niche market.)
@dosnostalgic I loved my PCjr. The differences vs the regular PC inspired me to reverse engineer games so that I could hack them to run on it. I got top marks at the state science fair for studying its sound generation vs other computers at the time. And once you expanded the RAM above 128k, you could load a TSR that would claim all the "slow" memory and things would run at full speed.
Ha, figured out why Night Shift had broken colors in Tandy mode. My video BIOS was treating the palette setting functions (INT 10h, AH=10h) as being EGA+ only, so I was ignoring them if called on earlier systems. But looking at the PCjr BIOS sources, it appears they were implemented first for the PCjr.
Digging into this also revealed that the CGA palette selection on post-CGA systems is emulated by manipulating the palette registers rather than via a magic bit in the CGA I/O space. Which explains why forcing CGA mode on more capable hardware was often giving the incorrect palette.
Now need to figure out why Night Shift insists on trashing low memory when trying to start the attract mode. Looks like an important vector never gets initialized, and then is later used as the target of a memcpy, which blasts over all the interrupt vectors and leads to mayhem.
@root42 PCjr was still RGBI, but there was a level of indirection so you could reassign the colors at will, kind of like on the original EGA. In fact, given how well they map to each other, it's pretty clear that the EGA attribute registers were a follow-on to the PCjr's design.
Thanks to my new heap manager, DREAMM now sports an XMS implementation. Previously, I was exposing only an EMS interface, which is apparently the fallback position for DOS extenders like DOS4GW. Now I am well educated on the difference between EMS and XMS, and other great TLAs like HMAs and UMBs.
There's actually an even more preferred mechanism, which is built on top of EMS called VCPI, but I haven't gone that far yet. It's weird because VCPI might not be available until you do at least one EMS allocation, so the sequence is:
See if EMS is available
If so, allocate one EMS page and then free it
See if VCPI is available
If so, use VCPI
If not, see if XMS is available
If so, use XMS
If not, use EMS
Some games that don't use DOS extenders use EMS directly, like Day of the Tentacle and X-Wing. So EMS still needs to be around. Isn't DOS fun?😜
I also reworked my EMS implementation to be built on top of XMS, so in theory both could co-exist within one program, though in practice this isn't likely to happen.
Starting to look good... Of course, this will all be for naught unless I can figure out how to wire up the Mac buttons to the SCUMM verbs, and when to show and hide the GUI. But it's obviously possible, seeing how the original did it.
I thought it would be much worse, but ScummVM provides simple access to the classic Mac fonts now. So far it's been fun messing around with it.
@et_andersson@ja2ke Actually, that's all before my time. Eric Johnston was the Mac contractor before me, and he was much more hands-on with Mac-ifying the ports, using higher resolution text and some actual Mac controls. This was more important for the early ports because B&W Macs were still an important target market, and a direct port would be pretty fugly.
When I arrived on the scene, it was apparent that this approach was unsustainable for ports given the number of games in the pipeline and the amount of custom work involved. Also color Macs were the norm by then. So I went with a more unified approach that tried to match 1:1 with the DOS versions and eschewed all the Mac-isms that previous ports had.
OMG is the Xcode UI just the most unintuitive pile of dung I've ever encountered. Nothing about it makes any logical sense. All I want to do is view stack memory. Why is that so hard? I know the sp value.
I can right click on the "sp" value in the register list and it helpfully gives me a "View memory of 'sp'" option ... except it then opens a memory view of a completely unrelated address. (I see the sp value in the memory so guessing I'm viewing the context record, gee so useful.)
So now I have a memory view, so let's change the address. How do I do that? Beats me. It's completely unobvious how to do so. You'd think maybe clicking on the address would let you change it, or there'd be a discoverable menu, but nope, it just pops up a menu. Thanks.
I also see there's a Debug->Debug Workflow->View Memory option, which brings up a memory view of 0. Highly useful. Also unable to change the address to anything else. What the F good is any of this?
Ok great, I can now view the memory address I want. But it's all bytes and I'm looking for 64-bit addresses on the stack. Let's see if we can find a way to display the bytes as 64-bit values. If such a control existed, I'd certainly expect it to live next to where the address and number of bytes/page is. But no.
Oh wait, there's an Editor menu. And hey look, a "Byte Grouping" submenu. Sweet, let's do 8 byte groups so I can see... Wait a second...
OMFG.
If you dump raw memory and group bytes by 8 they are not endian-swapped???? 🤦
You're on a little-endian machine. If you display in groups of 8, that means you should display them as 8-byte values of your native endianness, not just remove the spaces between all the other columns.
Clearly nobody uses Xcode for actual low-level debugging.
I'm terrified because now, after I manually reconstruct the stack addresses in the correct byte order, I'll want to view the disassembly there. Pray for my soul. I know this won't be easy, if it's even possible.
@HauntedOwlbear I wonder if any of the existing 3½" USB floppies are just a standard floppy interface plugged into a USB conversion interface. If so, then in theory you could swap in a 5¼" drive. But it's just a wild theory. :)