Messages

I can enlighten you (haha! Get it?....... *cough*) about the mechanics behind that 1 loop frame offset problem.

As already said the script are run before the screen is rendered. Additionally, all values are updated before the rendering, but after the scripts are run. Which means functions that run before the update are working with one frame old values.
Because in the sequence of events in the main loop, the repeatedly_execute_always and repeatedly_execute functions are run before the values are updated just in case the values were changed when those function are run.
There's a way to correct this. By making an update before the functions are run and another after for a double check.
I don't know if it will affect the frame rate, because it means going through huge arrays twice with the current engine architecture.

I have to test that, because I ran into the same problem, but resolved it by using a 0.5 frame offset hack; which only works with prerendered sprites though.

EDIT: Holy my holy! It works, but it runs twice its framerate. Which actually makes kind of sense. Needs more testing....

Okay ! I see what you did there that I didn't. Though I notice the StretchRect() function in the render loop. Was the size of the surface not the right one before being presented?

It's cool this way seems to works. Though it might not work with 8 bits depth games from what I know. But I guess at this point 8 bits depth games are far more better off with DD5.

I'm curious to know how you managed to make the GetBackBuffer() function to work. I passed evenings to figure out why I only got a black surface. Not to avail. Please enlighten me to spot my embarassing mistake.

Until now (for my personal use for the moment) I set-up a 255 scale transparency for Overlays and D3D RGB style tinting aside from the backward compatible Direct Draw one. I wonder to integrate these modifications into yours.

I don't know want you want to do exactly, but don't open them with wordpad, notepad or any other TEXT editor. The save files are raw binary, and those software will interpret them wrongly as ASCII/Unicode.

Use an HEX editor instead.
I did that once to understand why my saves files have become huge in size all of a sudden.

Actually having read and fiddled with the rendering loop on the D3D9 device. There are originally lines that corrects the color output to match the Allegro device by making them darker as indicated by the comments.

Bah! The end of this kind of story is pretty predictable.

You just betrayed yourself that you simply copy-pasted what Khris wrote. =P
Remove the quotes and it should work fine. Enums are basically ints with a name representing them (roughly said), and putting them into quotes convert them into strings. Hence your compilation error.

On the topic of D3D, I'm in the project of reworking/optimising the D3D rendering engine of AGS so I can put a post-processing feature (meaning setting a Backbuffer in D3D mode). Put so far I'm trying to understand all the settings and what calls what.
On an interesting side, implementing Overlays' Transparency was extremely easy, since it was already there, but unused.

@Nefasto:

Are you sure you were returning a pointer and not trying to return the instance itself? You've always been able to return pointers since AGS 2.7.

Code: ags

DynamicSprite* CreateDynamicSpriteUselessWrapper(int slot)
{
  return DynamicSprite.CreateFromExistingSprite(slot);
}

Take note that the return type is "DynamicSprite*" not just "DynamicSprite".

I don't remember if I returned it as a pointer, but that might be the reason it didn't work. Thanks.

Wait. A function can return a whole Dynamic Sprite?
Last time I tried that, the compiler said a big wet "NO" before spiting my game on the floor. Is that new?

Aside this. Funny module!

Hoho. I see, monkey. So it doesn't overwrite the array and adding a little allocation for the new index at every iteration as I instinctively thought. It just adds a new allocation for every new array, if I undertood it correctly. Shown that way my method is indeed a memory hog.

Anyway, glad we could help you, mode7.

Good point monkey. I wrote it off the top of my head so I didn't double check for optimization. Though I wonder if that wouldn't use more memory.

You could create an Explode function that converts your String into an Array of char values.

Something like this :

Code: ags

char[] Explode(this String*)
{
  short index = 0, in2 = 0, count = 0;
  char buffer[], list[];
  String sBuffer = this;
  list = new char[1];
  list[0] = count; // index 0 is the length of the array
    
  while (sBuffer.Length > 0) {
        
      buffer = new char[count+1];
      count++;
      while (in2 < list[0]) { // stores the values in a temporary array
        buffer[in2] = list[in2];
        in2++;
      }
      in2 = 0;
      list = new char[count+1]; 
      while (in2 < count-1) { // creates the new array with the values
        list[in2] = buffer[in2];
        in2++;
      }
      in2 = 0;
      
      list[0] = count;  // new length of the array in index 0
      
      index = sBuffer.IndexOf(",");
      
      if (index != -1) { //stores the value in new index
        list[count] = sBuffer.Substring(0, index).AsInt;
        sBuffer = sBuffer.Substring(index+1, sBuffer.Length-index);
      } else {
        list[count] = sBuffer.AsInt;
        sBuffer = "";
      }
      
  }
  
  return list;  
  
}

You can also store this in a global array, and then get the value you need from it in your script.

It depends from the gameplay you wish, but I got around this by scripting a double click to do either:
- a jump;
- a teleport;
- running;
- any secondary action;
You choose.

For the scrolling room, I like how the Broken Sword team dealed with that, by using a special interaction to that effect when the mouse is on the scrolling part of the screen. Or you can make it Zack and Wiki style, keeping the mouse button down to control the character walk.

Yep! It works like a charm on my side now.

Thanks for testing my suggestion!

Then I have another idea. In your shader txt you posted, in the hsv_to_rgb function, would it be better to write the if conditions like this :

I think it's ok, because of this:
float var_i = floor(var_h);
which ensures var_i is rounded down to an integer

I also thought it was ok.
However it's how the output of the colours when the bug appears, that I consider the problem maybe comes around there.
I noted down in a table many values using, like Calin did, a white square and checked the output colour with an external  software, with the hope to find a function for predicting when it occurs with differenciation.

For a more concrete example :
For (255, 245,  0) I get (255, 0, 10);
For (255, 239,  0) --> (255, 0, 16);
For (255, 128, 22) --> (255, 22, 149);
For (255, 156, 50) --> (255, 50, 149);
etc...

Then when I checked the shader txt, I saw that the last line of the conditional

Code: ags

...
else { RGB = float4(HSV.z, var_1, var_2, 1.0); }
...

seemed to fit the wrong values above, as if this line was processed instead of the right one in the conditional.
Thus my thinking that the int that the floor function returned may be badly interpreted in some weird cases and unknown reasons by the float var_i. So I came up with that correction just in case it would be the problem.

There's also the Dialog.HasOptionBeenChosen(int option) function, but I don't have an idea if it can be of any use in this case.

I had an equivalent issue with running a dialog option, when I did my own custom dialog options window prior to version 3.1. My solution, I used a GUI with a list containing the dialog options and I returned the index of the list added to the dialog ID multiplied by 1000. Then I called a custom dialog function with this resulted value, and run the dialog.
The drawback of this, I have all dialogs of the game in one single function (which is functional, but not the best).

There was this idea where, when the dialog is run, I would first create a buffer array containing all option states. Then I would switch off all options of the dialog, but the one I want to run. Normally if there is only one option active, AGS should run it automatically by default. After the dialog is finished, I would set all options back to their former state using the array (and maybe set the activated option, to its new state at the end).
But I didn't test this idea and don't know if it would work.

I see.

Then I have another idea. In your shader txt you posted, in the hsv_to_rgb function, would it be better to write the if conditions like this :

Code: ags

if     (var_i >= 0.0 && var_i < 1.0)           { RGB = float4(HSV.z, var_3, var_1, 1.0); }
       else if (var_i >= 1.0 && var_i < 2.0) { RGB = float4(var_2, HSV.z, var_1, 1.0); }
       else if (var_i >= 2.0 && var_i < 3.0) { RGB = float4(var_1, HSV.z, var_3, 1.0); }
       else if (var_i >= 3.0 && var_i < 4.0) { RGB = float4(var_1, var_2, HSV.z, 1.0); }
       else if (var_i >= 4.0 && var_i < 5.0) { RGB = float4(var_3, var_1, HSV.z, 1.0); }
       else                                                  { RGB = float4(HSV.z, var_1, var_2, 1.0); }

Since the var_i is a float ?

I would think the floats are either rounded up or down in some cases with DX9.

I would suggest to find a way to just use int values instead of float ones in the hsv_to_rgb function so that you get :

RGB(232,134,81) -> HSV(1137, 6500, 9100)
RGB(232,134,80) -> HSV(1140, 6500, 9100)

And then convert them back into RGB after all the needed blendings.

But after giving a look at the shader txt you posted, that would take lots of work.