You said you've been trying to work with some code snippets, right? Could you post what you've been trying to get working and maybe we can see what's a miss?
Iirc the memory layout was in 4kb blocks and the scanlines are interleaved between each block. So the first 320 pixels (80 bytes) come from B800:0000 and then the next scanline's 320 pixels (80 bytes) would come from BA00:0000. The third scanline goes back to B800 again with 320 pixels (80 bytes) starting at B800:0050. The easiest way I've found to do it is to make an array for the base offsets and just swap between them each scanline.
Fun fact, the same layout also works for Tandy 16 color graphics modes! In that case a scanline is 160 bytes long (to make 320 pixels) and you use the segments B800, BA00, BC00, and BE00 sequentially. Like first scanline is B800, second is BA00, third is BC00, then BE00 before returning to B800 for scanline 5.
Increment your offset whenever you return to B800.
This does mean that in CGA graphics modes 4 and 5 you're stuck blitting in blocks of N*4 pixels, as the pixels are packed 4 to a byte. Also keep in mind the order of pixels in the byte are probably going to be the inverse order that you expect them to be. CGA was very much a case of hardware engineering considerations first, software engineering considerations second (if at all).
That is quite the complex workflow. I can't speak for legalities, but I don't see any issues where the jam is concerned. Just so long as the submission is a single .COM file (Not an MZ executable) and will work on a classic DOS machine, it should be fine.
1) Nothing. There is no obligation to submit to the game jam. I'm always going to encourage folx to join and then to submit something but there's no penalty if you don't.
2) This is not a ranked jam so you are always allowed to use material from before the jam started.
3) No idea is too simple or too complicated, though overly complicated may be hard to complete before the end of the jam. Of course projects are acceptable in any state.
So no pressure! If you're new to coding for DOS feel free to ask. And above all have fun!
So this is technically all in data so would be easy to fix, right? Well, turns out the data compiler I wrote for the episode files hasn't been rebuilt in a long time and I had done a lot of reorganizing of the scripting language byte code while working on my adventure games. I don't seem to have a backup of the Bob version of the tools so I'm having to update Bob's executable to match the new byte code specs.
I am fantastic at planning ahead.
An easier fix might just be for me to edit the episode file in a hex editor. I think that's a much easier solution.
I'll have to look through the code. I can't remember off hand if those file names are data driven or computationally composed. Short answer though is sure, I should be able to change that around.
I'll let you know once I've got an updated build ready!
Glad you're enjoying the game! We agree that the restart hot key probably should have a confirmation dialog box. Not sure when the next update will actually go out just yet but we do plan to add that feature in it. Thank you for the suggestion!
Thanks for the patience! Looking back it seemed like such an obvious oversight on my part. There's a few bugs with the game still getting ironed out before we push out a proper v1.08 update, but good to know it's working on more real hardware! We hope you enjoy the game!
Hmmm....I notice you're not getting the * Gorgon 2.01 * message on your MT-32 where as Space Quest III *does* print it's intro messages. Is that an Amstrad? I wouldn't have thought that would be an X factor but I'm curious now. Could also be a timing issue where I'm trying to push too much data to the MT-32 too quickly if the CPU is powerful enough. Let me double check and see if I can find a better way to time the messages.
Unfortunately those aren't bugs. We're pretty new to the MT-32 and the current solution for the wind chimes was to use the flute and as for the waterfall we just couldn't find a way to express it via the music system that we were happy with. We've been researching into the more complex side of MT-32 programming with modifying patches but it's still early on yet.
An engine expansion we've toyed around with is possibly using meta data to link missing music tracks with the PCM sound effects pack, but we haven't settled on a particularly elegant solution for that idea.
A lot of this is a hold over from the Tandy 1000 3 Voice Sound mode only days where that was what we had so we made due.
What I will say is this won't be the last non-bug fix patch for the Aching and if we find a better solution we'll readdress some of the more questionable solutions to these challenges we're currently employing.
Tough for me to comment on what emulators are easy or difficult. I've been using DOS since it was relevant and so I have a slightly warped sense of easy of use for it. I'll try and get some perspective and add links accordingly.
As for your question about remaking a game you already have as a .COM file, that's absolutely okay! I might suggest creating a separate page for the .COM version for the sake of the jam tho, so as to keep it clear that it conforms to the restrictions set by the jam.
Hi, sorry for the delayed response! Yes this is that very issue you thought it was. The current build in dev has the fix but owing to how much we're still fixing and adding, it's taking us a bit longer than we'd like.
In response to your curiosity, it is technically a save game glitch. The engine uses a sort of VM and the save files are more or less save stating the VM. There was a bug in the current release that corrupted a few of the core state flags. Sorry for the inconvenience, but as you seem to have found out hitting certain rooms will force a state correction.
We're glad you've been enjoying the experience in spite of the bugs and hope to have the patch out very soon!
lol Yeah, we were made aware of that bug recently. The patch already has the fix for that in place. To be fair, it's the only way you can get the 130th point! The actual max points is supposed to be 129. That one was a basic math error on my part. ^.^;
That is indeed a bug! I'm implementing the fix right now. The current patch in development is fairly substantial so it's taking a bit to complete. We'll put out an announcement when it goes live.
I'm sorry, I thought we had responded to this. Bugs 1 & 3 appear to be fixed in the current version: v 1.04. Bug 2 is being squashed as we speak and #4 I'm looking into. Thank you for reporting these!
