Messages

So how about this:
8-bit: Keep it and convert to 32bit during runtime
<...>
I think this would also make 8bit graphics more attractive again, since palette effects are still cool and fun to try.

You do realize that all palette effects wont work if you convert graphics to 32bit?

I was just dreaming...

There's yet another solution, suggested by JJS: combined software-hardware renderer which first draws 8-bit gfx on a virtual screen, then moves result to 32-bit texture and puts that on real screen.

But this sounds like it would do the trick. Also it sounds like lots of work 

Are there any others?

Sure - educational reasons You can learn to keep your color-count low, while still producing great art.
I started out 8bit because of it. Then of course I had to upgrade to 16bit because of OS issues and not being able to port it to different systems anytime soon. 16bit on the other hand seems to be useless - it isn't even faster than 32bit, which was the main argument in the early 2000s. Now my project runs with 32bit and is totally fine

So how about this:
8-bit: Keep it and convert to 32bit during runtime
16-bit: any reasons why to keep it? If so - convert to 32bit during runtime.
32-bit: Let the editor do proper conversion of existing sprites. still convert 16-bit sprites to 32-bit during runtime.

I think this would also make 8bit graphics more attractive again, since palette effects are still cool and fun to try.

The more I think about this, the more I get the feeling we should classify this as a bug.
The normal behaviour should be "converting all sprites to 32bit once you click so in the editor", but for unknown reasons, the editor doesn't convert the existing sprites to 32bit (or only a few bmps?).

So why should this be fixed during runtime? I'd say choosing the colour depth again should trigger the conversion to 32bit.
Btw. choosing 32bit again already leads to the colour depth dialog - it just doesn't do anything

That would most convenient. At least I can't think of any reason why someone would need to mix 16-bit and 32-bit sprites - and after progressing to 32bit it's not possible to import 16bit sprites (and keep them 16bit) anyway.

I think this has already been discussed, but the search function doesn't reveal it to me. So I'm sorry in advance in case I waste your time

In the mid of development I converted my project from 16bit to 32bit, so there are quite a few 16bit sprites left and the editor identifies them as 16bit sprites. Now unfortunately these sprites aren't rendered on 32bit/alpha GUI surfaces (they simply don't show up), only after I re-import them.
But since I have hundreds of 16bit sprites in my project I would prefer to convert them inside the editor instead of reimporting them.

Something like: "right click -> convert to 32bit" would be really helpful.

I've played a few decent GameMaker games, so it can't be that bad.
It has just a huge price tag, especially for mobile development.

hehe - also a valid workaround. The initial problem with the translated GUI is actually a bug, which I've just fixed. I'll upload a new template soon in the according thread.

Yeah, that's correct. Could you solve that other translation issue in the meantime?

Yeah, you're right. That behavior is hard-coded.

Try to paste the contents from the linked file to guiscript.asc (overwrite it )
guiscript.txt

In-game you can re-enable the old behavior via set_approaching_char().

I did a quick paintover to help you with the face
[imgzoom]http://shatten.sonores.de/wp-content/uploads/2014/11/paintover.gif[/imgzoom]

A few hints from my side:
- Use less colors and make sure that the color you use, actually differ in contrast and tone. I reduced your 24 colors down to 13 and there are still room for improvement
- use top-light for shading. That way you don't need to adjust the lighting after flipping frames. Also it usually blends in better with existing backgrounds.
- don't use red lips for men

Apart from that, it's a nice sprite

It would be gorgeous, if that would work.
Dialog scripting hasn't seen much love after custom dialog rendering was introduced

In the first place I just need a way to start dialog topic by keyboard.
Here's an example - I'm recreating an oldschool JRPG talk gui, which is controlled by the keyboard:


To move the marker and to select the topic I'm doing something like this:

Code: ags

  
  if (isUpKeyDown && !IsKeyPressed(controls.Up) {
    keyboard_cnt--;
    if (keyboard_cnt <0) keyboard_cnt = kbd_last_option;
    CDG.active_opt_id = kbd_options[keyboard_cnt].id;
    Mouse.SetPosition(0, mouse.y);
    Joystick.Click(eMouseLeft);
}

Since the dialog topic surface isn't refreshable, I'm moving the hidden mouse out of the way and abuse the joystick plugin to refresh it.

To start the topic I'm placing the hidden cursor on the topic and click again with the joystick.

Code: ags

  
  if (IsSelectKeyDown && !IsKeyPressed(interact_key)) {
    if (CDG.active_opt_id >0) {
      Mouse.SetPosition(kbd_options[keyboard_cnt].xpos, kbd_options[keyboard_cnt].ypos);
      Joystick.Click(eMouseLeft);
    }
  }

So the easy way out would be Mouse.click, although the better approach might be the suggestion I've added to the tracker a few month ago.

[imgzoom]http://shatten.sonores.de/wp-content/uploads/2014/11/avatar_db32_3.gif[/imgzoom]

hmm... I just realized, that I'm using joystick.click to start dialog topics, since there is no mouse.click. So Linux has to wait, until I've learned C++ and add that function to the engine

[and]

Is that an early AGS game? Maybe something from Captain Mostly?

Yes and no.

Not fair! It is an early AGS game and it's by Captain Mostly

Well, this can be done with plain AGS functions, all those "any_click_walk" functions are shortcuts for walking, talking and doing things.
But nothing stops you from using stock AGS

e.g. like this:

Code: ags

function cup_AnyClick()
{
  if(UsedAction(eGA_PickUp)) {
      player.AddInventory(iCup);
      oCup.Visible=false;
      player.Say("Yoink!");
    }
}

Nice, thanks for sharing!
You might want to consider re-licensing the StringUtility, as it's currently under GPL which not all users might like (especially commercial users).

[AGSA]

This should be the current member list - am I missing anyone?

AGSA	Devs-Anon	PCA
Problem	Scavenger	Junkface
KodiakBehr	Gurok	Weston_Kaunk
Stupot+	Cassiebsg	HanaIndyana
Monsieur OUXX	Haggis	Adeel S. Ahmed
Lasca	Ghost	Cuiki
Baron	Eric	abstauber
Intense Degree	AprilSkies	--

So I think the PCA is the place for you

Code: ags

            _
           /(|
          (  :
         __\  \  _____
       (____)  `|
      (____)|   |
       (____).__|
        (___)__.|_____

Ah okay, thanks for the info. Is there still a way to detect the current build version? It wouldn't make much sense to show joystick settings which doesn't do anything