Menu

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.

Show posts Menu

Messages - vga256

#1
Awesome, thanks. Will get to work on the engine ports.
#2
Thanks Dualnames. Would appreciate a heads-up on the exact interpreter version being used so I can start doing the back-end work on the macOS/Linux/iOS ports.
#3
Neat! I'll look into that module. Thanks.
#4
In that case, I will focus on making 3.5.x ready for Mac/Linux/iOS.
#5
FWIW, if someone is willing to take the reins of the 2021 client, I will be happy to continue producing Mac/Linux and iOS ports for the future.
#6
Quote from: heltenjon on 04 Dec 2021, 14:39
Could it possibly be made a part of the "Adventure Game Studio Depository" collection at the same site, as well? To make it easier to find? i don't know how others search archive.org, but I usually start there if I'm looking for anything AGS.

Great idea. I will send a request over to the maintainer of that collection and ask to have it added.
#7
Quote from: Miez on 03 Dec 2021, 21:30
Thanks for the kind words and feel free to upload it to archive.org - that's actually a great idea!

Done! All of the above files are now available on archive.org Sorry about the weird music/sound preview in the header - I'll iron that out another time.
#8
Just dropped in to say thanks for your work on FoY, and sharing these great assets!

I first heard of AGS and FoY through the original Barnett College site back in 2004. If it hadn't been for this brief exposure, I would have never made note of Eternally Us several years later.... and several years after that, work professionally in the (adventure) game industry.

So, my hat's off to your project - it lives forever in a happy time when adventure games became exciting again. Thank you.

With your permission, I'd like to upload these files to archive.org so they have more permanent lifespan... our AGS history seems to vanish any time files live on external hosts :)
#10
It sounds to me like you're using a fresh install of Windows 7 that is very old, and does not have a working copy of Windows Update. Windows Update must be able to run and patch your system up to a much more current version of Win7. This is not an AGS problem - it is an old/unpatched operating system issue.

If you are running a 64 bit version of Windows 7, download and install Service Pack 1 first. A 32-bit version of SP1 is available here.

Once SP1 has been installed, then you can start running Windows Update to patch your OS up to the most recent version.
#11
Edit:
I remember running into this problem a few months ago on a new install of Windows 7. It is very possible you have the incorrect version of MSVC redistributable installed for Win7. Download this zip file, unpack it, and install vcredist_x86.exe.

If that fails... you can check if AGS has been quarantined here:
If you use Windows Defender (built into Win7)...

Start -> Type "defender" into the search box.
Click on "Windows Defender" in the search results.
The Windows Defender window will open up. At the top click "Tools".
A new window will open. Click on the "Quarantined Items" link.
If something with AGS in the name is in that list, click on it, click "View" and then "Restore" to remove the program from Quarantine.

#12
I am simulating an operating system, which uses a Macintosh-like wristwatch for a wait cursor. It is visually distracting when the hands reset themselves due to a new Wait().
#13
Thank you CW. Your example project allowed me to do a side-by-side comparison with mine, and I pinned down the exact cause: I had all 8 frames of my MOUSEWAIT View populated with graphics in the editor! I deleted all but the first frame, then set its image to zero, and voila - perfect looping behaviour.

So for anyone else who wants to use this little mouse cursor looping trick: your View in the editor must have only one frame with no image in it.
This was mentioned in Khris's original post "-remove all frames from the view but one", but I somehow missed that critical point!
#14
After reading this post on mouse cursor looping I went ahead and tried to replicate the same behaviour using the latest build of AGS 3.5.1. It no longer appears to work - the mouse wait cursor continues to reset itself to the first frame when a new Wait(x) is called.

I also noticed that when the animation runs, it "hiccups" and skips between frames. It appears as if the engine is competing with itself for the View's graphic property - sometimes the (below script's) scripting code "wins" and sets the graphic property, other times the view's default animation "wins" and sets the graphic property. Is there a chance that the engine's graphics execution order (or script execution order?), or something else has changed since this code was written in 2014?

Have I missed something obvious?


Update: cause of the problem found. See my response below.

Code below. I have ensured that the correct View is being used, as well as wait delay, frames and sprite numbers.
Code: ags

(at top of script)
// mouse wait cursor
int cursorWaitView = MOUSEWAIT; //view of your cursor
int cursorWaitDelay = 5; //animation delay of your cursor
int cursorWaitFrames = 8; //number of animated frames
int cursorWaitFirstSlot = 21; //ID of the first frame
int cursorWaitCounter; // maintain a counter for the cursor

function UpdateMouseWaitCursor()
{
  if (!IsInterfaceEnabled())
  {
    cursorWaitCounter = (cursorWaitCounter + 1) % (cursorWaitDelay * cursorWaitFrames);

    ViewFrame* vf = Game.GetViewFrame(cursorWaitView, 0, 0);
    vf.Graphic = cursorWaitFirstSlot + cursorWaitCounter / cursorWaitDelay;
  }
}

function repeatedly_execute_always()
{
  UpdateMouseWaitCursor();
}
#15
So glad you wrote this. Just saved me a ton of time redoing the same work!
#16
Quote from: eri0o on 08 Sep 2017, 12:15
Another option :-\

I Wonder what people who releases games on Steam does or if it's not needed at all and users are ok with it.  ???

Sorry for the Necro. The Steam (and GOG) launcher is signed and launches the game on behalf of itself, so the game executable does not have to be signed. Signing is only useful if you plan to launch the game via the Windows store, or on itch.io, or some other storefront that allows the game to be run without a launcher.
#17
Ah, okay - so I did not anticipate any of this because I have not implemented any room logic yet! Yes, the plan was always to have character animations, Objects and Hotspots - so I guess my ultra simple implementation will not work. Back to the drawing board.

Will post an update when I start trying to actually build a usable room.
#18
If you need the Line Spacing different for different controls (ListBoxes, Labels, etc), you can duplicate the font and have different versions of it for each control. E.g. eFontListBox with Linespacing = 2, eFontLabel with Linespacing = 3, etc.
#19
I am happy to report that I now have a working implementation. I created a completely invisible dummy GUI called "Occluder" that receives the same X/Y position as the Room GUI. When the Room GUI is set to Active (currently on top of other windows), the Occluder GUI is populated with a new backgroundgraphic:
Code: ags

  newOccluderSprite = DynamicSprite.CreateFromDrawingSurface(roomBackgroundSurface, 0, 0, roomBackgroundSurface.Width, roomBackgroundSurface.Height);
  gOccluder.BackgroundGraphic = newOccluderSprite.Graphic;

In other words, I'm simplying copying the Room's background surface onto a new sprite, then setting that sprite as the background of the Occluder GUI. After that, I set the Occluder GUI to be on top of the Room. When the Room GUI is inactive (behind another GUI), the Occluder gui is hidden.

Although this is twice as much rendering as we'd normally have, there do not seem to be any obvious performance penalties, and the implementation yields perfect behavior.

Video demonstration here.

Update: I realized that having an extra dummy/Occluder GUI is not even necessary - I can just use modify the background image of the Room GUI itself.
#20
Quote from: Cassiebsg on 20 Oct 2021, 10:23
But considering that maybe it's just a still image, maybe you could take a screenshot of the viewport room, and then use that as the BG for your GUI while you are dragging it around. Then once you stop dragging you would just turn back to the normal transparent BG to see the room. (or if it's easier, just have a dummy GUI with the BG screenshot and switch to it while dragging).

Haha yup, this was my original plan! I'm fairly sure I can just pause animations in the room when the GUI is forced to the background.
SMF spam blocked by CleanTalk