Author Topic: What are we working on?  (Read 133791 times)

0 Members and 1 Guest are viewing this topic.

Offline MusicallyInspired

Re: What are we working on?
« Reply #165 on: August 22, 2017, 04:26:39 PM »
I want it.
Brass Lantern Prop Competition

Offline Kawa

Re: What are we working on?
« Reply #166 on: August 23, 2017, 09:19:34 AM »
Implemented a wordwrapper. It's nice. Basically all that's left is that null pointer when copying game files and more capability detection.

Offline lskovlun

Re: What are we working on?
« Reply #167 on: August 23, 2017, 12:28:09 PM »
Implemented a wordwrapper. It's nice. Basically all that's left is that null pointer when copying game files and more capability detection.
Eeeek, hyphenation is a can of worms. One of the reasons \TeX{} became so popular is that it did it right. But that is a big task.

Offline Kawa

Re: What are we working on?
« Reply #168 on: August 23, 2017, 01:47:00 PM »
I said word wrap, not hyphenate :D

In fact, the output for the introduction message, if I change the company name back to "Sierra", ends up matching Sierra's with regards to wrap points, which is quite a feat when I set the maximum message width to 60 purely on a whim. Trying "Firrhna Productions" in both, the wrapping doesn't match anymore... but at 62 max, it does.

Anyway, I just about finished the script interpreter, added support for the SPACE configuration key (it conflicts with the SPACE command, as it does in Sierra's), made the CD command an internal one instead of shelling out to DOS (might be related to the nullpointer, doesn't match Sierra's), and basically only have more detection to consider. And maybe support for DAC*.DRV and such.

Current EXE size is 58.35 KB, packed to 32.56 KB, with no need for INSTALL.TXT/HLP files. Contrast Sierra's INSTALL.EXE at 74.4 KB, actually 167 KB unpacked, with another 26.5 KB for the TXT/HLP files as of KQ6.



MPU-401 detection only works if DOSBox is set to mpu401=intelligent, as opposed to Sierra detecting both that and UART mode. MPU-401 is now properly detected, checking off MT-32 and GM. Sound Blasters are "detected" by parsing the BLASTER environment variable instead of fiddling with DSP reset commands. Sound Blaster and AdLib are detected by fiddling with ports, or by parsing the BLASTER environment variable depending on #defines and command line parameters. EGA/VGA... I tried, but just check off VGA320, VGA320BW, and EGA640. EGA/VGA are properly detected, I hope. EMM and the mouse are detected in the proper ways.

I could release this now. I have it right here, ready for upload to the stash.
Y/n
« Last Edit: August 24, 2017, 08:15:55 AM by Kawa »

Offline Kawa

Re: What are we working on?
« Reply #169 on: August 27, 2017, 07:08:00 PM »
Y'ever wonder what it'd be like if SCI had one of those textmode ending screens like so many other games? 8)

Offline MusicallyInspired

Re: What are we working on?
« Reply #170 on: August 28, 2017, 01:12:24 AM »
Ooo neat. Taken from vocab is nice.
Brass Lantern Prop Competition

Offline Kawa

Re: What are we working on?
« Reply #171 on: August 28, 2017, 08:04:20 AM »
Here's what you do.

In startasm.s, between ExitFromC endp and end Start, add this:
Code: [Select]
gotoxy proc row: byte, col: byte
mov ah, 2
xor bh, bh
mov dh, row
xor dl, col
int 10h
ret
gotoxy endp
You'll need that because SCI doesn't include the standard library. In start.h, add void gotoxy(char, char); to match.

In start.c, find void exit(char code). Here's my reformatted version of it, with the new stuff marked:
Code: [Select]
void exit(char code)
{
int i;
/**/ Handle hB800;
/**/ volatile char far* vidya = (volatile char far*)0xB8000000;
/**/ char far* b800;

for (i = exitIndex - 1; i >= 0; i--)
exitProcs[i]();

if (panicStr)
WriteString(panicStr);
/**/ else
/**/ {
/**/ if ((hB800 = ResLoad(RES_VOCAB, 184)))
/**/ {
/**/ //I would use memcpy or sumth but it's a shit.
/**/ b800 = (char far*)*hB800;
/**/ for (i = 0; i < 80*25*2; i++)
/**/ *vidya++ = *b800++;
/**/ gotoxy(23, 0);
/**/ }
/**/ else
/**/ WriteString("Couldn't load endscreen.");
/**/ }
/**/ //else if (quitStr)
/**/ // WriteString(quitStr);

ExitFromC(code);
}

Now you just get your favorite screen editor out, save your work in the appropriate format, and use a hex editor of your choice to add [86 00] in front so SCI and Companion can tell it's a vocab. You should have a 4002-byte file.

Another idea might be to have a vocab like the kernel name table that contains a selection of random quit messages to use instead of doing it in script. I propose to use vocab.004 for this.

Offline lskovlun

Re: What are we working on?
« Reply #172 on: August 28, 2017, 08:10:27 AM »
Code: [Select]
void exit(char code)
{
/* ... */
for (i = exitIndex - 1; i >= 0; i--)
exitProcs[i]();

 /* Lots of endscreen code */
/**/ if ((hB800 = ResLoad(RES_VOCAB, 184)))
 /* Lots of endscreen code */
}
I'm a bit surprised this works at all. It runs after the resource manager has been shut down, right?
So you're operating on deallocated resource manager data and loading resources, just hoping it works - could end badly, depending on the situation.

Offline Kawa

Re: What are we working on?
« Reply #173 on: August 28, 2017, 08:39:39 AM »
I'm a bit surprised this works at all. It runs after the resource manager has been shut down, right?
I had exactly the same concern, so before I wrote even a single line I looked for calls to onexit. There's an InitResource call in main, but unlike many other subsystems like video and audio, there's no matching onexit call. I felt it safe enough.

Offline troflip

Re: What are we working on?
« Reply #174 on: November 15, 2017, 12:47:43 AM »
I'm taking a month (or two?) off from working on Cascade Quest to ship 4 short games on Steam. The Steam page for chapter 1 of Snail Trek is up:
http://store.steampowered.com/app/751280/Snail_Trek__Chapter_1_Intershellar/

Trailer is also up here:


Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: What are we working on?
« Reply #175 on: November 15, 2017, 06:19:43 PM »
The 2 GB RAM requirement still gets me.

Offline troflip

Re: What are we working on?
« Reply #176 on: November 15, 2017, 06:38:39 PM »
Well I don't know what the actual hardware requirements are. All I care is that I'm not filtering out people with that stat.  0.34% of Steam users have less than 2GB, so it seems a reasonable place to set it.
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Kawa

Re: What are we working on?
« Reply #177 on: November 15, 2017, 07:50:05 PM »
It's funny cos that's almost exactly what the creator of this one clicker game told me on Twitter.

Then they asked me what I felt was likely. I said it depended on the framework, and if it involved Unity (it likely did) then 2 GB was probably about right.

A goddamn clicker game. Lol forever.

Offline troflip

Re: What are we working on?
« Reply #178 on: November 15, 2017, 08:22:40 PM »
Yup, that guy is the guy who runs my coworking space. A bunch of us are doing "one game a week for a month" to see if little 99 cent games are a feasible income stream on Steam. One guy is doing a box looter game. Another took a bunch of Unity asset store stuff, cobbled it together, and had an online multiplayer car racing game with realistic physics up and running in less than a day. Game engines may be big and bloaty, but the stuff you can accomplish in no time at all is pretty amazing.

This game-a-week project was inspired by stories (in the last month) of someone who spent 7 years on a game which only sold a few thousand copies, vs a guy who spent a week making a game that sold a quarter million copies.

Unfortunately this text parser narrative stuff might take a bit more than one week per game....
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline lance.ewing

Re: What are we working on?
« Reply #179 on: November 04, 2018, 11:31:05 AM »
Projects unrelated to AGI or SCI:

  • A VIC 20 emulator written in Java to run on desktop and Android. This currently doesn't have sound but the rest works quite well. I sometimes play old VIC 20 games on my phone using this.
  • Building a VIC chip (MOS 6561) test board on a large breadboard. This is to experiment with some of the lower level behaviour of the video chip used in the VIC 20. I've got five of these video chips. Had an idea about mixing the video output of three of these together to see what would happen.
  • Reversing the schematic of the VIC 20's video chip from photos of the silicon.
  • Building a 4-bit home brew computer. I have all the components; just haven't put it all together yet.
  • Participating in the annual Javascript 13K game contest (js13kames). I've entered it twice. This year I'm thinking about submitting a graphic adventure game. Will be a challenge.

I thought I'd give an update on what I've been working on over the past 18 months. It has been a bit of the above. I spent quite a bit of time mid last year, through to the end of August, working on those 6561 VIC chip experiments, then I think I switched to the 2017 js13kgames contest like I've been doing most years in August/September over the past five (actually, last year it was a small graphic adventure game that I submitted, but unfortunately it was very small because I ran out of time, as I normally do with the competition. What I might do is build on the small Javascript engine I built for the 2017 competition and enter another graphic adventure in next year's js13kgames. I spent most of the time writing the engine and not enough time for the game).

http://js13kgames.com/entries/down-the-drain

Then after September 2017, I think I was working on item three in the list above, i.e. reverse engineering the logic of the 6561 video chip using the die shot photos. That must have kept be busy until about March this year. It's one of the projects that I've probably spent the most time on over the past 3 years. Then I got distracted by the Oric Atmos home computer, which I'd never really looked at before. I'd always been interested in it, but for some reason I started taking a closer look in March and started working on an emulator, which I'd mostly finished a couple of months after that. I was then busy for a while on a crusade to get die shot photos taken of the custom chip used in the Oric Atmos. I bought a few and sent them to a lab. The photos came back and that caused a bit of a stir in the Oric community. After that I learnt of the existence of a rare home computer called the Polycorp Poly 1, which had been built in New Zealand during the early 1980s. This caught my eye because I grew up in New Zealand but had never heard of this, even though it was supposedly used in schools. I spent quite some time studying the schematic and decided I was going to build an emulator for that computer as well. This effort began with emulating the M6809 CPU, which I've pretty much finished now. This is what I've been most recently working on. Along the way I also discovered that the Vectrex home computer runs on a 6809 cpu, which is now another machine on my list to emulate.

Incidentally, the TRS 80 CoCo 3 runs on a 6809 CPU and has a few AGI games available for it.

A couple of months ago I entered the js13kgames contest again. I was reasonably pleased with my effort. It had a few bugs in it, but I thought it wasn't too bad if you avoided those. Not sure if anyone else thought it was good. I think the kamikaze method of destroying the enemies might have put a few people off, or perhaps it was confusing to know what to do. The idea is to find a few miner machines to bring online then use those machines as a buffer/lifeline so that you can kamikaze a miner into the enemies. I managed to finish playing the game through to its end in just over an hour.

https://js13kgames.com/entries/astro-miners

Now I'm thinking about taking another look at the C# AGI Interpreter, but it will probably be in parallel with the emulators I'm working on.


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.031 seconds with 22 queries.