Messages

... quoted myself instead of editing ...

Photos can be manipulated to look like low res pixelart. In fact, that's the exact procedure that was used back in the day, but with scanned paintings instead of photos. Later in the FMV era, photos *were* the backgrounds.

There are several key elements to achieve the pixelart look:

- Jagged scaling. There were no advanced scaling algorithms back then that would blur the image. Linear scaling was the norm and edges were sharp!

- Enhanced contrast. The one chief difference from paintings to photos is that paintings usually exhibit much higher contrast values. Also, higher contrast works well with scaling and color reduction.

- Color reduction. Old games used 256 color palettes, but the background used lot less than that, usually no more than 150 colors. The rest was used for characters, fonts, palette shifting effects. That gives the familiar pixel jaggedness and randomness in color. Palettes can then be further edited in various software to achieve a more unified look across multiple images.

Here's the original image after a short work in Gimp.



In order:
- making the colors stand out by enhancing contrast, modifying curves, exposition
- rescaling the image down to 320x240 using the linear filter
- converting the image to indexed mode using just 96 colors


Now this is an almost completely automatic job. But even then, look at the flower pot and the staircase and railing around it, or that metallic grill thing on the right. That stuff already looks like something out of an early 90s Sierra game.

When done with more hands-on approach, one could separate image into layers and then convert each layer individually. Like how in my edit the arch uses a lot of colors and still looks messy. It would look much better if it used less colors. On the other hand the diner/bar area could use a little more colors and detail. The floor could use less contrast to not appear so washed out. Also, any sharp edges on letters etc. could be improved by hand. And the perspective could probably be tweaked so it looks like a proper 2-point perspective.

Photoshop will have more options for indexed images than Gimp, just because of its early 90s legacy. You even get extra points if you use an actual 90s version of PS.

Even with all possible optimizations, it would be completely unfair to judge AGS by its ability to run on systems it was not designed for.

I also did some research into SCUMM(VM) innards to see how it all worked back then. The level of optimizations it used to display scrolling backgrounds and animated sprites is absolutely huge. Even the pathfinding is just simple 4-sided polygons, using precalculated table for movement between them. Old cpus couldn't possibly handle even the simplest A* by today's standards.
That's when talking about "classic" early 90s era. From late 16bit 286PC or A500 to early 32bit 386 or A1200.

AGS, if optimized to insane levels, and with executable written from ground up in 32bit protected mode, could probably reach the performance of let's say, Full Throttle or Curse of Monkey Island. That's based on how AGS treats rooms, sprites, scripts, etc... which is similar to late era Lucasarts. But even those games are out of reach for a good old 386 or Amiga 1200. If not just by CPU power, then definitely by RAM usage. Let's not mention the 1MB Amiga 500, or 640k 286 PC.  Those old beasts just can't effectively handle C  , middleware libraries, and other late 90s "modern" stuff.

And the whole reasoniing of today's retro development is to be able to run on low end classic hardware or its emulation. Otherwise, what's the point.

Well, the point is to learn 16bit programming from the ground up, obviously! 
That's what I'm doing right now and it's the most fun I had on a computer in a quite a long while!

A bit late to the party, but here's my two cents...

Over the past few months I have tested old AGS versions running on MS-DOS, both real hardware and in Dosbox.
I've tested all versions of AGS that I could find, starting from 2.62 going backwards.

The conclusion is: AGS is almost pointless on DOS - it's just too slow. It runs, but it needs at least 486DX4 or Pentium CPU,with lots of RAM, which kind of defeats the whole purpose of DOS gaming.
And it's not (just) script, as I run the most basic one-room example. It's the pathfinding that completely kills the gameplay. It stutters every time it processes movement paths, even on 486DX2. Even the documentation of those versions recommend Pentium over anything else. Remember, this was early 2000s, DOS was "ancient and useless" back then, not "retro and cool" as it is now. 
AGS really was never a DOS software, but Windows 9x software that could run in Win9x MSDOS mode. Which is similar, but not the same.

So, based on this experience, I really doubt AGS would run effectively, even if it could theoretically, on any classic Amiga, even with the 68060 cpu. It's not you Amiga and DOS, it's the Moore's Law.

Oooh, they've just announced the 2.0 update! And now they're supported by Analogue, the guys who produce vintage console replicas, including the FPGA Gameboy clone. Greatness!

https://www.youtube.com/embed/Wk96Pf6OL8Y

I used to program a bit in GB devkit, or whatever the C libraries were called, the stuff that this is based on... way back in the day. Early to mid 2000s I believe. It was the GBA era, even before the DS.

I kind of regret missing so much good stuff in later phases of the original Gameboy. My unit was collecting dust by the late 90s, with all the 3d craze on the PC and real life getting in the way, and I've actually only discovered Pokemon games last year when my daughter got me hooked on them... we played through the first generation, and this year we're on Pokemon Crystal. All played on N3DS with fully functional GB linking, Pokemon trading etc... Fantastic RPGs!

I would definitely love to see a proper text adventure made with today's technology. And by that I mean the text parser input but with all the computing power, deep learning, neural networks and all that googly jazz...

Have you see this topic?
https://www.adventuregamestudio.co.uk/forums/index.php?topic=58222.0

Wow, this is ridiculously cool... tried it a few times and got some nice results out of it... it reminds me of a vastly improved version of Facade.

A VGA or high resolution of the Hobbit text adventure would be cool, especially if it keeps the parser, but then also adds point and click functionality as well.

I would definitely love to see a proper text adventure made with today's technology. And by that I mean the text parser input but with all the computing power, deep learning, neural networks and all that googly jazz...
I'm constantly frustrated by people bashing parser input as outdated, while millions use google search parser on daily basis. It's the '80s parser *technology and implementation* that got outdated, not the actual input method.

It may be both, but the issue here, IMO, is in different perspective on a program. You may look at this from "outside" seeing a final result, or from low-level to top, so to speak, seeing it as a set of parts. Because when it is a set of parts, it's easier to accomodate for more variants of use.
....

Exactly, and not only would it allow more variants of use, it would allow a decentralized development, and most importantly, quicker release circles, which is paramount in any software development, especially open source.

It sounds like your describing an IDE more suited to a professional development environment, rather than what AGS is, and always has been, to a lot of it's users: a simple, all-in-one, hobbyist tool.

But I'm no software engineer.

It kind of sounds like that to me too.
I think first and foremost, AGS should cater to the hobbyist over the professional. Sure, it's preferable to cater to both whenever possible. But if one has to be chosen over the other, the hobbyist should come first.

The problem with that approach is that so called hobbyist tools require more, often waaaay more, professional-grade work hours to get them to a polished state. And that can be problematic in an environment where work is not honored in money.

Open source software must use other leverages than financial gain to draw in developers. Focused passion is one of them. Some people love making GUI apps in high level languages, some people love making compilers in low level languages, some love designing scripting languages. It's not sensible to make the GUI guy do it all in low level programming code, or to have the compiler developer wade through endless gui source listings etc. It kills the passion, and consequently the project.

["works-out-of-the-box,"]

This is about the most misguided thing I've ever read. Sure, let people use other editors if they want/need to, but Adventure Games Studio as a complete, single-installation, "works-out-of-the-box," pretty well documented IDE is probably the second most important factor to its success as an engine (the first being that it's completely free). Give up on that and we might as well shut down now.

AGS works out of the box. On certain version of Microsoft Windows, with certain version of GUI toolkit installed. Once you're out of that ecosystem, you're screwed. Which makes AGS a lot less free and certainly a lot less portable than it could be. That's the whole point I was trying to make.
Add to that the fact that there just isn't a single GUI paradigm that works on all platforms or all devices for all users. The concept of a productivity app is in a state of flux at the moment and is changing on a daily basis. Just look at all the IDEs, Music DAWs, 3D Apps, Game engines. Almost all of them have unique proprietary GUIs built in-house. Conceptually, we're right back where we were back in late 80s gui-wise. It's everyone for themselves, and the concept of an unified interface on an unified platform on unified hardware is pretty much dead.

The other point was that writing usable GUIs occupies a whole lot of valuable resources. It is certainly nice to whip out own cross-platform widget rendering engine, text buffer and code parser. But then users start asking for syntax highlighting, window resizing, code auto completion, dark modes, etc. The list goes on and on, and sooner than later, you're writing a GUI library instead of adventure engine. And then someone comes up and says you're an old dinosaur who prefers puffy 90s icons, or a clueless material flat icon hipster. 

And based on all that, the sensible conclusion is to completely decouple the presentation aspect from the creation aspect. If someone prefers classic desktop interface, let them have it. If someone prefers web-like touch-friendly "material" look, let them have it. If someone prefers coding it all by hand in Emacs, let them have it, but at the same time let the compiler programmers worry not about it, at all. They get the configs and scripts and act on them. How and where those scripts were created should be the least of their concern.

This, divide-and-conquer approach has an additional benefit that it might attract GUI programmers who would otherwise be scared away from contributing to the project. This way a GUI "studio app" could be written in languages different from the core, from python to javascript to C, whatever someone prefers. They don't need to fork the main project to do it and they just need to output text files standardized with the compiler. The gui room/view editor could be written as a plugin for GIMP, Krita, Photoshop, Tiled, whatever, and let their programmers worry about dark modes and window resizing. Artists familiar with Photoshop would likely prefer to edit/preview rooms while working on art, without the need to import to the main app.

This way the 'adventure compiler' could be written in bare standard languages that'll compile on bare standard compilers, regardless whether particular GUI toolkit runs on a particular platform. As long as it reads script and asset files and outputs bytecode.

And then only the runner is tied to a particular platform. So a Windows/Linux runner could be written in C++, web runner could be written in javascript, iOS and Mac runners could be written in Swift. Sh!t, an Amiga runner could be written in assembly, as long as it gets the adequate bytecode and assets. Or it all together could be done as a ScummVM plugin and be readily available wherever and whenever ScummVM is available.

I mean, Java VM couldn't care less if the programmer used Netbeans or Eclipse to do their work. Unity couldn't care less if artists used 3dsMax or Maya for 3d models. AGS now doesn't give a rat's ass whether images were made in Photoshop or the GIMP. It's just standardized data...

Not only should the new tech be prioritised over backwards compatibility, but IMO, the whole concept of a "studio" app should be dropped as well.

GUI toolkits and the whole concept of GUI apps in in a such sad state of affairs right now. Proffesional GUI apps I mean. It seems everybody and their mother is reinventing their own custom GUI toolkits. The old ones are getting bloated into oblivion... It. Just. Makes. No. Sense. Anymore. Whatever one does today in whatever GUI toolkit, it will be hopelessly outdated 20 minutes in the future. And in the same time, it will severely limit the cross platform support.

There's really no need to waste resources on editor apps in this day and age. There are countless level editors, image, text editors out there that can be used instead.
I'd argue thet the best way of maintaining future-proof backwards compatibility (...I know Doc, but I'm back, I'm back from the future! ) is to have exactly zero binary code in an author's game project folder. Apart from obvious image and audio assets, that is.
It should be possible, maybe not desirable, but possible, to create a game in plain text editor, with nothing more than project script files, config files, binary assets and a command line compiler. The "unix way" of doing things. Visual editor should be an optional part of the toolkit, not it's foundation.

Editor(visual or not) + scripting language + assets + compiler + runner = game.

All components are interchangeable as long as the interface between them is common.

In that spirit, maybe the S in future AGS should stand for STANDARD?

To sum it up: different songs for different game parts, and each part endlessly looping (until the scene ends), with the possibility of more than a straightforward loop of the entire piece (eg. skipping an intro when looping). A tracker module music does that by design. A plain audio file requires additional steps to produce the same result.

I hope that did answer your question about how dynamic I want the playback to be â€" not so sure I was clear enough â€" you tell me â€" but it's the best I cand do to describe it I'm afraid.

That's essentially what iMUSE (https://en.wikipedia.org/wiki/IMUSE) was back in the day, which was the pinnacle of using built-in synth chips.
It's a musical equivalent of palette color shifting in indexed graphics. A lost art.

Stuff like that doesn't exist anymore, for various reasons.
Mainly that old hardware had limited storage space, so hardware synths were a necessity. CD kind of killed that, quite brutally. Playstation games literally played music tracks from the CD, and that was considered "high tech" and "progress" back then, compared to "obsolete" synth-on-chip implementations of 8 and 16-bit era. So instead of built-in music instrument, we got a glorified mix tape to play along with the game. 

Another reason is sheer convenience - it's much easier to create "normal" soundtrack music and then just play predefined variations of the same theme, than to "program" a synth. Not to mention a much larger pool of available artists - If you go the synth way, the musician has to know your synth and workflow. Otherwise, they just have to know their own instruments and workflow. This way they're also completely decoupled from the programming department, which is again convenient for scheduling and management. It's a win-win-win situation for artists, programmers and managers, with the downside being we're having movie soundtracks in games.

But, all being said, I agree with you and still think there's a huge untapped potential in this field. The gaming world has been in need of another iMUSE for a long, long time.

I'm still working on adventure games in gamemaker and due to my background with AGS I instinctively structure my games like AGS would.

Out of curiosity, how did you handle Gamemaker's resource handling? Has this changed in recent times? I've been out of the loop since GMS2 was introduced...

The reason I'm asking is I have developed a point'n'click engine in GMS v1.4 back in he day. There's even a thread in this forum somewhere...
But I eventually abandoned it as I realized Gamemaker was introducing more problems than it was solving.

Biggest issue was resource caching - GMS kept everything in RAM, all of the game graphics and sounds, *uncompressed*, *all* the frickin' time! Which is not a problem for simple tile-based games, but once you hit it with dozen or so high res background images and animated sprites, things go south quite quickly, especially on mobile.
That demanded creating own resource handling system to load room data, etc. -  custom room editor, custom bytecode scripting system... By this time I realized I was using 80% of time just handling GMS peculiarities, and said fudge it.

And all of that would be irrelevant if Gamemaker had its own resource caching system and was loading dynamically from data files. Apparently this was an intended, built-in killswitch mechanism that prevented users from creating other "game makers" in Gamemaker. To be fair, it still could be done, there are quite powerful functions for dealing with binary data, but doing that kind of work in GM Script is ... painful.

What I usually do when I'm in extra-careful mode is just create a batch script that compresses the entire working folder and copies it to a backup location, like an usb drive or cloud storage.

You could add the shortcut to the batch file on a taskbar or start menu, and it becomes really streamlined that way.
Save your work, then click on taskbar icon, and it's done.
That's the hoarder method. Not really useful for source code versioning, but quite effective for safety storage, and art/binary backup.

The smarter method is to use git / github, or other version control. But that's boring. 

The lazy method is to have your game folder in a Dropbox folder, automatically synced.

And the paranoid method is to combine all of the above.

Do you mean importing parser contents in the Editor or modifying it at runtime?
BTW I wonder if editor plugin API currently has access to parser dictionary. If it does, then this may be solved with the plugin.
Otherwise, some generic format should be established, as well as a rule of how and when the import occurs. OTOH morganw wanted to gradually shift Editor towards using files directly from disk rather than requiring to import them into editor data. This is too for consideration.

I meant just replacing the current input method in the editor with plain file input. Currently, it's difficult to input new words and to edit old words, once the dictionary gets too big.
So basically the engine parser data structure remains the same, it's just the user input method that changes.

But having a dictionary at runtime definitely sounds like a more useful option!

I saw there was a suggestion to improve text parser a bit over there in the now locked alpha thread...

I have one little improvement in mind that could streamline the whole parser business a lot:

Could we have parser words imported from plain text files?
Something simple like csv, which just lists all possible sinonyms in a single line of text. Ie. each line becomes a word group. Or we could manually specify groups as first value, whatever.

1, look, examine, peek at
2, get, take, pick up
3, talk, ask, tell, inquire
......

That way we can have all the words in a separate spreadsheet with spell checking, thesaurus and whatnot, and then just export to csv as needed.

I also disagree pretty vehemently that Photoshop looks best. It's better than the GIMP, but it's still afflicted with dithering pretty much covering the entire image â€" and what's worse, single-pixel dithering. Pixelator has a much more pleasant look to my eyes, though it feels a tad too soft. Playing with curves and contrast to get stronger outlines like in the original screen (which I think still looks better than any of these - just check out the sky in the top right, for example â€" presumably due to manual retouching and/or palette optimization) before downscaling and color reduction would probably have helped.

PS: Quite interesting to notice how in the game version they blurred elements of the foreground digitally.

Agree on all accounts.
Unintentional, unordered dithering of any sorts looks awful on modern LCD screens. The same goes for rogue (magenta, green, especially white) pixels. It's the fact we were looking at crappy old CRTs and that we knew no better that made it so awesome. The cheaper the monitor was, the better pixel shader it had. In those circumstance, there was no dithering, there was just a smooth gradient between colors and rogue pixels were erm... artistic accents. It all looked good then, that's the reason they left it in, in the first place.

There are quite a few areas where these MI2 backgrounds were retouched by hand, to add more detail to edges and stuff like that.

In this day and age I see little to no reason to downscale traditional art. Either go hi-res or do it digitally, either as pixel art or digital painting.
But if I had to take the downscaling route because, let's say, it makes character animation less demanding, and that's the biggest pro I can think of - I would take some extra time to separate the original scan into layers and then downscale, color correct and index each layer separately. Just imagine, in 1991 you probably had to have a Graphic Workstation (anybody remember those?) to do stuff like that. Nowadays any netbook with GIMP installed can do the trick.

In any case, IMO, Monkey 2 had the worst fitting backgrounds of all Lucasarts games. Not that they're artistically bad (they're great!), it's just like the art direction was slightly lost, trying too hard to be Sierra-like. While in fact it was Sierra and their blurry, muddy VGA backgrounds who were wrong all along (hindsight 20-20). DOTT and Sam&Max proved that, and then some.

Ahh, it's all much clearer now, thanks for the explanation! Thumbs up!

In the other situation, when starting from the default template (which has 32bit sprites), then lowering depth and re-importing room images at 8bit, it seems it remains in 32bit mode no matter what, as it still draws original 32bit sprites in full color, regardless of the palette and doesn't cycle even in software mode. Nothing is drawn corrupted and there were no crashes.

When you say "it seems it remains in 32bit mode", have you pressed Ctrl + V in game to check the actual display mode?

Thank you for reminding me of the obvious. Of course I didn't use the debug screen! That'd be too easy wouldn't it!
And yes! It was stuck in Hardware rendering, 32bit mode!

And I think I can finally fully reproduce it!

What settings have the priority when running the game with F5 from AGS? The editor saves it's settings in _Debug folder. I deleted everything from the Compiled folder.
But the game still ran on settings from the previous winsetup.exe in the compiled folder?!
As soon as game is recompiled, ran through winsetup, it will remain in whatever mode was set there. No matter what was set in the editor.

Even if I set the game to 8bit, software, and then compile and run it - it will still run at settings from previous compile (32bit, or whatever). It's only when run through winsetup that it truly changes the rendering mode.

Ok, I think I solved the palette cycling issue, somewhat...

It works if starting from an empty game template, using 8bit mode from the start, importing room backgrounds as 8bt images (with "remap palette" option in Preferences unchecked).
In this case, it will cycle (in software mode) even when raising color depth to 32 bit and using 32bit sprites for mouse cursor.
Then I experimented a bit, throwing in various sprites at various depths, with and without alphachannels and using all possible rendering modes. I got a few crashes and some graphics were drawn corrupted.

In the other situation, when starting from the default template (which has 32bit sprites), then lowering depth and re-importing room images at 8bit, it seems it remains in 32bit mode no matter what, as it still draws original 32bit sprites in full color, regardless of the palette and doesn't cycle even in software mode. Nothing is drawn corrupted and there were no crashes.

Hmmm. Are you sure the game is a 8-bit game? Importing 8-bit assets into a 16/32 bit game will never work as intended.

I thought of this too and created an empty game, switched from 32 to 8 bit, imported one room background, added cycling function in repeatedly-execute-always and that's it.
Perhaps the problem is in this defaulting to 32bit at creation?