What are we working on?

[MusicallyInspired]

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.



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.

[troflip]

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...

[MusicallyInspired]

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.

[Kawa]

Not chunking up the pixels really breaks the effect, I think.

[troflip]

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.

[Nicktatorship]

One's from Space Quest 1, and the other is from when you visit SQ1 in Space Quest 4. Probably redrawn/modified.

[Kawa]

Too many details are the same so I'mma say modified.



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

[MusicallyInspired]

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.

[Kawa]

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).

[MusicallyInspired]

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.

[Kawa]

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

[MusicallyInspired]

So I've been playing around with the idea of using palette cycling to animate the glow/shimmer effect of a lightsaber. The only problem is it doesn't look right when the palette cycling is just animating linearly. The way I have it drawn the gradient of the blade colour's glow is dither and thenends in transparency. So the palette cycle makes the transparent part appear inside the glow during the cycle obviously. So the most obvious option was to cycle back and forth like a View cel animation can cycle forwards and backwords. I thought this would be fairly simple since I had controlled palettes similarly with transitions (fading in and out of black with the palINTENSITY option) but I realized that this isn't possible in the same with with palANIMATE because you can only control the speed and you can't necessarily keep track of the position or how many times the palette cycling has cycled.

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

EDIT: On second thought, it looks like something is wrong with my code. I am trying to increment the local variable every cycle if it's below a certain value and decrement it if it's higher than another but the value isn't changing at all....what's going on? Does

Code: [Select]

(++CyclePos)
simply not work? I've also tried:

Code: [Select]

(= CyclePos (+ CyclePos 1))
Nothing. I'm PrintF-ing the value every cycle and it never changes from 0.

EDIT 2: Oh never mind. I'm a doofus. Haven't been programming in a while. I didn't have enough checks in my code so both blocks of if statements are incrementing and decrementing the value at the same time and not getting anywhere...sigh...

[Kawa]

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

[MusicallyInspired]

Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong? I've added some debug info code which activates if you press a button (only way to quit is force close DOSBox). Game is attached to post. I want to eventually do something more complicated like randomize the shimmer effect (shimmer back and forth at random intervals within the cycle limit instead of just all the way fully forward and backward) to make it look more realistic but I can't get anywhere until I sort out this sync issue.

Here's my script:

Code: [Select]

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

(public
rm100 0
)

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

(instance myDialog of Dialog
(properties)
)

(instance rm100 of Room
(properties
picture 100
)

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

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

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

(instance rmScript of Script
(properties)

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

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

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


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

Code: [Select]

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

(public
rm100 0
)

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

(instance myDialog of Dialog
(properties)
)

(instance rm100 of Room
(properties
picture 100
)

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

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

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

(instance rmScript of Script
(properties)

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

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

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


[lance.ewing]

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?