Community

General and Everything Else => The Games and other Sierra Adventure stuff => Topic started by: Nicktatorship on April 19, 2017, 08:38:36 PM

Title: What are we working on?
Post by: Nicktatorship on April 19, 2017, 08:38:36 PM
So Hi, Nick here, newest member of the forums with all the unbridled energy paradoxically entwined by possibility that comes with it.

Who's about? What are you working on? Are you making a game? Making tools? Got some side-project in the works that completely unrelated to anything on the forums? Let's chat! Let's talk! Let's get stupidly excited!!


My current bit is carrying a notebook around with me, and plotting out a fresher look at my old AGI game, The Lost Planet, incorporating as much of the original concept as I can, while also trying to update and modernise (though still sticking with AGI of course). Some of the time is plotting story, planning rooms or gameplay elements, while also inching back into the world of AGI logic programming. Last night I redid the menu in a new logic file (using WinAGI instead of AGI Studio), being sure to actually document the logics and streamline where I was able.

Expecting that whatever I do short-term will be highly iterative - getting the framework of the game in place, structured well enough that I can redraw or restyle things later. It will mean reusing a lot of the original assets to begin with, but despite the much broader scope intended, hope it won't get too out of control.


Your turn!  :D

Title: Re: What are we working on?
Post by: Kawa on April 19, 2017, 09:10:50 PM
The time is 03:06 AM and I just shut down my laptop after five hours of rendering a 30 frame animation for the full version of The Dating Pool. Tomorrow, or rather in a couple hours I will run a batch process I've prepared earlier to grade and palettize the frames and make a SEQ clip out of it with a relevant tool I made and released some time ago.

Then I will make another, most likely.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 19, 2017, 11:19:40 PM
I've got a little Star Wars SCI1 project going on. Whenever I get the inclination or a spare moment, anyway. I plan to use all manner of palette swapping/transitioning/cycling effects in any interesting way I can think up as the technique fascinates me. But first I need art (the slow part).
Title: Re: What are we working on?
Post by: troflip on April 20, 2017, 12:05:39 AM
Plugging away on Cascade Quest (http://cascadequestgame.com/). Today I worked on probably needless performance tuning, instead of what I should be doing (completing the story and puzzles).
Title: Re: What are we working on?
Post by: lance.ewing on April 20, 2017, 02:25:41 AM
My current active projects:


AGI/SCI projects currently on hold:


AGI project ideas simmering away in my thoughts:


Projects unrelated to AGI or SCI:

Title: Re: What are we working on?
Post by: gumby on April 20, 2017, 06:26:11 PM
Working on a first-person SCI 1.1 version of Zork.
Title: Re: What are we working on?
Post by: Kawa on April 20, 2017, 06:50:30 PM
Rendered the other FMV clip as I said I would. Somehow, a clip that's ten frames longer than the other one took three hours less. Made a cutscene version of the player's apartment (read: the back wall and ceiling aren't slanted and things aren't scaled weirdly for perspective reasons), and have been considering every now and then to try and port SSCI to SDL or something.

I probably won't. Too much ASM to rewrite.

The other idea I have regarding SSCI is to give it another pass and standardize the variable types; instead of void KFoo(word* args) {...} (or void KFoo(args) argList; {...} as it used to be) it'd be something like, well, void KFoo(kernelArg args) {...} or maybe even straight-up KERNEL(Foo) {...} see if I don't. Stuff like that, at any rate.
Title: Re: What are we working on?
Post by: AGKorson on April 21, 2017, 04:33:44 PM
I'm working on a new release of WinAGI. It's got a lot of improvements and bug fixes. Most of the big changes are done (I am still working on an improvement to line editing in the Picture Editor), so hopefully only a few more days of testing, then I'll build and release a beta.

I've decided I need to to something with all the old disk-based games I have - a bunch of Sierra titles, all the AD&D/SSI Goldbox games, a bunch of Microprose games, and others. Hopefully the disks haven't died yet. I was able to get a 5.25 drive USB adaptor, so with that attached to the last system I had with a built-in 3.5 drive, I should be able to capture all the disk images. Maybe this will inspire to play some of them again...

I need to learn C# as well. Once I'm done with WinAGI, I think I'll jump in and see how hard it is for an old dog to learn these fancy new tricks.

I am also trying to get more experience with java because I recently bought a Mazda, and I discovered on the user forums that it's pretty easy to write custom apps for the entertainment system - IF you know java. I wrote a speedometer/clock app, but haven't gotten enough courage to upload it to the car yet. This project's been back-burnered until WinAGI is done.
Title: Re: What are we working on?
Post by: Kawa on April 22, 2017, 05:53:12 PM
Today I worked on the soundtrack for The Dating Pool. I found a pack of CC MIDI files, picked out the stuff I could use, and mutilated it all into something that'd sound good on MT-32 and your average Windows 7 setup alike.

So here's a full recording (http://helmet.kafuka.org/catdate-mt32-full.ogg) featuring part of the Nurykabe MIDI 01 pack by Morusque, and five songs from three H-games that are already in the demo.

You'll notice that "Alhor's Theme" (actually track 2 from Nineteen) has an extra track now (http://helmet.kafuka.org/catdate-19-compare.ogg) to go with the improved instrumentation. Had the silly thing set to channel 1.

It wasn't until I checked the waveform view while trimming the ends that I noticed a couple tracks are particularly loud, almost all of them the old H-game rip songs. Tomorrow, I'll adjust them to better match the Nurykabe songs.

The time right now is 23:53, I'm off to sleep read pony stories in bed, then sleep.
Title: Re: What are we working on?
Post by: troflip on April 22, 2017, 07:13:52 PM
2 days ago I implemented arbitrary rotation support for sprites.

Today I'm implementing scaling, but with linear filtering that remaps the resulting colors to my fixed palette.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 22, 2017, 08:26:16 PM
I love your work, Phil.
Title: Re: What are we working on?
Post by: Kawa on April 22, 2017, 08:40:09 PM
You're a damn cheater, Phil.
Title: Re: What are we working on?
Post by: troflip on April 22, 2017, 11:15:10 PM
You're a damn cheater, Phil.

Scaling is mostly working. I feel bad for you calling me a cheater though, so I present this gif of the scaling in action - but using the dithered colors, so it's legit. It's still doing linear filtering (so it looks much better than Sierra's scaling which does point sampling) and remapping to the undithered colors, but then they are re-dithered as they are presented on screen.

Still some work to do on the scaling, the image is jiggling around more than it should and I think I can fix that.
Title: Re: What are we working on?
Post by: OmerMor on April 23, 2017, 03:48:05 AM
Very nice!
Title: Re: What are we working on?
Post by: spiffythedog on April 23, 2017, 04:33:55 AM
I'm in the final stages of releasing a couple of fan patches (in a similar vein to the SQ1VGA 2.1 patch) for the AGI versions of Space Quest I and II.

Several enhancements and minor bug fixes have been made for both games, as well as the implementation of a few previously unused assets (mostly sound effects and animation loops). No doubt the first thing you'll notice is that Roger's hair is now blonde, and he is wearing his usual standardized uniform (white vest and pants, purple undershirt, black boots, grey badge/patch on left breast):

PS: If anyone owns a copy of v1.0X of SQ1 and hooks me up the relevant logic file, I just might be able to reinsert the Ken Williams Easter egg that was removed in all subsequent versions of the game.


Title: Re: What are we working on?
Post by: Kawa on April 23, 2017, 11:12:01 AM
I said I'd fix the volume. I could've done better, but at least it doesn't get so loud it clips, if the waveform is any indication: new full soundtrack recording (http://helmet.kafuka.org/catdate-mt32-full-v2.ogg)
Title: Re: What are we working on?
Post by: troflip on April 23, 2017, 11:22:34 AM
No doubt the first thing you'll notice is that Roger's hair is now blonde

Noooooooo!

This makes me want to do SQ4, SQ5, and SQ6 patches to turn his hair brown....
Title: Re: What are we working on?
Post by: Kawa on April 23, 2017, 11:24:27 AM
Consistency is king.

And Wendy is queen.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 23, 2017, 06:19:35 PM
I'm in the final stages of releasing a couple of fan patches (in a similar vein to the SQ1VGA 2.1 patch) for the AGI versions of Space Quest I and II.

Several enhancements and minor bug fixes have been made for both games, as well as the implementation of a few previously unused assets (mostly sound effects and animation loops). No doubt the first thing you'll notice is that Roger's hair is now blonde, and he is wearing his usual standardized uniform (white vest and pants, purple undershirt, black boots, grey badge/patch on left breast):

Interesting. I have an old fan patch for SQ1 that someone made where they changed Roger's hair, uniform, and such. I think there was one for SQ2 as well. I think they were called SQ2Eye or something. I don't remember much about it, never played with it really. I just download fanmade things and keep them for posterity. :) Nevertheless this looks cool.

Quote
PS: If anyone owns a copy of v1.0X of SQ1 and hooks me up the relevant logic file, I just might be able to reinsert the Ken Williams Easter egg that was removed in all subsequent versions of the game.

I've got you...

I said I'd fix the volume. I could've done better, but at least it doesn't get so loud it clips, if the waveform is any indication: new full soundtrack recording (http://helmet.kafuka.org/catdate-mt32-full-v2.ogg)

This is quite nice! I love hearing new MT-32 tunes.

No doubt the first thing you'll notice is that Roger's hair is now blonde

Noooooooo!

This makes me want to do SQ4, SQ5, and SQ6 patches to turn his hair brown....

You missed SQ1VGA. Of course, I've already got that covered with SQ1Retro (I should get back to that one of these days). Gave him brown hair and replaced his blue space suit with his grey and red flight suit.
Title: Re: What are we working on?
Post by: spiffythedog on April 24, 2017, 12:49:25 PM
I've got you...
Thanks! Works perfectly.

Noooooooo!

This makes me want to do SQ4, SQ5, and SQ6 patches to turn his hair brown....
Don't worry, I was always going to give people the option of retaining the original Roger graphics. ;D
Title: Re: What are we working on?
Post by: troflip on April 24, 2017, 09:47:38 PM
Don't worry, I was always going to give people the option of retaining the original Roger graphics. ;D

Crisis averted!

I fixed the wiggle problem with the scaling, now it's pixel-perfect centered around the origin of the cel.
Title: Re: What are we working on?
Post by: Collector on April 24, 2017, 10:57:42 PM
Nice!
Title: Re: What are we working on?
Post by: MusicallyInspired on April 24, 2017, 11:11:30 PM
Freaking cool and very attractive! It does look better than SCI1.1's scaling.
Title: Re: What are we working on?
Post by: Kawa on April 25, 2017, 04:11:11 AM
It's like making an SCI11-like game in AGS and enabling smooth scale. Of course it looks better when you don't actually use the color depth you seem to use.

In related but less annoying news, I've been considering how to implement semi-translucency. Brandon might recognize it, but I was thinking of a lookup table created with a lot of Match calls. There don't seem to be any free signal bits but I'm sure some other method could be used to say "this view should be rendered semi-translucently". And/or upside-down. Creating the LUT seems like quite a task so I'd probably not do it automatically when the palette changes, but rather on demand. Of course, if it's a 50% blend about half the table can probably be skipped, and the X=Y case most certainly.
Title: Re: What are we working on?
Post by: spiffythedog on April 25, 2017, 06:27:53 AM
And here they are:

http://sciprogramming.com/community/index.php?topic=1734.0

Have at it.  :)
Title: Re: What are we working on?
Post by: Kawa on April 25, 2017, 11:19:01 AM
I got bored again. (http://helmet.kafuka.org/sci/sprites/)

I wanted to add King's Quest, but that kinda depends on the presence of sideways loops for Graham. Gotta be consistent! fuck that noise let's have a wedding.
Title: Re: What are we working on?
Post by: Nicktatorship on April 27, 2017, 01:08:33 AM
So aside from working out what I want to do, I started poking around with python/SDL2 two nights ago, and made some babysteps on a reader of the Picture format. Not sure why I'm doing it, other than to stretch some old mental muscles, but it's.. alright? Top is the original, and bottom is what the prototype can do.

(http://i.imgur.com/IvUCv7k.jpg)(http://i.imgur.com/EkarGur.jpg)

Most of what it does is create a list of draw commands (as a class) and populates the details of each command. Only the regular lines are drawn currently, which was to verify I had the right structure. In this case the draw is multiplying coordinates rather than mapping to 160x200 and doubling up from there.

It's not much, but it's kinda on this level.
Title: Re: What are we working on?
Post by: Kawa on April 27, 2017, 03:00:48 AM
I was going to say that's more than I could probably manage, but then I realized I'm being a pessimistic shit. BRB trying to whip up an AGI PIC renderer.
Title: Re: What are we working on?
Post by: Nicktatorship on April 27, 2017, 03:10:16 AM
You can do it :) It's really just reading byte by byte, working out what draw command it's trying to do (yay agi wiki reference), storing the list of coordinates, and then firing off some line commands.

Now I'm kinda wondering if it would be possible to do an AGI-to-SCI0 convert for PICs, even if it would turn out awful.
Title: Re: What are we working on?
Post by: Kawa on April 27, 2017, 04:20:25 AM
Well, that works well enough. If you only use absolute lines, and no pens or stairs.

Does the above refer to my attempts to render AGI screens, or to your idea of converting them to SCI? ;)
Title: Re: What are we working on?
Post by: MusicallyInspired on April 27, 2017, 08:42:54 AM
So aside from working out what I want to do, I started poking around with python/SDL2 two nights ago, and made some babysteps on a reader of the Picture format. Not sure why I'm doing it, other than to stretch some old mental muscles, but it's.. alright? Top is the original, and bottom is what the prototype can do.

(http://i.imgur.com/IvUCv7k.jpg)(http://i.imgur.com/EkarGur.jpg)

Most of what it does is create a list of draw commands (as a class) and populates the details of each command. Only the regular lines are drawn currently, which was to verify I had the right structure. In this case the draw is multiplying coordinates rather than mapping to 160x200 and doubling up from there.

It's not much, but it's kinda on this level.

That's neat. You should also try accounting for 4:3 tall pixel resolution since you're upscaling the vectors.
Title: Re: What are we working on?
Post by: troflip on April 27, 2017, 12:49:08 PM
Now I'm kinda wondering if it would be possible to do an AGI-to-SCI0 convert for PICs, even if it would turn out awful.

I think it should be - you'll have to double up on the pixels in order for fills to work properly though, so it'll still look just as chunky as the AGI version. You might be able to do something clever to make the lines full resolution, but I can't offhand think of how exactly...
Title: Re: What are we working on?
Post by: MusicallyInspired on April 27, 2017, 01:46:53 PM
I think Brian wrote one way back when he was developing SCI Studio but it didn't work very well, if at all. I definitely remember a command line program that did it.
Title: Re: What are we working on?
Post by: Kawa on April 27, 2017, 04:09:07 PM
Not chunking up the pixels really breaks the effect, I think.
Title: Re: What are we working on?
Post by: troflip on April 27, 2017, 10:40:06 PM
Came out pretty well, but why is there sand missing behind the top of the building on the left? The roof has moved relative to the sand dune.
Title: Re: What are we working on?
Post by: Nicktatorship on April 28, 2017, 01:16:38 AM
One's from Space Quest 1, and the other is from when you visit SQ1 in Space Quest 4. Probably redrawn/modified.
Title: Re: What are we working on?
Post by: Kawa on April 28, 2017, 03:41:50 AM
Too many details are the same so I'mma say modified.

(https://i.imgur.com/vOSGDsM.gif)

<Screwtape> Also, I hope that door makes the Star Trek door sound.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 28, 2017, 08:32:49 AM
Yeah I've always thought of the SQ1 shots from SQ4 as converted from their AGI counterparts with maybe only some minor pixel touchups, because some elements like the dithering on the roof there are just too similar. The confusing thing is in SQ4EGA, the SQ1 shots have a sort of dithered grey colour instead of solid grey, which is really strange.
Title: Re: What are we working on?
Post by: Kawa on April 28, 2017, 11:06:09 AM
Having seen the EGA pictures and their weirdly inconsistent dithering of the dome buildings, I'mma blame palette sloppiness. Where the source images' white became light(er) gray, I have no idea.

Oddly, the SQ3 screen is perfect in all three versions (SQ3 proper, SQ4 VGA and SQ4 EGA).
Title: Re: What are we working on?
Post by: MusicallyInspired on April 28, 2017, 11:58:35 AM
Yeah. Different people were probably in charge of the EGA conversion. Maybe they converted all the VGA graphics down to EGA instead of converting from AGI directly to EGA and the shade of grey in the VGA version used for the SQ1 screens was not quite close enough to the grey in the EGA palette and nobody bothered to check/fix it. There's no light grey in the SQ3 screen (as far as I know?) so that would be a possible explanation anyway. There's also probably a bit of a difference between converting from SCI0 to SCI1 and AGI to SCI1.
Title: Re: What are we working on?
Post by: Kawa on April 28, 2017, 01:15:52 PM
What's particularly interesting to me is that the SQ3 screen is bitmapped, even though the only missing feature is dithering. Feels like they could've just up and transplanted the same drawing commands if it weren't for the dither.

Bonus fun fact: the original SQ3 screen is pic #65. SQ4's version is #650.

Unrelatedly, here's something dumb I just did to demonstrate loose patch files to Letrune: http://i.imgur.com/frU30p1.png
Title: Re: What are we working on?
Post by: MusicallyInspired on April 28, 2017, 04:51:46 PM
So I've been playing around with the idea of using palette cycling to animate the glow/shimmer effect of a lightsaber. The only problem is it doesn't look right when the palette cycling is just animating linearly. The way I have it drawn the gradient of the blade colour's glow is dither and thenends in transparency. So the palette cycle makes the transparent part appear inside the glow during the cycle obviously. So the most obvious option was to cycle back and forth like a View cel animation can cycle forwards and backwords. I thought this would be fairly simple since I had controlled palettes similarly with transitions (fading in and out of black with the palINTENSITY option) but I realized that this isn't possible in the same with with palANIMATE because you can only control the speed and you can't necessarily keep track of the position or how many times the palette cycling has cycled.

I tried to just put a local variable there that would count the number of cycles and match it up mathematically automatically with the number of colour shifts I want it to make, and then reverse the animation before it goes too far, but it doesn't give the effect I want because it's just not precise enough. Just not reliable. I need a way to tap into when the palette shifts are actually cycling.

EDIT: On second thought, it looks like something is wrong with my code. I am trying to increment the local variable every cycle if it's below a certain value and decrement it if it's higher than another but the value isn't changing at all....what's going on? Does
Code: [Select]
(++CyclePos)
simply not work? I've also tried:
Code: [Select]
(= CyclePos (+ CyclePos 1))
Nothing. I'm PrintF-ing the value every cycle and it never changes from 0.

EDIT 2: Oh never mind. I'm a doofus. Haven't been programming in a while. I didn't have enough checks in my code so both blocks of if statements are incrementing and decrementing the value at the same time and not getting anywhere...sigh...
Title: Re: What are we working on?
Post by: Kawa on April 28, 2017, 05:38:53 PM
Meanwhile, I'm rendering the room from the intro of The Dating Pool in in-game perspective, so I can do the last bit of the girls' conversation with regular actor sprites. Render one thing (the background) and do all the animation in pixels :)
Title: Re: What are we working on?
Post by: MusicallyInspired on April 29, 2017, 03:34:06 PM
Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong? I've added some debug info code which activates if you press a button (only way to quit is force close DOSBox). Game is attached to post. I want to eventually do something more complicated like randomize the shimmer effect (shimmer back and forth at random intervals within the cycle limit instead of just all the way fully forward and backward) to make it look more realistic but I can't get anywhere until I sort out this sync issue.

Here's my script:
Code: [Select]
;;; Sierra Script 1.0 - (do not remove this comment)
(script# TITLEROOM_SCRIPT)
(include sci.sh)
(include Verbs.sh)
(include 0.shm)
(include game.sh)
(use Main)
(use Controls)
(use Print)
(use Cycle)
(use Game)
(use Actor)
(use System)

(public
rm100 0
)

(local
PaletteCycleDirection = 1
ScreenPaletteStart = 71
ScreenPaletteEnd = 87
ColoursShifted = 8
CyclePos = 1
Debug = FALSE
)

(instance myDialog of Dialog
(properties)
)

(instance rm100 of Room
(properties
picture 100
)

(method (init)
; Set port to the entire screen, since our title image is 200px high.
(SetPort 0 0 200 320 0 0)
(if gDialog (gDialog dispose:))
(super init:)
(gOldMH addToFront: self)
(gOldKH addToFront: self)
(gGame setCursor: 996 1)
(gIconBar hide: disable:)
(gUser canInput: TRUE)
(self setScript: rmScript)
)

(method (dispose)
; Restore the port to standard size.
(SetPort 0 0 190 320 10 0)
(gIconBar hide: enable:)
(= gNormalCursor 999)
(gGame setCursor: 996 1)
(gOldKH delete: self)
(gOldMH delete: self)
(super dispose: &rest)
)

(method (handleEvent pEvent)
(if
(and
(!= (rmScript state?) 1)
(&
(pEvent type?)
(| evVERB evMOUSEBUTTON evMOUSERELEASE evKEYBOARD)
)
)
; Skip to state 4 if the keyboard or mouse is used
;(rmScript changeState: 1)
(= Debug TRUE)
(pEvent claimed: TRUE)
(return)
else
(super handleEvent: pEvent)
)
)
)

(instance rmScript of Script
(properties)

(method (doit &tmp onControl)
(super doit:)
(if (== Debug TRUE)
(Printf "CYCLE START\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = UNDETERMINED" ColoursShifted CyclePos PaletteCycleDirection
)
)

(if (> PaletteCycleDirection 0)
(if (== Debug TRUE)
(Printf "1ST CASE = DIRECTION\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = INWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(if (< CyclePos ColoursShifted)
(if (== Debug TRUE)
(Printf "2ND CASE = COLOUR NOT MAX YET\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = INWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(++ CyclePos)
else
(if (== Debug TRUE)
(Printf "2ND CASE = COLOUR IS MAX\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = INWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(= PaletteCycleDirection -1)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(-- CyclePos)
)
else
(if (== Debug TRUE)
(Printf "1ST CASE = DIRECTION\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = OUTWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(if (> CyclePos 1)
(if (== Debug TRUE)
(Printf "2ND CASE = COLOUR NOT MIN YET\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = OUTWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(-- CyclePos)
else
(if (== Debug TRUE)
(Printf "2ND CASE = COLOUR IS MIN\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = OUTWARD" ColoursShifted CyclePos PaletteCycleDirection
)
)
(= PaletteCycleDirection 1)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(++ CyclePos)
)
)
(if (== Debug TRUE)
(Printf "CYCLE END\n
Colours to Shift = %d\n
CyclePos = %d\n
PaletteCycleDirection = %d\n
Shift State = UNDETERMINED" ColoursShifted CyclePos PaletteCycleDirection
)
)
)

(method (changeState newState &tmp temp0 [temp1 10])
(switch (= state newState)
(0 )
; Wait 4 seconds before going to the next state.
(1
(= seconds 0)
(= gNormalCursor 999)
(gGame setCursor: 999 1)
(Print
dialog: myDialog
font: gFont
width: 150
mode: alCENTER
addText: N_TITLEMENU V_LOOK 0 4 0 0 0
addText: N_TITLEMENU V_LOOK 0 5 0 10 0
addColorButton: 0 N_TITLEMENU V_LOOK 0 1 0 20 0 0 11 23 5 5 5
addColorButton: 1 N_TITLEMENU V_LOOK 0 2 0 30 0 0 11 23 5 5 5
)
(= temp0
(Print
addColorButton: 2 N_TITLEMENU V_LOOK 0 3 0 40 0 0 11 23 5 5 5
init:
)
)
(switch temp0
(0 (gRoom newRoom: 110))
(1
(gGame restore:)
(self changeState: state)
)
(2 (= gQuitGame TRUE))
)
)
)
)
)


Here's the code without the Debug print statements if it's hard to read:

Code: [Select]
;;; Sierra Script 1.0 - (do not remove this comment)
(script# TITLEROOM_SCRIPT)
(include sci.sh)
(include Verbs.sh)
(include 0.shm)
(include game.sh)
(use Main)
(use Controls)
(use Print)
(use Cycle)
(use Game)
(use Actor)
(use System)

(public
rm100 0
)

(local
PaletteCycleDirection = 1
ScreenPaletteStart = 71
ScreenPaletteEnd = 87
ColoursShifted = 8
CyclePos = 1
Debug = FALSE
)

(instance myDialog of Dialog
(properties)
)

(instance rm100 of Room
(properties
picture 100
)

(method (init)
; Set port to the entire screen, since our title image is 200px high.
(SetPort 0 0 200 320 0 0)
(if gDialog (gDialog dispose:))
(super init:)
(gOldMH addToFront: self)
(gOldKH addToFront: self)
(gGame setCursor: 996 1)
(gIconBar hide: disable:)
(gUser canInput: TRUE)
(self setScript: rmScript)
)

(method (dispose)
; Restore the port to standard size.
(SetPort 0 0 190 320 10 0)
(gIconBar hide: enable:)
(= gNormalCursor 999)
(gGame setCursor: 996 1)
(gOldKH delete: self)
(gOldMH delete: self)
(super dispose: &rest)
)

(method (handleEvent pEvent)
(if
(and
(!= (rmScript state?) 1)
(&
(pEvent type?)
(| evVERB evMOUSEBUTTON evMOUSERELEASE evKEYBOARD)
)
)
; Skip to state 4 if the keyboard or mouse is used
;(rmScript changeState: 1)
(= Debug TRUE)
(pEvent claimed: TRUE)
(return)
else
(super handleEvent: pEvent)
)
)
)

(instance rmScript of Script
(properties)

(method (doit &tmp onControl)
(super doit:)

(if (> PaletteCycleDirection 0)
(if (< CyclePos ColoursShifted)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(++ CyclePos)
else
(= PaletteCycleDirection -1)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(-- CyclePos)
)
else
(if (> CyclePos 1)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(-- CyclePos)
else
)
(= PaletteCycleDirection 1)
(Palette
palANIMATE
ScreenPaletteStart
ScreenPaletteEnd
PaletteCycleDirection
)
(++ CyclePos)
)
)
)

(method (changeState newState &tmp temp0 [temp1 10])
(switch (= state newState)
(0 )
; Wait 4 seconds before going to the next state.
(1
(= seconds 0)
(= gNormalCursor 999)
(gGame setCursor: 999 1)
(Print
dialog: myDialog
font: gFont
width: 150
mode: alCENTER
addText: N_TITLEMENU V_LOOK 0 4 0 0 0
addText: N_TITLEMENU V_LOOK 0 5 0 10 0
addColorButton: 0 N_TITLEMENU V_LOOK 0 1 0 20 0 0 11 23 5 5 5
addColorButton: 1 N_TITLEMENU V_LOOK 0 2 0 30 0 0 11 23 5 5 5
)
(= temp0
(Print
addColorButton: 2 N_TITLEMENU V_LOOK 0 3 0 40 0 0 11 23 5 5 5
init:
)
)
(switch temp0
(0 (gRoom newRoom: 110))
(1
(gGame restore:)
(self changeState: state)
)
(2 (= gQuitGame TRUE))
)
)
)
)
)
Title: Re: What are we working on?
Post by: lance.ewing on April 29, 2017, 04:14:36 PM
Most of what it does is create a list of draw commands (as a class) and populates the details of each command. Only the regular lines are drawn currently, which was to verify I had the right structure. In this case the draw is multiplying coordinates rather than mapping to 160x200 and doubling up from there.

You might remember from my web site back in the late 90s that I was attempting to draw AGI pictures in hi-res. The main problem I had was with the fills. It's certainly possible to draw the vector graphics in a higher resolution and to have those crisper lines, but the fills tend not to work most of the time. There are multiple reasons for this. One of these in the line drawing algorithm. There are different algorithms for drawing lines that place pixels in different places, and even if you get the algorithm the same, drawing the lines at a higher resolution ends up putting pixels in places that are not compatible with where the fills points are placed. Sometimes in AGI pictures, a single pixel is placed to plug a gap in a area that then gets filled. Drawing that at a higher res obviously won't plug that gap, so the fill spills in to the neighbouring area. Fills sometimes also land on top of lines in hi-res, since I've noticed that fill points are sometimes placed right next to a line, so if the line points differ slightly, the fill might land on a line pixel.

You've also got a problem with the "dithering" effect that some games use, where they draw diagonal lines. Doing that at hi-res needs some kind of intelligence to recognise that its dithering and to scale that up. You can't just draw the lines.

And obviously the "brush" tool isn't going to work at high res, unless you replace them with a higher res pattern.

I've had lots of ideas on how to do it better since my attempts in the 90s. I'd like to try again at some point.

I've never tried it, but I read somewhere that SCUMMVM supported a hi-res AGI mode. Is this true? Has anyone tried it?
Title: Re: What are we working on?
Post by: lance.ewing on April 29, 2017, 04:25:35 PM
Now I'm kinda wondering if it would be possible to do an AGI-to-SCI0 convert for PICs, even if it would turn out awful.

I'm going off memory here, but when I played around with those original Sierra SCI editor tools that Omer leaked a while back, I seem to recall that the SCI picture editor supported both AGI and SCI pictures (via command line options) and might therefore have supported a degree of conversion. Has anyone experimented with that yet?
Title: Re: What are we working on?
Post by: troflip on April 29, 2017, 04:26:13 PM
Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?

If I comment out two the palANIMATE calls (the 2nd and 3rd) it looks better - but I haven't looked into why (I'm not sure what it's suppsoed to look like).

Is there a reason you're using Printf instead of DebugPrint?
Title: Re: What are we working on?
Post by: lance.ewing on April 29, 2017, 04:34:08 PM
Too many details are the same so I'mma say modified.

(https://i.imgur.com/vOSGDsM.gif)

<Screwtape> Also, I hope that door makes the Star Trek door sound.

Ilira is so cool.

As an aside, Chris Pratt would have been a much better James T. Kirk in the new Star Trek movies. He apparently read for the role. Can't believe he didn't get it. He's much better (funnier) than Chris Pine. It would have been awesome.
Title: Re: What are we working on?
Post by: Kawa on April 29, 2017, 04:40:56 PM
I've never tried it, but I read somewhere that SCUMMVM supported a hi-res AGI mode. Is this true? Has anyone tried it?
Can't find it, and you basically just explained why one wouldn't be likely to find it anyway.

Certain render modes in AGI like Hercules use double the resolution to make room for dither patterns, much like EGA640.DRV in SCI, though.
Title: Re: What are we working on?
Post by: lance.ewing on April 29, 2017, 04:44:18 PM
This might be where I saw it:

http://wiki.scummvm.org/index.php/Sarien/Hires_Badness

Look's like it was removed quite a while ago.
Title: Re: What are we working on?
Post by: Kawa on April 29, 2017, 04:49:57 PM
That's not doubling the render resolution, that's filtering the result. Sarien, if I read this right, applied it to the actual bitmap screens (visual and priority), which gave rise to issues. ScummVM would rather apply it to the final render as a whole.
Title: Re: What are we working on?
Post by: lance.ewing on April 29, 2017, 05:01:47 PM
Yeah, I think it's a lost cause. The main reason I gave up on it was that the VIEWs are not vector based, so there would always be a mismatch. How are you meant to scale those up?

And besides, a lot of people like the retro low-res pixelated look, so not much point making it crisper. There's a resurgence.
Title: Re: What are we working on?
Post by: Kawa on April 29, 2017, 05:07:49 PM
With a blocky-ass aesthetic like AGI's, you shouldn't upsample at all, I think. Keep those lego bricks as they are.

Which reminds me of the new KQ's hallucination scene in the fifth chapter, where the so-called AGI graphics aren't. Only some pixels are wide, and the color palette...

So I redrew Old Graham for a laugh. Actual-AGI Knight Graham for comparison.
(https://i.imgur.com/RO8GD5m.png)

(also thanks)
Title: Re: What are we working on?
Post by: MusicallyInspired on April 29, 2017, 07:59:46 PM
Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?

If I comment out two the palANIMATE calls (the 2nd and 3rd) it looks better - but I haven't looked into why (I'm not sure what it's suppsoed to look like).

I've attached a GIF that shows what I'm going for. As you can see by the PIC's palette, if it cycles too far the eight transparent colour entries will start to cycle through next to the core of the blade which is undesireable. That's what the game is currently doing and I can't figure out why. Interesting that removing those animate calls somewhat fixes it. But that would leave pauses in certain cycles, right? I would prefer it to be smooth. After I successfully do this I want to try to regulate it at a slower speed as well (thought changing the cycle speed parameter in palANIMATE doesn't seem to make a difference).

Quote
Is there a reason you're using Printf instead of DebugPrint?

Yes. Because I didn't know it existed. How does that work?
Title: Re: What are we working on?
Post by: troflip on April 29, 2017, 09:00:08 PM
I think you're going to have a tough time cycling the palette back and forth. I don't think the interpreter is predictable in how many cycles it takes to do one shift (even if you call palANIMATE each frame, it doesn't always shift the palette right away). At least that's what I'm seeing (e.g. I tried making 8 calls to palANIMATE and then stopping, and the palette ends up at different places each time I run the game). What a silly implementation Sierra did.

DebugPrint is mentioned here (old syntax, sorry):
http://scicompanion.com/Documentation/debugging.html?highlight=debugging

Title: Re: What are we working on?
Post by: MusicallyInspired on April 29, 2017, 09:09:19 PM
Well that is depressing.
Title: Re: What are we working on?
Post by: troflip on April 29, 2017, 09:37:00 PM
Just make it a regular animated view and cycle through the cels. Much simpler, less code. Attached a view version of it (I think I messed up the handle) to be used with that pic palette.

Code: [Select]
(saber init: setCycle Oscillate -1)


Title: Re: What are we working on?
Post by: MusicallyInspired on April 29, 2017, 11:03:40 PM
I wanted full screen animations. I have these grand visions like the stuff Mark Ferrari did with his color cycling HTML5 stuff with like, say, a closeup of a face fullscreen and a lightsaber blade near their face and the glow of the lightsaber animating as well as the glow on the character's face. It's these types of things I want to experiment with. I know that I can do a View animation but that's too simple.
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 03:50:11 AM
Gotta make it hard on yourself, huh?

he says while contemplating rewriting the cel renderer from ASM back to plain C
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 08:33:28 AM
(http://i.imgur.com/XmFYAw0.png)
Title: Re: What are we working on?
Post by: Collector on April 30, 2017, 11:43:09 AM
MI, have you considered using SEQs?
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 12:08:21 PM
<sarcasm> I consider using SEQs often. </sarcasm>

*sobs quietly in the corner*
Title: Re: What are we working on?
Post by: lskovlun on April 30, 2017, 02:38:24 PM
Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?
Remember that the interpreter cycles in SCI1.1 are not tied to the system clock (unlike in SCI0). The palette cycling effect, on the other hand, is. So your doit: needs to detect how much time has actually passed. GetTime without any arguments will tell you this. The first time you call palANIMATE, use GetTime to figure out the current time in ticks. Then wait until the desired time (by calling GetTime in your doit: to see if the time is right).
GetTime only gives you the low 16 bits of what is internally a 32-bit value, so you'll need to handle the case where it wraps (which it does every 18 minutes; be sure to test this case when you're done coding).

EDIT: Of course, SCI keeps track of active palette cycles, so just call palANIMATE on every cycle, as you usually do. I was referring to the change of direction in the above.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 30, 2017, 04:56:19 PM
Gotta make it hard on yourself, huh?

he says while contemplating rewriting the cel renderer from ASM back to plain C

If I want the outcome I'm envisioning, it's gotta be the hard way. Plus, part of my motivation is that I just really want to open up the possibilities of what colour palette cycling can do. I don't want to just use this on little sprites. Like I said, I want fullscreen impressive visuals. I'm envisioning things like walking form one side of the room to the other with not only the lightsaber glowing, but the walls where the EGO is near glowing as well. I'm not sure how much of that is possible, but if I can think outside the box enough, it's a fun exercise to see if it's possible.

MI, have you considered using SEQs?

Nope. Not near smooth enough.

Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?
Remember that the interpreter cycles in SCI1.1 are not tied to the system clock (unlike in SCI0). The palette cycling effect, on the other hand, is. So your doit: needs to detect how much time has actually passed. GetTime without any arguments will tell you this. The first time you call palANIMATE, use GetTime to figure out the current time in ticks. Then wait until the desired time (by calling GetTime in your doit: to see if the time is right).
GetTime only gives you the low 16 bits of what is internally a 32-bit value, so you'll need to handle the case where it wraps (which it does every 18 minutes; be sure to test this case when you're done coding).

EDIT: Of course, SCI keeps track of active palette cycles, so just call palANIMATE on every cycle, as you usually do. I was referring to the change of direction in the above.

I'm struggling to understand how to code this. Do I wrap the first instance of the palANIMATE and ++CyclePos with a GetTime checking case? This is starting to hurt my brain...I don't do this enough lol.

EDIT: So far the ticks are wildly inconsistent. It doesn't look like I'm going to be able to iterate every tick because each time my code checks the number of ticks it's a lot more than one tick apart. Like, it goes from 68 to 2000 or something. I'm wondering, should I have only one instance of palANIMATE instead of a whole bunch and just let the variables change in each case instead of calling it each time?
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 05:17:36 PM
Nope. Not near smooth enough.
Y'know SEQs play at whatever speed you tell them to, right? CPU limits notwithstanding...
Title: Re: What are we working on?
Post by: MusicallyInspired on April 30, 2017, 05:30:56 PM
Ok, fine. Not near as much control as I could have with palette cycling. I want things changing in real-time like while the ego is moving around, not just a cinematic sequence.
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 05:49:40 PM
...yeah I don't think that's gonna be worth the considerable effort.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 30, 2017, 06:18:22 PM
Your opinion.
Title: Re: What are we working on?
Post by: Kawa on April 30, 2017, 06:19:49 PM
That it is.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 30, 2017, 06:21:48 PM
If I can regulate it all down to a public procedure or two it won't be that much work at all after the heavy lifting is done. It's about as "worthless" as the dynamic iMUSE music in Monkey Island 2's Woodtick section. Yeah, they stopped doing it after that, but it was an incredibly awesome feat and I don't have the limitations of a deadline or a budget like they did.
Title: Re: What are we working on?
Post by: lskovlun on April 30, 2017, 10:56:21 PM
This seems to work. It's not exactly what I wrote above, but it works. I would agree with the others in the simple case of a light sabre that a view (not a SEQ) would work better. But you wrote that you wanted to do larger scenes, in which case something like this is justified.

This doesn't work in ScummVM. I think the many calls to GetTime trigger ScummVM's speed throttler which is ironic, because the aim of the added code is to be a kind of speed throttler.

Another thing, the number of views on the screen will almost certainly have an effect on timing jitter. In this case, there are none, but I assume you intend to add some.

EDIT: Oh, and proper wraparound handling is not implemented.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 01, 2017, 12:13:19 AM
Another thing, the number of views on the screen will almost certainly have an effect on timing jitter. In this case, there are none, but I assume you intend to add some.

DANG IT. Hmmm...does PalVary, palSET_INTENSITY or any other palette functions work the same way as palANIMATE by not being beholden to game ticks? It would be a HECK of a lot more complicated, but what conceivably would be the odds of recreating an entirely new palANIMATE function that worked by ticks instead of cycles?

Thank you for working out that code, by the way. I appreciate that.
Title: Re: What are we working on?
Post by: lskovlun on May 01, 2017, 12:55:04 AM
You can always test it first, to see if you get the performance you need with the number and size of views you plan to have.  Use stopUpd and startUpd as much as possible to minimize the impact of the views that aren't doing anything at the moment. PalVary is another option, but it requires a palette resource and you might end up having to do the same thing I'm doing here for the change of direction. SCI32 would have a couple of additional options, and planes are nice for big scenes... Phil? 8)

I had to remove the debug code, because waiting for the user to dismiss the dialog box takes a few ticks, so it does matter - but that was before I got the code right. It went through a couple of iterations.
Title: Re: What are we working on?
Post by: Kawa on May 02, 2017, 06:34:47 PM
For fun, I added Dating Pool support to ScummVM.

For boredom, I cut it down from 11.7 MB, with the only enabled engine being SCI and no SCI32 support, to 5.4 MB. Right now, after another round of shaving, it's at 4.3 MB. I don't think I can get it any smaller than this without doing intricate things like removing SCI0 support or messing with the theme engine.
Title: Re: What are we working on?
Post by: Nicktatorship on May 02, 2017, 07:53:42 PM
So aside from working out what I want to do, I started poking around with python/SDL2 two nights ago, and made some babysteps on a reader of the Picture format. Not sure why I'm doing it, other than to stretch some old mental muscles, but it's.. alright? Top is the original, and bottom is what the prototype can do.

(http://i.imgur.com/IvUCv7k.jpg)(http://i.imgur.com/EkarGur.jpg)

Most of what it does is create a list of draw commands (as a class) and populates the details of each command. Only the regular lines are drawn currently, which was to verify I had the right structure. In this case the draw is multiplying coordinates rather than mapping to 160x200 and doubling up from there.

It's not much, but it's kinda on this level.

And here's how all that is looking now. Had a friend advise using PIL to handle images, instead of working direct with SDL so I did that, and gradually added code to handle the different draw actions. It probably diverges in places and isn't *quite* finished but it's getting there. I also split out the reader/imager for AGI pics to a class of its own, so I can very neatly call the shambles from other code that is still neat.

The one little bit of different, is that I *also* made it able to spit out a control-lines only image.

Here's the three it can do:

(http://i.imgur.com/k5mj9jN.jpg)
(http://i.imgur.com/fbErd4p.jpg)
(http://i.imgur.com/SJMXR4y.jpg)

It's a bit hacky in the picture class, and would like to make it better in time. Also still need to write the pen/plot tools, and give it the means to generate a picture file back out (from the stored commands on the class in python, *not* from other images).

Still don't know what I'll do with it after this. I doubt I have it in me to write a full-blown AGI interpreter, but I'd like to take this somewhere too. It's certainly been giving me a lot of ideas.


Title: Re: What are we working on?
Post by: AGKorson on May 03, 2017, 01:36:48 PM
That looks really good. I can still see a few pixels here and there that aren't quite right.

What are you using for your line drawing algorithm? The exact algorithm used by Sierra in AGI is pretty simple, and uses only integers. If you implement that algorithm, you'll get lines that come out exactly as Sierra drew them.

Here's a pseudo-code example of the Sierra line algorithm:
Code: [Select]
void drawline(int X1, int Y1, int X2, int Y2)
{
  //assumes X1 != X2 and Y1 != Y2
  //assumes pset knows correct color to set
 
  int xPos, yPos, DX, DY, vDir, hDir;
  int XC, YC, MaxDelta, i;
 
  //determine delta x/delta y and direction
  DY = Y2 - Y1; vDir = (DY<0? -1, 1);
  DX = X2 - X1; hDir = (DX<0? -1, 1);
 
  //set starting pixel
  pset(X1,Y1);
  xPos = X1; yPos = Y1;

  //invert DX and DY if they are negative
  if(DX < 0) DX *= -1;
  if(DY < 0) DY *= -1;
 
  //set up the loop, depending on which direction is largest
  if(DX >= DY) {
    MaxDelta = DX;
    YC = DX / 2;
    XC = 0;
  }
  else {
    MaxDelta = DY;
    XC = DY / 2;
    YC = 0;
  }
  //draw line
  for(i == 1; i == MaxDelta; i++) {
    YC += DY;
    if(YC >= MaxDelta) {
      YC -= MaxDelta;
      yPos += vDir;
    }
    XC += DX;
    if(XC >= MaxDelta) {
      XC -= MaxDelta;
      xPos += hDir;
    }
    pset(xpos, ypos);
  }
}

For plotting, there's good information in the WinAGI help file that explains how to code that, including brush sizes and shapes. For splatter plotting, the actual algorithm that Sierra used is a lot simpler than the bit array in the AGI specifications that has been used for years. Here's the actual Sierra algorithm:
Code: [Select]
//read starting pattern from picture data stream
pattern = pattern | 1
//set starting pixel to first pixel on top row of desired pen shape
do {
    newPatt = pattern >> 2
    if ((pattern & 1) == 1) {
      newPatt = newPatt ^ 0xB8
    }
    pattern = newPatt
    if ((pattern & 3) == 2) {
    //draw this pixel
    }
  }
  //move to next pixel, in left-to-right, top-to-bottom order
while !done //loop until all pixels in desired pen shape are tested

If you haven't already done it, make sure your fill algorithm handles cases where the visual and priority pens are set/not set; if only visual pen is set, fill will use boundary lines it finds in the visual picture; if only priority pen is set, fill will use boundary lines it finds on the priority screen; if both pens are set, fill will set pixels in both images, but will only use the visual screen boundaries it finds.

If you have any questions about AGI resources, take a look at the WinAGI help file - it's got a ton of information. Or you can message me/post here.
Title: Re: What are we working on?
Post by: lance.ewing on May 03, 2017, 06:16:05 PM
The one little bit of different, is that I *also* made it able to spit out a control-lines only image.

I've done something similar in the AGI interpreter I'm working on at the moment, with the exception that the priority screen doesn't show any control lines at all. Instead it uses the original AGI interpreter's algorithm for determining what the priority of a control line pixel should be. I haven't actually looked at it visually yet but my interpreter is using the resulting priority pixel array to make priority decisions and control screen pixel array to make control line decisions and it all seems to work functionally. I was planning to make the debug "show priority" feature show both screens one after the other but have yet to implement this.

Still don't know what I'll do with it after this. I doubt I have it in me to write a full-blown AGI interpreter, but I'd like to take this somewhere too. It's certainly been giving me a lot of ideas.

I'm hoping to work on the C# AGI interpreter to a point where it becomes a kind of reference implementation. The idea is to progressively refactor it over various iterations until it all kind of makes intuitive sense, with everything named and documented cleanly. I was then hoping that at some point in the future (once done) I could pick another language to learn and converting the code would be a matter of replicating the various classes and methods in that language and voil?!  you've have an AGI interpreter in that language. - Edit: If you were to think about a full-blown interpreter, you could hopefully make use of it as a guide. I'm trying to cross reference it against the original AGI source code fragments (found on a SQ2 game disk) as much as possible as I go along.

I will second AGKorson with regards to the line drawing algorithm. The example code in the AGI specs is the original version I came up with over 20 years ago using (literally) trial and error. It seemed to work at the time for all the pictures I tried but was quite inefficient. I wasn't in the habit of actually disassembling code in those days, in fact the first AGI picture drawing program I wrote was in GWBASIC under DOS 3.3 (which I really must dig out and try to run again).
Title: Re: What are we working on?
Post by: Kawa on May 03, 2017, 06:22:49 PM
and viola!
A viola is a slightly larger violin. Did you mean "voil?"?
Title: Re: What are we working on?
Post by: lance.ewing on May 03, 2017, 06:26:08 PM
Indeed I do  :)  Was just in the process of editing it for another reason, so will correct this now while I'm at it.

Edit: I'm somewhat distracted this evening with a break-in we've had at home. I'm up later than I would be, waiting for an emergency glazier to come and board up a ground level window. Have to keep myself occupied with something while I wait.
Title: Re: What are we working on?
Post by: Kawa on May 03, 2017, 07:09:37 PM
Goddamn. Anything gone besides the window and your sense of security?
Title: Re: What are we working on?
Post by: lance.ewing on May 03, 2017, 07:20:20 PM
Yeah, a macbook air, surface pro 4, ipad 3, and a couple of phones (both of which were older models not being used anymore). That's what we know about at the moment. It must have been a quick fill a bag and run I think. Larger items left alone.
Title: Re: What are we working on?
Post by: Nicktatorship on May 03, 2017, 08:33:30 PM
That looks really good. I can still see a few pixels here and there that aren't quite right.

What are you using for your line drawing algorithm? The exact algorithm used by Sierra in AGI is pretty simple, and uses only integers. If you implement that algorithm, you'll get lines that come out exactly as Sierra drew them.

Here's a pseudo-code example of the Sierra line algorithm:
Code: [Select]
void drawline(int X1, int Y1, int X2, int Y2)
{
  //assumes X1 != X2 and Y1 != Y2
  //assumes pset knows correct color to set
 
  int xPos, yPos, DX, DY, vDir, hDir;
  int XC, YC, MaxDelta, i;
 
  //determine delta x/delta y and direction
  DY = Y2 - Y1; vDir = (DY<0? -1, 1);
  DX = X2 - X1; hDir = (DX<0? -1, 1);
 
  //set starting pixel
  pset(X1,Y1);
  xPos = X1; yPos = Y1;

  //invert DX and DY if they are negative
  if(DX < 0) DX *= -1;
  if(DY < 0) DY *= -1;
 
  //set up the loop, depending on which direction is largest
  if(DX >= DY) {
    MaxDelta = DX;
    YC = DX / 2;
    XC = 0;
  }
  else {
    MaxDelta = DY;
    XC = DY / 2;
    YC = 0;
  }
  //draw line
  for(i == 1; i == MaxDelta; i++) {
    YC += DY;
    if(YC >= MaxDelta) {
      YC -= MaxDelta;
      yPos += vDir;
    }
    XC += DX;
    if(XC >= MaxDelta) {
      XC -= MaxDelta;
      xPos += hDir;
    }
    pset(xpos, ypos);
  }
}

For plotting, there's good information in the WinAGI help file that explains how to code that, including brush sizes and shapes. For splatter plotting, the actual algorithm that Sierra used is a lot simpler than the bit array in the AGI specifications that has been used for years. Here's the actual Sierra algorithm:
Code: [Select]
//read starting pattern from picture data stream
pattern = pattern | 1
//set starting pixel to first pixel on top row of desired pen shape
do {
    newPatt = pattern >> 2
    if ((pattern & 1) == 1) {
      newPatt = newPatt ^ 0xB8
    }
    pattern = newPatt
    if ((pattern & 3) == 2) {
    //draw this pixel
    }
  }
  //move to next pixel, in left-to-right, top-to-bottom order
while !done //loop until all pixels in desired pen shape are tested

If you haven't already done it, make sure your fill algorithm handles cases where the visual and priority pens are set/not set; if only visual pen is set, fill will use boundary lines it finds in the visual picture; if only priority pen is set, fill will use boundary lines it finds on the priority screen; if both pens are set, fill will set pixels in both images, but will only use the visual screen boundaries it finds.

If you have any questions about AGI resources, take a look at the WinAGI help file - it's got a ton of information. Or you can message me/post here.

I did see Lance's line-draw algorithm in the picture specs, though this one is literally just using the default line function in the Python Imaging Library. I was lazy, though, so there are a few differences. Also been doing some refactoring (which I may have mentioned) to get things into a separate class that could be used almost standalone in something else.

I'll have to try the method for the brush to see how close I can get - I have a few test PICs I've created to test out the actions my existing art didn't have (e.g. x/y corners or relative lines) so will do the same there. Start making a shell of a View decoder last night, though this time incorporated some improvements to the structure of how bytes are parsed (e.g. making a function to take two bytes, flip the order and scale up the big end appropriately).

-- Interlude --

A long time ago, though not as long ago as my original AGI days, I used to work with a bunch of people to make mods for Lionhead's The Movies, which meant writing python scripts for blender to move information back and forth, to make creating new content for the game much more accessible. I'm sort of using them as a reference/framework for how to structure my scripts, particularly for the new View one.

-- End Interlude --

I've definitely been hitting the wiki and the AGI Help files over the past few weeks, though the latter was more trying to reverse-document my original code for The Lost Planet (since I no longer had the logic text files).

One of the things that's important to me with how I'm approaching the classes, is I'd like to make it so you can programmatically create a resource, whether by adding code or reading from an xml or even just import a PIC and export it back out.


And y'know, since Lance is doing a C# AGI Interpreter (though probably distracted right now because of awful people doing crappy things), and you're doing a new version of WinAGI, here's what's on my mind - is there any thought at the moment to putting together a hypothetical 'v4' interpreter?

Like, incorporating the Hercules-like/(SCI0) interpreter from the start, maybe resolution improvements, or at least, less restrictions on resource numbers? The one that comes to mind is we've had AGI Mouse additions, and certainly we've had it catered for (even in our own games) through ScummVM, but instead of replacing existing 'unknown' commands as the original AGI Mouse implementation did, it'd be plausible for new v4-only ones to be added?

Even things like having a toolset (WinAGI) that didn't have a limit on PIC resource sizes, with an interpreter that didn't either, would be amazing. Nothing I'd be banking on, but is there a potential discussion to be had there?
Title: Re: What are we working on?
Post by: Nicktatorship on May 03, 2017, 08:34:11 PM
Yeah, a macbook air, surface pro 4, ipad 3, and a couple of phones (both of which were older models not being used anymore). That's what we know about at the moment. It must have been a quick fill a bag and run I think. Larger items left alone.

Really sorry to hear that.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 03, 2017, 08:39:44 PM
Geez, Lance, that's terrible I'm sorry that happened.
Title: Re: What are we working on?
Post by: troflip on May 03, 2017, 08:48:43 PM
Ick, sorry to hear about your break-in :-(
Title: Re: What are we working on?
Post by: Collector on May 04, 2017, 02:44:04 PM
Even things like having a toolset (WinAGI) that didn't have a limit on PIC resource sizes, with an interpreter that didn't either, would be amazing. Nothing I'd be banking on, but is there a potential discussion to be had there?

The talk about heap limits in the Cascade Quest thread was making me think of the problem that many fan AGI devs encountered with a blown stack that NAGI was able to deal with, too. I am a bit torn between accuracy of the new interpreter and the ability to work around the original limitations of the stack, but it might be worth while to at least think about addressing the blown stack problem with the C# interpreter.
Title: Re: What are we working on?
Post by: Kawa on May 04, 2017, 02:58:33 PM
Out of heap space!

[Increase and retry] [Halt and catch fire]
Title: Re: What are we working on?
Post by: MusicallyInspired on May 04, 2017, 10:55:10 PM
Out of heap space!

[Increase and retry] [Halt and catch fire]

*selects Increase and retry*

"Oops! You tried something we didn't think of!"
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 02:17:23 PM
I've been working on a backgrounds collection (http://helmet.kafuka.org/backgrounds/) for no good reason.

I have more games, but no tools to rip their background material without resorting to screenshots. This is an issue here because I want just the backgrounds, without any sprites. Sometimes, sprites never move out of the way, and sometimes what you think is part of the background is not (such as the missing facial features (http://helmet.kafuka.org/backgrounds/scumm/loom-ega/room%20055.png) in Loom EGA's closeup shots), or vice versa (such as certain characters' bodies in the Goblins games).

As you may notice, I only have a folder for Kyrandia 2. Kyra1 is... challenging. I have the artwork files, but have to manually match them to palette files and some don't seem to have proper matches...

I can record sprites (https://i.imgur.com/n5jurUq.png) from the Gob games through ScummVM hacks, but the backgrounds are apparently made of separate pieces and I can't quite find a good place to record them from... and recording doesn't do the palette quite right, but what can you do? And of course it requires playing through the whole damn game, so Goblins is right out.

Thankfully, SCI and SCUMM are easy as all hell, and AGI just needed a few more steps.
Title: Re: What are we working on?
Post by: OmerMor on May 05, 2017, 02:48:20 PM
I've been working on a backgrounds collection (http://helmet.kafuka.org/backgrounds/) for no good reason.

I have more games, but no tools to rip their background material without resorting to screenshots. This is an issue here because I want just the backgrounds, without any sprites. Sometimes, sprites never move out of the way, and sometimes what you think is part of the background is not (such as the missing facial features (http://helmet.kafuka.org/backgrounds/scumm/loom-ega/room%20055.png) in Loom EGA's closeup shots), or vice versa (such as certain characters' bodies in the Goblins games).

As you may notice, I only have a folder for Kyrandia 2. Kyra1 is... challenging. I have the artwork files, but have to manually match them to palette files and some don't seem to have proper matches...

I can record sprites (https://i.imgur.com/n5jurUq.png) from the Gob games through ScummVM hacks, but the backgrounds are apparently made of separate pieces and I can't quite find a good place to record them from... and recording doesn't do the palette quite right, but what can you do? And of course it requires playing through the whole damn game, so Goblins is right out.

Thankfully, SCI and SCUMM are easy as all hell, and AGI just needed a few more steps.

That's cool.
But some backgrounds are still missing their complementary views (http://helmet.kafuka.org/backgrounds/sci/police-quest-3/65.p56.png (http://helmet.kafuka.org/backgrounds/sci/police-quest-3/65.p56.png)). Do you plan to add these?
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 02:55:01 PM
If I planned to, I wouldn't have removed the objects in the SCUMM folders -- the extraction tool insisted on dumping and converting everything.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 05, 2017, 04:22:09 PM
Why did AGI require more steps?

EDIT: Also, it looks like you only have backgrounds for one version of KQ4 SCI...
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 05:56:08 PM
I only have the one version... I think. I'll check.

And AGI required more steps because I couldn't just click Export All. So I used SV-CLI to extract and convert the pictures, Paintshop Pro's batch processor to convert them to PNG because PNGOUT wouldn't take them even though it takes any other BMP file I have and ImageMagick frightens me, then another round in PNGOUT to optimize them. Same for QFG3, which crashes SCI Companion's export-all feature. The others only get a combined convert-optimize pass.
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 07:50:46 PM
Both versions of KQ4 are now represented in separate year-marked folders. I'm not gonna bother with the CD version of SQ4, because frankly the altered backgrounds are badly done and it's not exactly as wide a change as KQ4's revision.

Fun fact: the bobalu backdoor is removed in the 1989 version of KQ4.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 05, 2017, 08:19:50 PM
I agree about SQ4. Any plans for Last Crusade EGA, Maniac Mansion Enhanced, Zak McKracken Enhanced, Zak McKracken VGA? Or are you just not finished with SCUMM yet? Because you're also missing The Dig and Curse.
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 08:51:11 PM
These are just the games I have on hand. The ones you listed may come.
Title: Re: What are we working on?
Post by: Collector on May 05, 2017, 09:20:47 PM
Don't forget that there are more versions of KQ4 than just AGI and SCI. Different versions of the SCI had notable differences in some of the backgrounds. http://sciwiki.sierrahelp.com//index.php?title=King%27s_Quest_IV:_The_Perils_of_Rosella#Screenshots
Title: Re: What are we working on?
Post by: Kawa on May 05, 2017, 09:42:44 PM
But Collector, I literally just uploaded the alternate backgrounds :D
Title: Re: What are we working on?
Post by: troflip on May 05, 2017, 10:42:24 PM
Same for QFG3, which crashes SCI Companion's export-all feature. The others only get a combined convert-optimize pass.

Hmm, it doesn't crash for me... Which version of SCI Companion are you using?
Title: Re: What are we working on?
Post by: Kawa on May 06, 2017, 03:08:36 AM
3.1.0.3, compiled from the latest source.

Edit: added The Dig.
Title: Re: What are we working on?
Post by: OmerMor on May 06, 2017, 06:02:08 AM
What about LSL6 lowres?
EGA versions of SCI16 games? (kq5, lsl1, longbow, dr. brain 1, hoyle3, jones, sq1, sq4, lsl5, mumg, pq3)
Title: Re: What are we working on?
Post by: Kawa on May 06, 2017, 06:21:45 AM
LSL6 is the low-res version, and I don't have all of the other games you just listed. But hey, I'll see what I can do.

In unrelated news, here's a tool involving selector tables. Run without parameters and a 997.VOC file in reach to get a 997.TXT, run with only a 997.TXT to get a 997.VOC. Run with both and whichever's newest is converted to replace the oldest. Run with one parameter to switch extensions (easy drag-drop!) or with two to decide both in and output filenames. Comes with the selectors from Sierra's template and Companion's. In the TXT files, //<num> sets a point to start/resume counting so it's nice and sparse. For the record, the kernel's list (selector.h) stops after vanishingY.

Update: KQ5, LSL1/5, Hoyle3, SQ1/4, and PQ3 EGA versions added.
Title: Re: What are we working on?
Post by: lskovlun on May 06, 2017, 11:41:16 AM
I've been working on a backgrounds collection (http://helmet.kafuka.org/backgrounds/) for no good reason.
The "debug buttons"/text on the Kyra2 backgrounds are interesting.
Title: Re: What are we working on?
Post by: AGKorson on May 06, 2017, 12:14:00 PM
I only have the one version... I think. I'll check.

And AGI required more steps because I couldn't just click Export All. So I used SV-CLI to extract and convert the pictures, Paintshop Pro's batch processor to convert them to PNG because PNGOUT wouldn't take them even though it takes any other BMP file I have and ImageMagick frightens me, then another round in PNGOUT to optimize them. Same for QFG3, which crashes SCI Companion's export-all feature. The others only get a combined convert-optimize pass.
If you can wait just a few more days (I plan on realeasing beta of WinAGI 1.2 by 13 May 2017), you'll have a better option. You can export pictures (visual and/or priority) as BMP or GIF, individually, or all at once. I have only implemented these two formats since I haven't had time to figure out how to implement the file format/compression algorithms for PNG and JPG - they're much more complicated. But once you get BMPs or GIFs, I imagine it'd be pretty simple to batch change those into another format using different tool.
Title: Re: What are we working on?
Post by: Kawa on May 06, 2017, 12:47:17 PM
Thanks, but unless I can acquire more games this current method will suffice ;)

(No way I'mma dump all these fangame backgrounds ;D)
Title: Re: What are we working on?
Post by: Kawa on May 07, 2017, 01:00:01 PM
Just for fun, here's what you get when you don't let ScummVM's Gob engine actually draw any sprites:
(https://i.imgur.com/48IQ7mE.png) (https://i.imgur.com/XswjU9H.png) (https://i.imgur.com/5QmhfMP.png) (http://i.imgur.com/xGUhIp9.png)

Which still leaves the lack of palette information and having to actually play the entire game to collect all the screens.
Title: Re: What are we working on?
Post by: Collector on May 07, 2017, 07:28:58 PM
Which still leaves the lack of palette information and having to actually play the entire game to collect all the screens.
And playing the game without the sprites. You could look at it as a challenge.
Title: Re: What are we working on?
Post by: Kawa on May 07, 2017, 08:07:47 PM
Yeah well, Gob is essentially a dead end with regards to this project. I wonder what can be done about Kyrandia...
Title: Re: What are we working on?
Post by: Collector on May 08, 2017, 08:54:07 AM
I know nothing about it, but take a look at this. http://wiki.xentax.com/index.php/The_Legend_of_Kyrandia_trilogy_Toolset
Title: Re: What are we working on?
Post by: Kawa on May 08, 2017, 11:12:23 AM
That's what I used, actually. For Kyra2, most of the screens have their own palette files. For example, DOCK.CPS has a matching DOCK.COL. Only the _*.CPS files don't, with for example _BOOK?.CPS sharing _BOOK.COL. For Kyra1... none of this. I have eleven palette files, 85 screens, and zero clue. I've only managed to match three screens with any certainty, and from simply trying all eleven palettes in a row, there are screens that simply don't ever look right.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 08, 2017, 11:23:16 AM
Would there be a hardcoded palette maybe?
Title: Re: What are we working on?
Post by: Kawa on May 08, 2017, 11:36:28 AM
I don't know. I'm just working on LSL6-SVGA, LSL7, and GK2 now...
Title: Re: What are we working on?
Post by: lskovlun on May 08, 2017, 02:21:35 PM
Would there be a hardcoded palette maybe?
There is definitely some palette stuff in the KYRA.DAT file in the ScummVM distribution. From the tool that creates this file:
Code: [Select]
static const byte k1SpecialPalette10DOSCD[45] = {
        0x29, 0x00, 0x00, 0x26, 0x00, 0x00, 0x24, 0x00,
        0x00, 0x22, 0x00, 0x00, 0x20, 0x00, 0x00, 0x1E,
        0x00, 0x00, 0x1B, 0x00, 0x00, 0x19, 0x00, 0x00,
        0x17, 0x00, 0x00, 0x15, 0x00, 0x00, 0x12, 0x00,
        0x00, 0x11, 0x00, 0x00, 0x0E, 0x00, 0x00, 0x0C,
        0x00, 0x00, 0x0A, 0x00, 0x00
};
There are 33 of them, but they definitely aren't full palettes, all are roughly the same size as this one.
I don't know how they are supposed to be used.
Title: Re: What are we working on?
Post by: Collector on May 08, 2017, 08:02:51 PM
Who did the Krya engine for ScummVM? He may be able to shed some light.
Title: Re: What are we working on?
Post by: Kawa on May 08, 2017, 08:24:18 PM
I'd rather study the code myself before getting more people involved with this. Just something like tracking what files are involved in loading at least one of these screens would be a major hint. Like a floodlight.

What I've learned so far:
I am tempted to do what I did to Gob and simply dump the CPS files to BMP as they are decoded, with whatever the present palette is. Unlike with Gob, there's a handy debug command to switch to any room.
Title: Re: What are we working on?
Post by: Kawa on May 11, 2017, 01:11:01 PM
As seen on Twitter:

Card games on motorcycles? No! Felin mods on card games!
(https://i.imgur.com/kuF25TF.png)
Title: Re: What are we working on?
Post by: troflip on May 11, 2017, 02:22:01 PM
What is that!?
Title: Re: What are we working on?
Post by: Kawa on May 11, 2017, 03:09:30 PM
That's Ilira from The Dating Pool in Hoyle's Classic Card Games.
Title: Re: What are we working on?
Post by: MusicallyInspired on May 11, 2017, 03:26:52 PM
Ugh that skin palette....;)
Title: Re: What are we working on?
Post by: Kawa on May 11, 2017, 03:34:36 PM
What can you do, right?
Title: Re: What are we working on?
Post by: Kawa on May 15, 2017, 10:01:48 AM
Added to the background archive: Maniac Mansion v2, Zak McKracken v2 and FM-Towns, Last Crusade EGA, Sam and Max.
Title: Re: What are we working on?
Post by: Kawa on May 22, 2017, 06:08:15 PM
You've seen (RemapColors rcPERCENT 253 64), which I use to draw a shadow under my Catdate characters. But what about the other remap effects available in SCI16?? Well, given a light view with index 254 in it, nabbed from QfG4...

(RemapColors rcPERCENT 254 200) -- mask color, brightness.
(https://i.imgur.com/73oLA7o.png)
Brightness ranges from 0 to to 200, where 100 is effectively no change. 0 is not entirely all-black, and 200 you can see above. Anything higher yields weird spots.

(RemapColors rcRANGE 254 64 165 96) -- mask color, range start, range end, addition.
(https://i.imgur.com/BHROxNw.gif)
Given a picture with this (https://i.imgur.com/zdf2dYf.png) palette.

(RemapColors rcGRAY 254 75) -- mask color, percentage.
(https://i.imgur.com/6VXTqhI.gif)
Soda pressing.

(RemapColors rcPERCENTGRAY 254 75 120) -- mask color, percentage, brightness.
No visual. Applies both rcPERCENT and rcGRAY effects at once.

? No, I won't stop calling it that >:3
Title: Re: What are we working on?
Post by: Collector on May 22, 2017, 07:11:32 PM
? No, I won't stop calling it that >:3
As opposed to SCI32?
Title: Re: What are we working on?
Post by: Kawa on May 22, 2017, 07:18:44 PM
SCI32 is quite a different beast, what with the planes and all. I'm just calling it SCI16 because that's the name of the archive as OmerMor released it.

You might wonder what documenting RemapColors has to do with this thread, but that's in fact exactly what I was "working on".
Title: Re: What are we working on?
Post by: MusicallyInspired on May 22, 2017, 07:54:38 PM
Fascinating!
Title: Re: What are we working on?
Post by: Kawa on May 22, 2017, 08:25:35 PM
Bonus: it's hard to tell with the light that far up, but just as the shadow effect (rcPERCENT) can stack when two views overlap, so can the other effects.

At least, you'd expect that from how the remap effect is implemented. In the renderer, there's only one code path these remapping colors take.
Title: Re: What are we working on?
Post by: lskovlun on May 23, 2017, 04:29:52 AM
? No, I won't stop calling it that >:3
The polygon editor in QfG4 (SCI32) is out of order, and refers the user to SCI16. So even Sierra did this retroactively.
Title: Re: What are we working on?
Post by: Kawa on May 23, 2017, 01:58:46 PM
Guess who figured out what he was doing wrong with regards to always-on iconbars?

(http://i.imgur.com/dTrChDg.gif)
Title: Re: What are we working on?
Post by: Kawa on May 24, 2017, 04:55:35 PM
(http://i.imgur.com/AXqUdkf.png)
:)
Title: Re: What are we working on?
Post by: Kawa on May 25, 2017, 09:26:00 AM
I just keep doing crazy shit.

https://www.youtube.com/watch?v=Ws_7Fh3uxiw (https://www.youtube.com/watch?v=Ws_7Fh3uxiw)
Quote
Such a cheap hack, it won't even do cue points no doubt.

I don't know what went wrong with the framerate, but the message seems clear.

In engines/sci/sound/soundcmd.cpp:
Code: [Select]
void SoundCommandParser::initSoundResource(MusicEntry *newSound) {
//...
if (g_sci->getGameId() == GID_HOYLE4)
checkAudioResource = false;

char hqFile[50];
sprintf(hqFile, "%d", newSound->resourceId);
newSound->pStreamAud = nullptr; //just making sure.
newSound->pStreamAud = Audio::SeekableAudioStream::openStreamFile(hqFile);
if (newSound->pStreamAud != nullptr)
{
newSound->soundType = Audio::Mixer::kMusicSoundType;
newSound->isSample = true;
return;
}
Title: Re: What are we working on?
Post by: MusicallyInspired on May 25, 2017, 10:32:01 AM
Ew ew ew ew ew ew ew. Someone on the ScummVM forums attempted to do this and create high quality digital music packs for Sierra games as well as other ScummVM supported games and I was vehemently against it because of the lack of loop/cue capabilities that the nature of digital files have. Sorry, I gotta defend my MIDI! ;)

That said, I wonder if it could be utilized to respect metadata loop tags in measurement of samples like certain engines that support digital files do (like EDuke32 and GZDoom with my SC-55 digital music packs (http://sc55.duke4.net/)). That still wouldn't solve the issue for cues (music would be cut off too quickly) but it would work for loops.

What is going on with the speed anyway?
Title: Re: What are we working on?
Post by: Kawa on May 25, 2017, 11:06:41 AM
The speed's just me using incorrectly set up tools or sumth. I don't know, I don't care :)
Title: Re: What are we working on?
Post by: gumby on May 26, 2017, 07:50:11 AM
Working on Zork, specifically scaffolding for moving objects between rooms - in some ways similar to the inventory.  The one thing of note is that all corresponding view instances are created dynamically when a room is init'd.
Title: Re: What are we working on?
Post by: Kawa on June 17, 2017, 10:21:35 AM
Today's project: adding previews to the font archive (http://helmet.kafuka.org/sci/fonts/).
Title: Re: What are we working on?
Post by: Kawa on June 18, 2017, 05:54:38 AM
Been working on the manual for The Dating Pool, and found this in my research:

(http://i.imgur.com/CLrdZfe.png)

...something's fucky.
Title: Re: What are we working on?
Post by: Kawa on July 01, 2017, 06:38:15 PM
I just added an "Advanced" window to my launcher and put the "Show Console" option in there, along with aspect correction, full screen, and shaders. These settings, like show console before them, are stored in resource.cfg because the terp doesn't care, and instead of having a dosbox.conf file the launcher builds a series of command line arguments, basically ending up running something like dosbox .\sierra.exe -exit -c "config -set render aspect=true" -noconsole -scaler advmame3x.

I might add a preview image showing what each scaler looks like. Just a small one.

Next up: if we're running on Windows, use its MIDI API to get a device list and allow setting the midiconfig value from it. If we're not running Windows, just use a textbox instead. Why? Because I have no clue how to populate that list under other OSes! ;D

That icon bar I posted earlier remains fucky to me, and in completely unrelated news my conlang (as seen in my game) is Language of the Month (http://www.conworkshop.com/view_article.php?ns=fbc2095011437e6919086348ac966f9c). Go me.
Title: Re: What are we working on?
Post by: Collector on July 01, 2017, 11:51:25 PM
http://www.dosbox.com/DOSBoxManual.html#MIXER
Title: Re: What are we working on?
Post by: Kawa on July 02, 2017, 06:23:52 AM
Indeed? Interesting little detail about the ports and such.
Title: Re: What are we working on?
Post by: Kawa on July 04, 2017, 02:24:13 PM
And today's reason to double-post:
(http://i.imgur.com/GZsWpCO.gif)
Title: Re: What are we working on?
Post by: MusicallyInspired on July 04, 2017, 07:03:40 PM
Well done!
Title: Re: What are we working on?
Post by: Collector on July 04, 2017, 07:42:45 PM
Nice. I wonder how hard it might be to add a bit of randomness to the wave cycle.
Title: Re: What are we working on?
Post by: Kawa on July 04, 2017, 07:53:04 PM
Well, it's not shown in the gif but the delay is random already, much like the shuttle passing overhead, or Template Guy drinking.
Title: Re: What are we working on?
Post by: Kawa on July 06, 2017, 01:00:00 PM
As shown on Twitter and Tumblr:
(https://68.media.tumblr.com/7808d228b3079d15c29757e58e3c74f6/tumblr_inline_osocq6jQPL1qmrl2s_1280.png)
Title: Re: What are we working on?
Post by: MusicallyInspired on July 06, 2017, 05:34:09 PM
Hehe
Title: Re: What are we working on?
Post by: Kawa on July 06, 2017, 06:24:08 PM
What?
Title: Re: What are we working on?
Post by: MusicallyInspired on July 07, 2017, 01:17:39 AM
I like it. That's neat.
Title: Re: What are we working on?
Post by: Kawa on July 08, 2017, 04:37:07 AM
I've been studying the DRV files a bit.

VGA320:
Code: [Select]
seg000:0000 seg000          segment byte public 'CODE'
seg000:0000                 assume cs:seg000
seg000:0000                 assume es:nothing, ss:nothing, ds:nothing
seg000:0000                 jmp     entry
seg000:0003                 align 2
seg000:0004                 dd 87654321h            ; Driver marker
seg000:0008                 db 0                    ; D_VIDEO
seg000:0009 aDrvID          db 6,'vga320'
seg000:0010 aDrvName        db 43,'VGA or IBM PS2, Models 25 & 30 - 256 Colors' ; not quite right
seg000:003C                 dd 0FEDCBA98h           ; ExtDrv marker
seg000:0040 word_40         dw 80h                  ; VGA
seg000:0042                 align 4
seg000:0044 dispatch        dw offset D_DETECT      ; DATA XREF: seg000:0DA7 (that's in entry --K)
seg000:0046                 dw offset D_INIT
seg000:0048                 dw offset D_TERMINATE
...

VESA:
Code: [Select]
seg000:0000 seg000          segment byte public 'CODE'
seg000:0000                 assume cs:seg000
seg000:0000                 assume es:nothing, ss:nothing, ds:nothing
seg000:0000                 dw 0                    ; There's no jump here, child.
seg000:0002                 dw 0
seg000:0004                 dd 87654321h            ; Driver marker
seg000:0008                 db 0                    ; D_VIDEO
seg000:0009 aDrvID          db 4,'VESA'
seg000:000E aDrvName        db 12,'VESA 640x400'
seg000:001B                 dd 0FEDCBA98h           ; ExtDrv marker
seg000:001F                 dw 80h                  ; VGA
seg000:0021                 dw 0
seg000:0021 seg000          ends                    ; Yup. --K

GENMIDI:
Code: [Select]
seg000:0000 seg000          segment byte public 'CODE'
seg000:0000                 assume cs:seg000
seg000:0000                 assume es:nothing, ss:nothing, ds:nothing
seg000:0000                 jmp     near ptr entry
seg000:0000 ; ---------------------------------------------------------------------------
seg000:0003                 align 2
seg000:0004                 dd 87654321h            ; Driver marker
seg000:0008                 db 1                    ; Music
seg000:0009 aDrvID          db 4,'dude'             ; Most music drivers I've checked have this.
seg000:000E aDrvName        db 37,'General MIDI for Roland MPU interface' ; wait no
seg000:0034                 dd 0FEDCBA98h           ; ExtDrv marker
seg000:0038                 dw 200h                 ; MPU Midi
seg000:003A                 db    0
seg000:003B                 db    0
seg000:003C aV1_08          db 'v1.08'
... ; Dispatch table is much further down.
Title: Re: What are we working on?
Post by: Scavenger on July 09, 2017, 01:48:18 PM
I still can't figure out how to make a new interface for SCI1.1, so I made an AGS game instead in a month:
http://www.adventuregamestudio.co.uk/site/games/game/2170/ !

I'm really quite proud of it.
Title: Re: What are we working on?
Post by: Kawa on July 09, 2017, 05:57:26 PM
My install/setup app is now almost feature-complete. It just needs to show the extra details for devices like the MT-32 (already in its database), extra confirmation, not store a driver setting at all if there are no possible options (because yes, if you remove for example all your video drivers and then save in the original install.exe, it doesn't write a videoDrv line), and yeah I think that's about it besides maybe boot disk creation. I'll most certainly not do any "supported by your system" checks haha I want to live.

The built-in driver database (which is the full set it will recognize, as opposed to install.exe which'll complain on finding an unknown .drv even though they contain their own names and class) has everything from SCI1.1 and earlier, including a bunch of video drivers that won't actually work in practice on an SCI1.1 game, and still the entire thing is a single 28.4 KB file (33.5 if you build with -DISOFONT), opposed to install.exe/hlp/txt totalling 100 KB. Probably even if I did include the F1 descriptions (the \\___.hlp entries) it wouldn't be that large... considering install.exe makes up 74.4 of that 100.

I might make a variant that actually copies/unpacks game data from diskettes to HD, but that'll be instead of picking drivers.

I'm really quite proud of it.
Title: Re: What are we working on?
Post by: Scavenger on July 12, 2017, 03:00:08 PM
Why did you mimick me, Kawa? All I wanted to do was share something I thought y'all might like that I worked hard on. :\
Title: Re: What are we working on?
Post by: Kawa on July 12, 2017, 04:38:04 PM
Because we're both proud of what we did, and your closing line made me smile.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 13, 2017, 10:51:34 AM
Don't take it that way. I don't think that's how he meant it. I like the art style!
Title: Re: What are we working on?
Post by: Kawa on July 13, 2017, 01:08:28 PM
Every now and then I try to extend the GK1-style permanent icon bar into LSL6-style. And fail horribly 8)
Title: Re: What are we working on?
Post by: Kawa on July 23, 2017, 07:09:46 AM
While studying how the Sierra installer handled installing to hard drive, I found a little something in KQ6. So I added KQ6ART.AVI to the background archive as a bonus feature (http://helmet.kafuka.org/backgrounds/sci/kings-quest-6/kq6art/). Too bad it's not 640x480, huh?
Title: Re: What are we working on?
Post by: MusicallyInspired on July 24, 2017, 11:39:20 AM
Yeah, what a tease.
Title: Re: What are we working on?
Post by: Kawa on August 07, 2017, 07:51:57 PM
I've been studying the shit outta that installer. I just found out it does a bunch of tests to determine system capabilities and stores them in a bitfield, such as "is a particular model", "has an MPU-401 interface", "has a Sound Blaster", "has a MediaVision", and "current drive is a CD-ROM"... which considering that's the only place it does such a check iss probably how it knows to offer copying files to HDD instead of only saving RESOURCE.CFG. Not sure how it tells if it's running from a diskette though, but I'd just check if the current drive is < 2 (that'd be C:) and assume A: and B: are always diskette drives.

Kinda feel like writing a custom windowing toolkit with proper control objects, and porting my custom installer to it. Get some proper buttons in it instead of "press Y/N" prompts so you can use the mouse... Besides the main menu not being a list anymore, it'd look pretty much the same.
Title: Re: What are we working on?
Post by: lskovlun on August 07, 2017, 08:48:22 PM
Kinda feel like writing a custom windowing toolkit with proper control objects, and porting my custom installer to it. Get some proper buttons in it instead of "press Y/N" prompts so you can use the mouse... Besides the main menu not being a list anymore, it'd look pretty much the same.
At which point, just having a Win32 app or whatever would be easier and just as good?
Title: Re: What are we working on?
Post by: Kawa on August 07, 2017, 08:57:01 PM
But that wouldn't be a DOS app!
Title: Re: What are we working on?
Post by: MusicallyInspired on August 07, 2017, 10:04:29 PM
"DOS app". That rubs me the wrong way. :P (those two terms together, not DOS programs themselves)
Title: Re: What are we working on?
Post by: Kawa on August 08, 2017, 05:19:38 AM
I was on my phone, ready for sleep. Didn't think to write "program" and couldn't be arsed to write "lication".
Title: Re: What are we working on?
Post by: Kawa on August 22, 2017, 06:56:27 AM
Ka-BOOM!

https://www.youtube.com/watch?v=NglgFROFZd8 (https://www.youtube.com/watch?v=NglgFROFZd8)
Title: Re: What are we working on?
Post by: MusicallyInspired on August 22, 2017, 12:18:32 PM
I love this. Can this be made modular and customized to any game?
Title: Re: What are we working on?
Post by: Kawa on August 22, 2017, 02:03:26 PM
It already works on any SCI0 through SCI11 game. It's a bit less modular than the original in that all the text is internal to the .exe file, as opposed to stored in install.hlp and install.txt, but equally game-specific in that it takes install.scr files for the actual "copy to disk" part.

Recent enhancements: title bars (http://i.imgur.com/Qh1z4Oa.png) and dynamic-width menus (http://i.imgur.com/l2elWmI.png), thus allowing the full name for the MT-32 option, also buttons instead of "press this or that" prompts. (http://i.imgur.com/L9CVdcl.png) There's no mouse control for those, but you can use left/right/tab, enter/escape, and if it's a yes/no question Y/N.
Title: Re: What are we working on?
Post by: lskovlun on August 22, 2017, 02:15:31 PM
Kawa, does this mean there's a game coming out soon?  ;) ;D
Title: Re: What are we working on?
Post by: Kawa on August 22, 2017, 03:44:55 PM
No, but you can have the source to this installer and its binary by next week at the very latest if you want it.
Title: Re: What are we working on?
Post by: MusicallyInspired on August 22, 2017, 04:26:39 PM
I want it.
Title: Re: What are we working on?
Post by: Kawa 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.
Title: Re: What are we working on?
Post by: lskovlun 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.
Title: Re: What are we working on?
Post by: Kawa 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
Title: Re: What are we working on?
Post by: Kawa 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)
Title: Re: What are we working on?
Post by: MusicallyInspired on August 28, 2017, 01:12:24 AM
Ooo neat. Taken from vocab is nice.
Title: Re: What are we working on?
Post by: Kawa 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 (https://xkcd.com/221/).
Title: Re: What are we working on?
Post by: lskovlun 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.
Title: Re: What are we working on?
Post by: Kawa 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.
Title: Re: What are we working on?
Post by: troflip 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:
https://www.youtube.com/watch?v=1kA94ULzDgo

Title: Re: What are we working on?
Post by: Kawa on November 15, 2017, 06:19:43 PM
The 2 GB RAM requirement still gets me.
Title: Re: What are we working on?
Post by: troflip 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.
Title: Re: What are we working on?
Post by: Kawa 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.
Title: Re: What are we working on?
Post by: troflip 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....
Title: Re: What are we working on?
Post by: lance.ewing 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.
Title: Re: What are we working on?
Post by: Collector on November 04, 2018, 03:51:24 PM
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?
Title: Re: What are we working on?
Post by: Kawa on November 04, 2018, 07:21:57 PM
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?
But... Android runs on Java, though?
Title: Re: What are we working on?
Post by: lance.ewing on November 05, 2018, 01:51:17 PM
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?

As far as I know, Java has never run on iOS. Steve Jobs was against it from the start. I think he described it as a big heavyweight ball and chain. To be fair though, he was probably thinking of J2ME at that time, which is what all the phones had prior to that. J2ME has definitely faded away, as have Java applets. I think its still possible to run applets in a browser if you jump through a few hoops, but it is pretty much crippled due to the security lock down on applets. So no one builds applets anymore.

Desktop Java and Android are a different thing though (as is server side Java). Desktop Java is being updated all the time and is regularly getting the latest security patches as far as I know. You just have to keep it up to date.

For Android, most apps are built using Java. Most Android developers would be coding in Java. For the emulators I'm writing, the coding is done in Java using a library called libgdx. It targets several platforms, including desktop, Android, iOS, and HTML5. To code in such a way that it would work when converted to JavaScript and HTML5 is a bit restrictive, so I'm deliberately avoiding the HTML5 support at the moment. Maybe one day I'll take another look at that. I'm also avoiding iOS because there are a few extra things that you have to set up to get that working. Rather than running Java on iOS though, what it does is compile the Java to something that can run on iOS. So its no longer Java anymore. A similar thing with the HTML5 support in libgdx. It compiles the Java to JavaScript. For the desktop and Android versions though, it is Java that you end up with on the other side of the compilation.
Title: Re: What are we working on?
Post by: AGKorson on November 06, 2018, 10:29:02 AM
Incidentally, the TRS 80 CoCo 3 runs on a 6809 CPU and has a few AGI games available for it.
Do you happen to have any copies of these? My first computer was a 16K CoCo. I wish I had saved it. I have an emulator that I fiddle with from time to time, just to remember the 'good old days'.
Title: Re: What are we working on?
Post by: MusicallyInspired on November 06, 2018, 06:13:59 PM
I have KQ3 for the CoCo. Never been able to play it as our CoCo never had enough RAM. But I have it CIB and everything.
Title: Re: What are we working on?
Post by: EricOakford on December 21, 2018, 11:53:33 AM
Fresh off the heels of making the SCI01 Template, I have been using it to create a remake of Residence 44 Quest. I figure that creating a game based off my template will help me fix bugs in the template, and I've learned quite a bit about how SCI works, such as adding objects into the game, imposing conditions on events, etc.

The choice for R44Q was inspired by an old project from 2011 that was to be made with AGS. Now that SCI has been much better documented since, I decided to just use that. With SCI01, I don't think running out of heap space will be as big of a problem as it is with SCI0 (even if R44Q isn't nearly as complex as QFG2).

While I have done a significant amount of work on the scripts (using the original's logics for reference), graphics are not my thing. As a result, I can't yet implement animations (which I put in Print messages as a stand-in) or conditions that check for Ego's position.
Title: Re: What are we working on?
Post by: Kawa on December 21, 2018, 01:01:16 PM
Between The Dating Pool and unrelated stuff, I'm working on a set of command line tools for SCI (https://github.com/Kawa-oneechan/SCITools). Some of them are related to my recently basically-finished UTF-8 hack in SCI11. On that same note, I've been working on a somewhat extensive 0.FON that said tools and terp can make use of.

I'm open for suggestions.

Hmm... having the text file to message tool work both ways like the image to font tool does wouldn't be too hard I don't think... maybe add .sh support...
Title: Re: What are we working on?
Post by: Collector on December 21, 2018, 04:23:52 PM
Nice
Title: Re: What are we working on?
Post by: Kawa on December 21, 2018, 04:38:29 PM
I know, right? Now all I need is to add that .sh support.
Title: Re: What are we working on?
Post by: Collector on December 22, 2018, 10:22:56 AM
Does the strike through edit mean you have added it?
Title: Re: What are we working on?
Post by: Kawa on December 22, 2018, 11:52:15 AM
Yup.
Title: Re: What are we working on?
Post by: Kawa on January 14, 2019, 04:17:14 PM
As you can see if you're so curious as to switch branches on my github, I've been trying to get compression in SeqMaker. (https://github.com/Kawa-oneechan/SCITools/tree/compress/SeqMaker) And dammit all I got so close, but there are still parts where it breaks the frame or even the animation as a whole. And the former is practically guaranteed :(
Title: Re: What are we working on?
Post by: Kawa on January 25, 2019, 08:23:28 PM
You know how in the SCI Companion view editor you have to break flow to switch to the eyedropper tool? In Phil's experimental branch you can right-click instead but that seems a little counter-efficient to me. So today I added control-sampling to my fork. Left and right mouse clicks work as before, but holding control effectively temporarily switches to the eyedropper.

Also I replaced the eyedropper cursor with one of a more sensible size.
Title: Re: What are we working on?
Post by: troflip on January 26, 2019, 07:27:19 PM
So today I added control-sampling to my fork. Left and right mouse clicks work as before, but holding control effectively temporarily switches to the eyedropper.

How does that affect ctrl-resize?
Title: Re: What are we working on?
Post by: Kawa on January 27, 2019, 03:40:57 AM
Not. Resizing works on the edge of the cel, but tools work on the inside. You made it like that yourself.
Title: Re: What are we working on?
Post by: MusicallyInspired on January 27, 2019, 10:39:47 PM
That's awesome. I can't tell you how many times I did that on instinct and was mildly frustrated that it didn't work lol.
Title: Re: What are we working on?
Post by: Kawa on January 31, 2019, 05:37:04 PM
Those who follow my twattle know that I've been studying the window styles of late SCI11 to early SCI2 games. Basically the late 1993 to very early 1994 range, near as I could tell. Because I got second thoughts about the window styles in my game, basically.

The start of it (https://twitter.com/NoxicoDev/status/1090727458964496384) (ft Phil)
Going in-depth on PQ3 and 4's various different styles (https://twitter.com/NoxicoDev/status/1090945695484465153)
Concluding that pretending Catdate is released in 1996 is wrong (https://twitter.com/NoxicoDev/status/1091008980166606848)
Listing all those games (https://twitter.com/NoxicoDev/status/1091050093694906369)

And that ends with an invitation to bikeshed (https://twitter.com/NoxicoDev/status/1091064400910405636). I just went through a few rounds looking at some of these styles actually in-game, and I can't choose.
Title: Re: What are we working on?
Post by: Kawa on February 01, 2019, 01:53:16 PM
Here, have a thing I made.
Title: Re: What are we working on?
Post by: lskovlun on February 01, 2019, 01:59:52 PM
Nice. Perhaps make the color thing an edit instead (or make a color picker too, but that would be a bigger job  8))
Title: Re: What are we working on?
Post by: Kawa on February 01, 2019, 02:21:14 PM
I considered it.
Title: Re: What are we working on?
Post by: Kawa on February 05, 2019, 03:00:12 PM
Here, have another thing.
Title: Re: What are we working on?
Post by: Kawa on March 22, 2019, 04:20:38 PM
I'd hate to triple-post but I released a newly-updated Dating Pool demo earlier today: https://kawa-neechan.itch.io/the-dating-pool
Title: Re: What are we working on?
Post by: lskovlun on March 23, 2019, 01:02:32 PM
@Kawa, I got hit by a missing resource (11.snd) and subsequent crash. When installing the new canister, there was also a wrong message "try aiming it at the empty slot" when I'm actually doing so. The canister does end up installed and the game continues, but the message needs fixing.
Title: Re: What are we working on?
Post by: Kawa on March 23, 2019, 01:44:37 PM
And this mere hours after the new demo got into ScummVM XD
Title: Re: What are we working on?
Post by: Kawa on April 03, 2019, 08:08:06 AM
I've been trying to figure out why in a bunch of different SCI11 games, both fan and original, keyboard control is shot when playing in ScummVM. And I have officially reached my limit.

https://twitter.com/NoxicoDev/status/1112671891246977024 - the discovery
https://twitter.com/NoxicoDev/status/1112796555310972929 - the curveball
https://twitter.com/NoxicoDev/status/1112868008949682176 - the endless logging
https://twitter.com/NoxicoDev/status/1113407856236216320 - the wall... and a revelation!

Turns out ScummVM doesn't handle Contained polygons very well.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 03, 2019, 09:22:05 AM
Yeesh!
Title: Re: What are we working on?
Post by: Kawa on April 03, 2019, 11:29:41 AM
I figured out it's something to do with the determination of the distance between the actor and the considered maybe-nearest point. Since the game checks like 30000 pixels away and the distance function cuts off at 4096, every point was considered equally near. So it picked the first, which was off to the left.

And only for contained access.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 03, 2019, 02:02:25 PM
File a bug report to them?
Title: Re: What are we working on?
Post by: lskovlun on April 03, 2019, 04:20:56 PM
Turns out ScummVM doesn't handle Contained polygons very well.
I can well believe that. Walter wrote the code based on the patent text, which does not mention contained polygons at all. So the behavior of contained polygons was discovered by experimentation. Apparently not enough experimentation; but there are time limits on university projects.

EDIT: I think I have said this before, but it is known that Sierra had a test suite for their polygon code. That would be interesting to get my hands on.
Title: Re: What are we working on?
Post by: Kawa on April 03, 2019, 04:22:54 PM
File a bug report to them?
What I'm wondering is

how did nobody discover this several years ago?
Title: Re: What are we working on?
Post by: troflip on April 03, 2019, 04:28:34 PM
Yeah, that's crazy... not crazy that ScummVM has it wrong, that's understandable - crazy that no one noticed it until now!

Also, as someone who had to implement their own integer polygon pathfinding for this, it's really f***ing hard.
Title: Re: What are we working on?
Post by: Collector on April 03, 2019, 06:44:27 PM
I think I have said this before, but it is known that Sierra had a test suite for their polygon code. That would be interesting to get my hands on.

I wonder if Omer has a contact. Not sure if he has any systems guys in his contact.
Title: Re: What are we working on?
Post by: OmerMor on April 04, 2019, 12:17:17 AM
I don't believe I got any pathfinding test suite.
Title: Re: What are we working on?
Post by: Kawa on April 05, 2019, 04:56:31 PM
So it seems they're working on remaking ScummVM's pathfinder in SSCI's image. I'm gonna be watching the commits even closer now!

And hey. Thanks for the ❤️, OmerMor ;)
Title: Re: What are we working on?
Post by: OmerMor on April 07, 2019, 12:31:13 PM
And hey. Thanks for the ❤️, OmerMor ;)

Thanks for improving ScummVM!  :)
Title: Re: What are we working on?
Post by: Kawa on April 08, 2019, 06:10:07 AM
Did I?
Title: Re: What are we working on?
Post by: OmerMor on April 10, 2019, 12:19:37 PM
Did I?

Yes, you did. (https://github.com/scummvm/scummvm/pull/1574)  :)
Title: Re: What are we working on?
Post by: Kawa on April 10, 2019, 08:11:19 PM
I don't feel like that counts :\
Title: Re: What are we working on?
Post by: MusicallyInspired on April 11, 2019, 09:30:04 AM
Someone there says it might be a regression?
Title: Re: What are we working on?
Post by: Kawa on April 11, 2019, 10:43:05 AM
Someone does. But if it was based on incomplete information anyway, that regression would just be two different implementations based on incomplete information where one of them just happens to give better results. If the plan is to rewrite it based on complete information, that'd be even better.

At least that's how I understood it.
Title: Re: What are we working on?
Post by: MusicallyInspired on April 11, 2019, 03:23:21 PM
Yeah, that makes sense.
Title: Re: What are we working on?
Post by: Kawa on April 11, 2019, 05:01:43 PM
What makes considerably less sense than a polygonal pathfinding patent is the one feature in SCI11+ that's the least likely to appear in ScummVM if only because The Dating Pool doesn't use it¹, and why it keeps shooting me in my goddamn face.

I mean, of course, the part where double or triple-byte UTF8 sequences cause text to measure wider than it really is (https://twitter.com/NoxicoDev/status/1116100672519274498). I've tried rewriting the mentioned function in C but that made it eat the first character of every line after the first (when compiled with UTF8 support, that is), with garbage taking its place after. I backported SCI32's C++ version of the same, but found I was actually pretty close in my attempt, in the sense that it gave exactly the same results.

The shit's on my github if you want it.

(¹: There are plenty more features like that. I have a branch ready to PR.)
Title: Re: What are we working on?
Post by: Kawa on April 12, 2019, 10:20:13 AM
AAAAAH! (https://twitter.com/NoxicoDev/status/1116700400919502849) AAAAAH! (https://github.com/Kawa-oneechan/SCI11-Plus/commit/0349c56d3c7f97ee59af547e530d6f9cea67d59a)
Title: Re: What are we working on?
Post by: lskovlun on April 13, 2019, 01:12:41 AM
AAAAAH! (https://twitter.com/NoxicoDev/status/1116700400919502849) AAAAAH! (https://github.com/Kawa-oneechan/SCI11-Plus/commit/0349c56d3c7f97ee59af547e530d6f9cea67d59a)
I hope you can understand that commit message  8)
Title: Re: What are we working on?
Post by: Kawa on April 13, 2019, 04:10:13 AM
Perfectly well, thank you. It's not exactly drunk coding.

As you know, text resources are quite under-used in SCI11, in favor of messages. The only text resources you can expect to find are some debug format strings. Now, my toolset includes a message converter that can go from the raw message resource to a text file in the same format as SV and back again, with the added ability to have defined names instead of numbers, comment lines, references, and of course UTF8 if the file has a magic marker as the first line.

If I were to make a text resource counterpart and made it use SV-style output too, you'd get this visually strange case where each entry has a number key, but they're not actually part of the file and don't add anything when editing the data for later conversion back to a resource. The only reason to keep them in is to allow multi-line entries: if a line starts with a tab, it's part of the current entry (the message table parser uses a bunch of tabs, and still allows more to be part of the line proper). But if I remove the superfluous numbers, I can't easily tell if a newline ends the current entry, or is actually part of the entry.
Code: [Select]
2 "Leisure Suit Larry in the Land of the Lounge Lizards" contains some elements of plot which may not be considered appropriate for some children.
3 Use the TAB key to select,
then ENTER to continue.
4
5 Sorry, but this game can only be played by adults, or with an adult. Please find an adult, come back, and try again.
I could of course just shrug and make it use escaped newlines to mean the latter?
Code: [Select]
"Leisure Suit Larry in the Land of the Lounge Lizards" contains some elements of plot which may not be considered appropriate for some children.
Use the TAB key to select,\nthen ENTER to continue.

Sorry, but this game can only be played by adults, or with an adult. Please find an adult, come back, and try again.
"But Kawa, what if you want to use the text files to look up which tuple to use?" Well, besides comment lines, obviously you could enable line numbers in your text editor and subtract one to make it zero-based... or you just frikken import the resource and look it up from inside SCI Companion?
Title: Re: What are we working on?
Post by: JRedant on June 29, 2019, 11:54:44 AM
Okay.

After a hiatus and some tinkering around with YouTube streaming, and purchasing some equipment, I'm resurrecting the Werewolves and Wanderer project I worked on in the past.

This time I'm using the SCI 1.1 Engine in SCI Companion (the latest build)

Game Dev (Werewolves and Wanderer): https://www.youtube.com/playlist?list=PLUXBHpzHsJ3oiIP7JKf7vpBQrmp7LqEl7

This is a real time development. Which means the series itself will be dry and boring.

It will give a sense as to exactly how much time is needed to develop one of these things.
Title: Re: What are we working on?
Post by: Kawa on June 29, 2019, 05:10:27 PM
As for me, I'm on-off working on SCI11+ support in ScummVM. Specifically,UTF-8.
Title: Re: What are we working on?
Post by: NilG on June 29, 2019, 09:16:46 PM
I've uploaded the demo for the thing I've been working on...  Unfortunately, I discovered afterwards that some save game files seem to lock up the game when you go to restore.  Most of them seem to be working without issue, but that could definitely be annoying.  That and the Inventory possible-memory menu text aside, though, it should be pretty solid...  If I can sort the occasional save game glitch, it'd be good to reupload.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 01, 2019, 12:00:09 PM
On-off working on KQ2SCI and KQ1VGASCI (which I can't ever really release, but it's fun to work on anyway).
Title: Re: What are we working on?
Post by: OmerMor on July 01, 2019, 12:54:55 PM
On-off working on KQ2SCI and KQ1VGASCI (which I can't ever really release, but it's fun to work on anyway).

Why can't you release that Brandon?
Title: Re: What are we working on?
Post by: MusicallyInspired on July 01, 2019, 03:38:13 PM
Because I'm using assets from AGDI's KQ1VGA AGS remake which is under license that it can only be distributed from AGDI's website and any and all updates must be QC'd by ActiVision.
Title: Re: What are we working on?
Post by: Collector on July 01, 2019, 08:35:17 PM
can you use KQ5 resources?
Title: Re: What are we working on?
Post by: MusicallyInspired on July 01, 2019, 10:57:37 PM
That changes nothing for backgrounds and speech and all the custom animations.
Title: Re: What are we working on?
Post by: Collector on July 02, 2019, 10:42:58 AM
I was only thinking of a starting point. Seems as if most of the Graham views needed could be taken from KQ5.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 02, 2019, 01:14:33 PM
I'm not really that interested in doing the whole game from scratch, though. This way is much faster and gets me practice for SCI1.1. And perhaps in the future I'll be able to release it somehow. I got the source straight from Chris (AGD2) so it's nice to be able to just plug stuff in for the most part. There's stuff I definitely have to play with like converting dialogue portraits from 24-bit colour to 256 colours (hardest part so far). Well, actually 64 colours so that it can only use the first 64 colours of the game's palette that never change throughout the game. The result ends up looking closer to KQ5 and a little more cartoony.
Title: Re: What are we working on?
Post by: Kawa on July 03, 2019, 05:50:12 AM
That's it! That's what irks me about those remakes!
Title: Re: What are we working on?
Post by: Collector on July 03, 2019, 10:07:30 AM
That's it! That's what irks me about those remakes!

The cartooniness?
Title: Re: What are we working on?
Post by: MusicallyInspired on July 03, 2019, 11:49:11 AM
Think he meant too many colours to work with.
Title: Re: What are we working on?
Post by: Kawa on July 03, 2019, 01:51:12 PM
Exactly!

The interface style is a good second.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 04, 2019, 01:52:10 AM
The icon bar?
Title: Re: What are we working on?
Post by: Kawa on July 04, 2019, 03:09:36 AM
Buttons and such.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 04, 2019, 12:26:48 PM
Ah yes. That too. The font wasn't the same and there was no embossing.

What did you think of the whole interface of KQ3Redux? The stone look was supposed to mimic the KQ logo stone wall in every KQ game.
Title: Re: What are we working on?
Post by: Kawa on July 04, 2019, 04:22:09 PM
What I think of KQ3 Redux? Graphically speaking? Well, going by the screenshots on Moby...

Can you really call them VGA remakes when they go above and beyond VGA? Fun fact: if I read this list correctly there are 320x200 VESA modes in 15, 16, and 32 bit color depths. And 8 bit but then you might as well use 13h. I just tested the first one, 10Dh, with a KQ3 Redux screenshot.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 05, 2019, 12:00:55 PM
It's NOT called VGA. That was expressly intentional.
Title: Re: What are we working on?
Post by: Kawa on July 05, 2019, 01:56:21 PM
Tell that to most everybody else who talks about them lol
Title: Re: What are we working on?
Post by: MusicallyInspired on July 05, 2019, 09:07:10 PM
What other people call the game is irrelevant. "Can you really call them VGA remakes...?" We didn't. The end.

Well, the first two were. But even KQ2 was called KQ2VGA+ and eventually just KQ2+. There was a clear attempt to break away from the VGA label.
Title: Re: What are we working on?
Post by: EricOakford on July 20, 2019, 10:07:32 PM
Here's my prototype of a new SCI1.1 template game!
It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts, and lots of fonts.

This new template is in Sierra Script right from the start, and uses original Sierra names for defines, globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.

The graphics are the same as the existing template, but it's quite a different beast script-wise. Then again, Sierra's programmers all had different ways of implementing things.

I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).

Now to bring this to SCI2.1...
Title: Re: What are we working on?
Post by: Collector on July 21, 2019, 10:43:37 AM
I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).

For completeness' sake? It would be nice to have ones for every main SCI version.
Title: Re: What are we working on?
Post by: Kawa on July 21, 2019, 12:50:20 PM
But we can't (de)compile every SCI version 😸
Title: Re: What are we working on?
Post by: OmerMor on July 21, 2019, 02:44:11 PM
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0 (https://github.com/OmerMor/SCI0)

It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.
Title: Re: What are we working on?
Post by: EricOakford on July 21, 2019, 03:21:03 PM
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0 (https://github.com/OmerMor/SCI0)

It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.

Cool! I'd better examine these scripts. One set's from November 30, 1988 (close match to LSL2), the other's from October 25, 1989 (close match to LSL3).
I guess I'd better start working on that SCI0 template and touch up the SCI01 and SCI10 templates, since it may be a while before SCICompanion properly supports SCI2.1.
Title: Re: What are we working on?
Post by: MusicallyInspired on July 21, 2019, 03:28:27 PM
I would love to have an SCI01 template game so I can migrate KQ2SCI over to it and use things like PICTURE scrolling.
Title: Re: What are we working on?
Post by: Collector on July 21, 2019, 08:40:11 PM
Might motivate you to get started on it again.
Title: Re: What are we working on?
Post by: EricOakford on July 23, 2019, 09:23:02 PM
And here it is (https://github.com/EricOakford/SCI0-Template-Redux) - SCI0 Template Redux! Fully in Sierra Script, built off of the Codename Iceman demo, and no assembly blocks anywhere!

Feel free to fix any bugs that you may notice - that's why I put it up on GitHub in the first place.
Title: Re: What are we working on?
Post by: Collector on July 23, 2019, 11:04:05 PM
Nice.
Title: Re: What are we working on?
Post by: EricOakford on August 29, 2019, 11:53:24 AM
Major update on the SCI1.0 template: it has been redone, using the Mixed-Up Fairy Tales demo as the base. That means the interpreter and system scripts are newer, and it has separate drivers for music and digital audio! With that, GMBLAST is not needed any longer. Ego is now played by the white boy from MUFT, and his head moves normally in real-time (as opposed to using cycle speed like in SQ1VGA and SQ4).

Now I see why those timer bugs were present in the CD-ROM version of SQ4, but not the floppy version - it all comes down to the Game class's doit:, which had things like a "gameTime" global added in around late 1991. Unfortunately, the game-specific scripts were not adapted for this upgrade, thus you get things like Roger's head moving super-fast, for example.

You know, I think the SCI16 series of game templates is ready for action.
Title: Re: What are we working on?
Post by: Kawa on August 29, 2019, 01:23:39 PM
Meanwhile I've being working on an SCI-inspired game engine of my own, in C++ with SDL2. I never write proper C++ code (rather, I write C with nice things like auto) but here it is anyway. I originally wanted to use actual SCI as its script system but eventually woke the hell up and switched to Lua, so that's a thing.

https://github.com/Kawa-oneechan/newsci
Title: Re: What are we working on?
Post by: OmerMor on August 29, 2019, 03:48:59 PM
SCI-inspired game engine of my own, in C++

Do you know Sierra actually did something similar with Shivers 2? They pretty much re-wrote SCI in C++.
I don't know if they re-used this engine in any other game afterwards.
Title: Re: What are we working on?
Post by: OmerMor on August 29, 2019, 03:52:27 PM
SCI-inspired game engine of my own, in C++

Do you know Sierra actually did something similar with Shivers 2? They pretty much re-wrote SCI in C++.
I don't know if they re-used this engine in any other game afterwards.

If you're interested, you can actually see Collin Snover's work on re-implementing this game in ScummVM:
https://github.com/csnover/scummvm/tree/shivers2/engines/sci/s2 (https://github.com/csnover/scummvm/tree/shivers2/engines/sci/s2)

Unfortunately, he left ScummVM before completing this.
Title: Re: What are we working on?
Post by: Collector on August 29, 2019, 04:12:22 PM
I knew that Collin had joined ScummVM for SCI1+, but had not heard he had left.

Too bad that there is no source for the Shivers 2 engine. I wonder how different the scripting was from SCI32.
Title: Re: What are we working on?
Post by: OmerMor on August 29, 2019, 04:30:56 PM
I knew that Collin had joined ScummVM for SCI1+, but had not heard he had left.
You can read his resignation mail here:
https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html (https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html)  :'(

Too bad that there is no source for the Shivers 2 engine. I wonder how different the scripting was from SCI32.
Who said there isn't?  ;)
Title: Re: What are we working on?
Post by: Kawa on August 29, 2019, 10:08:39 PM
I don't know what Shivers 2 ran on but I know SCI32 is C++.
Title: Re: What are we working on?
Post by: OmerMor on August 30, 2019, 01:54:11 AM
I don't know what Shivers 2 ran on but I know SCI32 is C++.

I think I was mistaken. I thought you're writing a game engine in which the scripts are compiled and written in C++. Now I noticed the scripts are in LUA.
You're right about SCI32.
Shivers 2 uses C++ both for the engine and the scripts.
Title: Re: What are we working on?
Post by: Kawa on August 30, 2019, 03:26:19 PM
Now I noticed the scripts are in LUA.
I'm just going to pretend those capitals are for emphasis :)
Title: Re: What are we working on?
Post by: Collector on August 30, 2019, 03:30:12 PM
You can read his resignation mail here:
https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html (https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html)  :'(

Wow, I had no idea. I have had some email contact with Eugene in the past, most recently for my installer code for Blade Runner. He was always cordial with me, but that may have been just standard operating procedure for him when reaching out for code. I have felt that many of the ScummVM people do not have that high of an opinion of me, but that may be from the early efforts of adding SCI with complaints about our having the SCI Wiki and hosting the old Free SCI specifications. That along with the undithering nonsense. I cannot say that I really know Colin, but have always gotten along with him since the early days of VOGONS.
Title: Re: What are we working on?
Post by: lskovlun on August 30, 2019, 03:54:18 PM
I don't know what Shivers 2 ran on but I know SCI32 is C++.
Shivers 2 used external (C++) DLLs for all the rooms, but was actually SCI32 underneath. They had a glue layer making the innards of the interpreter callable from the DLLs. Shivers 2 is one of the reasons why I don't believe for a minute that
Quote
But SCI needed to be recoded in order to get the Duck [movie] player into it. [Which is why it is in version 3 whereas the previous game in the Phantasmagoria series used version 2.]
here (http://anthonylarme.tripod.com/phantas/p2inttw.html). It is much more likely that it was being rewritten because they needed to shoehorn that in. Some of the internal changes corroborate it.
Title: Re: What are we working on?
Post by: Kawa on September 09, 2019, 06:27:00 AM
Just for fun, I've been looking into adding long filename support to SCI1+. So that if you run it in Windows 9X or some other environment with Int 21h AX 7100 installed, you can use those.

R&D on Twitter:
https://twitter.com/NoxicoDev/status/1170696375228620800
https://twitter.com/NoxicoDev/status/1170741800870584320
https://twitter.com/NoxicoDev/status/1170948893854580737

Actual code:
https://github.com/Kawa-oneechan/SCI11-Plus/blob/lfn/EXT/FILEIO.S

Go ahead and say it folks. Say "Kawa, your ASM is atrocious."
Title: Re: What are we working on?
Post by: lskovlun on September 09, 2019, 01:36:10 PM
If this had been SCI1.0 you could have called the result SCIDHUVLFN.EXE, but I guess you are left with RESOURCES.000 or AwesomeDriver.DRV ...
Title: Re: What are we working on?
Post by: NilG on November 11, 2019, 02:03:34 AM
Back to it with Sect.  I hope to have one of those elusive full games up here, someday.  ;)  It'll be a while yet, but progress is good.
Title: Re: What are we working on?
Post by: gumby on November 11, 2019, 09:17:45 AM
Picked Zork back up.  I'm starting over with all my visuals (export/import) based on a better understanding of palette management.  Reserving 30-ish colors in each room for color cycling.
Title: Re: What are we working on?
Post by: Kawa on November 12, 2019, 07:46:20 AM
I've been mostly working on a fantasy computer emulator, while waiting for some difficulties in the lives of both me and my writer to pass so we might pick up The Dating Pool again. So the only thing I've done on that recently is replacing the simple railing on the space station screens with a hexagonal design which involved a lot of vector tracing, drawing another cameo or two, and updating another.
Title: Re: What are we working on?
Post by: MusicallyInspired on November 12, 2019, 09:50:52 AM
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
Title: Re: What are we working on?
Post by: Kawa on November 13, 2019, 02:48:17 AM
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
Any relation to your current profile pic?
Title: Re: What are we working on?
Post by: Doan Sephim on November 13, 2019, 08:04:44 AM
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
That's awesome! Best of luck!
Title: Re: What are we working on?
Post by: MusicallyInspired on November 13, 2019, 06:03:03 PM
Thanks!

Any relation to your current profile pic?

Yep. JP, one of the artists, has rendered all the team members in the style of the in-game characters. So we all get neat era-appropriate avatars.