AGS Awards votes close at 13:59 BST on Wednesday 07 March 2018. You've already voted, so you've got 16 days and 15 hours left to wait before voting closes!

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Crimson Wizard

Pages: [1] 2 3 ... 392
Engine Development / Re: AGS engine Android port
« on: Today at 22:03 »
I was able to compile AGS port for Android, almost (see note below), using following two changes:

1. Changes to native libs building scripts (practically identical to ones we have in pull request)

2. Changes to the Android port itself:

I solved the SwapInterval problem slightly differently, but that's not important. Most important was to add -lGLESv2 to makefile, which resolves shader-related functions.

Native engine's .so object was linked, but then it failed on lua plugin, saying something about "no rule to make".

I did just that but it carried on and ran the next mode interaction...
Not sure I understand you, what exactly happened, did it perform actions for mode10? What is "next mode interaction"?

E: One thing I may add, is that if your script calls ProcessClick with eWhateverMode, while your mouse.Mode is actually different, then ofcourse you need to change the condition. Maybe store the actual mode in a variable, or set mouse.Mode before calling ProcessClick to eWhateverMode and return it back later.

OK, got it working. Not quite sure what happened before >:(

Oh, ok.

For additional custom modes you may use "Any click on object" event, and in the event function check "if (mouse.Mode == eWhateverMode)" to detect the click with your custom mode.

Critics' Lounge / Re: Strategy game models
« on: Yesterday at 13:18 »
First things first, though; how would one go about making the map navigable by clicking as in: entire map is there, but each full screen only shows a part of it. ? :)

Hate to be the one, but this is wrong forum section for those questions.

Engine Development / Re: AGS engine Android port
« on: 16 Feb 2018, 22:01 »
Should we demand it and explicitly link to GLES2 library, or handle it as an option, similarily to Windows version, by loading functions from the corresponding .so and using them only if they exist.

Note, that unlike Windows version, Android has only OpenGL renderer and cannot change to anything else. Therefore if it fails, the game won't be able to run.

I feel that from the last sentence, there is no point in per function loading. :/

Hmm, perhaps I was not clear enough, because I meant opposite.
I was speaking about function loading for optional features (tinting shaders), because then renderer will work even where they are not supported. Which may be important, because unlike Windows version, where you may change to Direct3D or Software renderer, on Android you have to use OpenGL.

Engine Development / Re: AGS engine Android port
« on: 16 Feb 2018, 20:42 »
Alright, I decided to begin anew, reset all the changes I did to my repositories and started following solution eri0o found step by step.

So, what is confirmed is that newest NDKs dropped support for building for Android platforms lower than v 14. Here's some discussions I found:!topic/android-ndk/qqRVhXwSN4Y

History of Android devices:

I opened the issue on github regarding this, and couple of accompanying problems:

Trying to sum up, there are following problems that need to be decided now:
1) Updating building scripts for native libraries, where we need to decide if supporting Android API 9 (Gingerbread and Honeycomb) devices is a must, or we should move to minimal support of API 14 (Ice Cream Sandwich).

Personally, I am not Android user, and have no idea whether these old devices are still in use (the port was originally developed in 2011-2012 when they were still very new).

2) Another thing is how we are going to support GLES2 on Android, for OpenGL shaders (currently uses GLES1). Should we demand it and explicitly link to GLES2 library, or handle it as an option, similarily to Windows version, by loading shader-related functions from the corresponding .so and using them only if they exist.
Note, that unlike Windows version, Android has only OpenGL renderer and cannot change to anything else. Therefore if it fails, the game won't be able to run.

I am trying to find information about GLES2 support on Android devices now.

UPDATE: found super useful statistics page:

Notably, it mentions number of devices with given API and GLES support.

From the looks of it, GLES 2 should be supported on 99+% devices. Also I read somewhere that its support was introduced in API level 8, which is below API 14 we may switch to.

PS. Regarding iOS compilation, since there does not seem to be any iOS developer available right now, I would rather simply declare the shader functions as integer constants equal to 0, which would prevent AGS from calling them (or maybe defining empty function stubs).

Critics' Lounge / Re: Strategy game models
« on: 16 Feb 2018, 17:55 »
There should not be any problem making turned based strategy in AGS, people were doing realtime strategy in the past (not sure if that one was released), arcade games etc. TBS should be much easier technically. One thing to keep in mind is that you probably should not be using built-in room objects and script drawing sprites on surface yourself.

The file access rules - is something that still bothers me in AGS, and I'd really wish to patch it as one of my last ammendments to the engine.

It all started when Radiant asked me to save config file in the user documents instead of current folder, because it does not work when the game is installed in C:/Program Files (or any other non-writeable location). Instead of doing just that I also decided to change how file access works in game scripts too, but I have doubts that did that fully right.
I would like to make final fixes to that, and decided to post here to get any input from other people and make sure I don't screw that up again.

Summing up current state of the file system (as of 3.4.1):
1) When working with file system in scripts (opening files, loading sprites, and so on), following tokens may be used to define location:
* $INSTALLDIR$ - a directory where game was installed.
* $SAVEGAMEDIR$ - a directory for savedgames, one for each system user.
* $APPDATADIR$ - a directory for storing shared data, same for all system users.

2) The rules for working with files are following:
* Absolute paths are forbidden.
* When using $INSTALLDIR$ you cannot write anything, only read existing files.
* Game config lets you set up custom paths for $SAVEGAMEDIR$ and $APPDATADIR$. This is done primarily to let players change save game location according to their preference.
* When no location token is given, engine remaps the path as relative to $APPDATADIR$. Note, that this is different from how it worked before AGS 3.3.5, where path without token meant "relative to game's (installation) directory".
* Now, there is something not very explicit, which was made primarily for backward compatibility: when you are trying to read file using relative path without token, the engine will check two paths: first in $APPDATADIR$, then in $INSTALLDIR$. If a file is found in $APPDATADIR$, then it will be read, otherwise file in $INSTALLDIR$ (if it exists).
The reason for doing this was to silently remap relative paths in scripts in old games to $APPDATADIR$ when they are writing files, but still let them be able to read existing files from the current directory.
But this solution is something I am not very proud of...

The problems, as I see them, are:

1) Is it really good to completely deny writing to the current game directory? Initially I thought it is, since contemporary operating systems have stricter rules to where programs may write files. So this acts as a safety measure to prevent unexperienced game creators from making a mistake (as being said, game may fail if it tries to write to C:/Program Files/...).
On the other hand I myself found at least one case when that may be useful: if you are creating an edit mode inside your game, which creates data for the game itself.
Currently the only way to do that would be to setup custom path for $APPDATADIR$ for the development time and then do not forget to reset it to default before public release.
There is now a token with explicit meaning ($INSTALLDIR$), for which we may have a warning in the manual, telling not to write files there without serious reasons.

2) What should be the way to treat paths without a token? The idea behind changing from treating them as relative of game dir to relative of $APPDATADIR$ is that new users won't make their games impossible to be run from C:/Program Files by mistake. Is it a good reasoning? Because while it may make things safer it also may cause confusion
 when user will look for the written files in the game directory and won't find them.

3) Not much related to running new games, but in terms of backward compatibility, is there a better solution for their issue? I am speaking of a situation when the game writes files to game directory, which makes it impossible to be install in particular locations.

The possible solutions I am thinking about right now are:

1) Allow to write files in $INSTALLDIR$. There are options here: make it work always or only if game works in Debug mode, if that makes sense.

2) I don't have a decisive opinion about how to deal with paths without tags.

3) I would like to try implementing different solution for older games. To remind, the problem is this: consider there is a game made a while ago where game author has used paths without token to save files to the game directory. You won't be able to use such game if it's installed somewhere where you cannot write (restricted directories, read-only device). One solution in such case is to simply install it somewhere else. But if that's unwanted or impossible for any reason, may there be a simple fix for this situation?
Right now, as I said, engine silently remaps writing file to $APPDATADIR$, but when reading it has to check both $APPDATADIR$ and $INSTALLDIR$.
Of course this is not ideal, because user may not find files where he expected to. This may be particulary annoying with games which include level editor, like old "ColorWise" game, for instance, where original levels are stored in the game directory, and player will probably expect to find all levels in one place.
So, I was thinking, what if instead of silently changing the path, it would use another option in config. The meaning of option would be "how to treat paths without token", and has possible values corresponding to supported path tokens. Such option could be used like a casual hack: if you've found an old game (or a newer game where author did not consider possible issues) that writes files to the game directory, and that causes trouble for you, you just set this option to something else, like $APPDATADIR$. (Naturally, at same time you may also set custom path for $APPDATADIR$).

BTW, if such option is introduced that may also change the opinion on p. 2), and perhaps paths without tags could mean $INSTALLDIR$ again. Idk about that.

Okay, well I created my GUI, however it didn't far as the background (which was transparent) blocked the mouse cursor from objects.... sometimes.
How do I z-order the thing to the not-interfering with the mouse layer?
Or do I just make it a small GUI and place it at the bottom of the screen?
Well that would seem obvious...

Just set Clickable to false.

However, if your main purpose in learning is to draw for game backgrounds and sprites, I feel you can take a larger number of shortcuts. The important thing is to come up with a streamlined process that you can repeat consistently with consistent (not necessarily super-quality) results.

Hey, this actually reminds me how I was practicing drawing backgrounds for adventure game. I decided to leave attempts to draw perfectly precise lines or being realistic and just painted basic outlines with brush, then kept correcting and repainting it over and over, doing quick strokes using only two colors (like - outline color on left mouse button, background color on right mouse button) as if I were working with clay: first you mash it up roughly, then "cut" to reach final shape. The trick there was to kind of turn your head off, stop worrying and enjoy the process of brushing color on canvas :).
I was continiously drawing similar shapes over and over, like bridges, roads, houses etc, in few weeks I was able to reproduce rather consistent style. Making full image could still take quite a while, but results were pretty. Like this: 1, 2, 3. Sometimes looking at the final picture you've just drawn can make you wonder if you actually did that, because it may seem too complicated for you. But all of that was drawn like said: first paint crude outline, then many iterations of repainting shapes with front/background color until you're happy.

Then I used same technique to draw colored pictures: I'd draw a rough sketch using only black & white brush on a transparent layer put over white background layer (for convenience). Then I add a layer (or few separate layers, each for its part of image) right under the transparent sketch, and paint "behind" it, trying to match the outlines. Then - hide the sketch layer and finish the colored version on its own.

Engine Development / Re: AGS engine Android port
« on: 15 Feb 2018, 01:07 »
Ok, I just realized that you had "undefined reference" error, not "undefined symbol", meaning its a linker error.

The reason could be that Android port links to GLES v1:

Right now I wanted to split the issue, because all this is becoming bit disorganized.

1) First, compiling Android port without rising platform version.

2) Second, finding a solution for shader problem. Frankly I do not want to discuss it right here in this thread, because it makes it messy.

TBH, personally I would not want to delve too deep into this, because I do not know Android, and cannot predict consequences of my actions.

As a quick fix we could just disable tinting at all for now. Maybe look for a way to fallback to software tinting if hardware one is not supported.

Then, maybe we would need to check for ES version and find out if there is a way to get these functions dynamically, just like Windows port does, to make sure the port supports devices without GLES2.
(Then again, maybe GLES2 is a standard for Android now, and should be available everywhere?)

EDIT: found an example of getting OpenGL functions dynamically:
I keep forgetting Android is just a Linux, so the standard C library linking functions should work.
NOTE: we have a generic wrapper over library linking, class called AGS::Engine::Library.

Engine Development / Re: AGS engine Android port
« on: 15 Feb 2018, 00:27 »
Edit2: Right below the first if defined (ANDROID_VERSION) I added
#include <GLES2/gl2.h>

This header should be included in ogl_headers.h, where <GLES/gl.h> is.

Firstly we need to find out whether gl2.h is enough, secondly if there are still functions that have different names (if there are) should be remapped using defines, similar to how other GL functions are remapped, e.g.
Code: C++
  1. #define glGenFramebuffersEXT glGenFramebuffersOES
  2. #define glDeleteFramebuffersEXT glDeleteFramebuffersOES
IDK if that is needed, so just mentioning FYI.

But not sure if that would be enough.
I was going to try that out after I am able to build it.

Right now I am very concerned about changing platform versions, from platform-9 to 14 in library scripts, and the one you mentioned later in project-properties, because I have no idea how that work and what could be broken by doing that.
E: I found platform version history here:
E2: Also some similar discussion, for reference:

What bothers me also is whether these shader functions are supported on all Android devices or not. And what will happen if we demand it inclusion into program. For instance, Windows version works with function pointers which it first tries to get from OpenGL's DLL. If it fails, it can simply check for that and skip some code during drawing.

There's an alternative solution, when the functions that are not found right now will be declared as ints = 0, and similarily skipped during drawing. This will disable tinting on mobile devices (at least with OpenGL means), but at least won't break anything that already exists.

PS. Ideally the OpenGL renderer should be rewritten, having some generic OpenGL API exposed, and the inner workings hidden in implementations, one for each platform. But that will take some time to do.

Hey JanetC. The tinting in AGS, under OpenGL in Windows requires OpenGL 3.0 compatibility. Can you check if the OpenGL drivers are available in your computer and versions?
AGS prints OpenGL version in the log, as well as warnings about non-working shaders.

I was thinking about fallback to software tinting mode in case shaders are not supported, but that would require modifying program structure a bit.

Engine Development / Re: AGS engine Android port
« on: 14 Feb 2018, 06:22 »
Hey CW! Created the pull request here!.

This is my first pull request in a public project, so please check if I did any mistake! (nod)

Ouch, I forgot to mention, could you do that in "release-3.4.1" branch? Because master already has some differences, and I'd like to be able to make a compilable 3.4.1 Android port.

Engine Development / Re: AGS engine Android port
« on: 14 Feb 2018, 02:46 »
eri0o, could you make a pull request of the changes you made to building Android libs? just a patch file will also work.

Now it appears what is needed, is to add those OpenGL defines, which was said here and is pointed in the github issue here. I need to sleep now, and have no idea how to do that

Same way as other functions are connected through macros, there should be awhole bunch of these already.

I will probably be able to check this out tomorrow.

Critics' Lounge / Re: Strategy game models
« on: 14 Feb 2018, 01:18 »
Imo the huge advantage CivII has is that it has an event file. Stupid Firaxis (company controlling CivIII) didn't include a feature that was so popular.
Seems to be usual in the civ series after civ2, eg civ3 with no event file, civ4 with (iirc) 1-era leaderheds only, civ5 with a very unpopular '1 unit pet tile' rule, civ6 with... not sure... lost it at civ4 :=

Civilization series left me baffled all the time, each new game introduced something good and discarded something good from the previous game.

Civ2 was interesting for me because it was interesting to conquer the world :). It had very random maps, quite unrealistic sometimes, but that was a part of fun. The shape of continent provided new challenge almost every time. It was also exciting to see your cities and roads cover the map as years go. Civ5 seemed to turn to smaller focused countries instead, making it largely different game. Perhaps that was the concept they were looking for all this time, but it somehow did not work for me. Guess I was looking at it as at warfare simulator rather than civilization simulator.

That said, CivII did have a very problematic "if (strongest) defender in a tile loses, ALL units in the tile die".

Eh, it had other problems, like no country borders, which let enemy sneak settlers onto your territory and build a city in the middle of your area of interest. You had to play "catch the settler" game by moving several units out to the frontier and block rival settlers there :).

The trade and espionage were rather annoyingly made IMO. You create a caravan locked with certain good, and then have to move it across the map, which may take many years, and then you arrive to destination, they sometimes don't demand that goods anymore.

PS. Whoops, why I am posting this in the Critic Lounge anyway?

Modules & Plugins / Re: MODULE: SpeechBubble v0.8.0
« on: 14 Feb 2018, 00:14 »
verbgui.asc(1594): Error (line 1594): '.SayBubble' is not a public member of 'Character'. Are you sure you spelt it correctly (remember, capital letters are important)?

Make sure that Bubble module is positioned above verbgui in the list of scripts. In AGS scripting scripts can only use functions and variables declared before them.

Not built-in, no.
I believe that would be possible to write plugin for that.

Advanced Technical Forum / Re: Unicode for translations?
« on: 12 Feb 2018, 22:09 »
Right, thanks. I suppose the issue is not so much that the translation code doesn't do unicode, but that the main code itself doesn't?

Sorry, yes, that's right, that's all because of the engine. I misread your first post thinking you are talking about engine reading translations.
The TRS/TRA mechanism is intentionally aligned with the engine. It converts everything to the current ANSI codepage when creating TRA file. If it meets something that cannot be converted 1:1 it will replace it with some other character from withing ANSI range of codes.

Same happens to any text you put in the editor: strings in scripts, object names, and so on.

Pages: [1] 2 3 ... 392