Messages

Yep. We're hard at work polishing up the engine, and fixing various issues. In answer to some of the previous questions
1) We do have fallback detection for any unknown game title found, so any games we don't know about can still be added. The only downside is that it gets added with a generic "AGS Game" description. Eventually, the fallback detection will be enhanced to extract the game title from the found game and display that instead.

2) As for support, the ScummVM engine in theory supports the same version range that the standalone source it's based on does (i.e. 2.5+). However, the ScummVM reimplements the Allegro library as a thunk layer to translate calls to the ScummVM graphics classes & code. So initially there were lots of games that crashes due to mistakes in my implementation, or some of the more obscure Allego drawing routines not being implement. Likewise for the C++ std classes. That's our current focus.

As for announcements, Sev already made a posting on the group's Facebook page: https://www.facebook.com/ScummVM/
The images there are a good example of how fixes are being done over time.. previously, 32-bit images were getting their RGB mixed up. That also is fixed in the latest daily builds. More formal announcements other than that will probably wait until we're ready to announce an official testing period.

I don't know whether it was intentional or a typo, but I also learned a new term.

Yep, that was intentional. Call it a thunk, bodge, or shim layer. Heh, at times previously at work we called some of our nastier interface code the "Wibble" layer, from the Rowan Atikinson Black Adder series where he pretended to be insane by sticking pencils up his nose.

The biggest problem of the current codebase in ags engine is that it's very dirty, and fuzzie did a big job refactoring it into cleaner code. I think I must mention this. Over time we were gradually replacing old code with new one, especially when adding more features, but there are still places that look just terrible.

That makes sense. It's a trap I've fallen for myself in the past - back when I was converting a previous project to work on ScummVM I started making too many changes, then when the time came to debug it when I got it up and running, it became difficult to track down issues. I guess it was even harder if things were actively being changed in the source codebase. These days when I'm converting projects I initially tend to try and keep the original code as unchanged as possible, and simply create a thunk layer to emulate the original libraries. Then only worry about any cleanup once I've properly gotten everything to at least run. Over the last few days I've created a ScummVM skeleton engine, and seen how much code I code import and get to compile. It's been fun, although frustrating in that I still need to put it aside to finish my current project. But it seems like once that's done, I likely will experiment over the Christmas holidays to see if I can get it working for ScummVM.

I played around with the fork of fuzzie's work on adventuregamestudio/scummvm, and the results are just too poor for my liking. Of the games that had detection entries, one crashed trying to load data, one threw a wobbly about slider value, and the final one did manage to start showing the intro sequence but then crashed with "FollowCharacter unimplemented". It's just unfeasible for someone like me, with no prior experience with the AGS engine codebase, to try and debug and update a semi-restructured/different project. It'll result in endless frustrations for me. Far better to have an almost identical codebase based on the current community engine, where the backend Allegro or SDL calls have a ScummVM stub layer. That way if something goes wrong, I'll be able to compare execution between the two if something goes wrong in the ScummVM version. That kind of thing has been helpful in the past. For example, I once hacked DosBox to do output of port values written to the sound card in one of the Tsunami Media games, and doing likewise in my sound driver code in ScummVM, I was able to do a diff, and easily track down where discrepancies in my code started happening. But I digress. That there aren't any more major changes planned for 3.5.. it may indeed be the case that there's not much to be gained waiting for any SDL changes. I'll have a play around with the codebase, familiarize myself, and see how I go.

Thanks for the informative reply. It sounds like it'll be more effective for me to work on the AGS3 "final version", after the switchover. Whenever that happens. I'm also familiar with SDL, and not at all with Allegro, so it would certainly make it much easier to make a port for ScummVM afterwards. Guess I'll hunt up something else to work on over Christmas.

Hey all. I'm a long-time ScummVM developer, and am currently (hopefully ) in the finishing stages of the current engine I'm working on. So I've been starting to cast around for a project to work on over the Christmas holidays, and thought it might be time to revisit the question of integrating AGS support into ScummVM. The previous threads in years past got somewhat contentious at times, but my understanding was that there was certainly overall support from the AGS community for older games to be supported at the very least. Though technically there are two options, with both the community codebase and fuzzie's earlier attempt, it seems like the community codebase is the way to go in that it covers a greater range of historical versions.

As such my question before I start such an effort, is whether there would be any issues with doing a conversion now. Particularly, I'm wondering what codebase point would be best to be used. I see that there's an ags3 branch, but it seems to be out of date compared to master, which has later 3.5 releases. Would the most 3.5 release tag be a good point to start for a ScummVM conversion? Though I'm also wondering if there's a near-term plan for a 4.0 release? Particularly if that ends up significantly changing the AGS format, would it be better to forget about it for now, and wait for the last 3.x release prior to working on a conversion? Something like that could end up being ideal, since there'd be less issues with a ScummVM implementation trying to play catch up with further commits and sub-releases on the main AGS repository.

Any guidance would be appreciated.

I have set up a repository so we can start to refactor the engine code. Any developer willing to join is welcome to.

...

In the meanwhile, we should also discuss coding conventions, ScummVM's seem to be a good starting point.

Particularly given that you're in favour of following the ScummVM code formatting guidelines, it may be worthwhile considering merging your effort with that of fuzzie, who's recently started a combination refactoring of the code and porting it to the ScummVM framework.

See  https://github.com/fuzzie/scummvm/commits/ags for the repository, and http://logs.scummvm.org/log.php?log=scummvm.log.12Feb2012&format=html around 14:15 where there's a brief discussion about it.

Given how much work I understand refactoring the source code at all will take, it seems worthwhile to merge efforts. I know there's a lot of talk in the AGS Source Code release thread recently that I haven't weighed in on, but there doesn't seem like any major issues that would prevent collaboration on cleaning up the code.

"Those people" are mostly me  . In fact, if you look at their forums right now, you'd see that I started a thread about AGS going open source. The truth is that this could be the greatest thing to happen to ScummVm in years!

I dunno. The added support for Sierra SCI games would probably still top it. 

If AGS goes open souce, think about all the platforms it can be ported to!

Not to mention that we'll be able to port it to ScummVM, and finally dispense with the people who keep asking whether it can integrated. 

Whoopsie. The download is version 1.2.. I guess I forgot to simply update the labels on the webpage. I'll do it tonight.

Okay, I sorted out the problem. It seems that several lines dealing with Gurgi actually falling into the cauldron, and flagging his death were missing - I must have accidentally removed it. I've put the appropriate code back, and uploaded a new version of both source and executable to my website.

Thanks for pointing it out to me. 

First of all, yes a GUI can take up the entire screen if you want it to.

As to your problem, are you putting the script in the interface_click method of the global script? From the sounds of it, your script isn't getting called at all. What you could is put a debug message at the start of interface click to display the interface and button values, to make sure you've got them correct.

Finally, when using the GUIOn and GUIOff methods, it would probably be better to use the names of the GUI rather than the direct number, as it makes your code clearer, and less likely to get gui's mixed up.

If you could send me a savegame from the cauldron room before you try to jump in (and Gurgi takes your place) to tg_files@hotmail.com, I'll have a look into the problem.

Hey Strazer, thanks for providing for providing such good support for people asking questions.. I just got back from my summer holidays, so if anyone has any further questions, I can answer them now.

Dragonrose, if you're still around, I'm not sure how you managed to start walking around the forest again.. when Gurgi's entered the Cauldron, and the cutscene of going down the river is finished, the walk cursor is meant to become disabled, preventing you from moving, and forcing you to talk to the witches and end the game.

[Display("test");]

That looks fine. If you're still not seeing the inventory item in inventory after that, it must be some other problem. A few I can think of:

* Perhaps you put the script in the wrong hotspot. Try putting a debug line in the script, such as Display("test"); to make sure the script runs.

* If you're using a custom inventory script, you might want to try reverting back to the built-in one temporarily just to check whether your object is appearing.

A minor plug - version 1.1 of my Black Cauldron remake contains a custom save/restore dialog box with support for more than 20 slots. In retrospect I could have optimised it further, since I didn't know about the GetSaveSlotDescription method, but you may get some good ideas for it. Basically, I use a custom file to store the current ordering of save game slots, and then use it to load the listbox with the save games in the correct order.

http://tg_comics.tripod.com/bc.html

Hi there,

Whilst working on keyboard control for a custom save/restore dialog in my game, I noticed that the keycodes for the small area of the keyboard that contains the Ins/Del/Home/End/PgUp/PgDn keys (not the numeric keypad) seem to have a weird effect with the global on_key_press method.. not all the values map to the values the help file says they should.

The Page Up button is particularly noticable, in that it maps to 380, which is the key for the down arrow. I tried putting the following line at the start of the global on_key_press:
Ã,  Ã,  Display("%d %d", keycode, IsKeyPressed(keycode));

It showed that whilst several of the keys mapped to the correct value, only one of them returned 1 for the IsKeyPressed check. So what I'm wondering is why this happens.. is it a bug, or is it intended? And if it's intended, then why?

Thanks for the praise. I've finally gotten version 1.1 finished and ready for download. I took some extra time to add some spiffy features, like a custom save/restore wrapper to allow more than 20 savegames, and enhanced keyboard and mouse support in the new save/restore dialogs.

About two months for the main body of the game, once I got beyond general experimenting with AGS and decided to concentrate on remaking Black Cauldron. But keep in mind that I dedicated a lot of time to it, frequently working until after midnight on weekdays, and all day on the weekends.

I somewhat sacrificed my social life whilst working on it, but it was so damn engrossing, and so cool to see the game coming to life as a result of my efforts.

Yeh, sorry I didn't reply too quickly. As you found out, the current source has been compiled with the latest beta. It's taken kind of longer than I expected to get the save/restore dialogs working properly, since I want them to have more than 20 slots, which means I had to implement my own ordering code. Hopefully I'll get it finished shortly.