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.