Author Topic: Initial AGS Engine Source Code release  (Read 99599 times)

RickJ

  • fix'n one thing and break'n two ...
    • I can help with scripting
    • I can help with story design
    • RickJ worked on one or more games that was nominated for an AGS Award!
library for Android Port?
« Reply #140 on: 02 Oct 2011, 15:03 »
LibGDX seems like it may be a possible basis for an Android port (and other platforms as well).  It's Java, likely because that's the Android programming language. 

"LibGDX is a cross-platform 2D and 3D game development framework written in Java/C/C++. It's free for commercial and non-commercial use, pretty powerful and lots of fun to work with! Or at least no-one complained yet. Write your game once, deploy to Windows, Linux, Mac OSX and Android! Be brave, click the links to the right to learn more. "

http://libgdx.badlogicgames.com/
http://code.google.com/p/libgdx/

Re: Initial AGS Engine Source Code release
« Reply #141 on: 02 Oct 2011, 20:06 »
LibGDX seems like it may be a possible basis for an Android port (and other platforms as well).  It's Java, likely because that's the Android programming language.  

"LibGDX is a cross-platform 2D and 3D game development framework written in Java/C/C++. It's free for commercial and non-commercial use, pretty powerful and lots of fun to work with! Or at least no-one complained yet. Write your game once, deploy to Windows, Linux, Mac OSX and Android! Be brave, click the links to the right to learn more. "

http://libgdx.badlogicgames.com/
http://code.google.com/p/libgdx/

Why using another library and even still forking AGS? I see the different ports aren't finally merged into the same codebase, making difficult to test all modificacions in different platforms and not need to merge changes from different repositories in a difficult way (just use some DVCS like Git).

Another negative point is the requiring of a Java Virtual Machine, LibGDX depends on Java. This adds more dependencies to the project, maybe not a problem in Android (Dalvik isn't exactly Java, anyway...) but it is in terms of portability and efficiency on other platforms.

Why not using something even more portable without requiring a big dependency like the Java Runtime Environment? I'm interested on the Android platform but... Why adding another dependency just for the Android port? There's tons of options out there, some of them already ready for *A LOT* wider variety of platforms and even more efficient.

If you see other interesting projects of this kind, their code is focused on portability and code reusability. Why not using a common code base and use native or a commonn library framework? Being Allegro, SDL, OpenGL, Direct2D or a backend framework for all them.

As an user and soon to be developer wannabe, I would like the AGS interpreter to have a common code base and make it easier for porters too. The more platforms AGS is, the more benefits AGS community and commercial developers will enjoy. Those developers from different worlds (commercial, hobbyist...) can help to improve AGS in a more proactive way, primarily due to stronger common interests and flow of ideas from different engines from those platforms or aiming to have a broader support of their game releases).

Are there some iniutiative likes this or we will need to wait to the full release (maybe including older releases by releasing the full Microsoft Visual SourceSafe source code repository into another repository like Git, by using a combination of automated conversion by vss2git and manual tweaking) of both the interpreter and the editor?

It's something discussed previously in certain away, I just want to keep the topic alive. I personally think the future of AGS depends on efforts like this. Are there visible project (co-)leader(s) along with Chris Jones?
« Last Edit: 04 Oct 2011, 12:48 by timofonic »

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #142 on: 04 Oct 2011, 12:22 »
I agree. libGDX would be a terrible choice.

Re: Initial AGS Engine Source Code release
« Reply #143 on: 07 Oct 2011, 10:01 »

Re: Initial AGS Engine Source Code release
« Reply #144 on: 07 Oct 2011, 12:47 »
what about EDGELIB?

http://www.edgelib.com/index.php?node=features

It seems quite portable, but not on most consoles (that's difficult to have all in one framework, anyway).

I see a quite negative point, the lack of source code and having to accept an EULA before downloading the "free version". The lack of source code is a problem if wanting to port it to other platfor or solve bugs.  It can be quite hypocrite to having an Open Source project like this depending on a propietary blob, anyway.

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #145 on: 07 Oct 2011, 13:19 »
Was there a reason that SDL was discounted? It seems to me to be the obvious choice since its functionality maps very closely to Allegro.

There is also iOS and Android support in the 1.3 branch.

Alan v.Drake

  • ...
    • Alan v.Drake worked on one or more games that won an AGS Award!
    •  
    • Alan v.Drake worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #146 on: 07 Oct 2011, 13:36 »
I've heard good things about SFML, but yeah, SDL is more estabilished and all.


- Alan

Re: Initial AGS Engine Source Code release
« Reply #147 on: 07 Dec 2011, 19:16 »
Any news? What about releasing the code of older AGS runtime? I hope Chris Jones reads this someday...

Re: Initial AGS Engine Source Code release
« Reply #148 on: 11 Jan 2012, 13:21 »
I realized today that the source code had been released. Wonderful. So I have a question:

a) Is anyone working on a mac port? If not, I will check if I can do the job. Just what to be sure to not make the job twice
b) If a) = true ;) may I help? (I'm working as a software developer for years, since one year I started developing on Mac OS. So knowledge won't be the Problem).

Thnx so far
SchodMC

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #149 on: 11 Jan 2012, 17:54 »
Hi Schod, and welcome to the forums!

Anyone is welcome to take a crack at the source so long as they know what they're doing! ;)

Just be sure to review the license and you should be good to go (you'll have to release it as "derived from AGS 3.2.1" or some such, but the license is pretty easy to work with).

Calin Leafshade

  • Long live King Cat!
    • I can help with making music
    • I can help with voice acting
    • Calin Leafshade worked on one or more games that won an AGS Award!
    •  
    • Calin Leafshade worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #150 on: 11 Jan 2012, 19:34 »
Hey Schod,

If you're an experienced mac developer then you are *very* welcome here. I suggest you take a look at this thread ( http://www.adventuregamestudio.co.uk/yabb/index.php?topic=44047.msg604616#new ) and perhaps you can help us with an official port.

Re: Initial AGS Engine Source Code release
« Reply #151 on: 12 Jan 2012, 08:15 »
Hi,

well, *experienced mac developer* - some kind of. ;) I have a lot of experiences developing Software under Windows. So C/C++ won't be the Problem. As I told, I learned developing under Mac OS using Xcode and Objective-C round about a year. So I think, I will have enough knowledge to help porting the AGS sources. However, I have enough experience to know how to learn what I need to.

Long story short: I will say "hello" in the thread you posted and take a look how I can help. See you there.

Greets,
SchodMC

P.S.: because of my rare spare time, I'm primary interested in the engine-part of the project.
« Last Edit: 12 Jan 2012, 08:19 by SchodMC »

Snarky

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #152 on: 14 Jan 2012, 00:18 »
From Gen-Gen:

What would need to be taken into consideration for the future of AGS as a viable development platform?
* Commercial use - Wadjet Eye Games is the obvious company here; Himalaya Studios (AGDI) is another. Balancing the needs of AGS's commercial users versus the noncommercial users is not going to be easy. Being noncommercial (open source) itself means that AGS is not necessarily beholden to prioritise commercial users' needs.
* Noncommercial use - this is the majority in terms of AGS use.

There's also The-Company-Formerly-Known-as-Zombie-Cow,-Now-by-Some-Completely-Unmemorable-Name-That-I-Can't-Be-Bothered-to-Look-Up, in case they ever decide to make more Ben & Dan games.

I actually think most of the things that are important for commercial users are the same as the things that are important for noncommercial users: stability, power, multi-platform support, an efficient production pipeline, good support for collaboration. A number of free games are just about as ambitious (in most ways) as the commercial titles, so they have most of the same needs.

But of course, there will occasionally be differences in priorities. For example, savegames breaking on game updates seems to have turned into a relatively big issue for Wadjet Eye, while it's probably not such a big deal for freeware games.

Conversely, I think bringing something like the old interaction editor back; that is, a way for newbies to define game events with no/minimal coding, would really help attract new users, but it's probably not particularly useful to commercial users. (Though I've been thinking about a way to code a game interactively, as you're playing it, which might be a way to speed up development. Insane, I know.)

Quote
What other projects could AGS learn from?
* OpenSLUDGE - this uses a lower-level approach in comparison to AGS. Some of its ideas (such as storing animation data as code), might be worth looking at at least.
* Inform 7 - see how this project is managed primarily; also see if its approach of the editor as a separate program from the compiler could be of use for AGS (if it could facilitate independent editor projects for other platforms, it is at least a possibility). See if its approach regarding bug tracking and feature requesting would work for AGS.
Outreaching to these projects and others (e.g. ScummVM) would be of use. It has been suggested before that ScummVM could have support for older AGS versions included ala AGI or SCI games. Not sure if this is actually feasible, but the possibility should at least be investigated.

Wintermute is the other obvious engine to take inspiration from.
I would also look at Eclipse, Visual Studio and other IDEs, since they are designed for many of the same tasks as AGS.

The major bottlenecks for any integration with ScummVM were that Chris hasn't released the 2.7 source yet (though I'm guessing most of it is still present in the 3.x release), that the organization of future AGS development was very much unclear at the time, and licensing issues (anything that integrates with ScummVM will be GPL-only).

Quote
Priorities?
* A Project Manager being assigned for AGS as a whole - someone needs to be at the least, a go-between for the (possibly) disparate development targets within AGS and tie it all together. A figurehead is not of use here. As has been pointed out, deep technical experience is not required; that said, at least some technical knowledge of AGS (and at least basic knowledge of e.g. who would use it) would be a plus. A long-term plan for AGS is certainly essential, but the short term must not be forgotten either, as it will serve as the foundation for any long term plans going forward. Any project manager would need to be able to be trusted by all the relevant parties.
* Either using an existing source repository as the master source repo going forwards, or the creation of one - at the moment, there really does not seem to be a central source code repository for AGS. The main website has an SVN server, but access seems problematic and as a result people have set up their own, which introduces the problems of code forking and of not being shared properly.
* Assigning tasks to people dependent upon their strengths and interests (ideally)
* Bug tracker
* Promotion of the development project, recruitment of developers - separate to the promotion of AGS as a development environment in itself should be the promotion of AGS as being in development and therefore in need of developers. Recruitment should be controlled mainly by the needs of the project. Focus should be given primarily on areas of expertise lacking within the existing AGS coding team, but certainly not to exclusion.

I would add to that: managing the website and the forums day-to-day, and overseeing updates and redesigns. A lot of the bigbluecup stuff still goes only through CJ, if I understand it correctly. If he wants to maintain ultimate control, that's fine, but I think we need someone to be a bit more hands-on. (This could also potentially be broken out into a separate role, though I tend to think that it's easier to find a few people to do a lot of work than many people to do a little bit of work each... at least you're more likely to get people who'll stay committed over time that way.)

Quote
AGS STRENGTHS:
* Flexibility - AGS can do more than just graphic adventures. Increasing it's flexibility in terms of what it can do is a good idea. Whether this should be done within AGS or by facilitating plug-ins (moreso than already) is another matter.
* Community - AGS has a good community built around it, and whatever is done to AGS should bear it in mind.

AGS WEAKNESSES:
* Sprite storage - the folder idea is not a bad idea, but it is somewhat let down by the usage of numbers to represent the sprites. This means it can be hard to remember what sprite numbers are used for what. It would be very tedious to have to name every individual sprite (or even groups of sprites) too. One possible solution could be to use the original sprite filename (with sprites imported as part of an animated GIF containing the frame number). Room backdrops could also be stored in this way - it would remove the distinction between sprites and backdrops (although I don't know if this would actually be useful). Sprites wouldn't be stored in the way they are now, but as discrete images in a SpriteCache folder (ala the AudioCache folder for audio files). Some code may do things like run code if an object/character is within a range of numbers (animation states); similar could be achieved by being able to "tag" a sprite or sprites with a value (or, perhaps, allowing "arrays" of sprites).
* Room numbers - in a similar way to sprite numbers, it can be difficult to remember what room is for what while coding. There is also the issue that rooms above 300 do not save state (although how much importance that has is debatable, and the number of games this affects is certainly almost vanishingly small). Having rooms referred to with identifiers would go a long way to resolving that.
* Lack of HD mode support - this has already meant one project has moved away from AGS (The Journey Down). With HD increasingly prevalent in the gaming world, it is odd that AGS has no native HD support. This also goes for widescreen modes. There appears to have been a prevalently conservative mindset regarding widescreen or HD mode support with AGS, though there are practical concerns too (The Journey Down had considered, but ultimately abandoned, incorporating HD and/or widescreen support into AGS).
* DirectDraw/Direct3D support - supporting both of these can be problematic. Trying to change this to something else (under Windows) could equally be as difficult.

I think it's pretty clear what the main priorities are for AGS right now:

* Multi-Platform support: Get stable, well-integrated ports of the engine for Mac, Linux, and particularly the mobile systems, Android and iOS. More importantly, refactor the codebase so the engine is mostly platform-agnostic, with back-end adapters for different systems.
* Better Windows support: The whole DirectDraw/Direct3D issue, as well as resolutions, color modes, application folders, etc. It should be unacceptable for AGS to fail to run on any Windows system (XP or later).
* HD/widescreen resolutions. This might also entail optimizing certain things that AGS is slow at, and possibly relying more on hardware acceleration.

In addition, there is one longstanding bug that has become a major irritant and has to be eradicated in the next version, no excuses:
* Music skipping on room change.

When it comes to the editor, I would advocate moving to a model of file-based resources, getting rid of the internal sprite file completely (and also the same for audio, fonts, scripts and translations). The compiler should still pack it all up for the game, of course, but the editor should be reading it from the file system, and the project file should just be a list of references and property values. I think this (given a proper UI design) would really improve the workflow for many tasks. This is probably not as immediately critical as the other points on the list, though.

Dualnames

  • AGS Baker
  • Rottwheelers
  • Pretty Badass
    • Dualnames worked on one or more games that won an AGS Award!
    •  
    • Dualnames worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #153 on: 14 Jan 2012, 00:44 »
Seconded, about the Music Skipping. Also for the love of I don't know what, more events!

eEventRoomAfterFadeIn
eEventStartDialog
eEventEndDialog
eEventOMGLOL

EDIT: Oh, and implementing Tzachs fantastic idea about an auto-detect feature in the engine.
« Last Edit: 14 Jan 2012, 00:45 by Dualnames »
No more military army stuff. I'm alive and back.

monkey0506

  • SEND PIZZA.
    • Best Innovation Award Winner 2017, for his work to help AGS games reach the widest possible audience - through popular distribution platforms (Steam, Galaxy) as well as other operating systems (Android, Linux)
    • monkey0506 worked on one or more games that won an AGS Award!
    •  
    • monkey0506 worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #154 on: 14 Jan 2012, 22:43 »
Dual, eEventEnterRoomAfterFadein can already be utilized even though on_event may not be called. You say "Bah, workarounds!" I say, why not? :P

Anyway, there are a lot of things that we need to do in cleaning up the code. Personally I think that refactoring should be the #1 priority for moving forward right now. We need a clean and consistent codebase if we're going to make progress without falling prey to the same problems that ail us right now. Documenting the code as we reimplement it should also be made priority, so that we have a clear understanding of what code does what.

From there we can definitely begin to address the more key features/functions of the engine that need to be implemented.

Adamski

  • Mittens Viscount
  • Subaquatic Battle Weapon
    • Adamski worked on one or more games that won an AGS Award!
    •  
    • Adamski worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #155 on: 16 Jan 2012, 00:56 »
In addition, there is one longstanding bug that has become a major irritant and has to be eradicated in the next version, no excuses:
* Music skipping on room change.

Hello. Just out of curiosity, and mainly because I've never experienced this on my own computer(s) and have done a lot of buggering about with music in AGS, how wide-spread is this issue and what conditions make this happen? Is there a consistent reason or is it just happening here and there for some people?

LGM

  • I am the Thane of Whiterun
    • I can help with play testing
    • I can help with proof reading
    • I can help with story design
    • I can help with voice acting
    • LGM worked on one or more games that won an AGS Award!
    •  
    • LGM worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #156 on: 16 Jan 2012, 01:43 »
I was under the impression that it was something to do with the implementation of DirectX in the engine.
You. Me. Denny's.

Re: Initial AGS Engine Source Code release
« Reply #157 on: 16 Jan 2012, 08:07 »
In my ports I solved the sound stuttering by introducing a new thread that handles the sound updates. The only problem is that it sometimes throws off lipsyncing by a bit. Btw, the source in my repository now compiles for Windows too, so you guys can check it out if you want.
Ask me about AGS on PSP, Android and iOS! Source, Daily builds

Snarky

  • Global Moderator
  • Global Moderator
  • Mittens Lord
  • Private Insultant
    • Best Innovation Award Winner 2018, for his numerous additions to the AGS open source ecosystem including the new Awards Ceremony client and modules
    • Snarky worked on one or more games that won an AGS Award!
    •  
    • Snarky worked on one or more games that was nominated for an AGS Award!
Re: Initial AGS Engine Source Code release
« Reply #158 on: 16 Jan 2012, 08:43 »
I have a fairly high-end computer (3.2 GHz AMD Phenom II X4 processor, GTX 560 graphics card and an Audigy 2 soundcard), and it happens with most games for me.

A quick test of some of the games I've been playing lately:

Chance of the Dead - no skipping
Arden's Vale - skipping
11-11-11 - no skipping
Death on Stage - skipping
Venator - skipping
Tales of Otubania - skipping (badly)
Beacon - skipping
Quasar - no skipping (surprisingly, as it's in 640x480)
Egress - skipping (badly)
Byte of the Draculator II - no skipping
DONNA - no skipping
Indy Passage of Saints - skipping

It happens with games made in 2.7 (as I recall) and 3.x versions of the engine. It skips more in high-resolution games than in 320x200/240 games, but also in some low-resolution games. Possibly it doesn't happen with MIDI, only WAV/MP3/OGG, but I'm not sure about that (is Passage of Saints MIDI or recorded?). It skips more when the screen transition is set to 'fade to black'. It doesn't matter what graphics filter (none to 4x) the game is set to use.

Supporting LGM's theory, it doesn't happen if the graphics driver is set to Direct3D, and it happens far less (not at all in most games, barely at all in Egress) if the game is set to run in a window instead of full-screen.

Re: Initial AGS Engine Source Code release
« Reply #159 on: 16 Jan 2012, 09:45 »
Alright, I decided to do builds of the Windows engine too. Check it out here: http://jjs.at/daily . It should fix the sound skipping.
Ask me about AGS on PSP, Android and iOS! Source, Daily builds