Messages

Hey! It's a waistcoat! (Jackett, or vest, as you americans say). Hey... I can feel my improvement in English! 

I didn't think they were suspenders. It's pixellated, but the human brain fills the gaps with its experience : when I see a cowboy with 2 vertical lines on the sides, I see the sides of the waistcoat, because in my imagination all cowboys have waistcoats  :-)

I seriously can't find any defect in that sprite. Like, *any*.
You'd better deliver that walkcycle, Nacho, I'm watching your ass! ;-)

OK, then, maybe a tiny-weeny one : the bottom of the right foot is flat. Maybe you could anti-alias a bit the far-end pixels of the foot (left and right) to make it rounder, since the boot is supposed to be slightly pointy?

Hello! I would love to have any advise on how to improve this guy.

Could you present it on a lighter background, please?
Right now it's creating optical illusions that mess with its outline.

Okay, you may now start laughing. Even with all this helpI can't get it to work  :'(

Yeah but you didn't say what actually doesn't work...

[integers]

I'd recomand to work as much as possible with integers. That's a miracle solution for all time-consuming tasks.
That's how they made Doom so incredibly fast and good-looking in the first place, compared to Wolfenstein.

Integer arithmetics can of course not replace float arithmetics completely, but it should be used strictly every time you can exclude scenarios from your code - scenarios that would require you to calculate things repeatedly and with high accuracy.

Exclude scenarios. All the time. In every circumstances. Make your code straight-forward. Never mind if the result lacks accuracy : if it looks like it's correct, then for the player it's correct.

Example 1: As it has been mentionned before, calculating a displacement vector (using floats, if necessary) once and for all (at the time you set the direction of a moving object - i.e. when you create it or when it rebounds), and then always refer to that constant vector, expressed in integer pixels offest (e.g. "move 3 pixels to the right" - not 2.5, not 3.5, not 3.0, but strictly 3).

Example 2: pixel-perfect collision detection is very rarely needed. Use a box or a circle or a "vertical lozenge". Even for bullets.

Let's make this instead :

I've seen that font somewhere ;-)

Phew! C'est fini!

Et nous aussi!

Arrêtez de parler dans des langues étrangères, on ne comprend rien à ce que vous dites.

[A shortcut to move a module up or down]

Something super-easy to implement :

A shortcut to move a module up or down (within the list of modules).

I have above 50 modules and it's really time-consuming to have to move the module all the way down every time I create a new one.

Does the I'm with stoopid goes for me? :o

Of course not! It goes for me!!!!
You didn't have any way to guess that I actually didn't copy-paste my #define statement properly!!!

Sorry if it was confusing

DAMMIT!

I found the issue.

My macro declaration was actually :

Code: ags

#define RED 55;

STOOPID!

Thanks for putting time into this, dualnames.

I don't get it. What's your point here?

In case you believe I forgot to include this code in a function body, then, no, I'm not so stupid.
It's a truncated version of the code, to explain my issue.

I've already written several thousands of lines of codes in the AGS script before

OK, I've got this code :

Code: ags

      #define RED 55
      #define AGSH_RBNode_Parent 0+
      #define AGSH_RBNode_Color  3+
      #define TO_LOCAL -
      #define SEGADDR_INT  33

      int memInt[100];

      int debug2 = memInt[AGSH_RBNode_Parent(z  TO_LOCAL SEGADDR_INT)]; 
      int debug3 = memInt[AGSH_RBNode_Color(debug2)];                   
      while ( debug3 == RED) {
           ...
      }

When I complie, I get error "Parse error in expr near '55'", for the line containing while (...

I just don't get why.


Here is a clearer picture of what the code looks like after the pre-processor has replaced the macros :

Code: ags

      int memInt[100];

      int debug2 = memInt[0+(z  - 33)]; 
      int debug3 = memInt[3+(debug2)];                   
      while ( debug3 == 55) {
           ...
      }

I'm confused.  
Could it be a bracket or similar missing somewhere else in the code?

(and keep in mind that a lot of mac and linux users have now tears in their eyes )

...And this is why a primitive rendering library will be inside AGSHack :-)

I'm impressed by the technical level.
It doesn't look like, but it includes many little things hard to cahieve in AGS.
I wonder how you did that.

There you go people, I followed your advice.

"number 5 wasn't being remade yet
http://img.photobucket.com/albums/v296/loontje/sierra_003v26.png

I don't get it.
Of course, console versions of the game are not looking good :


...But the PC version was already VGA! (that's from the actual game)



Did I miss something?

Yey! Gilbet saved my day!
But don't worry guys, I'll keep the other fonts for the high-res GUI, so thanks to you too!

For low res you can always make your own font.
pixel fonts are pretty easy to do yourself.

Yep, I know, but I'm a techie, and I've already enough to do with scripting! There's plenty of resources out there and my moto is : DON'T RE-INVENT THE WHEEL! (Except if it's to solve a puzzle and if it involves a hamster, of course) 

Good tip with the "double space", Gilbet!

with the exception of the space character, which is 4-pixel wide

Oh, I didn't see that.
Well, perfect!
Thanks a lot.

EDIT: the links to the fonts editor are broken 
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=23521.0

The font proposed by Gilbet is much better than what I actually have!
The width is still not constant though.
I don't understand how it works. Damn!

Droid sans mono is good and Liberation are good, but they're TTF; I'm looking for some good old pixels. I'll continue searching.