Messages

[also]

I had this problem “from the other side” a few months ago: I had uploaded some games and pictures onto my server and others couldn't download them from there.

At that time I hit on a snag concerning my server: It wasn't enough to just change the download links from "http://" to "https://". I also had to teach my server to accept those new "https://" requests. It had something to do with installing a "Let's encrypt certificate". Before I'd done that, my server would refuse the "https://" addresses in the same way that it'd refuse wrong or unknown addresses.

So, just changing all the "http://" links won't necessarily solve the problem in all cases. We'd need to check for each individual link whether the "https://" variant is resolved.

[lot]

The trouble with modules is, a lot of event functions must reside in GlobalScript.asc, the character and inventory events among them.
You can, of course, do something like

Code: ags

function cEgo_UseInv()
{
    EgoUseInv();
}

move EgoUseInv() into some script module and let EgoUseInv() do the real work. But the stub that calls EgoUseInv() will still muddle up GlobalScript.asc.

Did you get yours in Fernewelten?

I'm afraid not. Mind you, I'm not giving up on it, it only wasn't ready for the jam end date.

I was struggling with several aspects, the puzzle concepts among them. So I've mainly got visuals but not much code.

It's a real shame. I don't think I would have had much of a chance of winning $105 (and besides, if I need $ 105 I can take them out of my pocket), but being part of a really large game jam would have been a big opportunity of gaining some visibility.

Oh well.

[height]

Note that the default blocking height is only five pixels AFAIK. That may be reasonable in 320x200 games but is not reasonable in high resolutions.

A perspective drawing emulates three dimensions.with only two dimensions.  Let's call the three dimensions  left/right, high/low, upstage/downstage (the latter means to the back/to the front). And let's call the two dimensions X and Y.

The Y dimension of the perspective drawing is the one that does “double duty”: When a character is jumping, their Y component will decrease and when the character is walking upstage, their Y component will decrease, too. So if you have two points in a perspective drawing, one directly above the other, then you simply don't know whether the one is farther upstage than the other or whether the one is floating higher above the other.

So in this context, the term “Blocking height” is potentially misleading: What is meant is a distance in the upstage/downstage dimension, not in the high/low dimension.

Here's an illustration.

Let's call the rectangle that the solid object is standing on (in the left/right, upstage/downstage dimensions) the “footprint rectangle”

Note that AGS treats walking characters as if they didn't have any footprint rectangle at all.  Instead, characters are represented by just the mid point of their baseline. Every character can walk anywhere so long as the mid point of their baseline stays within the walkable area. When the midpoint of the baseline of a character is right at the edge of the walkable area, then their real extensions will already be off.

This is important because the footprint rectangle of the “solid” object is cut out of the walkable area. To prevent collisions you need to guess how big the footprint rectangle of the biggest potentially colliding character will be, and then enlarge the footprint rectangle of the “solid” object so that even that character can't collide, even when the midpoint of the baseline of that character is right on the edge of the cut out area.

Let's say that your biggest character has a sprite width of 100 pixels. Then the “blocking width” of all solid objects or characters must be 100 pixels larger than their own footprint width would be (50 additional pixels to the right of the sprite and 50 additional pixels to the left of the sprite). Let's say that your biggest character has an extension in the upstage/downstage direction of 100 pixels. Then the “blocking height” of all solid objects or characters must be 100 pixels larger than their own footprint height would be.

Finally, note that according to AGS, the “blocking height” extends as far below the baseline as it does above. In my opinion, this is a design mistake. It would mean that the deeper an object extends upstage, the deeper it extends downstage, too, and this is patently false.

What's right instead is that the baseline is right at the lower edge of the footprint rectangle. Although we need to extend the footprint rectangle in the upstage/downstage dimension somewhat to compensate for the footprint rectangle of colliding characters, only this additional, extending amount extends as far upstage as it does downstage.

[specific suggestions]

For a general discussion, have a go at your pet peeves.

But in order to act on specific suggestions, we'd need them in the AGS bug tracker so that they don't get lost.

Also have a look at

• this PR in the section "Summary of additions to the language"
• this PR
• this PR

to see what we've already got with the new compiler so far.

I'll see what I can do for you

Let's put them in the study instead of the library. It offers more possibilities, and it offers shelves with books, too.  And here is a first version of it:

..

[through]

I'm not the best expert for perspective questions, but here's how I understand dealing with heights:

Your background pic has a "horizon line". That's the eye height of the viewer of the background pic. It doesn't necessarily run through the picture: For instance, if the viewer is looking onto the scene from very high above, then the horizon line will lie higher than the upper edge of the background pic. I'm having good results in my pictures with horizon lines that are around 1/3 from the top.

Impale your person with a broomstick and cut the broomstick so that its top is exactly on the horizon line. Then wherever your person is when it is walking on the floor, it must be proportionally sized down or up so that its broomstick still goes exactly to the horizon line. See below, the horizon line is thick red.

Now if the person is high up, e.g., on a table, then it must have the height that it would have when walking on the floor. (Below, left)
Now his broomstick has become the wrong size. It needs to be adjusted so that its end will go to the horizon line again. When he's walking at the new height level, its proportions will change so that the new broomstick tip still exactly touches the horizon line. (Below, right).

 

So when a person is climbing a flight of stairs, you can interpret it as if they were climbing a large prism. To find their size at the bottom, stand them on the floor. To find their size at the top, still stand them on the floor, exactly below the top of the stairs and adjust their height there. Then move them to the top of the stairs without adjusting the size.

Corollary: When the flight of stairs is parallel to the front edge of the stage (or top or bottom edge of the background pic) then characters that walk down or up them don't change size. When the "stairs" are a (nearly) perpendicular ladder, then characters using them don't change size, either.

AGS has the concept of "Walking areas" with variable "scaling". I usually deal with that by placing a specific character temporarily into my background picture and finding out how high the tip of their head should measure up to (e.g., it should be just as high as the top edge of that vase in the background). Then I place the character downstage in the room and dink with the max scaling of the walk area until it's about right, i.e, the tip of the head is as high up as it should be. Then I repeat that with the character placed upstage and the min scaling. It's a hassle, but manageable.

As to a geometric construction:

If all the stairs have equal width "in reality",, then you can draw an X through the outer stair corners, and the place where the X lines cross is the half-way mark. There should be exactly as many stairs below the crossing point as there are above.

In your drawing, you're very far off that. There are 9 steps below the crossing point, only three steps above. See below, the half-way mark is in green.



You can find quarter-way marks by drawing the "X" into the upper half and into the lower half, and repeat this for eighth-way marks and so on. You'll find that there are many more distant stairs than you'd ever have imagined and that they become thinner than you'd ever have thought. But you don't need to adhere too much to geometry. You're allowed to fudge, and the viewer's eye will pardon it, but don't overdo it.

[thickness]

You can't be strictly proportionate in pixel art and you needn't to,
But if you want to make your background more realistic then the stairs of the top should be smaller than they are now.

You can use your figure as a measuring stick for judging the proportions. Ego at the top has about 1/3 the size of Ego at the bottom. So the strictly proportionate thing would be that everything at the top has 1/3 of the size that it would have at the bottom. You can fudge that for pixel art, but not by too much.

At the bottom of the stairs, the height between adjacent stair lines is roughly the height of 1/4 Ego. So the strictly proportionate thing at the top is that one step still has the height of 1/4 Ego. As of now, it has about twice that. The top stair lines should be nearer together.

Same thing with the thickness of the lines that represent the stairs. The lines at the top should be thinner than the lines at the bottom. Strictly proportionate would be to have the line thickness of the top stair be 1/3 of the line thickness of the bottom stair.

The actual walking animation is fine IMO,

So, you leave me no choice. Hello to yet another escape adventure!

So Count Bumbley is a brave Englishman that is living in an English castle, and therefore this castle is probably being haunted.

And it is! So meet Eeric, the ghost that has been trapped in the castle library for centuries:

Eeric can only haunt between midnight and 1 o'clock, of course. In order to manage this haunting, he needs a theme, and here it is:

Perhaps Eeric can help Count Bumbley escape further from Lady Anemone's wiles: Bumbley's teamed up with Randy and Larry, and he's left his bedroom, but he hasn't escaped from the castle yet.

Let's hope that I find enough time for all that! 

“486 joined”!

What a pity that I've already just written "Castle Escape" and "Flight from the robots". 

I guess I'm showing my age then, as I'm referring to the "very very original" version.

Might also be a case of regional versions.

I've once researched "Mastermind" in order to find out whether one was allowed to even implement it. I don't really remember all the details. The game has quite a story by now, but the upshot was, as far as I could gather, that the patents have expired: You may implement the game. The trademarks, on the other hand, have not: You may not call your game, "Mastermind". The original company seems to have sold the game to a large game producer at one time. Different kinds of board have been produced at different times and for different markets. The oldest version, as I understood, was the one with a four-places code and a "square" arrangement for the feedback. Our family had one with a "line" arrangement for feedback. The piece of paper with the rules has gone lost.

Part of the problem isn't in the register architecture itself but in the compiling concept, which is everything but optimal.

Crimson's first example is comparing two values:

Code: ags

PUSHREG ax         <--- copy first value from Ax register to stack
LITTOREG ax, arg2  <--- copy second (literal) value to Ax register
POPREG bx          <--- copy first value from stack to Bx register
LESSTHAN bx, ax    <--- compare first value to second and store boolean result in Bx register
REGTOREG bx, ax

• Lines 1 and 3 are clumsy because they are equivalent to moving AX to BX, for which an instruction already is in the instruction set.
• Line 5  would be superfluous if the compiler could simply keep track of the fact that the expression result happens to be in BX this time instead of enforcing that it must always end up in AX no matter what.
• And the whole construct could be simplified if we simply kept the first value in AX, where it is fine already, and loaded BX with the second value.
  

Code: ags

LITTOREG bx, arg2
LESSTHAN ax, bx

The instructions are all in the instruction set already. You can't blame that on the instruction set, that's all on the compiling concept.

The compiler makes no attempt to keep track of what registers are currently loaded with values we will need and what registers may safely be clobbered.
The compiler insists that all expression results must always end up in AX,

• even though BX to DX are available, too, and especially CX and DX are idling most of the time
• even though a good portion of "expression results" are in the memory pointed to by MAR, with MAR already loaded correctly, which is good enough for keeping track of them, and
• even though a portion of "expression results" are literals or constants known at compile-time and so really needn't be stored anywhere before they are used.

By the bye, concerning the second example in your post you reference: Allocating an integer variable.

Code: ags

LITTOREG ax, arg2  <--- copy the literal number (initial value) to Ax register
REGTOREG sp, mar   <--- copy stack ptr address to memory address register (MAR)
MEMWRITE ax, mar   <--- write value from Ax register to where MAR points to (here - stack ptr)
ADD      sp, arg2  <--- advance stack ptr by N bytes (4, if that was integer), thus completing new local variable

The fastest way to do this with the current instruction set is to simply PUSH the initial value onto the stack (and keep track offline that the memory block on stack has increased by 4 bytes, which you need to do in any case). I think that's what the new compiler does right now.

Code: ags

LITTOREG ax, arg2 
PUSHREG ax

[we]

That we emulate the technological limits of an x86 processor is a bit of make-believe.

For instance, we compile for exactly 8 registers. In the x86 processor, there might indeed be exactly 8 memory addresses that are particularly fast to access. But the virtual machine that we provide isn't fundamentally limited in that way. We only pretend that. Our registers are just a constant-size array. We could equally provide 64 or 2048 "register" addresses without losing any efficiency whatsoever.

In the same vein, we pretend that we can only do conditional jumps that are dependent on the AX register but not on the BX register. But our virtual machine doesn't have that limit really. It's about just as efficient to do (if REGISTERS[0] == 0) as it is to do (if REGISTERS[1] == 0).

If the x86 instruction set is indeed a bottleneck, we could gradually extend it and gradually make the compiler prefer the added instructions to the inefficient ones. But perhaps it may be the other way round: The original x86 instructions might be emulated efficiently, and the instructions that have been added to this set might be the inefficient culprits. Or perhaps neither is very inefficient, and we're barking up the wrong tree entirely.

[not]

If there's clamour for it, I can introduce a 'class' keyword to the compiler. OTOH, we can achieve a similar effect as far as this is concerned by simply saying #define class struct.

But that's only half the fun with classes.

What you'd expect from classes is constructors and destructors and stuff. Also, unless you have grown up with 'C' style languages, True Inheritance for functions and attributes: For instance let Car inherit from Vehicle: When a Vehicle pointer v actually points to a car at runtime then the expression 'v.Accelerate()' should by default call 'Car.Accelerate()', not 'Vehicle.Accelerate()'.

We can't get that sort of thing from a simple renaming.
To the contrary, renaming 'class' to 'struct' might raise expectations that we can't yet fulfill.

The placement of the tags doesn't match the placement of the symbols. […]

Ooooh, I didn't know that. I suddenly realize that my brothers and I have been playing Mastermind with bad rules as children  :-[  .

Even though I don't think it's mentioned in the rules, […]

As far as I know, the very very original Mastermind had a board like that:
O O O O  oo
         oo
                   
O O O O  oo
         oo
(and so on.)

The left holes are for the guesses, the right holes for feedback. In this arrangement the assumption doesn't suggest itself that there might be a one-to-one correspondence between guess positions and feedback positions. So this might be the reason that the rules don't state explicitly that there shouldn't be.

The arrangement that we all know today only came later.
O O O O   o o o o
O O O O   o o o o
O O O O   o o o o
(and so on)

Dunno. It makes for a less long board, maybe?

OTOH, I don't do Discord, so I might contribute a submission, but there's nothing where I could sign up beforehand.

So if a submission comes, expect it to be a huge surprise.