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.

Messages - lance.ewing

Pages: 1 ... 3 4 [5] 6 7 ... 40
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.

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.

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

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.

This might be where I saw it:

Look's like it was removed quite a while ago.

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

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

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?

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?

AGI Development Tools / Re: agi.js
« on: April 29, 2017, 01:50:17 PM »
Hi r1sc! Great to see that you've registered on here. If I didn't already have a few AGI projects in my queue, I'd definitely be keen to contribute immediately to agi.js. I have a history of picking up other people's projects, such as the Java AGI interpreter that I did a bit of work on last year. So I've added agi.js to the queue.   :)

As I mentioned to you a few days ago, I'm currently working on an AGI interpreter in C#, which I notice from your github account that you're also proficient in. I certainly can't claim proficiency since this is my first C# project but hopefully it will turn out okay. It's a shame I can't share the code at the moment. What I did was fork Collector's bitbucket AGI/SCI Developer repo, which I think is private, so the fork is also private (as an aside Collector, I think we should make the repo public if we can). - We seem to have a lot of C# developers on this forum, which is kind of why I decided to write this interpreter in C#.

But I'm also a big JavaScript fan. I've entered the js13kgames contest two times in the past. Neither entry was complete. I always end up being away on holiday for half of the one month period, which means I've basically got 2 weeks to create something new. This year I'm planning to create an adventure game if I can.

If you're not planning to work on agi.js yourself anytime soon, it would still be great to see you in the forums. To have spent all that time creating the AGI interpreter in JS, you obviously have a passion for it. We all have long term projects on the boiler that we come back to every few years. Most of the time we're just talking about stuff.


AGI Development Tools / Re: C# AGI Interpreter
« on: April 25, 2017, 01:49:42 PM »
A quick update to say that I've been doing a bit of refactoring on the graphics side of the interpreter. I'd initially assumed I could get away without needing to have what the interpreter calls background "save areas" for my animated objects. My reasoning was that I simply needed to redraw the animated objects on top of the background on each cycle. This works fine in most cases, but it rules out some of these non-standard features like leaving a ghost of a save area behind on the screen when using the position command. My interpreter wouldn't have been able to support that properly without background save areas. So now all the animated objects have background save areas. I'm still working through some of the finer detail with how the off screen and on screen pictures are handled. Soon I hope to have it pretty much exact.

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.

I've now checked the MT DB backup and can confirm that all three of those threads are in that backup.

We have confirmation of the "consumption" in the following thread from last year:

First reply says this:

Briefly: one of the two (or three?) fora that were eventually merged into OS-Dev was a forum on a message board called Mega-Tokyo, originally hosted on Geocities IIRC. It was primarily a site for supporting an FOSS reimplementation of the AGI and SGI game interpreters originally used by Sierra Online in the mid-1980s. I am not sure how it came to host an OS forum, but I assume that one of the mods had an interest in the subject.

Reading on it would seem that it was a merger of the osdev forums on MT and the forums:

Oct 18 2006: The two largest os development forums, and, are merged in to one single forum creating the single largest community of operating system developers working on different OSes. The original OS development newsgroups are eclipsed by several orders of magnitude in traffic.

I'd have to check to be certain but I suspect some of the non-AGI/SCI specific forums were consumed as you suggest may have happened. I have a db backup of the whole of the MT forums, so could search for those posts later on; unless someone else beats me to it.

AGI Development Tools / Re: WinAGI is Back
« on: April 17, 2017, 03:55:28 PM »
I did go through periods of nostalgia, where I would search around, but could rarely find more than broken mirrors, especially after the "Ultimate AGI/SCI" site moved and became less a thing. It was a few years back that I did find a playthrough of TLP on YouTube, and a running copy on, but it was never the complicated mess of a solution I remembered best, and only this past week found *that*, setting right a bit of memory.

A couple of months back I discovered that The Ruby Cast demo was on as well. Amazing what turns up on there, and great to know now that The Ruby Cast is preserved in that form.

Still deciding if I'm "back" but tools and such are definitely familiar. While I know I could try SCI instead, it does feel like i've got unfinished business with the state of my past AGI gamey stuff.

Well I guess you are "back" whenever you post a message on here. That's kind of how I view it. I got lost in a bit of VIC 20 nostalgia at the start of last year. I spent literally 6 months staring at a microscopic photo of the silicon layers of the video chip used in the VIC 20 and was trying to reverse engineer the schematic. Made quite a bit of progress while I was at it, perhaps covering about a sixth of the surface. I guess I was away from the AGI community over that time but made another return in the second half of last year.

The Ruby Cast is certainly unfinished business for me. I will eventually focus enough to continue working on that.

It should definitely be possible to create it more like SCI and have the prompt and text input within the window. That is what I got working with that screen shot I posted earlier in this thread.

Yeah, it seems that losing the first key is an issue though, unless you were to do as you say and have a key that opens the dialogue. Var 19 does store the last key entered but get.string doesn't allow you to pass in a starting value. You could add it to the prompt parameter I guess, which would mean that the entered key is displayed but it would then be a permanent part of the entry and couldn't be deleted. The original AGI interpreter source code shows that the GetString function calls a GetLine function that does support passing in an initial value for the string but unfortunately GetString clears the string before calling the GetLine function. If only it didn't do that (would be easy to hack the AGI interpreter so it didn't clear the string but that wouldn't be AGI anymore).

Pages: 1 ... 3 4 [5] 6 7 ... 40

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

Page created in 0.091 seconds with 21 queries.