AGS Draconian Edition 3.4.11 r10 (December 31, 2017)

Started by Alan v.Drake, Mon 26/09/2011 01:24:41

Previous topic - Next topic

BigMc

There will be a new AGS release eventually.. Not enough to motivate you to get your changes in?

BTW, refactory is now master.

Yeppoh

If Alan is okay, I'm in favour to include the features Alan did for his build of the AGS Engine.
On a creative standpoint the little features and enhancements he put are interesting. Like the auto panning on the sounds linked on the animation frames relative to the screen, the new filters in DirectDraw, the new parameter in ChangeRoom() to set the loop/direction, the improved vSync and Gamma in D3d for windowed mode and the fact he setup the backbuffer in D3d to retrieve the screen faster which can open to some interesting ideas for postrendering.

I also added some features in my build with an added optional parameter for AudioChannel.SetRoomLocation(int x, int y, int radius) where you can set the radius of the sound earshot, and auto panning relative to the character position; and a variable to set the opacity of Overlays;

Alan v.Drake

Quote from: BigMc on Wed 13/02/2013 20:35:31
There will be a new AGS release eventually.. Not enough to motivate you to get your changes in?

BTW, refactory is now master.
Ah, but I do carry over my changes, with utter slowness perhaps, but I do. If I had a more free time it'd happen faster :D

Quote from: Nefasto on Wed 13/02/2013 22:42:38
If Alan is okay, [...]
Of course I'm okay, I keep a public repository just so anyone can get the good pieces and improve AGS.

- Alan

Crimson Wizard

Whatever you do... just remember... one thing...

*cough*
Spoiler
Backward compatibility
[close]
*cough*
:D

This means: all old games should run the same way without recompilation. There are ways to introduce new script functions with same names but different number of parameters in such a manner, that won't cause errors when older scripts are used. IIRC Alan already knows how to.

The bugs are, of course, an exception. But, there may be bugs that existed for so long, that people started to rely on them. In this case, they should be treated as feature. If you fix em, increase version number, test against engine version stored in game, and choose between backwards compatible and new paths.

For putting more data to save games I'd suggest to revise the save game format, make it extensible. At the moment, you may increase save game format id, and read data depending on what format the file has. Or simply add new data to the end.

When changing contents of data structures, append variables rather than insert in the middle, otherwise you may break some plugin. There's also a need to update scripting behavior. In short, the new script interpreter allows to map old offsets & object sizes to new ones; that is not difficult to do, but I must find time to explain this properly.

Yeppoh

#144
For the save file format, I was once considering a new one as an encrypted XML file. This idea came when I once wished I could retrieve a variable from any save file using only the known variable name. However I don't know the feasibility of something like this yet with the current AGS.

So far the AudioChannel.SetRoomLocation() with the new parameter is normally backward compatible. I made the parameter optional (the default value is 0 where it calculates the range of the sound like the old way).
The opacity of the Overlay so far was always in the source code but never actually used. The only thing I did for now, I just changed the optional 'transparent' parameter in Overlay.CreateGraphical(int x, int y, int slot, char transparent) where the transparent value is now a char that can set the opacity (1-255) of the overlay when it's set higher than 0. This solution's really ugly and not very user friendly on a coding standpoint, but it was just for personal use, so it didn't bother me that much. But I'm open to a better solution.

Quote from: Crimson Wizard on Thu 14/02/2013 08:27:08
The bugs are, of course, an exception. But, there may be bugs that existed for so long, that people started to rely on them. In this case, they should be treated as feature. If you fix em, increase version number, test against engine version stored in game, and choose between backwards compatible and new paths.

There was an old one in the version 3.1.0 of the engine - or was it 3.0.0? I'm not sure - about the Character/Object/DrawingSurface.Tint(int red, int green, int blue, int saturation, int luminance) function in D3d where you could change the tint RGB values without the need of the saturation and luminance, as opposed as in DirectDraw mode. I was quite accustomed to that bug (which I thought was a feature) until I was taken aback when it was corrected on the next versions. When the engine went open source, I changed it a little so that when 'saturation' and 'luminance' are both set to 100, the function only used the RGB values to change the tinting. Again, not very pretty, but functional without breaking anything. Though a Character/Object/DrawingSurface.RGBTint(int red, int green, int blue) - or Character/Object/DrawingSurface.RGBATint(int red, int green, int blue, int alpha)? - function would have been better.

Crimson Wizard

#145
Quote from: Nefasto on Thu 14/02/2013 11:56:26
The opacity of the Overlay so far was always in the source code but never actually used. The only thing I did for now, I just changed the optional 'transparent' parameter in Overlay.CreateGraphical(int x, int y, int slot, char transparent) where the transparent value is now a char that can set the opacity (1-255) of the overlay when it's set higher than 0.
Changing from int to char has not much sense, because internally the script interpreter operates only with 32-bit integers.
Well, did that. In our branch it's little different now.

Yeppoh

It was originally a bool.
The char comes mostly out of an optimisation habit.

Crimson Wizard

#147
Quote from: Nefasto on Thu 14/02/2013 14:04:12
It was originally a bool.
There's no bool in AGS script, it is a mystification :D.
In the engine code, it was "int".

Quote from: Nefasto on Thu 14/02/2013 14:04:12
The char comes mostly out of an optimisation habit.
I am not sure it will optimize anything. AFAIK such parameters are always passed as 4 bytes (on 32-bit platforms) regardless of the type you declared (int, short or char).
But it is of course useful to restrict value range.

Yeppoh

Quote from: Crimson Wizard on Thu 14/02/2013 14:32:28
There's no bool in AGS script, it is a mystification :D.
In the engine code, it was "int".
For some reason I remembered it as a bool in the engine code, but now that I checked, you're right.
Man, I got confused.

Quote from: Crimson Wizard on Thu 14/02/2013 14:32:28
I am not sure it will optimize anything. AFAIK such parameters are always passed as 4 bytes (on 32-bit platforms) regardless of the type you declared (int, short or char).
Wait?! You mean I took the time in my AGS scripts to carefully use the adequate type for a given variable, for being concerned about memory space, for nothing? GAAAH!
No seriously. I was mostly using shorts and chars, then int for last when I knew I had to deal with really big numbers.

Alan v.Drake

Quote from: Crimson Wizard on Thu 14/02/2013 08:27:08
Backward compatibility

Bah, assward compatibility.
I haven't committed anything in the feature branches that breaks it.

But I'll make sure to break it hard on my custom versions, so if someone absurdly believes to use them to run old junk he'll be sadly mistaken, hah.

- Alan

Crimson Wizard

#150
Quote from: Nefasto on Thu 14/02/2013 15:02:15
Quote from: Crimson Wizard on Thu 14/02/2013 14:32:28
I am not sure it will optimize anything. AFAIK such parameters are always passed as 4 bytes (on 32-bit platforms) regardless of the type you declared (int, short or char).
Wait?! You mean I took the time in my AGS scripts to carefully use the adequate type for a given variable, for being concerned about memory space, for nothing? GAAAH!
No seriously. I was mostly using shorts and chars, then int for last when I knew I had to deal with really big numbers.
I was speaking only about script function parameters. They are always passed as 32-bit ints when engine function is called from script (in vanilla AGS). Global/local script variables may be really of different sizes.

Real programming language is a different thing, because it deals directly with physical machine, and computer has different vision of optimization, than you do :).
For example, alignment of data in structures, which may negate your "memory savings" in certain cases:
http://en.wikipedia.org/wiki/Data_alignment#Data_structure_padding
And the fact, that on x32 platforms function parameters less than int are still passed as 4-byte value (and on 64-bit platform they have minimum size of 8-byte value!): http://www.codeproject.com/Articles/257589/An-Idiots-Guide-to-Cplusplus-Templates-Part-1
Quote
On 32-bit platform, function arguments would require 4-bytes minimum, and in multiple of 4-bytes. This means a char or short would require 4 bytes in call-stack. An 11-byte object, for example would require 12-bytes in stack.
Similarly, for 64-bit platform, 8-bytes would be needed. An 11-byte object would require 16-bytes. Argument of type double would need 8-bytes.

Yeppoh


DrJone.s

Yeah, that's something compilers do so that there's an easy way to implement the passing of parameters. I had to program a full optimizer compiler last year from scratch and it was a pain to make that one work. :tongue:

You can always use global variables instead of parameters to avoid that memory overhead, and it will even run a bit faster as there's less use of the stack, but you'll lose some useful features such as recursivity, concurrence, parallelism, and automatic optimization of code done by the compiler. Plus, it looks ugly and is harder to debug. The option is there, though. :smiley:

Radiant

Dear developers:

I have received several requests to modify Radiant FontEdit to work with 256-character fonts instead of just 128, because the new Draconian editor supports such fonts. However, I do not have a lot of spare time these days, because of studies as well as game design. So I was wondering: if I send the source code of FontEdit to the developers, it shouldn't be all that hard to include it in the editor. It is written in C++. Please let me know if this is a feasible approach.

Crimson Wizard

Quote from: Radiant on Wed 06/03/2013 15:53:36
So I was wondering: if I send the source code of FontEdit to the developers, it shouldn't be all that hard to include it in the editor. It is written in C++. Please let me know if this is a feasible approach.
What about making an Editor plugin? I think that would be very nice.

Alan v.Drake

Quote from: Radiant on Wed 06/03/2013 15:53:36
So I was wondering: if I send the source code of FontEdit to the developers, it shouldn't be all that hard to include it in the editor. It is written in C++. Please let me know if this is a feasible approach.
Sure it is, if you send the source I'll try to find some spare time to add the support.
It would be also nice to add an import bmp directly into the editor, I love that about FontEdit.

- Alan

DoorKnobHandle

#156
Hey, so during my livestream of my MAGS game being developed, using R7 I found out that all calls to DrawingSurface.DrawImage would fail (it wouldn't draw anything, no error message) even though source and destination were both 16 bit color depth. Today I tried the same project, without changes, with AGS 3.2.1 and there it works just fine. That leads me to believe there might be some issue with DrawImage in your version of the editor.

Just wanted to report this, no idea what I can do to help you track this down or no, all I can tell you is that the project, on my laptop, renders fine using AGS 3.2.1 and doesn't draw using R7. After MAGS is done with, I can probably send you the project if that helps? Unfortunately I have no other system to test this on atm!

Calin Leafshade

the draconian edition is only 32bit compatible because it uses my drawimage code from AGSBlend which doesnt make allowances for other colour depths.

DoorKnobHandle

Oh, the more you know haha! I can't find that in the original post, though, maybe it would make sense to put that info somewhere in big red letters or something (assuming I'm not blind and missed it). In fact, it says "(Note: this version doesn't have Calin changes to DrawingSurface because the one who requested it version had trouble with them)". Thanks for the letting me know!

Alan v.Drake

Quote from: DoorKnobHandle on Fri 08/03/2013 13:16:07
[...] requested it version had [...]

What, where does that abusive "version" comes from, was I sleeping when I posted that thing, and when I was re-reading ?
Good news though, in a couple of months I should manage to turn my job into part-time so there's good chance of me getting things done. Unless I waste it away shamefully, of course.

- Alan


SMF spam blocked by CleanTalk