Messages

[Scripts in-game]

...This entire thread brilliantly demonstrates why a "real" language is a must in AGS: As Denzil explained in his previous long post, Lua can then be used for no less than 3 different things :
1) Scripts in-game, that can use the billions of scripts already developed in Lua, out there in the real world.
2) Scripts run only once, when the game gets compiled (imagine for example if you pre-processed some Tweens once and for all at compile time, to make the game faster later on -- that's just an example)
3) Make the Editor customizable (a bit the same way as you can run scripts in Photoshop, 3DS or Blender). That would be priceless for people who make large projects and are tired of repeating the same imports and stuff.


I'm planning on packaging a version of AGS that embeds Lua by default, along with other "advanced" tools (SpeechCenter, Tween module, etc.). Is there a default Lua game template?

[MAOI]

The MAOI link is interesting, I had never spotted that program before. I don't think it's in the sticky post either.

[skilled individual]

A skilled individual can certainly hold an entire program's idea and architecture and progress in his head. And there is indeed a beauty to that.

But a good programmer/designer is the one that will know how to break it down so that the project never ever ever relies on one single person. Neither during development phase nor maintenance phase.

To a certain extent, the guy who has the perfect program in his head but can't share it with anybody (because if someone touches anything it will be broken or the inventor will stop mastering it) can even be considered a bad programmer.

Let us never forget that a program is like a machine. If you build a machine on your own, without blueprint and stuff, you'll never be much more than a mad scientist. When the DeLorean got hit by a train, all got lost in a blink. Furthermore, had Doc hit his head before completion and forgotten the flux capacitor's design, all would have been lost too.

I could even argue that the same thing can be said for mathematicians: If you find a theorem but don't bother explaining around, you suck. Let us remember Fermat's laziness. It took 3 centuries to prove his so-called "easy demonstration".


In a nutshell: my personal opinion is that a "cool/good programmer" is not the one who holds everything in his head, but the one who makes the longest lasting things.
That is, not the one who will create things that will be harmonious only in his head, but instead things that will fit nicely in their entire environment.

I'm currently proof-reading the game, which was rushed because it was originally a MAGS entry.
It will be re-released soon.

is this intended to be some kind of adventure everyone has to complete before contributing?

For the record: that's because the community brutally took over Chris Jones' code and 2 years later you can still feel the aftermath of this. While there is a lot of very good contribution, the whole process is not fully centralized yet (at least in appearance). But if you ask questions on the forum, as you can see people are glad to help, and overall the result is very good!

[consistent syntax]

The things that Lua has and AGS doesn't have (and haven't been mentionned yet) are :
- A consistent syntax
- No need to map the darn AGS objects/variables to your wrapper every time you create one (IMO that's the main reason why plugins have limited features: because the guys who make them doen't go through the effort of mapping the hundreds of available functions of the underlying library to AGS). For example, the Direct3D plugin is fine, but the guy didn't implement everything into AGS. And I'm sure there is already a complete Lua/Direct3D wrapper somewhere out there.
- Libraries for data storage (arrays, trees, hashmaps, etc.). This is a BIG BIG issue in AGS at the moment. Every time you want to program a puzzle of some sort: "oh no, I'll have to code a search function yet again". Existing modules in AGS help, but overall it's still a real pain in the neck.

I'm almost certain that already exists.
Try to dig out McCrea's old modules list, it has a short description for each of them.

I think "CJ against the Evil cellphone games plunderers" should have a fan game.
This way it would be a fan game of a game from a fan of a fan of games.

[stripes of various widths]

Also, specifically about the gold effect (or reflection effects in genral), you don't really need to master the technique of it, you can just achieve that by using tricks :
- a very high contrast (the dark bits are really really dark)
- random alternance of lighter bits and darker bits, preferably arranged in stripes of various widths.

The two following pictures sum up what I mean :

What are you dealing with exactly:
1) Making sure that the engine won't crash on exotic resolutions? (sometimes DirectX will tell you it can't initialize the device)...
...OR...
2) Offering those resolutions in the Editor, for design purposes?

Point 1 is my priority, even though big steps forward have been made in some branches of the Engine (can't remember which one).

[new instructions]

I think it's a great idea to introduce new instructions.

I suppose that historically the old instructions were meant to map the x86's assembler as closely as possible, when AGS was running on MS-DOS, or later on Windows in "real mode".
But nowadays, there are so many layers between the engine and the actual processor. Therefore I think it's OK to invent new instructions that will require less parsing and will let Windows do the actual computing.
You could say that parsing the engine's "assembler" has become more costly than executing fancy calculations.

Actually, my opinion would be that, on the long run, the engine should contain as many instructions as there are built-in high-level instructions in the AGS API -- but that's off-topic.

+1

I hate that darn combo box.
Not to mention very often I even forget about it and spend way too long remembering how to switch between areas.

[dropping the AGS language]

To me, the biggest argument in favor of dropping the AGS language is that its grammar has loopholes; and the object-oriented inheritance system's implementation is half-baked. I'm ok with any syntax as long as that syntax has been proven consistent by armies of languages specialists -- instead of invented along the way (no offense to CJ -- as it's been said before, he used the appropriate technology level at all times, and provided amazing tools on his own).

I support the idea of moving to a "language-agnostic system with several different bindings for different languages" (these are Calin's words).

For the time-being and a smooth transition, would it be possible to provide both in the template? Why not offer the choice of mixing the languages, using tags in the code? (just a silly idea).

The very least would be that, at first, the Lua version looks exactly the same as the AGS one in its structure (execute_always, etc.) and function names. This would be an incentive to migrate to it.

I'd be interested.

abstauber: Don't forget to add the dates to the very first post.

Why am I not surprised that WHAM chooses the nazi army's "Afrika Korps" as a game theme, and an "oberreiter" as main character?

My point was (advice to Ali) : Avoid a straight-line sea. Maybe use an animated sea, or something. Or a trick of any sort. A sub-pixel movement applied to a straight line looks crap, and a sub-pixel movement applied to a texture movement looks blurry.

Can't you just blow up all the sprites and BG by 10x, draw at appropriate place and then scale it all down again?

In-engine? No. You would need to do a nearest-neighbor upscaling and a bilinear downscaling (otherwise the process ends up blurring the result), and the AGS scaling functions don't give you control over what sort of sampling function to use.

I'd also add that I tried that manually using a Paint program, and I was not very happy with the result. when the movement is really really slow, then it's like each row of pixels slowly fades in, one after the other. As soon as a row has finished fading in, the next one starts fading in above it (if the sea is moving up). In the end it looks like a weird Tetris game (with rows of pixels piling up) rather than an actual movement.
But I must admit there is virtually no other solution.

Having said all that, the convolution matrix approach is a per-pixel approach (unless I missed something).

You missed something. - convolution is by definition a Fourier-space based approach and not a per-pixel approach

Yeah, I contradicted myself, after having explained at length why the convolution stuff was not per-pixel Bottom line is : Ali, do as you like, but good luck if you go the Fourier way!

Well, the first step would be to implement Fast Fourier Transform and convolution functions in AGS.

LOL.
Even though that would be really nice, my advice is this: Ali, don't let yourself be terrified by Snarky's post.

For short: A convolution Matrix is a small 3x3 array containing the values of the color-change you must apply to each pixel in the picture, and to its 8 surrounding pixels. You need to do a big loop and apply this color change to every pixel in the picture. You will notice that a consequence of the Matrix's size (3x3) is that some color changes will be applied to each pixel several times : when the matrix is applied to the pixel before them, then when it's applied on them, then when it's applied to the pixel after them, etc. Except the color change won't have the same value each time, since the 3x3 array doesn't store the same value in every cell.
If you convolution Matrix contains the right fine-tuned values, then it will create the transformation effect you seek. That's pretty much the concrete implementation of a shader.

Then, all the FFT stuff is to optimize (you stop seeing your input picture as an array of pixels, but instead you see it as a "wave" in a different "space" (in the mathematical sense of the word)). There's a lot of mathematical theory behind it, but for short, it's like you're Neo and you're inside the Matrix, and you see only the essence of the picture. You don't need to look closely at every pixel to get the picture, instead you apply some mathematical functions to it, that will apply some bulk-processing to the relevant pixels at once, in a super-optimized manner. Think of JPEG compression, for example : instead of storing every pixel, it calculates only some raw variations in the picture's contrast (and stores them as sinusoidal "waves" or "curves"), and when you superimpose those variations on top of eachother (at rendering time), then BOOM, an image magically appears (the drawback being that you can't keep all the details, hence the blocky/dirty effect wherever there is a sudden contrast change). I'm not saying Snarky suggested you implement JPEG, I'm just giving an example of FFT (and all that "wave" magic) in everyday life.

Having said all that, the convolution matrix approach is a per-pixel approach (unless I missed something). I don't know if it's very optimized (unless you write a plugin -- in that case I'd recommend the EXCELLENT "AGSEasyPlugin" tool ;-) ... or you could just add some features to Calin's Blending plugin, I'm pretty sure all the code base you need is there). Your/others' idea of relying on hardware-accelerated features (transparency, etc.) and manipulate entire pictures is nice as well, and has the virtue of keeping it simple, and at module level.

Considering that the intro of "How they found silence Deluxe" is an ocean wave effect exactly like yours, and that it looks horrible (per-pixel movement), and that I knew that eventually I'd have to implement what you describe... You have my blessing for this