Community
General and Everything Else => The Games and other Sierra Adventure stuff => Topic started 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
-
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.
-
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).
-
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).
-
My current active projects:
- An AGI interpreter written in C#: It's also about learning C# because I didn't know it before starting out. I'm spending a lot of my spare time on this at the moment.
- When I finish the C# AGI interpreter, the plan is to help out with the Visual AGI IDE. I haven't yet contributed to this, but the C# AGI interpreter does make use of it's AGI Library, to which I have made some additions in my fork, such as LOGIC resource decoding.
AGI/SCI projects currently on hold:
- Continuing the work on Dr Zoltan's Java AGI interpreter/viewers. I moved a copy of this to my github account and started adding some AGI v1 support to the LOGIC, PICTURE and VIEW viewers.
- Investigating the content of original AGI and SCI game disk slack space. Originally the idea was to see if there was any original SCI source code but that goal kind of went away when Omer released the original SCI documentation and many examples of the original SCI syntax.
- Version of PICEDIT written in Java. This is already usable and available but I had many plans for taking it further.
- The Ruby Cast
AGI project ideas simmering away in my thoughts:
- Writing AGI interpreters in other computer languages. This would be mainly for learning those languages but would be good for keeping my AGI knowledge fresh.
- Building an AGI IDE in Javascript that uses an interface similar to Scratch with Visual Programming. Desktop apps written in Javascript are getting quite common these days, so the idea would support running standalone or on a website.
- An AGI-like interpreter for the VIC 20. If that proves difficult (due to its resources), I might switch the idea to the C64.
Projects unrelated to AGI or SCI:
- A VIC 20 emulator written in Java to run on desktop and Android. This currently doesn't have sound but the rest works quite well. I sometimes play old VIC 20 games on my phone using this.
- Building a VIC chip (MOS 6561) test board on a large breadboard. This is to experiment with some of the lower level behaviour of the video chip used in the VIC 20. I've got five of these video chips. Had an idea about mixing the video output of three of these together to see what would happen.
- Reversing the schematic of the VIC 20's video chip from photos of the silicon.
- Building a 4-bit home brew computer. I have all the components; just haven't put it all together yet.
- Participating in the annual Javascript 13K game contest (js13kames). I've entered it twice. This year I'm thinking about submitting a graphic adventure game. Will be a challenge.
-
Working on a first-person SCI 1.1 version of Zork.
-
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.
-
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.
-
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.
-
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.
-
I love your work, Phil.
-
You're a damn cheater, Phil.
-
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.
-
Very nice!
-
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.
-
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)
-
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....
-
Consistency is king.
And Wendy is queen.
-
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.
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.
-
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
-
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.
-
Nice!
-
Freaking cool and very attractive! It does look better than SCI1.1's scaling.
-
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.
-
And here they are:
http://sciprogramming.com/community/index.php?topic=1734.0
Have at it. :)
-
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.
-
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.
-
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.
-
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.
-
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? ;)
-
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.
-
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...
-
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.
-
Not chunking up the pixels really breaks the effect, I think.
-
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.
-
One's from Space Quest 1, and the other is from when you visit SQ1 in Space Quest 4. Probably redrawn/modified.
-
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.
-
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.
-
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).
-
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.
-
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
-
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
(++CyclePos)
simply not work? I've also tried:
(= 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...
-
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 :)
-
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:
;;; 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:
;;; 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))
)
)
)
)
)
-
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?
-
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?
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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)
-
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).
Is there a reason you're using Printf instead of DebugPrint?
Yes. Because I didn't know it existed. How does that work?
-
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
-
Well that is depressing.
-
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.
(saber init: setCycle Oscillate -1)
-
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.
-
Gotta make it hard on yourself, huh?
he says while contemplating rewriting the cel renderer from ASM back to plain C
-
(http://i.imgur.com/XmFYAw0.png)
-
MI, have you considered using SEQs?
-
<sarcasm> I consider using SEQs often. </sarcasm>
*sobs quietly in the corner*
-
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.
-
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?
-
Nope. Not near smooth enough.
Y'know SEQs play at whatever speed you tell them to, right? CPU limits notwithstanding...
-
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.
-
...yeah I don't think that's gonna be worth the considerable effort.
-
Your opinion.
-
That it is.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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:
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:
//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.
-
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).
-
and viola!
A viola is a slightly larger violin. Did you mean "voil?"?
-
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.
-
Goddamn. Anything gone besides the window and your sense of security?
-
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.
-
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:
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:
//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?
-
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.
-
Geez, Lance, that's terrible I'm sorry that happened.
-
Ick, sorry to hear about your break-in :-(
-
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.
-
Out of heap space!
[Increase and retry] [Halt and catch fire]
-
Out of heap space!
[Increase and retry] [Halt and catch fire]
*selects Increase and retry*
"Oops! You tried something we didn't think of!"
-
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.
-
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?
-
If I planned to, I wouldn't have removed the objects in the SCUMM folders -- the extraction tool insisted on dumping and converting everything.
-
Why did AGI require more steps?
EDIT: Also, it looks like you only have backgrounds for one version of KQ4 SCI...
-
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.
-
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.
-
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.
-
These are just the games I have on hand. The ones you listed may come.
-
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
-
But Collector, I literally just uploaded the alternate backgrounds :D
-
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?
-
3.1.0.3, compiled from the latest source.
Edit: added The Dig.
-
What about LSL6 lowres?
EGA versions of SCI16 games? (kq5, lsl1, longbow, dr. brain 1, hoyle3, jones, sq1, sq4, lsl5, mumg, pq3)
-
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.
-
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.
-
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.
-
Thanks, but unless I can acquire more games this current method will suffice ;)
(No way I'mma dump all these fangame backgrounds ;D)
-
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.
-
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.
-
Yeah well, Gob is essentially a dead end with regards to this project. I wonder what can be done about Kyrandia...
-
I know nothing about it, but take a look at this. http://wiki.xentax.com/index.php/The_Legend_of_Kyrandia_trilogy_Toolset
-
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.
-
Would there be a hardcoded palette maybe?
-
I don't know. I'm just working on LSL6-SVGA, LSL7, and GK2 now...
-
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:
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.
-
Who did the Krya engine for ScummVM? He may be able to shed some light.
-
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:
- CPS files can contain internal palettes. None of the archived files do, but the loose-leaf TOP.CPS and BOTTOM.CPS do.
- These two are parts of the title screen.
- When loading TOP.CPS no explicit palette pointer is given. Though they both have internal palettes, an explicit palette is given for BOTTOM.CPS.
- There is no palette, internal or passed, for the various other CPS files used throughout, with the exception of MAIN15.CPS, the UI, which has one passed.
- No, the palette from TOP.CPS does not match what TRUNK.CPS needs either.
- CPS2BMP expects the source files to be only 200 lines high. The sprite sheets are not.
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.
-
As seen on Twitter:
Card games on motorcycles? No! Felin mods on card games!
(https://i.imgur.com/kuF25TF.png)
-
What is that!?
-
That's Ilira from The Dating Pool in Hoyle's Classic Card Games.
-
Ugh that skin palette....;)
-
What can you do, right?
-
Added to the background archive: Maniac Mansion v2, Zak McKracken v2 and FM-Towns, Last Crusade EGA, Sam and Max.
-
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
-
? No, I won't stop calling it that >:3
As opposed to SCI32?
-
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".
-
Fascinating!
-
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.
-
? 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.
-
Guess who figured out what he was doing wrong with regards to always-on iconbars?
(http://i.imgur.com/dTrChDg.gif)
-
(http://i.imgur.com/AXqUdkf.png)
:)
-
I just keep doing crazy shit.
https://www.youtube.com/watch?v=Ws_7Fh3uxiw (https://www.youtube.com/watch?v=Ws_7Fh3uxiw)
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:
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;
}
-
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?
-
The speed's just me using incorrectly set up tools or sumth. I don't know, I don't care :)
-
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.
-
Today's project: adding previews to the font archive (http://helmet.kafuka.org/sci/fonts/).
-
Been working on the manual for The Dating Pool, and found this in my research:
(http://i.imgur.com/CLrdZfe.png)
...something's fucky.
-
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.
-
http://www.dosbox.com/DOSBoxManual.html#MIXER
-
Indeed? Interesting little detail about the ports and such.
-
And today's reason to double-post:
(http://i.imgur.com/GZsWpCO.gif)
-
Well done!
-
Nice. I wonder how hard it might be to add a bit of randomness to the wave cycle.
-
Well, it's not shown in the gif but the delay is random already, much like the shuttle passing overhead, or Template Guy drinking.
-
As shown on Twitter and Tumblr:
(https://68.media.tumblr.com/7808d228b3079d15c29757e58e3c74f6/tumblr_inline_osocq6jQPL1qmrl2s_1280.png)
-
Hehe
-
What?
-
I like it. That's neat.
-
I've been studying the DRV files a bit.
VGA320:
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:
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:
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.
-
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.
-
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.
-
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. :\
-
Because we're both proud of what we did, and your closing line made me smile.
-
Don't take it that way. I don't think that's how he meant it. I like the art style!
-
Every now and then I try to extend the GK1-style permanent icon bar into LSL6-style. And fail horribly 8)
-
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?
-
Yeah, what a tease.
-
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.
-
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?
-
But that wouldn't be a DOS app!
-
"DOS app". That rubs me the wrong way. :P (those two terms together, not DOS programs themselves)
-
I was on my phone, ready for sleep. Didn't think to write "program" and couldn't be arsed to write "lication".
-
Ka-BOOM!
https://www.youtube.com/watch?v=NglgFROFZd8 (https://www.youtube.com/watch?v=NglgFROFZd8)
-
I love this. Can this be made modular and customized to any game?
-
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.
-
Kawa, does this mean there's a game coming out soon? ;) ;D
-
No, but you can have the source to this installer and its binary by next week at the very latest if you want it.
-
I want it.
-
Implemented a wordwrapper. It's nice. Basically all that's left is that null pointer when copying game files and more capability detection.
-
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.
-
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
-
Y'ever wonder what it'd be like if SCI had one of those textmode ending screens like so many other games? 8)
-
Ooo neat. Taken from vocab is nice.
-
Here's what you do.
In startasm.s, between ExitFromC endp and end Start, add this:
gotoxy proc row: byte, col: byte
mov ah, 2
xor bh, bh
mov dh, row
xor dl, col
int 10h
ret
gotoxy endpYou'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:
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/).
-
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.
-
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.
-
I'm taking a month (or two?) off from working on Cascade Quest to ship 4 short games on Steam. The Steam page for chapter 1 of Snail Trek is up:
http://store.steampowered.com/app/751280/Snail_Trek__Chapter_1_Intershellar/
Trailer is also up here:
https://www.youtube.com/watch?v=1kA94ULzDgo
-
The 2 GB RAM requirement still gets me.
-
Well I don't know what the actual hardware requirements are. All I care is that I'm not filtering out people with that stat. 0.34% of Steam users have less than 2GB, so it seems a reasonable place to set it.
-
It's funny cos that's almost exactly what the creator of this one clicker game told me on Twitter.
Then they asked me what I felt was likely. I said it depended on the framework, and if it involved Unity (it likely did) then 2 GB was probably about right.
A goddamn clicker game. Lol forever.
-
Yup, that guy is the guy who runs my coworking space. A bunch of us are doing "one game a week for a month" to see if little 99 cent games are a feasible income stream on Steam. One guy is doing a box looter game. Another took a bunch of Unity asset store stuff, cobbled it together, and had an online multiplayer car racing game with realistic physics up and running in less than a day. Game engines may be big and bloaty, but the stuff you can accomplish in no time at all is pretty amazing.
This game-a-week project was inspired by stories (in the last month) of someone who spent 7 years on a game which only sold a few thousand copies, vs a guy who spent a week making a game that sold a quarter million copies.
Unfortunately this text parser narrative stuff might take a bit more than one week per game....
-
Projects unrelated to AGI or SCI:
- A VIC 20 emulator written in Java to run on desktop and Android. This currently doesn't have sound but the rest works quite well. I sometimes play old VIC 20 games on my phone using this.
- Building a VIC chip (MOS 6561) test board on a large breadboard. This is to experiment with some of the lower level behaviour of the video chip used in the VIC 20. I've got five of these video chips. Had an idea about mixing the video output of three of these together to see what would happen.
- Reversing the schematic of the VIC 20's video chip from photos of the silicon.
- Building a 4-bit home brew computer. I have all the components; just haven't put it all together yet.
- Participating in the annual Javascript 13K game contest (js13kames). I've entered it twice. This year I'm thinking about submitting a graphic adventure game. Will be a challenge.
I thought I'd give an update on what I've been working on over the past 18 months. It has been a bit of the above. I spent quite a bit of time mid last year, through to the end of August, working on those 6561 VIC chip experiments, then I think I switched to the 2017 js13kgames contest like I've been doing most years in August/September over the past five (actually, last year it was a small graphic adventure game that I submitted, but unfortunately it was very small because I ran out of time, as I normally do with the competition. What I might do is build on the small Javascript engine I built for the 2017 competition and enter another graphic adventure in next year's js13kgames. I spent most of the time writing the engine and not enough time for the game).
http://js13kgames.com/entries/down-the-drain
Then after September 2017, I think I was working on item three in the list above, i.e. reverse engineering the logic of the 6561 video chip using the die shot photos. That must have kept be busy until about March this year. It's one of the projects that I've probably spent the most time on over the past 3 years. Then I got distracted by the Oric Atmos home computer, which I'd never really looked at before. I'd always been interested in it, but for some reason I started taking a closer look in March and started working on an emulator, which I'd mostly finished a couple of months after that. I was then busy for a while on a crusade to get die shot photos taken of the custom chip used in the Oric Atmos. I bought a few and sent them to a lab. The photos came back and that caused a bit of a stir in the Oric community. After that I learnt of the existence of a rare home computer called the Polycorp Poly 1, which had been built in New Zealand during the early 1980s. This caught my eye because I grew up in New Zealand but had never heard of this, even though it was supposedly used in schools. I spent quite some time studying the schematic and decided I was going to build an emulator for that computer as well. This effort began with emulating the M6809 CPU, which I've pretty much finished now. This is what I've been most recently working on. Along the way I also discovered that the Vectrex home computer runs on a 6809 cpu, which is now another machine on my list to emulate.
Incidentally, the TRS 80 CoCo 3 runs on a 6809 CPU and has a few AGI games available for it.
A couple of months ago I entered the js13kgames contest again. I was reasonably pleased with my effort. It had a few bugs in it, but I thought it wasn't too bad if you avoided those. Not sure if anyone else thought it was good. I think the kamikaze method of destroying the enemies might have put a few people off, or perhaps it was confusing to know what to do. The idea is to find a few miner machines to bring online then use those machines as a buffer/lifeline so that you can kamikaze a miner into the enemies. I managed to finish playing the game through to its end in just over an hour.
https://js13kgames.com/entries/astro-miners
Now I'm thinking about taking another look at the C# AGI Interpreter, but it will probably be in parallel with the emulators I'm working on.
-
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?
-
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?
But... Android runs on Java, though?
-
Given all of the security issues with Java, do they even allow it to run on Droid or iOS these days?
As far as I know, Java has never run on iOS. Steve Jobs was against it from the start. I think he described it as a big heavyweight ball and chain. To be fair though, he was probably thinking of J2ME at that time, which is what all the phones had prior to that. J2ME has definitely faded away, as have Java applets. I think its still possible to run applets in a browser if you jump through a few hoops, but it is pretty much crippled due to the security lock down on applets. So no one builds applets anymore.
Desktop Java and Android are a different thing though (as is server side Java). Desktop Java is being updated all the time and is regularly getting the latest security patches as far as I know. You just have to keep it up to date.
For Android, most apps are built using Java. Most Android developers would be coding in Java. For the emulators I'm writing, the coding is done in Java using a library called libgdx. It targets several platforms, including desktop, Android, iOS, and HTML5. To code in such a way that it would work when converted to JavaScript and HTML5 is a bit restrictive, so I'm deliberately avoiding the HTML5 support at the moment. Maybe one day I'll take another look at that. I'm also avoiding iOS because there are a few extra things that you have to set up to get that working. Rather than running Java on iOS though, what it does is compile the Java to something that can run on iOS. So its no longer Java anymore. A similar thing with the HTML5 support in libgdx. It compiles the Java to JavaScript. For the desktop and Android versions though, it is Java that you end up with on the other side of the compilation.
-
Incidentally, the TRS 80 CoCo 3 runs on a 6809 CPU and has a few AGI games available for it.
Do you happen to have any copies of these? My first computer was a 16K CoCo. I wish I had saved it. I have an emulator that I fiddle with from time to time, just to remember the 'good old days'.
-
I have KQ3 for the CoCo. Never been able to play it as our CoCo never had enough RAM. But I have it CIB and everything.
-
Fresh off the heels of making the SCI01 Template, I have been using it to create a remake of Residence 44 Quest. I figure that creating a game based off my template will help me fix bugs in the template, and I've learned quite a bit about how SCI works, such as adding objects into the game, imposing conditions on events, etc.
The choice for R44Q was inspired by an old project from 2011 that was to be made with AGS. Now that SCI has been much better documented since, I decided to just use that. With SCI01, I don't think running out of heap space will be as big of a problem as it is with SCI0 (even if R44Q isn't nearly as complex as QFG2).
While I have done a significant amount of work on the scripts (using the original's logics for reference), graphics are not my thing. As a result, I can't yet implement animations (which I put in Print messages as a stand-in) or conditions that check for Ego's position.
-
Between The Dating Pool and unrelated stuff, I'm working on a set of command line tools for SCI (https://github.com/Kawa-oneechan/SCITools). Some of them are related to my recently basically-finished UTF-8 hack in SCI11. On that same note, I've been working on a somewhat extensive 0.FON that said tools and terp can make use of.
I'm open for suggestions.
Hmm... having the text file to message tool work both ways like the image to font tool does wouldn't be too hard I don't think... maybe add .sh support...
-
Nice
-
I know, right?
Now all I need is to add that .sh support.
-
Does the strike through edit mean you have added it?
-
Yup.
-
As you can see if you're so curious as to switch branches on my github, I've been trying to get compression in SeqMaker. (https://github.com/Kawa-oneechan/SCITools/tree/compress/SeqMaker) And dammit all I got so close, but there are still parts where it breaks the frame or even the animation as a whole. And the former is practically guaranteed :(
-
You know how in the SCI Companion view editor you have to break flow to switch to the eyedropper tool? In Phil's experimental branch you can right-click instead but that seems a little counter-efficient to me. So today I added control-sampling to my fork. Left and right mouse clicks work as before, but holding control effectively temporarily switches to the eyedropper.
Also I replaced the eyedropper cursor with one of a more sensible size.
-
So today I added control-sampling to my fork. Left and right mouse clicks work as before, but holding control effectively temporarily switches to the eyedropper.
How does that affect ctrl-resize?
-
Not. Resizing works on the edge of the cel, but tools work on the inside. You made it like that yourself.
-
That's awesome. I can't tell you how many times I did that on instinct and was mildly frustrated that it didn't work lol.
-
Those who follow my twattle know that I've been studying the window styles of late SCI11 to early SCI2 games. Basically the late 1993 to very early 1994 range, near as I could tell. Because I got second thoughts about the window styles in my game, basically.
The start of it (https://twitter.com/NoxicoDev/status/1090727458964496384) (ft Phil)
Going in-depth on PQ3 and 4's various different styles (https://twitter.com/NoxicoDev/status/1090945695484465153)
Concluding that pretending Catdate is released in 1996 is wrong (https://twitter.com/NoxicoDev/status/1091008980166606848)
Listing all those games (https://twitter.com/NoxicoDev/status/1091050093694906369)
And that ends with an invitation to bikeshed (https://twitter.com/NoxicoDev/status/1091064400910405636). I just went through a few rounds looking at some of these styles actually in-game, and I can't choose.
-
Here, have a thing I made.
-
Nice. Perhaps make the color thing an edit instead (or make a color picker too, but that would be a bigger job 8))
-
I considered it.
-
Here, have another thing.
-
I'd hate to triple-post but I released a newly-updated Dating Pool demo earlier today: https://kawa-neechan.itch.io/the-dating-pool
-
@Kawa, I got hit by a missing resource (11.snd) and subsequent crash. When installing the new canister, there was also a wrong message "try aiming it at the empty slot" when I'm actually doing so. The canister does end up installed and the game continues, but the message needs fixing.
-
And this mere hours after the new demo got into ScummVM XD
-
I've been trying to figure out why in a bunch of different SCI11 games, both fan and original, keyboard control is shot when playing in ScummVM. And I have officially reached my limit.
https://twitter.com/NoxicoDev/status/1112671891246977024 - the discovery
https://twitter.com/NoxicoDev/status/1112796555310972929 - the curveball
https://twitter.com/NoxicoDev/status/1112868008949682176 - the endless logging
https://twitter.com/NoxicoDev/status/1113407856236216320 - the wall... and a revelation!
Turns out ScummVM doesn't handle Contained polygons very well.
-
Yeesh!
-
I figured out it's something to do with the determination of the distance between the actor and the considered maybe-nearest point. Since the game checks like 30000 pixels away and the distance function cuts off at 4096, every point was considered equally near. So it picked the first, which was off to the left.
And only for contained access.
-
File a bug report to them?
-
Turns out ScummVM doesn't handle Contained polygons very well.
I can well believe that. Walter wrote the code based on the patent text, which does not mention contained polygons at all. So the behavior of contained polygons was discovered by experimentation. Apparently not enough experimentation; but there are time limits on university projects.
EDIT: I think I have said this before, but it is known that Sierra had a test suite for their polygon code. That would be interesting to get my hands on.
-
File a bug report to them?
What I'm wondering is
how did nobody discover this several years ago?
-
Yeah, that's crazy... not crazy that ScummVM has it wrong, that's understandable - crazy that no one noticed it until now!
Also, as someone who had to implement their own integer polygon pathfinding for this, it's really f***ing hard.
-
I think I have said this before, but it is known that Sierra had a test suite for their polygon code. That would be interesting to get my hands on.
I wonder if Omer has a contact. Not sure if he has any systems guys in his contact.
-
I don't believe I got any pathfinding test suite.
-
So it seems they're working on remaking ScummVM's pathfinder in SSCI's image. I'm gonna be watching the commits even closer now!
And hey. Thanks for the ❤️, OmerMor ;)
-
And hey. Thanks for the ❤️, OmerMor ;)
Thanks for improving ScummVM! :)
-
Did I?
-
Did I?
Yes, you did. (https://github.com/scummvm/scummvm/pull/1574) :)
-
I don't feel like that counts :\
-
Someone there says it might be a regression?
-
Someone does. But if it was based on incomplete information anyway, that regression would just be two different implementations based on incomplete information where one of them just happens to give better results. If the plan is to rewrite it based on complete information, that'd be even better.
At least that's how I understood it.
-
Yeah, that makes sense.
-
What makes considerably less sense than a polygonal pathfinding patent is the one feature in SCI11+ that's the least likely to appear in ScummVM if only because The Dating Pool doesn't use it¹, and why it keeps shooting me in my goddamn face.
I mean, of course, the part where double or triple-byte UTF8 sequences cause text to measure wider than it really is (https://twitter.com/NoxicoDev/status/1116100672519274498). I've tried rewriting the mentioned function in C but that made it eat the first character of every line after the first (when compiled with UTF8 support, that is), with garbage taking its place after. I backported SCI32's C++ version of the same, but found I was actually pretty close in my attempt, in the sense that it gave exactly the same results.
The shit's on my github if you want it.
(¹: There are plenty more features like that. I have a branch ready to PR.)
-
AAAAAH! (https://twitter.com/NoxicoDev/status/1116700400919502849) AAAAAH! (https://github.com/Kawa-oneechan/SCI11-Plus/commit/0349c56d3c7f97ee59af547e530d6f9cea67d59a)
-
AAAAAH! (https://twitter.com/NoxicoDev/status/1116700400919502849) AAAAAH! (https://github.com/Kawa-oneechan/SCI11-Plus/commit/0349c56d3c7f97ee59af547e530d6f9cea67d59a)
I hope you can understand that commit message 8)
-
Perfectly well, thank you. It's not exactly drunk coding.
As you know, text resources are quite under-used in SCI11, in favor of messages. The only text resources you can expect to find are some debug format strings. Now, my toolset includes a message converter that can go from the raw message resource to a text file in the same format as SV and back again, with the added ability to have defined names instead of numbers, comment lines, references, and of course UTF8 if the file has a magic marker as the first line.
If I were to make a text resource counterpart and made it use SV-style output too, you'd get this visually strange case where each entry has a number key, but they're not actually part of the file and don't add anything when editing the data for later conversion back to a resource. The only reason to keep them in is to allow multi-line entries: if a line starts with a tab, it's part of the current entry (the message table parser uses a bunch of tabs, and still allows more to be part of the line proper). But if I remove the superfluous numbers, I can't easily tell if a newline ends the current entry, or is actually part of the entry.2 "Leisure Suit Larry in the Land of the Lounge Lizards" contains some elements of plot which may not be considered appropriate for some children.
3 Use the TAB key to select,
then ENTER to continue.
4
5 Sorry, but this game can only be played by adults, or with an adult. Please find an adult, come back, and try again.I could of course just shrug and make it use escaped newlines to mean the latter?"Leisure Suit Larry in the Land of the Lounge Lizards" contains some elements of plot which may not be considered appropriate for some children.
Use the TAB key to select,\nthen ENTER to continue.
Sorry, but this game can only be played by adults, or with an adult. Please find an adult, come back, and try again."But Kawa, what if you want to use the text files to look up which tuple to use?" Well, besides comment lines, obviously you could enable line numbers in your text editor and subtract one to make it zero-based... or you just frikken import the resource and look it up from inside SCI Companion?
-
Okay.
After a hiatus and some tinkering around with YouTube streaming, and purchasing some equipment, I'm resurrecting the Werewolves and Wanderer project I worked on in the past.
This time I'm using the SCI 1.1 Engine in SCI Companion (the latest build)
Game Dev (Werewolves and Wanderer): https://www.youtube.com/playlist?list=PLUXBHpzHsJ3oiIP7JKf7vpBQrmp7LqEl7
This is a real time development. Which means the series itself will be dry and boring.
It will give a sense as to exactly how much time is needed to develop one of these things.
-
As for me, I'm on-off working on SCI11+ support in ScummVM. Specifically,UTF-8.
-
I've uploaded the demo for the thing I've been working on... Unfortunately, I discovered afterwards that some save game files seem to lock up the game when you go to restore. Most of them seem to be working without issue, but that could definitely be annoying. That and the Inventory possible-memory menu text aside, though, it should be pretty solid... If I can sort the occasional save game glitch, it'd be good to reupload.
-
On-off working on KQ2SCI and KQ1VGASCI (which I can't ever really release, but it's fun to work on anyway).
-
On-off working on KQ2SCI and KQ1VGASCI (which I can't ever really release, but it's fun to work on anyway).
Why can't you release that Brandon?
-
Because I'm using assets from AGDI's KQ1VGA AGS remake which is under license that it can only be distributed from AGDI's website and any and all updates must be QC'd by ActiVision.
-
can you use KQ5 resources?
-
That changes nothing for backgrounds and speech and all the custom animations.
-
I was only thinking of a starting point. Seems as if most of the Graham views needed could be taken from KQ5.
-
I'm not really that interested in doing the whole game from scratch, though. This way is much faster and gets me practice for SCI1.1. And perhaps in the future I'll be able to release it somehow. I got the source straight from Chris (AGD2) so it's nice to be able to just plug stuff in for the most part. There's stuff I definitely have to play with like converting dialogue portraits from 24-bit colour to 256 colours (hardest part so far). Well, actually 64 colours so that it can only use the first 64 colours of the game's palette that never change throughout the game. The result ends up looking closer to KQ5 and a little more cartoony.
-
That's it! That's what irks me about those remakes!
-
That's it! That's what irks me about those remakes!
The cartooniness?
-
Think he meant too many colours to work with.
-
Exactly!
The interface style is a good second.
-
The icon bar?
-
Buttons and such.
-
Ah yes. That too. The font wasn't the same and there was no embossing.
What did you think of the whole interface of KQ3Redux? The stone look was supposed to mimic the KQ logo stone wall in every KQ game.
-
What I think of KQ3 Redux? Graphically speaking? Well, going by the screenshots on Moby...
- I like how the title screen has only one plank, going a little further than KQ6 did...
- ...but then there's the buttons which look just Very Much Not The Part
- The background art seems okay...
- ...but the cursors really need more contrast. I found it hard to tell that the walk cursor is a pair of brown boots, at least on that floor.
- The window frames have a nice design, reminiscent of KQ6, but way too many colors, as do the portraits.
- 51032 colors with no UI or portraits on screen?
- The death screen is all mossed up and the decorative skull overlaps the quit button? If it looked less like the regular window it'd be more acceptable.
- Alpha-blended auras on half-translucent characters. That's a hard pass.
Can you really call them VGA remakes when they go above and beyond VGA? Fun fact: if I read this list correctly there are 320x200 VESA modes in 15, 16, and 32 bit color depths. And 8 bit but then you might as well use 13h. I just tested the first one, 10Dh, with a KQ3 Redux screenshot.
-
It's NOT called VGA. That was expressly intentional.
-
Tell that to most everybody else who talks about them lol
-
What other people call the game is irrelevant. "Can you really call them VGA remakes...?" We didn't. The end.
Well, the first two were. But even KQ2 was called KQ2VGA+ and eventually just KQ2+. There was a clear attempt to break away from the VGA label.
-
Here's my prototype of a new SCI1.1 template game!
It's built on top of the ImagiNation Network demo, whose interpreter is an exact match for the interpreters included in the SCI16 source. Said demo also has a complete set of system scripts, and lots of fonts.
This new template is in Sierra Script right from the start, and uses original Sierra names for defines, globals, scripts, and procedures. Various game-specific subclasses (the inventory and icon bar, for example) are now in their own scripts (this became standard in the SCI32 era). There is no assembly code in any of the scripts. Basically, the code is much simpler, cleaner, and more accurate to Sierra's original code.
The graphics are the same as the existing template, but it's quite a different beast script-wise. Then again, Sierra's programmers all had different ways of implementing things.
I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).
Now to bring this to SCI2.1...
-
I was going to do a new SCI0 template, but why bother? My SCI01 template fills that niche just fine, and has additional features (doVerb method, improved memory management, and scrolling styles, to name a few).
For completeness' sake? It would be nice to have ones for every main SCI version.
-
But we can't (de)compile every SCI version 😸
-
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0 (https://github.com/OmerMor/SCI0)
It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.
-
Eric,
I've created a github repo for the SCI0 system scripts:
https://github.com/OmerMor/SCI0 (https://github.com/OmerMor/SCI0)
It has 2 commits for the 2 versions I have.
You can use that to create better SCI0 template.
Cool! I'd better examine these scripts. One set's from November 30, 1988 (close match to LSL2), the other's from October 25, 1989 (close match to LSL3).
I guess I'd better start working on that SCI0 template and touch up the SCI01 and SCI10 templates, since it may be a while before SCICompanion properly supports SCI2.1.
-
I would love to have an SCI01 template game so I can migrate KQ2SCI over to it and use things like PICTURE scrolling.
-
Might motivate you to get started on it again.
-
And here it is (https://github.com/EricOakford/SCI0-Template-Redux) - SCI0 Template Redux! Fully in Sierra Script, built off of the Codename Iceman demo, and no assembly blocks anywhere!
Feel free to fix any bugs that you may notice - that's why I put it up on GitHub in the first place.
-
Nice.
-
Major update on the SCI1.0 template: it has been redone, using the Mixed-Up Fairy Tales demo as the base. That means the interpreter and system scripts are newer, and it has separate drivers for music and digital audio! With that, GMBLAST is not needed any longer. Ego is now played by the white boy from MUFT, and his head moves normally in real-time (as opposed to using cycle speed like in SQ1VGA and SQ4).
Now I see why those timer bugs were present in the CD-ROM version of SQ4, but not the floppy version - it all comes down to the Game class's doit:, which had things like a "gameTime" global added in around late 1991. Unfortunately, the game-specific scripts were not adapted for this upgrade, thus you get things like Roger's head moving super-fast, for example.
You know, I think the SCI16 series of game templates is ready for action.
-
Meanwhile I've being working on an SCI-inspired game engine of my own, in C++ with SDL2. I never write proper C++ code (rather, I write C with nice things like auto) but here it is anyway. I originally wanted to use actual SCI as its script system but eventually woke the hell up and switched to Lua, so that's a thing.
https://github.com/Kawa-oneechan/newsci
-
SCI-inspired game engine of my own, in C++
Do you know Sierra actually did something similar with Shivers 2? They pretty much re-wrote SCI in C++.
I don't know if they re-used this engine in any other game afterwards.
-
SCI-inspired game engine of my own, in C++
Do you know Sierra actually did something similar with Shivers 2? They pretty much re-wrote SCI in C++.
I don't know if they re-used this engine in any other game afterwards.
If you're interested, you can actually see Collin Snover's work on re-implementing this game in ScummVM:
https://github.com/csnover/scummvm/tree/shivers2/engines/sci/s2 (https://github.com/csnover/scummvm/tree/shivers2/engines/sci/s2)
Unfortunately, he left ScummVM before completing this.
-
I knew that Collin had joined ScummVM for SCI1+, but had not heard he had left.
Too bad that there is no source for the Shivers 2 engine. I wonder how different the scripting was from SCI32.
-
I knew that Collin had joined ScummVM for SCI1+, but had not heard he had left.
You can read his resignation mail here:
https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html (https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html) :'(
Too bad that there is no source for the Shivers 2 engine. I wonder how different the scripting was from SCI32.
Who said there isn't? ;)
-
I don't know what Shivers 2 ran on but I know SCI32 is C++.
-
I don't know what Shivers 2 ran on but I know SCI32 is C++.
I think I was mistaken. I thought you're writing a game engine in which the scripts are compiled and written in C++. Now I noticed the scripts are in LUA.
You're right about SCI32.
Shivers 2 uses C++ both for the engine and the scripts.
-
Now I noticed the scripts are in LUA.
I'm just going to pretend those capitals are for emphasis :)
-
You can read his resignation mail here:
https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html (https://lists.scummvm.org/pipermail/scummvm-devel/2018-September/012235.html) :'(
Wow, I had no idea. I have had some email contact with Eugene in the past, most recently for my installer code for Blade Runner. He was always cordial with me, but that may have been just standard operating procedure for him when reaching out for code. I have felt that many of the ScummVM people do not have that high of an opinion of me, but that may be from the early efforts of adding SCI with complaints about our having the SCI Wiki and hosting the old Free SCI specifications. That along with the undithering nonsense. I cannot say that I really know Colin, but have always gotten along with him since the early days of VOGONS.
-
I don't know what Shivers 2 ran on but I know SCI32 is C++.
Shivers 2 used external (C++) DLLs for all the rooms, but was actually SCI32 underneath. They had a glue layer making the innards of the interpreter callable from the DLLs. Shivers 2 is one of the reasons why I don't believe for a minute that
But SCI needed to be recoded in order to get the Duck [movie] player into it. [Which is why it is in version 3 whereas the previous game in the Phantasmagoria series used version 2.]
here (http://anthonylarme.tripod.com/phantas/p2inttw.html). It is much more likely that it was being rewritten because they needed to shoehorn that in. Some of the internal changes corroborate it.
-
Just for fun, I've been looking into adding long filename support to SCI1+. So that if you run it in Windows 9X or some other environment with Int 21h AX 7100 installed, you can use those.
R&D on Twitter:
https://twitter.com/NoxicoDev/status/1170696375228620800
https://twitter.com/NoxicoDev/status/1170741800870584320
https://twitter.com/NoxicoDev/status/1170948893854580737
Actual code:
https://github.com/Kawa-oneechan/SCI11-Plus/blob/lfn/EXT/FILEIO.S
Go ahead and say it folks. Say "Kawa, your ASM is atrocious."
-
If this had been SCI1.0 you could have called the result SCIDHUVLFN.EXE, but I guess you are left with RESOURCES.000 or AwesomeDriver.DRV ...
-
Back to it with Sect. I hope to have one of those elusive full games up here, someday. ;) It'll be a while yet, but progress is good.
-
Picked Zork back up. I'm starting over with all my visuals (export/import) based on a better understanding of palette management. Reserving 30-ish colors in each room for color cycling.
-
I've been mostly working on a fantasy computer emulator, while waiting for some difficulties in the lives of both me and my writer to pass so we might pick up The Dating Pool again. So the only thing I've done on that recently is replacing the simple railing on the space station screens with a hexagonal design which involved a lot of vector tracing, drawing another cameo or two, and updating another.
-
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
-
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
Any relation to your current profile pic?
-
I'm composing the soundtrack for the Coles' next game Summer Daze at Hero-U (https://summerdazegame.com/).
That's awesome! Best of luck!
-
Thanks!
Any relation to your current profile pic?
Yep. JP, one of the artists, has rendered all the team members in the style of the in-game characters. So we all get neat era-appropriate avatars.
-
Restarted work on Zork.
Currently lost in the rabbit hole of palette cycling, I'm getting together a nice room example. Refining my process, after you get past all the technical gotchas it isn't that difficult, just requires time and patience. When I'm done I thought I would post a tutorial on how I did it - something that would go along nicely with what Troflip put together in the Companion help file.
-
Sweet!
-
Restarted work on Zork.
Currently lost in the rabbit hole of palette cycling, I'm getting together a nice room example. Refining my process, after you get past all the technical gotchas it isn't that difficult, just requires time and patience. When I'm done I thought I would post a tutorial on how I did it - something that would go along nicely with what Troflip put together in the Companion help file.
Sierra Script?
-
Yes, Sierra script. I'm thinking about uploading all the artifacts too. Maybe upload a demo room.
-
For the last couple of years, on and off, I've been working on a fairly extensive mod to QFG1EGA. I'm touching on just about every room and every script, but in a slightly different way than the two excellent QFG3 and QFG1VGA fan-updates. It's a fairly ambitious mod for me, and I'm probably another few years away from completion at least.
There's 3 major areas of the game I'm changing (I think and hope for the better).
1) This is the hardest to explain, and probably the most controversial. Replace every Restore/Restart/Quit dialog with Retry/Restore/Quit.
2) Add a new player avatar choice. Female.
3) Add a Goblin Maze and Town Shed interior, along with a new puzzle and new characters involving them.
In order of completion, #1 I've fully finished; #2 I've finished all the coding and have only (only) to draw 700 some-odd brand new character animations; and #3 I've only just begun. I've unlocked the town shed door, and programmed it opening/closing and ego can walk through it to a crudely drawn white room. #'s 2 and 3 will take me a very long time, because art is my weakest area of expertise (seconded only by music ;)).
I've actually fully programmed #2 so that up to 3 or 4 different avatars are supported. I had to rearrange the number of several of the views, and in some cases split them up into ego and stationary. To test it, I duplicated each existing ego view and inverted the colours. It's slightly bizarre to watch this inverted-color aberration wander through a regular Spielberg.
I wasn't even planning on #2,3 originally --- I wanted to do #1 as a proof of concept (the result of which I'm very proud) and figured since I finished that, I'd try and learn view and pic editing/creating.
So let me explain a bit about #1. I think we're all familiar with the major difference between the Sierra games and the LucasArt ones... Sierra games strongly encourage (require?) you to save early/save often, while LucasArts games generally have no dead-ends. I always liked the character deaths... they were humorous, and helped give the world and characters a sense of consequence -- however as a player (especially one well past his youth, with limited time in any given day to actually play games) I find it incredibly annoying and discouraging to be penalized for exploring the world and trying new things. I mean I think Corey Cole summed it up pretty good way back when he first gave QFG2VGA a go. As he described it, he got killed by an unexpected brigand inside the City of Shapier; Realizing he hadn't saved his game he didn't bother restarting or redoing the lost 30 minutes or more he put into the game, he just turned it off and never went back.
To use a QFG1 example, it's one thing to try drinking the Dragon's breath. You've (possibly) been warned about it by the Sherrif... it looks very ominous when the bartender pours it... arguably, that's sufficient forewarning that maybe you should save your game before drinking it; and if you didn't, oh well, that's on you. But picking your nose, early in the game? There's absolutely no reason (especially in the EGA version, when you're not clicking the lock pick on yourself) to think that telling the hero to go "pick his nose" will cause him to kill himself. It's not fair to require your player to save the game before every single action, and to penalize them if they don't. But it is a funny message.
So, that was my personal challenge. Keep the humour of the deaths, but remove the penalty. Could it be done in the original engine... And of course, the answer is yes. I think I came up with a novel solution. I turned it from a penalty into an additional in-game challenge. Now, not only can you instantly reverse any fatal mistakes you make, but the game keeps track of each death and will show you a list, stating how many times you died. It changes deaths (and thus exploration) from something to be avoided into something actively encouraged. Can you beat the game scoring every single death?
Yeah, so that's how I've been spending some of my free time. I'm really happy with the results.
-
I love this idea (#1) Charles. Controversial sure, but improving the gameplay experience to remove the painful-points makes these classics more approachable for those who are new. It doesn't detract so much from the game that it loses it's original character and charm. Good luck, looking forward to the finished product.
-
I love this idea.. it's like an achievements mechanism. :)
However, what about dead-ends? I guess you'll have to restore, and lose any unsaved death achievements?
Are there any dead-ends in QfG1?
-
If you leave the dryad without taking the seed, you can't spawn it, which ends the game.
-
Awesome!
-
However, what about dead-ends? I guess you'll have to restore, and lose any unsaved death achievements?
Are there any dead-ends in QfG1?
Yeah, the dead-ends are still a problem. I think they’re only related to the dispel potion though. If you don’t take the seed in the first place, or you waste your potion once it’s made. I think the best fix there is to not limit the times you can get the ingredients. Maybe with the Dryad (or whoever else) grumbling about the hero needing it again.
Speaking of achievements, there’s no reason one couldn’t also implement a Points List screen that lists off everything you’ve done to score points (or conversely, what’s left to score). Heck, I bet it could even be tied into the Gog or Steam Achievements API somehow. That’d be neat.
If there’s any interest, I might write a tutorial post on how to convert other existing games to use Retry/Restore/Quit. I coded it in such a way, it can be a drop-in replacement to the stock EgoDead function in Main. Then you can update each Restore/Restart/Quit one at a time without breaking any other part of the game.
-
Wouldn't you also need to store all status, inventory items, etc. right before ego enters the situation that kills him for the retry? Wouldn't that require modification at each danger point?
-
I also don't remember, but does the Mandrake plant grow back if you take it in the daytime?
Even if it does grow back, I think if you try to take it the day you get the Baba Yaga quest it won't be there for you at midnight, resulting in an unwinnable state. Probably just having it spawn at midnight would solve this problem.
Also, I love the death achievement log! I'm not sure how you are achieving that, but I would love to add something like that to my current project...but I guess it includes a huge overhaul of the entire save/restore system. Still, I really love it!
-
Wouldn't you also need to store all status, inventory items, etc. right before ego enters the situation that kills him for the retry? Wouldn't that require modification at each danger point?
That's exactly the sort of challenge I faced at the outset. Most of the time, if you die it's because of something you immediately did wrong. Like step on the wrong trap in the Brigand Fortress, or fall down a hole in the Graveyard, etc. Those are easy. Just back track to right before you did that one thing -- reposition ego, reset any views, undo any flags.
But my earlier example of destroying the spitting plants... you might do that early on in the game, and then forget about it... you could have done dozens of tasks and played through a handful of game days between destroying those plants and actually meeting the Dryad face to face. Others may approach the solution differently, but I decided on a minimally invasive approach to the Retry. In other words, I only change the one specific thing that caused you to die (and anything directly related to it). Anything else you may have done after killing the plants still happened... time doesn't reverse, your stats aren't reversed, the only thing that changed is that Retry brings you back in the spitting plant room and the plants are alive (and the seed is out of your inventory and back with the plants). Now you can Retry to get the seed the proper way.
Similar thing if you died in battle, or because your stats were too low. I don't reverse any skill improvements you made. With the premise that this is a game and above all, should be fun... if you died because your character wasn't good enough, it would be incredibly frustrating to be put back right where you were, with skills still too poor. You're just going to need to grind again anyway... There are dozens of places where the hero can lose HP (and thus potentially die). I took different approaches in different contexts... in some, I revert the HP to before whatever caused them to die... in others, I just restore them to a token 50% HP or such.
And if people are concerned about "cheating" or getting a freebie or having an unfair advantage because they clicked Retry, well, it's not free... it's marked off in their Death List. That's why I not just mark the unique deaths, but the total number of deaths. You're still free to Save/Restore if you want the extra challenge. That's entirely on you.
I also don't remember, but does the Mandrake plant grow back if you take it in the daytime?
Even if it does grow back, I think if you try to take it the day you get the Baba Yaga quest it won't be there for you at midnight, resulting in an unwinnable state. Probably just having it spawn at midnight would solve this problem.
Also, I love the death achievement log! I'm not sure how you are achieving that, but I would love to add something like that to my current project...but I guess it includes a huge overhaul of the entire save/restore system. Still, I really love it!
The Mandrake is similar to killing the plants. It isn't a walking dead state, like not getting the seed on time. True, the mandrake doesn't respawn. But if you agree to get Baba Yaga her mandrake (and if you don't agree, you die) then you have 3 days to do so. If you don't do it in that time, you die. So I respawn the mandrake on that Retry. It may not be the most intuitive, and I may still tweak it, but I wanted to stay as true as possible to the original intent of the game... it's completely subjective... I'm just some schlub editorializing someone else's work. Obviously if you implemented this in your own project, it's entirely your choice to decide how to handle it.
Speaking of, I don't think it's as daunting a task as you imagine to retro fit it. Yes, I had to edit almost every script (and especially every script that had a death), but I wrote my modified EgoDead function so that I could fix things up piecemeal. I'll try and post the code later today in another thread, but basically, you can update the EgoDead function and change nothing else, and the game will properly recompile and all the existing Restore/Restart/Quit dialogs will remain unchanged. Then you can go through one by one, and update the existing Deaths at your leisure.
-
Speaking of, I don't think it's as daunting a task as you imagine to retro fit it. Yes, I had to edit almost every script (and especially every script that had a death), but I wrote my modified EgoDead function so that I could fix things up piecemeal. I'll try and post the code later today in another thread, but basically, you can update the EgoDead function and change nothing else, and the game will properly recompile and all the existing Restore/Restart/Quit dialogs will remain unchanged. Then you can go through one by one, and update the existing Deaths at your leisure.
Ohhh! Of course. I was envisioning a huge overhaul, but really it's more just tweaking some things here and there. Would it be rude of me to implement just the death counter and type in my game similar to what you are doing here? I think it's a really cool idea.
Edit: This actually reminds me of a small game I wanted to make a while ago as well. It was supposed to have 100 different deaths in it, and this would allow achieving each type of death as the actual victory condition :P I may have to revisit that at some point
-
Would it be rude of me to implement just the death counter and type in my game similar to what you are doing here? I think it's a really cool idea.
I absolutely welcome it. I'm happy it's been as well received as it has. I'm not sure if you could implement just the death counter without the Retry option, but I wrote up a couple page tutorial on how I did what I did http://sciprogramming.com/community/index.php?topic=1946.0 (http://sciprogramming.com/community/index.php?topic=1946.0).
-
I've decided to expand my game decompilation efforts to SCUMM games. I've already got some here. (https://github.com/EricOakford/SCUMM-Decompilation-Archive) I was pleased to find that the SCUMM demos were stripped-down versions of the full games, just like the SCI ones!
Since there's no simple IDE for SCUMM games, I had to make do with ScummRP (to extract the data files) and descumm (from the ScummVM tools). I got the idea from this disassembly project (https://github.com/segrax/Maniac.Mansion.Disassembly) for the C64 version of Maniac Mansion.
-
Thanks to EricOakford's SCI Decompilation Archive (https://github.com/EricOakford/SCI-Decompilation-Archive), I'm now very close to putting the finishing touches on my update patch for Space Quest III, a project I've been sitting on for about three years now.
There are only two things left to be done:
- The view for the back of Roger's head (view.031) on the Aluminum Mallard. The shadow doesn't work now that he has blonde hair, and simply replacing the colours produces what you see in the fourth screenshot below. While I've done a lot of editing and colour replacement, I'm certainly no pixel artist. Are there any talented artists out there that can help me make this look presentable?
- For the life of me, I just can't get any version of MAKEVOLS to work. Maybe it's because SQ3 is an SCI0 game and the formatting of the RESOURCE.TXT and WHERE files are different for earlier versions of the program/interpreter. I couldn't even get KQ6 floppy to pack using the files (http://sciprogramming.com/community/index.php?topic=1631.msg10398#msg10398) NRS provided with MAKEVOLS version 3.01. I suppose I could just use ResDumpPack if I still can't figure it out.
If anyone could help me out with these two issues, I'd greatly appreciate it!
-
I've been working on a thing, I guess.
Also have a long-belated attempt at a blonde Rog head.
-
SCUMMCompanion? That's awesome. Looks like a .NET project?
-
What tipped you off? 😸
-
That's awesome Kawa!
-
Yeah, imagine if it actually let you change more than just boxes, and anything in a property grid. And actually saved.
-
Very cool anyway, I'm sure you'll get that working before too long.
Does .net stuff run on ok Mac/Linux these days? My biggest regret with SCI Companion was relying way too heavily on Windows-only stuff for the UI. Really wish I'd used a cross-platform widget library.
-
Myself, I'd be interested in seeing the bootscripts/UI/lower level scripts. Y'know, is SCUMM really as extensible as SCI, and how do the parts relate. Missed that in the Ron Gilbert video, but I realize it might not appeal to everyone.
-
Does .net stuff run on ok Mac/Linux these days?
Usually I try to use as few P/Invokes as I can so it will in fact run on Mono. Unfortunately there are some parts in here that break that rule: fetching system icons for folders and generic documents, and removing the bevel from the MDI window so the right hand panel in the explorer window and such looks like it's part of the parent, not the child.
I blame you.
Obvious solution: have the wrapper functions detect they are not in fact running on Windows and thus doomed. Return built-in icons and just don't remove the inner bevel in those cases, way before you try to do the thing.
I'm sure you'll get that working before too long.
Well, I do have a "save selected branch to separate file" test menu item, and it did manage to save an exact recreation of the "rowboat and oars" OBCD. And then an equally valid "roeiboot en riemen" after I renamed it.
Myself, I'd be interested in seeing the bootscripts/UI/lower level scripts.
Probably part of the first-seen LFLF/room and the last-stored. I'll find out soon enough.
Y'know, is SCUMM really as extensible as SCI, and how do the parts relate.
FT, S&M, but mostly Loom come to mind.
I do know with near certainty that the system window layouts are hardcoded, but their text is loaded in by startup scripts.
-
Cooooool
-
Y'know what's really cool?
I just confirmed I can load Monkey Island, immediately save it, and get a file that's exactly the same as the MONKEY.001 I started with.
Things I'd need to at least produce a proof-of-concept text hack:
- Using and saving the LOFF chunk and index file.
- Compiling scripts.
Both only so as to allow different string lengths.
Edit: I have altered the first playable screen. Pray I do not alter it any further. (https://twitter.com/NoxicoDev/status/1381249457103200261)
-
Myself, I'd be interested in seeing the bootscripts/UI/lower level scripts.
Here's how Fate of Atlantis sets up its verb bar. LFLF #66, script 14:VerbOps(50, [New(), SetXY(0, 144), SetToObject(0x04EE, 98), Off(), BackColor(0)]);
VerbOps(51, [New(), SetXY(0, 144), SetToObject(0x0548, 98), Off(), BackColor(0)]);
VerbOps(5, [New(), Text("Give"), Key(103), SetXY(15, 159)]);
VerbOps(3, [New(), Text("Open"), Key(111), SetXY(14, 173)]);
VerbOps(4, [New(), Text("Close"), Key(99), SetXY(12, 187)]);
VerbOps(11, [New(), Text("Pick up"), Key(112), SetXY(54, 159)]);
VerbOps(12, [New(), Text("Talk to"), Key(116), SetXY(53, 173)]);
VerbOps(9, [New(), Text("Look at"), Key(108), SetXY(53, 187)]);
VerbOps(8, [New(), Text("Use"), Key(117), SetXY(108, 159)]);
VerbOps(6, [New(), Text("Push"), Key(115), SetXY(106, 173)]);
VerbOps(7, [New(), Text("Pull"), Key(121), SetXY(108, 187)]);
VerbOps(10, [New(), Text("Walk to"), Key(119), SetXY(0, 210)]);
The first parameter to VerbOps is also what an object's VERB chunk uses:LookAt {
print(1, ["It's a stone carving of Shiva."]);
}This would be stored as a 9 byte, followed by a pointer to the script code for looking at it.
-
Also have a long-belated attempt at a blonde Rog head.
Woah, thanks for the blonde Roger, Kawa! Using your Rog head as a template, I was inspired to make a version of my own without the shadow. Personally, mine feels a little too 'busy' compared to the shadowed one, so whichever version people prefer, I'll stick it in.
Great work on the SCUMM engine editor, btw.
-
Try fading to dark gray instead of outright black like the original does.
-
OK, so I found the bootscripts for some SCUMM games. And I've decided that if I write a single line of Scumm code in my life, it will be this:
object sputm
{
name is "SCUMM interpreter"
verb use
{
shell-execute "SCIV.EXE"
}
}and then over in SCI I'll do
(instance rickroll of Room ... code ...)Maybe I'll figure out how to fly a little banner across the screen in Scumm once SCIV exits: USE SCI INSTEAD
-
Kicking this thread up a bit just to say that I'm my usual predictable self and have spent the last three days porting Softporn Adventure from Pascal to C. It's going pretty well.
-
That's awesome, I never played it.
-
It's pretty much done, and before the weekend no less.
https://helmet.kafuka.org/softporn-c-port-public-beta-1.zip
-
Just scored 250 out of 350 points in my Zork effort. Game locked up, I've probably got a memory management issue ::)
-
I put my Softporn rewrite on my github, with a release for beta 2 if anyone wants to give it a whirl.
https://github.com/Kawa-oneechan/softporn
-
Is it a one-to-one rewrite?
-
There's a few QoL things and about 90% fewer !!!!!! and ... but otherwise walkthroughs for the originals should still work.
-
I was thinking more along the lines of all of the original strings and all of the original parser commands.
-
I was thinking more along the lines of all of the original strings and all of the original parser commands.
That's what "walkthroughs for the originals should still work" implies, does it not?
-
True.
-
I've been doing a little work on remaking Space Quest: The Lost Chapter in SCI01. With that engine, it could work as a hybrid of SQ3 and SQ4. It will have the parser, but may eventually also have VGA graphics (though the focus is on EGA for now).
I've got what I've done in a private Github repository.
-
Nice. I'll be interested in seeing the results. There is also the "Space Quest 0: Replicated" fan AGI game.
-
Will there be speech pack for VGA Version ? And please fix the Stupid Squid puzzle.
-
Will there be speech pack for VGA Version ? And please fix the Stupid Squid puzzle.
No speech pack, since the VGA version will still have the parser. That requires the Seasoned Professional VGA interpreter.
That squid puzzle will definitely be fixed in pretty much the same way the root monster puzzle was in SQ2VGA.
-
For SQ:TLC and R44Q, I'll be doing animated talkers.
The dialog will be modeless, meaning the characters will move their mouths while the text is on-screen, so as not to interrupt the flow of events. QFG1EGA and Conquests of Camelot did just that. QFG2 fleshed it out further.
R44Q will just have a standard "talk to" command. This will not require separate script states for each line of text.
A better example for SQ:TLC is with Wilco Interactive, the hidden in-game hint service. You'll be able to ask him about anything, and the game will check an array for a matching said spec. If there's a match, he says the appropriate response. That's exactly how LB1 and QFG2 did things.
-
I'm familiar with SQ:TLC, but not R44Q - I see it was originally in Dutch. Do you plan to support both languages? I'm not sure how translations in SCI work, do they have to be separate versions for each language or is there a mechanism to toggle between them?
-
In SCI01 I suppose you can use the multilingual Print and such, and give it "text like this%Dtekst zoals dit", but of course %D isn't a recognized language separator so you might as well just pretend it's English or German and use %G.
Somewhat relevant blog post: https://helmet.kafuka.org/logopending/2019/03/08/sci01-1-multilanguage-games-and-telephone-country-codes/ (yes the blog post uses # for its split point and the above example uses %, this is because one is SQ4 in French and the other is SQ3 in German.)
-
In SCI01 I suppose you can use the multilingual Print and such, and give it "text like this%Dtekst zoals dit", but of course %D isn't a recognized language separator so you might as well just pretend it's English or German and use %G.
Somewhat relevant blog post: https://helmet.kafuka.org/logopending/2019/03/08/sci01-1-multilanguage-games-and-telephone-country-codes/ (yes the blog post uses # for its split point and the above example uses %, this is because one is SQ4 in French and the other is SQ3 in German.)
Unfortunately, The Seasoned Professional's interpreter (which is being used here) does not support this feature. A translation will probably require a separate version.
I'll try to make things easier by moving strings into Text resources later on.
I've actually managed to get the animated talkers working properly, thanks to a little thing called sub-scripts.
My main obstacle will be the graphics. The AGI rooms are too claustrophobic for Ego.
-
I know I've got a full plate already with projects, but one more I've got my eye on is to adapt QFG4 1/2 into SCI.
I'll likely remove the QFG title from the game, leaving only the subtitle (which I did in the status line). There will also be a content advisory (like Disney+) at the beginning of the game, as well as a setting in the control panel to adjust the mature content. I get how polarizing the game is, and the ability to make it less offensive will help.
I actually already extracted the original's data files using QuickBMS and its AGS script. The MIDI files can be imported into SCI sound resources, and the compiled room files have all the strings as plain text in them, which I can bring over to message resources. The only issue will be the graphics, which are stored in acsprset.spr. If only ScummVM supported pre-2.5 games...
But I should probably focus on testing the QFG1VGA upgrade to completion first.
-
as well as a setting in the control panel to adjust the mature content.
If you would like to see how I did that exact thing in The Dating Pool I'll be happy to share the relevant code with you.
-
as well as a setting in the control panel to adjust the mature content.
If you would like to see how I did that exact thing in The Dating Pool I'll be happy to share the relevant code with you.
No thanks, I've already done that as a new slider, and it seems to work okay.
-
Except it's more than just the slider. I have things change to reflect the new setting, on the fly.
-
For the first time, I was able to do a complete play-through of Zork end-to-end. Still have a lot to do, but the game is winnable 8)
-
Congratulations on that!
-
Woo!
-
For the first time, I was able to do a complete play-through of Zork end-to-end. Still have a lot to do, but the game is winnable 8)
Very cool! I know that's been a long-term project you've been active on. Great to hear it's progressing!
-
Here's a SQ4CD debugger I made. Same commands as the SQ4 Beta, with the addition of ALT + s to change the music. Attached below. Since SetDebug was removed from the SQ4 interpreter, I migrated the code from rm800.sc into main. Command list: http://sciwiki.sierrahelp.com//index.php?title=SCI_Debug_Modes#Space_Quest_4_.28beta.29
Also, just for fun I made a KQV CD patch to change poisonous to venomous. See 5500.aud.
Patching individual lines of audio dialog is only possible because instead of using messages for speech, KQ5 uses the AUD resource format which can be patched. I used SCI Sound Utilities to create a new SOUND.000 file, then renamed it 5500.aud. I had to use a hex editor to clean up some garbage at the start of the file to remove pops/clicking.
-
Nice!
-
For the first time, I was able to do a complete play-through of Zork end-to-end. Still have a lot to do, but the game is winnable 8)
A noble project, I have a particular interest in that as the fan of Zork.
-
A noble project, I have a particular interest in that as the fan of Zork.
Among somewhat lesser well-made text adventures, hmmmm?