Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - gumby

Pages: [1] 2 3 ... 9
SCI Syntax Help / SCI 1.1 - Game class, newRoom method
« on: February 11, 2022, 09:00:09 PM »
I'm having an issue where sometimes my game completely locks up between switching rooms. This is occurring in debug mode, and I get the message "Switching to room...", but the new room is never displayed and control is never returned to player.  Just "locked up".  Frustrating part is that it's not easily reproducible, so I'm looking for help.

Right now, I'm suspicious of this code block in the newRoom method, which seems like it could explain the lockup:

Code: [Select]
(self startRoom: gRoomNumber)
(while ((= temp5 (Event new: 3)) type?)
(temp5 dispose:)
(temp5 dispose:)

...which is a head-scratcher.  What is the point of the loop that generates events and checks to see if a type is defined until it breaks out of it?

Is there any way to detect what the color of a pixel is (or the index # of the palette) when clicking on a view?  I have several views that are very large and irregularly shaped and I'd like it so that the view only responds to a click when that click isn't on a transparent portion of it.

If not, I was thinking about solving this need with creating polygons on-the-fly that match the placement of the view on the screen.  Anyone see any gotchas this this approach?  One potential one that comes to mind is that I don't think I want to use any of the existing polygon types, unless maybe PTotalAccess would be appropriate?

SCI Syntax Help / SCI 1.1 - Alternate Palette for Rooms - Grayscale
« on: August 19, 2021, 09:13:07 PM »
I have a need to create an alternate grayscale palette for all room pics for Zork (100+).  Similar to day/night scenes I've seen done in SCI0, I'm guessing there have been similar scenes in later Sierra games.  I could create 2x the number of pic resources, but it seems like using an alternate palette for existing pics would be appropriate. I'm thinking of taking each existing palette and converting it to grayscale in a non-manual way?

Any suggestions how best to accomplish what I'm trying to do?

SCI Syntax Help / Numeric overflow
« on: August 01, 2021, 11:01:45 AM »
Here's a bit of code that caused downstream problems in my game resulting in OOPS messages.  My use case was debugging the results from checking flags and got nailed when the gFlags index was 16.

Code: [Select]
    (DebugPrint "Flag value = %d" (Btest MY_FLAG))

Simplified, you can get the same result with:
Code: [Select]
    (DebugPrint "Flag value = %d" $8000)

It returns "Flag value = -4294934528", which is an overflow for a 16 bit integer - I should have used %x instead  :-[

SCI Syntax Help / Status line vertical size
« on: May 25, 2021, 09:51:19 AM »
I'm trying to get the status line to be a few pixels taller, the font I'm using has some characters that drop below the status line and get chopped off.  I was able to get the status line code modified to be larger, but when DrawPic commands are executed, they look to be getting applied at a y=10 and effectively overwriting the status line pixels that extend the 10th y pixel.

Anyone know if making a larger status line is possible?

SCI Syntax Help / SCI 1.1 - Refresh Inventory Screen
« on: February 13, 2021, 02:15:37 PM »
I have a scenario where interacting with an inventory item on the inventory screen needs to change the currently displayed view for the item.  For example, the action being taken within the inventory screen is turning on a flashlight.  I want to swap out the view of the flashlight being off to a view of the flashlight being on.

A kludgey solution is to hide and show the inventory screen, but this also introduces a flicker-effect because the window is being torn down and redisplayed:

Code: [Select]
   (gInv hide:)
   (gInv show:)

What's the correct way to do this?  Is there a built-in way to ask the inventory screen to refresh itself?  Or should I instead reference the view within the inventory screen, change the view and call forceUpd - or something along these lines?

SCI Syntax Help / Out Of Heap - DosBox vs ScummVM
« on: January 02, 2021, 01:26:44 PM »
I'm working on an SCI1.1 game and I'm running out of heap.  In my testing I tried using DosBox and ScummVM and I found that upon starting up the game and immediately going into the debugger and viewing the available heap (alt-d, alt-r) there are differences.

In DosBox, I have 10040 bytes free.  In ScummVM, I have 32746 bytes free.  Does someone here have an explanation as to why this would be? 

SCI Community How To's & Tutorials / Palette Cycling Tutorial
« on: October 11, 2020, 02:41:18 PM »
The SCICompanion instructions are very good; I've put this tutorial together for someone who wants to do this in Paint.NET.  This is how I did it, there are probably different/better ways but I'm putting this out there in hopes it might help others.  I've uploaded the final result, along with all the artifacts I used to create it from the fan games section here:

Step-By-Step (geared for following the demo game)

1. In SCICompanion, create a new template game for SCI 1.1.

2. Create/import your background pic (refer to 'original background.bmp').  Right click 'Import bitmap to pic', reserving the last 2 rows (32 colors) for the palette cycling

3. Create the first gradient.  Edit the palette, select the first 8 unused colors, hit 'Gradient'.  Choose A-B as the gradient type and leave the default colors (white to black) as is.  Save the PIC (you have to save the palette to the PIC before attempting an import utilizing palette changes)

4. Create an 8 color palette file matching the gradient you created in the palette tool in Companion (I've included a 8-color and 16-color file in the demo game you can use - refer to the '8 color cycle' file).  If you are creating these from scratch, you will need to look at every color in the palette for the RGB values and make corresponding entries in the Paint.NET palette files. Drop these in the Documents\ User Files\Palettes folder on your file system
5. In Paint.NET open the background pic (needs to be already sized to 320x190 - again, refer to 'original background.bmp')

6. Create a new layer (Layers->Add New Layer).  Make sure this new layer is on top and selected.

7. Open the 'Colors' window, and select the 8 color palette file that you just created.

8. Draw, pixel by pixel, typically in an ascending/descending pattern of colors from the 8 color palette on the top (transparent) layer.

9. When finished, delete the 'Background' layer and 'Save-As' the top layer.  Save as a PNG with a bit depth of 8 and dithering level of 0 (refer to 'pixels - range 1.png')

10. In Companion, import the PNG you just created, choosing 'Overlay on current' and 'Map to current palette', selecting the 8 color gradient that you created in step 3.

11. Save the pic and reopen.  You should now see the background merged with the the PNG that you just imported.  Change the gradient colors to whatever suits your picture. I've done a combination of the following with varying success:
   1) Use the gradient tool.  Pick a start color and end color and you are done
   2) Random copy/paste.  Choose colors that are already preexisting from the room palette and just paste them into each of the cycle indexes with little/no regard to neighboring colors
   3) If after testing out the color cycling it's too light or dark with the surrounding areas, use the 'Adjust' tool against the full cycle range and lighten/darken it (or do other color adjustments)

12. Test out the results.  Open the corresponding room script (110) and this code to the room instance (assuming that your gradient uses color indexes 224 to 232)

   (method (doit)
       (Palette palANIMATE 224 231 -20)      
13. At this point I strongly suggest exporting the palette (assuming you are reasonably happy with the results).  This allows you to rework (add/delete pixels) on your transparent layer and re-import without having to redefine the palette every time (refer to 'pal range 1.pal').  You may also want to export the full pic resource as well to support 'mutiple passes' at giving the room  - if you don't do this, you'll just have to re-import each layer individually and reapply the palettes you defined (not a big deal).
14. Technically, at this point you are 'done' - but in reality you will more than likely need to work & rework your transparent image before you are satisfied.  Let's create another color cycling range and corresponding transparent layer:

15. Repeat Steps 3-11, this time with another 8 color gradient range (colors 232 - 239).   

16. Test out your new changes.  Change your Palette command to this and test the room:
        (Palette palANIMATE 224 231 -20 231 239 -50)
17. If you are satisified, again I recommend doing Step 13 (export the palette range and pic resource if desired)

18. Now we can move on to the last range, this time using a 16 color range (again, see included resources in the demo).  Perform the same steps (making adjustments) 15-17.  Here's the updated Palette command:
       (Palette palANIMATE 224 231 -20 232 239 -50 240 255 -35)

SCI Syntax Help / Views with more than 64 colors
« on: August 02, 2018, 07:57:29 AM »
I have a need for a view that will be used in multiple rooms and the built-in 64 colors aren't enough so I created a view using the first 112 palette entries.  My rooms share the same first 112 palette entries and the remainder of the palette is used for the room colors.

In the room I init the view and it nukes the current room palette, the only thing I've found that allow for the room and view to display propertly is to force the palette to be updated in the doit method.

Code: [Select]
  (method (init)
(super init:)
(thief init:)

(method (doit)
(Palette palSET_FROM_RESOURCE 0)

This feels wrong to be making the call in the doit.  I did try using a changeState method in a room script, but that didn't work - looks like the view's palette overrides the room palette.  Is there a better way to be doing this?

SCI Syntax Help / Repeat, continue, break
« on: July 15, 2018, 06:34:24 PM »
Just found that this combination of commands work perfect for a goto replacement.  Continue and break I'm familiar with in multiple languages, but repeat was a new one to me.  More elegant than a (while (== 1 1) loop.

SCI Development Tools / Creating PICs with palette cycling
« on: May 30, 2018, 06:54:37 PM »
I've been playing with palette cycling and realized very quickly how time consuming it can be to setup the overlay pic.  I'm looking for suggestions as to how to effectively create the overlays, because drawing pixel-by-pixel is pretty laborious, considering that one needs to change the drawing color each time (for something like the example in the Companion help file - specifically a water effect).

I've been doing everything outside of Companion with Paint.NET, but it isn't cutting it.  My basic process is to create two layers, load the background image as one layer and use another layer for the overlay.  I create the overlay by drawing a pixel, changing the pen color, draw another pixel, rinse-and-repeat.

Anyone done any development in this area that can recommend a more streamlined process or a particular tool-set that would help?

I'm having an issue which seems to be related to the number of global variables I have defined in Main (SCI 1.1 game).  When I get past about 256 values (including array indices), it causes the status bar to corrupt.  I've troubleshot it to the point where if I add/subtract a single global it either works/doesn't work as expected.

Is there a known limit to the number of global variables that can declared?

This game is finally released.  By no means 'complete' in the traditional sense; I've only created the first part of the game (one could consider it a 'proof of concept').  A far cry from what I started out to do which was a traditional 'port' using SCI0, but I'm very pleased with the results.  I fully intend on fully finishing this endeavor now that I have a framework in place that I can build upon.

Download it from the fan games page here:

I ran into a need to have a view displayed at different scales based on the room it was displayed in.  Making things more difficult, it wasn't just one view, I needed logic for N views.  No way I was going to make 20+ different versions of the same view cel for all my views to accommodate all the different scales that I needed.

I started by creating views that were 'full size', meaning either 320 on the x-axis or 190 on the y.  Then I assigned relative 'scale values' or 'sizes' between them so they would sized appropriately when displayed with any other views.  For example:

Code: [Select]
(define SWORD_SCALE 80) 
(define LAMP_SCALE 65)              ; the lamp is 80% the size of the sword
(define CLOVE_OF_GARLIC_SCALE 5)    ; the clove of garlic is 6% the size of the sword

Then determine what your room scale value should be, 1 being a 'zoomed in' room and larger values get you 'further away' from them, effectively making them scaled down.

I added this procedure in the script:

Code: [Select]
;;;  Calculates what the scale should be based on the relative room scale (current room) and relative view scale
;;;    viewScale - a relative scaling value between ~5 (smallest) to ~100 (largest).
;;;    roomScale - value between 1 ('closest' or 'largest views') to ~50  ('furthest' or 'smallest views')
(procedure (calcRelativeScale view loop cel viewScale roomScale &tmp width height dim tmpScale)
   (= width  (CelWide view loop cel))
   (= height (CelHigh view loop cel))
   (if (> width height)
      (= dim width)
      (= dim height)

   (= tmpScale (/ (/ (* dim viewScale) 100) roomScale))
   (if (< tmpScale 3)
      (= tmpScale 3)    ; smallest possible scale with full-screen views
   (if (> tmpScale 100) 
      (= tmpScale 100) ; full size
   (return tmpScale)

Then prior to initing your view, calculate the scale by passing in the view, loop, cel and your viewScale and roomScale.  Just to be safe, make sure that the computed value is sane.

Code: [Select]
   (= view 10)   ; the sword view
   (= loop 4)
   (= cel 0)
   (= viewScale SWORD_SCALE)
   (= roomScale 50)    ;  I actually added a new property to the Room object and set the scales for the rooms there

   (= tmpScale (calcRelativeScale view loop cel viewScale roomScale))

   ; don't attempt to scale if we have no scale value defined
   (if (> tmpScale 0)   
      (myView init: show: setScale: Scaler tmpScale tmpScale)
      (myView init: show:) 

The scaled views that I generated from a 'full size' seemed pretty good at any size but this code could be improved by having more than just one view to choose from.  We could make a 'half-size' view with max dimensions of 160x85 and perhaps another 'quarter-size' one.  Compute the scales against all 3 views and choose the one that has a resulting scale nearest to 100 - this may help with any visual degradation when the scale size gets too small.

I've attached a screenshot of 3 different views, scaled at 5 different 'room sizes' using this process:

SCI Syntax Help / Scaler error
« on: November 11, 2017, 10:16:51 AM »
I'm having a problem using the scaler.  When I call it with a view that has an instance explicitly declared in room (Egg) it works just fine, but when I call it on a view I create 'on-the-fly', the scaler throws an error of "<View setScale:> y value less than vanishingY".  My best guess is that I'm improperly creating the on-the-fly view, but I don't know how else to do it.

Code: [Select]
(method (init)
     (super init:)

     (Egg         view:24 loop:4 cel:0 x:100 y:100 init: setScale: Scaler 50 50)
     ((View new:) view:24 loop:4 cel:0 x:100 y:150 init: setScale: Scaler 50 50)

(instance Egg of Prop)

EDIT: Deferring the scaling doesn't seem to make a difference either.  The 'egg' instance works just fine, the dummy fails in the same way as the code above.
Code: [Select]
        (Egg view:24 loop:4 cel:0 x:100 y:100 init: )
        (Egg setScale: Scaler 50 50)
        (= dummy ((View new:) view:24 loop:4 cel:0 x:100 y:150 init:))
        (dummy setScale: Scaler 50 50)

EDIT2: I figured it out.  Shouldn't be using the 'View' class, should be using the 'Prop' class.  Once I changed the code to new-up a Prop it worked fine, which made perfect sense once I discovered the scaler property associated to Prop.  :-[

Pages: [1] 2 3 ... 9

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

Page created in 0.145 seconds with 18 queries.