Initial AGS Engine Source Code release

Started by Pumaman, Wed 27/04/2011 01:55:57

Previous topic - Next topic

RickJ

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/

timofonic

#141
Quote from: RickJ on Sun 02/10/2011 15:03: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?

Calin Leafshade

I agree. libGDX would be a terrible choice.


timofonic

Quote from: ptiz_govorun on Fri 07/10/2011 10:01:17
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

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

I've heard good things about SFML, but yeah, SDL is more estabilished and all.


- Alan

timofonic

Any news? What about releasing the code of older AGS runtime? I hope Chris Jones reads this someday...

SchodMC

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

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

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.

SchodMC

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

Snarky

From Gen-Gen:

Quote from: Sslaxx on Fri 13/01/2012 22:53:46
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.)

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

QuotePriorities?
* 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.)

QuoteAGS 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

#153
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.
Worked on Strangeland, Primordia, Hob's Barrow, The Cat Lady, Mage's Initiation, Until I Have You, Downfall, Hunie Pop, and every game in the Wadjet Eye Games catalogue (porting)

monkey0506

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

Quote from: Snarky on Sat 14/01/2012 00:18:52
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 was under the impression that it was something to do with the implementation of DirectX in the engine.
You. Me. Denny's.

JJS

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

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.

JJS

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

SMF spam blocked by CleanTalk