Messages

Great work everyone! Thanks for the release.

Hi snake. Sorry to hear about your loss. I myself never had a cat or dog. But I had over a dozen furry family members myself. My favorite was my bunny, Biggles. He was sooo awesome. When ever he was out of his cage he would always sit next to me on the couch and watch TV. If I would lay down on the floor and watch TV, he would lay down by my head, watch me and lick my nose every once and a while. Miss him a lot. He died at almost two years due to pneumonia... I'm sure it is not the same as having a dog for 13 years, but I can certainly empathize. Remember though that time heals a lot of the pain.

Still seems to persist. No rush to fix this though, I am just trying to create a Android packaging tool for AGS and am trying to see if I could compile the latest version. The error seems similar though:

jni/../jni/../../../Engine/platform/android/acpland.cpp: In function 'void selec
tLatestSavegame()':
jni/../jni/../../../Engine/platform/android/acpland.cpp:542:37: warning: compari
son between signed and unsigned integer expressions [-Wsign-compare]
jni/../jni/../../../Engine/platform/android/acpland.cpp: In function '_jstring*
Java_com_bigbluecup_android_PreferencesActivity_readStringConfigValue(JNIEnv*, j
object, jint, jstring)':
jni/../jni/../../../Engine/platform/android/acpland.cpp:302:1: warning: control
reaches end of non-void function [-Wreturn-type]
"Compile arm  : agsengine <= libc.c
jni/../jni/../../../Engine/platform/util/libc.c:22:8: error: conflicting types f
or 'malloc_usable_size'
compilation terminated due to -Wfatal-errors.
make: *** [obj/local/armeabi/objs/agsengine/platform/util/libc.o] Error 1

BTW that is with the 3.3.0 release source code.

I just tried to compile the engine using the Android NDK and I received the following error:

Code: ags

"Compile++ arm  : agsengine <= acpland.cpp
jni/../jni/../../../Engine/platform/android/acpland.cpp: In function 'void selec
tLatestSavegame()':
jni/../jni/../../../Engine/platform/android/acpland.cpp:542:37: warning: compari
son between signed and unsigned integer expressions [-Wsign-compare]
jni/../jni/../../../Engine/platform/android/acpland.cpp: In static member functi
on 'static AGSPlatformDriver* AGSPlatformDriver::GetDriver()':
jni/../jni/../../../Engine/platform/android/acpland.cpp:767:31: error: cannot al
locate an object of abstract type 'AGSAndroid'
compilation terminated due to -Wfatal-errors.
make: *** [obj/local/armeabi/objs/agsengine/platform/android/acpland.o] Error 1

Any idea's what's causing this?

Joseph, I don't mean to be offensive, but I think you are inventing a plan for the plan's sake. In my opinion the lesser versions are situational and are only made when there's a need to add minor improvements to already stable version, while major version is being developed but not yet released.
In my opinion we should rather use the next major version as the primary aim and reference, and release minor versions only if such need arises.

EDIT: Right, I forgot to say this... Regardless of what you think of me, in fact I feel rather disoriented in a situation when people start to invent/contribute things to a project. That's still a lack of organization. I don't have time to check/test everything (and frankly do not want to do this all the time ), so there must be a way for people to organize, that is:
1. Define milestones for the next major version;
2. Discuss and assign tasks to people, so that no one duplicate/spoil others work;
3. Define a set of rules and conventions to let more people contribute previously unplanned additions without messing things up.

Hey CW, definitely not offended. Believe me, I know you have under-taken a large task with not a lot of help. Like I said, you have done an amazing job vastly improving an already AWESOME engine. And that goes for everyone that has helped out on AGS over the last few years. And I know that, even though that there are guys like me and others just trying to provide our two cents to help, that it can be difficult to hear all these things coming from different directions and people. The community would still like to help in whatever way we can. The thing is, we are unsure who to goto to offer this help. While the community views CW and maybe even JJS as the leaders of the development of AGS, we are not sure who is taking the lead. Maybe noone wants to step up or many may feel that it is not necessary, but a project lead would be beneficial. Maybe the community can vote on it? Or maybe all the developers involved can vote on picking one? Don't know. We should leave that with the powers that be, but I think it should be there.

With having that said, and this goes for CW as well as any other developer working on AGS, what is it that us non-C++/C# programmers can do to help in the progression of AGS? We all would like to lighten the load but at the same time not add extra burden on the developers. Would it be beneficial to see if we can recruit other developers from other sites/projects and see if they are willing to lend a hand? Would monetary/material contributions help in any way? How/what can we beta test to help you out? Would it just be better if we simply stick to the basics and just make feature requests/post bugs when we need/encounter them? If there is something we can do to help, then we want to help.

I wanted to get everyones thoughts on this as I can't seem to download Monsieur OUXX's version of the manual any longer... If you check out my Star Wars Game that I am developing and running at sw-bfs.com(Slow going since I am programming all the game features myself), you will notice a rules section. Part of how that works is that you have chapters. Each chapter has its own set of rules which are sectioned off. You can actually see that when you click on the intro. I did something similar with the FAQ. The beauty of the system I created is that when you have administrative priviledges, each chapter/section will have an Add/Delete/Edit button right on the page so that you can edit the rules as you would like. There is only one missing feature on this: Downloading for offline use.

However, on the forums, in one of my test threads for administrators, there is an option to download an entire thread into a story mode PDF or Doc file for offline reading. I could easily apply that to My rules feature and allow the manual to be easily updated online and viewable both on and offline. I can adapt the whole thing for use as an AGS Manual an change the way it displays. I can have it easily export the whole manual to PDF or Doc.

There are only two problems I can see with this, which I can work on. One would be that some may want this to be in HTML as it is easily viewable in web browsers everywhere and would allow for a better sectioned manual. I can do that certainly. I can add it as a third export option. It may take a little longer to implement, but I can do it. The benefit of this would be too that if you are in the AGS Editor and you need help with a particular section of the editor, you can hit F1 or whatever key you would like and it could take you to the right html file to get help rather than take you to the index page/table of contents.

The second issue is that it would be very difficult to make an accurate search function within the HTML version. I can possibly write a Javascript function that would search all the HTML pages for the words provided and display it as search results. However, that is also a little bit of extra work.

But despite this, like I said, this would be beneficial as it can allow easy/fast online editing of the manual and provide an on the fly solution for generating and downloading a PDF, Doc and HTML Help file version. If you think this would be a good idea and would like to use something like this, please say so and I will get to work on it right away. If you prefer Monsieur OUXX's solution or another, that is fine too. I just figured I would give this as an option.

What are the Draconian features you want, Joseph? I am looking at DX9 Vsync currently.

Do people want #region and #endregion? I'm just asking because I'm kind of in that zone right now. On my local repository, I added for, break and continue statements. I am thinking of proposing these as additions to AGS script too.

Obsidian theme? Did people use that?

I purely mentioned the Draconian Edition as it was in CW's plans and people have been wanting those features integrated into the new version of AGS. For me, I would want all the editor improvements, the 5 parameter tinting and the Directdraw filters. Although I am very interested in your break/continue, for loop and switch cases though. I though the for loop and switch was already implemented in AGS. Maybe it was when Chris was using the SeeR engine??? Oh well.. Would be nice though Gurok.

Hey CW. Again, thanks a lot for taking charge in this and providing updates and bug fixes. You really are amazing and if it weren't for you (As well as a handful of others of course), AGS would be dead in the water. So thanks a lot to everyone on this!

My thoughts on what you are proposing depend on a few things. For one thing, I totally agree that the Bug Fixes need to be taken care of ahead of anything else. Once the bugs are squashed, development can proceed with a clean slate, so to speak. But for everything else, I had some questions that I was curious about which was mentioned at some point in AGS Development discussion. For the next part of the discussion, I would like to apologize as it would seem I will be bombarding you with a billion questions. Please forgive me. This is mainly to figure out what is next for AGS and for my own curiosity. Knowing what you have in mind will help me and anyone else make more constructive suggestions.

Firstly, Is there an Allegro 5 port being worked on? I know someone said they were personally experimenting with this and I am just curious as to the progress on that. The reason why this interests me is that first and foremost, it will bring more compatibility with Linux, Windows and Mac support as well as iPhone and even Android(Experimental). It would break the PSP port, however I am not sure how many people really find that port useful as it seems to be more of a novelty. I do not believe we can sell our games for PSP without a $10,000 license. Regardless, if people really would like a PSP port, I am sure Allegro can be adapted to work with it. Is SDL 2.1 being considered as a new alternative? I know that was a discussion at one point too.

Second, Are you (Or anyone else) still planning on refactoring the source code? Or is this already considered done based on all the updates that have gone into AGS in 3.3.0? If this is still an option, at what stage of development should/is planned to be done? Or another question could be: Is it really necessary?

My next question is, how much work would it be to provide compatibility with the Draconian Edition and implement its new features? Just curious about this. Also, as far as Mac/Linux compatibility, I know Wadjet Eyes had provided the community with the source they have. Is this planned to be used as well?

One final question... Has anyone provided you with the source to their plugins since you made the request on the forums? If so, how would these sources factor into AGS?

Again, accept my apologies for asking so many questions. I just want to get a clear indication of what the next work load consists of.

Now as far as what I personally think is the best option for 3.3.1 would be to just keep it small and simple. For instance, fix whatever remaining bugs you can find out there, merge the Draconian code in there and add very very very few minor new features. AGS is feature-full already, but as far as new features go, we can wait on those a little longer. I think the exception would be to remove limits and have custom resolutions, but I don't think these should be in 3.3.1.

I know I contribute nothing to the source code of the AGS Engine or the editor, but perhaps my insight might be useful. There's a first for everything after all. I always feel that having a roadmap for several versions ahead can help give you perspective and allow you to develop appropriately. SCUMMVM had always done that and it has helped them tremendously. Having said that, the way I personally see how AGS should go forward from now until 3.4.0 would be this way:

3.3.1:
*Bug fixes
*Draconian Compatibility/features
*Some small limit removals.
*One or two very minor features.
*Ports to other OS improvements if possible and if there is time.
*Some small improvements to the Winsetup(I say this because I already see this happening. Perhaps it can be merged with 3.3.1 if all is working well.)

3.3.2:
*Further development on the ports and getting the bugs fixed on Linux/Mac, iOS, Android.
*Possibly experiment in removing a few other limits

3.3.3:
*Bug fixes from previous two versions.
*Some more improvement on the ports.
*Creating some way for us to eliminate the need for a winsetup(optionally of course) and change settings within our game.
*Not custom resolutions, but perhaps some preset resolutions that AGS does not currently have. That may allow control over the code and bugs to be a bit more stable.
*One or two minor features
*Some small compatibility implementations with plugins that become open sourced??

3.3.4:
*Bug Fixes
*Port improvements
*Remove some more limits
*Some new features.

3.3.5:
*Bug fixes
*Port improvements

3.4.0:
*Custom Resolutions
*Bug Fixes

Beyond 3.4.0:
*Full removal of limits
*Ports to Blackberry, Windows Phone/RT and others.
*More plugins becoming open sourced
*More bug Fixes
*More new features (Obviously)
*Ports of the editor to MacOS X, maybe Linux too.

Again, all of you as the main developers would really know whats best in regards to the roadmap. From how I understand things currently, from what I would personally want and from what I have been reading around the forums as well as what work I can see that many users have done in other branches... This is the way I would arrange it. But please do not take this as me "telling" you or "Strongly suggesting" that you do it this way. I am just putting in my two cents. It's the best I can do under the circumstances

Anyway, thanks again for all the hard work you guys do. You deserve a lot of credit and praise as well as thanks from the whole community.

-------------------

I also wanted to provide some resources or thoughts if you would need or like them. For one thing, in regards to Git or SVN, has anyone considered hosting the source on Sourceforge or Google? Another option would be to house the code on the AGS web server using http://www.projectfork.net/.

Finally, for those who are/will be working on ports... If you need a MacOSX Environment, you can use virtualmacosx.com. It is a Cloud desktop which runs MacOSX(Similar to desktop.onlive.com) so that you can develop Mac OSX apps and iPhone Apps. Just a thought.

I have lost the source for the D3DVSync plugin but it was a single line in the initialisation of the graphics engine that enabled VSync. I'd argue that VSync should be enable by default anyway on D3D.

(Actually i'd argue that directX should be removed entirely in favour of opengl but whatever)

This would be nice one day. But no rush on this. AGS is great enough.

On a side note, since you sent out the e-mail today and made this a sticky (Can probably post this on AGS Blog too!) Has anyone with closed source projects come forward yet?

Winsetup should be deprecated and the relevant functions moved into the script domain, imo.

Agreed.

JJS was working on making ports & improving compatibility with older games, but he is not commiting much lately (probably being busy?).

As for the ports to iOS and Android... The interface which interacts with the OS and the engine only needs some minor work done which M.M. and Wadjet Eyes seems to have achieved already with their version of games. In fact M.M. has sent me his Android code and hopefully I can make heads or tales of how to make it work officially in AGS. With iOS, I am not very familiar with that. Perhaps Janet C can shed some light on that area as they have with Mac and Linux. The bigger issue with the ports are the C++ side of things. I think JJS set the groundwork up for that and with beta testers, ports are very much possible to do. With Android, with every release I can test a game or feature in particular and report back to you if you would like and see if we can trace the bugs together on that end. And I am sure you will have more than a few willing to do the same with the other OS. But unless JJS decides to come back to working on the ports and adding more OS to the list, or if someone else is willing to work on the ports, this would be the best we can do with that.

Also CW, I remember hearing you were working privately on porting AGS to Allegro 5, not sure if that will break things rather than improve them, however, Allegro 5.1 does support Mac, Windows, Linux, iOS and Android and may break portability to PSP(Which I am not really sure if this benefits us much). The only other major port I would like to see is Windows Phone and support for Windows 8(I haven't tried a game on this yet, so there may be no issues anyway).

The custom resolutions can't go in 3.3.1, because it's a larger change, and will take more time to polish, so normally I'd like to see it in "limits removing" 3.4.0. On other hand, it will require some time to make 3.4.0 cleaner and usable (also lots of testing), and some people already want to use custom resolutions, or, at least, custom display resolutions (if not the game ones), because players demand the games to be run with their native screen size. And at least one game dev wants to upgrade his recently released game to have this feature.
This is a dilemma... we might have an intermediate release between 3.3.0 and "limits removing" version. Or keep some "temporary" version with just the strictly features we need for running game on any res.


Other thing, there are few games made with Draconian Edition, and people cannot use engine ports to run these, because there are incompatible script functions. Since most (or all) of these functions are good ones, we may consider plan a 3.3.1 release which will not only have fixes to 3.3.0 (if necessary), but also improves compatibility with Draconian Edition.

I personally would love to see what ever is in the Draconian edition merged with the current public release. That would be great. In my opinion, as to what comes next after 3.3.1 has all its bugs fixed is to start working in the custom resolutions. For me, the bigger thing would be the limits removed, but it seems that most suggestions are moving towards custom resolutions. But for some reason I feel that trying to get the custom resolutions implemented would cause AGS development to be prolonged further. Would it be easier to add more resolutions rather than a field for custom resolutions for the meantime? For instance, Knox is using 1600x900. Can we add that resolution to the list of resolutions instead of allowing a user to manually set custom resolution numbers? Would that make it less buggy and as a good temporary solution?

Also, are there any limits that can be removed or increased in the meantime as well that wont break anything in AGS(Before removing all the limits completely)?

Personally I feel the priority at this stage is in this order:
1. Bugs.
2. Portability
3. Custom/more resolutions
4. fewer limits
5. Internal implementations of AGS plugins (LUA, RainSnow, etc..) for further backwards compatibility.
6. New Features
7. Forward save game compatibility
8. Further backward game compatibility.

Just my thoughts.

I was going to post something like that. I really think this is a 3.4.0 release. If you did implement the custom resolutions and the limit removal, I would go as far 4.0.0.

Good going Dual! I need to get myself together and put up another post myself at some point this week or this month...

Nice work as always!

Already purchased Gemini Rue a second time for Android(Always try to do my the best I can to support AGS'ers that create commercial games) and gave Gemini Rue 5 star rating and review. More than any of the code that is available, I would love to see the full Android port seeing as you got past the Obb issues and even some user interface hickups. Great Job!

It would actually need to be the entire game folder that is copied there.

No worries monkey. I didn't think you were blaming me for anything. Was just clarifying to the op what is needed for a standalone apk. As far as reading from an apk... it wouldn't do that. Once the apk is installed, it would extract all game data to the main apk data folder in root, I believe. You could retrieve it with file.internalcache or getinternalcache() or something along those lines.

I created an app that basically downloads the game and allows you to play it on AGS(AGS Stream), which hasn't been updated in a while because I am waiting for a couple of fixes and features for basic4ppc. The engine is still stand alone with a default launcher list in there. Standalone APK's are not hard. Like monkey stated, you can easily edit the source thats available now to do that. However, Any data over 50mb will need to be split up into .OBB extension files. You can have up to two expansion files at 2gb each. Generally speaking, your app should download those expansions automatically when being installed. However, there is a possibility the installation may not go as planned. That's where the trickier code comes in. My Java is very limited. I use basic4ppc.com to develop android apps. Unfortunately, in order for basic4ppc to be able to use expansion files would require me to create a class library in Java to run AGS and to download OBB files, which again, I am limited in doing since my knowledge of Java is limited.

YAY!