Messages

IIRC you need 2.0 framework, which is not included with 3.x, you should download it separately.
The new .NET versions do not include old ones.

EDIT: hmm, actually framework 3.5 includes 2.0. Which one did you install?

How cute .

ncw911, a suggestion: use [ imgzoom ] tag for small screenshots. This adds a zoom option when you hover mouse on the image.

Example:
[imgzoom]http://i1277.photobucket.com/albums/y490/ncw911/wizardworld1_zps355894a1.png[/imgzoom]

[another]

I guess I never really thought about the dynamic array being responsible for tracking its own size, so 4 extra bytes would make sense. But why would it be storing "total bytes" in another, separate 4 bytes?

It is not a template, that's why it needs to know the size of element. What may be questioned is why it stores elem_size * elem_count instead of just elem_size... Maybe to reduce computations, but that's a random guess. Also dynamic array never uses elem_size anyway, the element offsets are precalculated by compiler.

As for speed, I haven't said there will be perfomance drops if you change static array to dynamic, I said merely that there will be some difference... I suppose the perfomance will be affected by many other things, and dynamic array peculiarities won't be the decisive ones.

The Host?

Correct!

The well combined thriller and black/ironic humor.
One of my favorite scenes is when the guy in biosuit walks across the room full of quaranteed people and suddenly slips on a slippery floor and falls down. I laughed for about a minute after that

    (with the sentence of Dark Splashes # 3 „We point, you click!“)

Tabata, those sentences are random, they are chosen from the list every time AGS editor starts

CW, I don't recall, but you said that dynamic array pointers are 8 bytes? I could have sworn that as with other AGS pointers that they were always 4 bytes. AFAIK isn't dynamic array access in AGS simply a dereferencing operation? Even C++ doesn't support run-time sized arrays without dereferencing.

Every reference in AGS is 4 byte id (aka handle), if you mean that.
However, the dynamic array object allocates extra 8 bytes at the head of buffer to store number of elements (4 bytes) and total bytes (another 4 bytes). It also uses one of those extra integers to store internal flags.

As for dereferencing, yes, it does that using handle as an index in pointer array. I seem to confused that with different thing: sometimes it does the inverted search (address to handle), but this only happens when a reference is being assigned new object, which probably never happens to array.
So, I should correct myself, that using dynamic array is almost as fast as a static one. I am risking to start nitpicking here though, because this difference is in calling two extra functions (to get inside managed pool), so it might make any significant impact only if there are many thousands of dereferences, or something like that.

Alright, this screenshot stopped the game
Here's another one, of the same movie, of course:

[voting]

Alright, that was enough time, I think.

Let's start voting.
Please choose your splash!
Considering the importance of the issue I suggest giving 2 weeks for this voting, ending 21st July around 00:00 GMT.
Please tell all your friends to vote.


THE ENTRIES
I deliberately decided to not name authors here (of course you may find who they are by checking the link or searching the thread), and tried to group splashes by their look. Sorry if you find my imagination wasn't good enough to call the group well.

The entries are numbered inside every group. When voting, please give name of group and number of splash.


CLEAN SPLASHES

Spoiler

#1
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2013/05/ags_splash1.png[/imgzoom]
#2
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2013/06/ags_splash3.png[/imgzoom]
#3
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2013/06/ags_splash5.png[/imgzoom]
#4
[imgzoom]http://www.bwdhosting.com/ags/splash-idea1.png[/imgzoom]

[close]

GRADIENT SPLASHES

Spoiler

#1
[imgzoom]http://stupot.agser.me/misc/Splash3.png[/imgzoom]
#2
[imgzoom]http://stupot.agser.me/misc/Splash4-2.png[/imgzoom]
#3
[imgzoom]http://www.bwdhosting.com/ags/splash-idea3.png[/imgzoom]

[close]

CUP SHAPED SPLASHES

Spoiler

#1
[imgzoom]http://selmiak.bplaced.net/stuff/cup1_round.png[/imgzoom]
#2
[imgzoom]http://selmiak.bplaced.net/stuff/cup1_poppy.png[/imgzoom]
#3
[imgzoom]http://selmiak.bplaced.net/stuff/cup1_round2.png[/imgzoom]
#4
[imgzoom]http://selmiak.bplaced.net/stuff/cup3.png[/imgzoom]
#5
[imgzoom]http://selmiak.bplaced.net/stuff/cup3_pixel.png[/imgzoom]
#6
[imgzoom]http://selmiak.bplaced.net/stuff/cup3_3dpix_1.png[/imgzoom]
#7
[imgzoom]http://selmiak.bplaced.net/stuff/grande_pix.png[/imgzoom]
#8
[imgzoom]http://selmiak.bplaced.net/stuff/starsdarkcup.png[/imgzoom]
#9
[imgzoom]http://selmiak.bplaced.net/stuff/starsdarkcup_pixel.png[/imgzoom]
#10
[imgzoom]http://selmiak.bplaced.net/stuff/starsdarkcup2.png[/imgzoom]
#11
[imgzoom]http://selmiak.bplaced.net/stuff/starsdarkcup_pixel2.png[/imgzoom]

[close]

FUNKY SPLASHES

Spoiler

#1
[imgzoom]http://www.miez.nl/tmp/cup_logo_mz.png[/imgzoom]
#2
[imgzoom]http://selmiak.bplaced.net/stuff/lettering_t.jpg[/imgzoom]
#3
[imgzoom]http://imageshack.us/a/img13/7284/agssplash.png[/imgzoom]

[close]

DARK SPLASHES

Spoiler

#1
[imgzoom]http://www.shuugouteki.net/paul/Images/ags_3.2_splash.png[/imgzoom]
#2
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2013/06/ags_freshmode_splash.png[/imgzoom]
#3
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2013/06/ags_splash4.png[/imgzoom]

[close]

I still wish I had some information on those crashes before making next build.
Any ideas on which sequence of actions cause it?
Maybe some project that crashes often?

[bytes]

A dynamic array by itself (before it is even assigned) takes up 4 KB of memory.

What programming language it was about???
AGS allocates extra 8 bytes per dynamic array (to store length and some flags), C++ itself may allocate maybe 8 more for new/delete checks (don't remember now).
But 4 kb...

Strictly speaking working with dynamic arrays in AGS is generally slower, because it accesses it with managed "handler", not direct address. But how "slower" it is - it's very difficult to say without tests.

2-3 years ago I've been told that dynamic arrays are super evil and I should use them, because they waste a lots of memory and resources.

lol what???

As I aded to my post above, I guess that's a historical issue: perhaps AGS cannot distinct initialized global variables from non-initialized.
Never paid attention to this.

Silly really.

Abstauber, Scavenger, I think the solution would be to use dynamic arrays instead (tiles = new ctile[] etc).

Answer found.

TENG script module has global data size = 35.627.832 bytes.

Look into the TENG.asc:

Code: ags

#define NUM_MAX_TILES	100000
#define NUM_MAX_SPRITES 128
<...>
struct ctile
{
  AudioClip *sound[LAYERS];
	short x[LAYERS];
  short y[LAYERS];
  bool mirrored_x[LAYERS];
  bool mirrored_y[LAYERS];
  
  bool is_solid[LAYERS];
  bool is_destructable[LAYERS];
  bool is_bonus[LAYERS];
  bool is_deadly[LAYERS];
  bool is_ramp[LAYERS];
  bool is_fg_ramp[LAYERS];
  bool is_ramp_support[LAYERS];
  bool to_bounce[LAYERS];
  bool is_platform[LAYERS];
  bool is_ladder[LAYERS];
  short bounce_counter[LAYERS];
  short emit_particle[LAYERS];
  short emit_particle_cnt[LAYERS];
  
  short loop[LAYERS];
  ViewFrame *vf[LAYERS];
  short frame_counter[LAYERS];  
  short tileno[LAYERS];
  DynamicSprite *spr[LAYERS];
  
  short frm_speed[MAX_FRAME_TILE];
  short frame[MAX_FRAME_TILE];
  short frames_in_use[LAYERS];
  
  short ani_delay[LAYERS];
  short ani_delay_counter[LAYERS];  
  bool ani_sync_enable[LAYERS];  
};
<...>
ctile tile[NUM_MAX_TILES];

"ctile" struct is lots of bytes.
and tile array is (lots of bytes) * 100.000;





E: The question remains, why does AGS writes global data to the game file... Never thought about this. Perhaps it cannot distinct compile-time initialized data (like when you write "int a = 10;") from non-initialized one.

EE: Confused two struct names, fixed the code above.

Well, I guess that three things that take most space are: room background, sprites and audio files (voices most of all).

I have an interesting idea. I could try and make a small utility that tells the offset and size of files in the compiled game.

That's interesting, I may look into this if I have time;
but I must say that since many things in AGS are constant sized, like objects number, not only this prevents from making more objects, but this adds a lot of unused data. For example, there's data for all 50 hotspots for every room, even though only small number of these may be used. The amount of useless chunks grow with room count.

Sorry, I seem to become nervous lately.

I solved some thing that was troubling me in the engine and that seem to work ok, for now.

If you are really willing to do it, then the fastest and most convenient way will be to rewrite the engine from scratch.

That was never my intent. Although I see that may be tempting.
The biggest limitations are script and plugin interface, then the bloated feature implementations (because many different "styles" are mixed and intertwined in code).
However, having an existing platform has its benefits. It also serves as a "backup", so that if you can't find time to rewrite something you just leave the old code which may be bad but working.
Stopping doing small changes and do large ones instead (like completely rewriting certain functionality) may be a compromise.

For the time now, you should just release what you have. Maybe just make limits to be changeable instead of entirely removing them, if this is easier.

I think I'll do this, if it gets to usable state soon enough.

I was looking into adding onto the MonoDevelop source code, or something similar, to be the backbone of the Editor. It would certainly be the easiest approach for me because I wouldn't want to deal with AGS editor code and the whole backwards compatibility nonsense

What's wrong with the Editor? It does not have any problems with backwards compatibility. Most importantly, it does not need to support all the AGS Script tweaks, because it does not run it, only saves (and compiler is almost a separate program).
Maybe you mean engine?

I think I must tell about this, because it depresses me very much lately.
I made a very bad and rushed decision when I started to remake engine further: I continued to use the "partial upgrade" method by slowly changing parts of engine one by one, ensuring backwards compatibility working after every step, instead of writing essential parts anew and carry over compatibility later. Not only it took me more time working like this (because I had to break my head and make hacks after every change), but I now ended with a pretty ugly workarounds.
This can't keep going same way (not only technically difficult, but also psychologically exhausting for me).

However, redoing it right will take more time. Not only that, but, - let's put this frankly - I am quite tired now and can't promise I'll do this all soon. Perhaps I just need a change and forget about engine and this made up pressure for a while.

Therefore, this question is very important for me: is it worth to release this "raw" (or "alpha" if you like) version, forcing it to work by few more hacks? Are there people who would like to have new features regardless of risks? Assuming that I will be making few more fixes to support this "temporary" version.

The features I am speaking about are:

Spoiler

- unlimited number of state-saving room (max room count is still 999) and ability to select whether room is state-saving without setting ID > or < 300;
- unlimited number of dialogs and dialog topics; also option text of any length (not that it was important though)
- unlimited number of controls on gui; also Label/button/list text of any length;
- unlimited number of mouse cursors;
- unlimited number of room backgrounds;
- unlimited number of room objects;
- other room items are potentially unlimited too, but there is a problem with Editor UI lacking way to set their number; however I could, for instance, increase region/walkable area/walkbehind limit to match number of hotspots (50).
- unlimited number of custom properties; a way to change property value at runtime;
- unlimited number of overlays;

[close]

http://www.adventuregamestudio.co.uk/wiki/Dialog_functions_and_properties#Dialog.SetOptionState

Also: http://www.adventuregamestudio.co.uk/forums/index.php?topic=14373.0

Nay.

No...